Skip to main content
Aixy implements the native Anthropic Messages contract used by Claude Code. Requests still use a project-scoped Aixy API key, so model policy, guardrails, budgets, routing, and usage attribution remain attached to the selected project.

​
Configure Claude Code

Create an API key for the project, connect your Claude provider, and publish model aliases for the exact Claude IDs used below. Export:
Do not add /v1 to ANTHROPIC_BASE_URL; Claude Code appends /v1/messages. For a self-hosted instance, replace the host with its public gateway URL. All three defaults are set because Claude Code can select different model classes internally. You can replace each value with a different Claude model available to the project. Exact Claude API IDs let the client recognize each model’s capabilities while the alias chooses its configured provider and region. The aliases must already resolve in Aixy; the gateway does not guess their destinations. The discovery setting adds the project’s available Claude IDs to /model on supported Claude Code versions. Aixy’s organization and project blocks determine access; restart Claude Code to refresh its picker after changing the catalog. Discovery does not remove Claude Code’s built-in entries. Start Claude Code normally:
ANTHROPIC_AUTH_TOKEN sends the Aixy key as a Bearer token. Anthropic SDKs that use x-api-key can send the same gak_ value without changing its project scope.

​
Choose models

If an administrator publishes the exact model IDs your Claude Code version sends as model aliases, you can retain Claude Code’s model selection and configure only ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. Create routes for the models used by your main session and internal tasks, and confirm each destination’s capabilities. Unknown IDs remain unavailable; aliases do not add capabilities to the destination. Provider-qualified Claude identifiers from Models, for example anthropic/claude-sonnet-4-5, are also usable. A client may not recognize a provider-qualified or custom ID’s capabilities; discovery lists IDs but does not configure the client’s thinking or effort defaults. Prefer exact Claude API aliases for the initial setup, or provide the client’s documented model mapping. Choose a native Anthropic connection for Claude-specific capabilities. Aixy also supports translated conversations, whose supported fields depend on the execution contract; verify the features your Claude Code workflow needs on every target of a routing alias. For Bedrock Runtime, Aixy selects the reviewed Messages transport automatically for each exact model or profile. Administrators can block or allow entries in Models, including individual inference profiles, without changing the gateway adapter. A new upstream model needs a reviewed execution contract before it becomes usable. For a Bedrock deployment, distribute CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 with the client configuration to avoid requesting Anthropic pre-release capabilities the upstream may not offer. This is a deployment preference, not a per-model gateway rule. It also disables some experimental client features; model discovery and ordinary Messages/tool exchanges remain available. When using an opaque routing alias, use Claude Code’s modelOverrides setting to associate it with the intended Claude model’s capabilities. Exact published Claude IDs avoid that extra mapping.

​
Verify the connection

Aixy’s token counting depends on the destination; a reviewed Messages route alone does not promise token counting for a Bedrock profile. Claude Code uses an estimate when counting is unavailable. On native Anthropic routes, streaming Messages events and provider error bodies are passed through without response reconstruction. Inspect the request in Activity after testing from Claude Code. See Anthropic’s LLM gateway contract for Claude Code’s upstream protocol details.