A single endpoint for a Claude Code session

Pointing Claude Code at a custom endpoint changes where its requests go, not the basic rhythm of working in a repository. You still inspect files, propose edits, and run checks. The useful comparison is between two request paths: Claude Code using its usual Anthropic connection, and Claude Code sending requests through Vana API.

The distinction matters because an endpoint address alone does not establish compatibility. Authentication, message format, model identifiers, and tool behavior all need to line up.

§ The connection: default service or explicit gateway

Direct connection: Claude Code uses its normal authentication and service configuration. Depending on your setup, that may involve an account login or API credentials. There is no additional gateway operator between the client and the model provider.

Vana API connection: You explicitly direct Claude Code to https://api.vanaapi.com. Vana API supports the Anthropic Messages protocol as well as OpenAI-compatible and Gemini native protocols. For Claude Code, the Anthropic-compatible interface is the relevant one; OpenAI compatibility alone would not be sufficient.

This gives you one API destination without requiring every client to speak the same protocol. It does not make every model interchangeable inside every client.

§ The setup: existing authentication or scoped variables

Direct connection: Leave the endpoint override unset and use your established Claude Code authentication. Before changing anything, note whether your current session relies on a login, an API key, or shell configuration.

Vana API connection: Set ANTHROPIC_BASE_URL to https://api.vanaapi.com for the shell or process that launches Claude Code. Use the gateway's documented authentication method with your Vana API credential. Claude Code supports ANTHROPIC_AUTH_TOKEN for bearer-token authentication and ANTHROPIC_API_KEY for API-key authentication; these are different mechanisms, not interchangeable labels.

Create a Vana API account to obtain a credential, then check its current Claude Code setup instructions for the appropriate authentication variable.

Start with a temporary terminal session rather than a permanent shell profile. Avoid leaving competing credentials active, do not put secrets in repository files, and restart Claude Code after changing the environment. An already-running process will not inherit later shell changes.

§ The model: a familiar choice or a routed identifier

Direct connection: Model selection follows the choices and identifiers supported by your Claude Code installation and provider account.

Vana API connection: Select an identifier that Vana API accepts and that is suitable for Claude Code. If you want Claude Sonnet 5.5, for example, use the exact API identifier in the current model listing rather than deriving one from its display name.

A single endpoint can relay multiple model families, but availability is not proof of full coding-agent compatibility. Check streaming, tool calls, context limits, and any secondary model requests your client makes. Keep the model constant during your first comparison so that routing changes are not confused with model differences.

§ The bill and the data path

Direct connection: Usage and charges follow your existing provider arrangement. Your requests follow that provider's service path and applicable policies.

Vana API connection: Vana API bills per real token with no monthly fee. This is a different billing arrangement, not a guarantee that a given task will cost less. Compare recorded usage and actual charges rather than assuming identical token accounting across services.

The gateway also becomes part of the data path. Before using a private repository, review the applicable retention, logging, and upstream-processing policies. A custom endpoint is not evidence of local execution or zero retention.

§ A small comparison before making it permanent

Run the same modest repository task through each connection: inspect a file, request one edit, and execute a relevant test. Compare the patch, tool execution, latency, errors, and usage record. Confirm that requests appear in the intended account.

If the routed session behaves as expected, save the configuration in your preferred local environment. If it does not, remove the overrides and return to the original connection. Keeping the first experiment narrow makes both the result and the rollback easier to understand.