One API key in two coding tools

Agents at the terminalEN2026-10-26

Switching between Claude Code and Codex can leave you managing more accounts and credentials than you expected. Each tool has its own settings, and each needs a way to authenticate its requests. Those credentials can come from the same place.

With Vana API, you can use one API key in both tools. Claude Code and Codex remain separate applications, but their model requests go through the same service. That gives you a shared account for API usage while letting you choose the tool that suits the work in front of you.

§ What the shared key does

An API key is a secret credential. When a coding tool sends a request, the key tells the service which account should pay for it. Think of it as permission to use that account’s API balance.

Using the same key in Claude Code and Codex means configuring each application to authenticate with Vana API. It does not connect their conversations, share their memory, or copy settings between them. A session in Claude Code stays separate from a session in Codex.

The shared part is access and billing. You still decide which project to open, which model to select, and which actions each tool may take.

§ One service, different request formats

Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com. It also supports the Anthropic Messages and Gemini native protocols. These are different formats for sending instructions to a model and receiving its answer.

This matters because coding tools do not all communicate in the same format. Claude Code uses the Anthropic interface, while Codex needs its own provider configuration. Vana API handles those connections through one service, so you can keep the same credential without expecting both tools to have identical settings.

The model choice remains separate, too. You might select Claude Sonnet 5.5 for a Claude Code session and GPT-6 Astra for a Codex session, using the model identifiers provided by Vana API. A shared key does not make every model interchangeable across every tool.

§ Setting up the two tools

To begin, create a Vana API account and generate an API key. Treat the key like a password: store it privately and keep it out of project files that might be committed to a repository.

Then configure each tool separately. The exact settings depend on the installed version, but the basic steps are the same:

Choose the API connection. Use each tool’s supported settings for an external provider rather than assuming its existing subscription login will use Vana API.
Set the service address. Use the Vana API configuration instructions for that tool, including any required path after https://api.vanaapi.com.
Supply the key. Give both applications the same Vana API credential through their supported authentication settings.
Select a supported model. Copy the exact model identifier from Vana API, then start a fresh session if the configuration requires it.

For the first check, ask each tool a short question that does not require editing files. Confirm that both return an answer and that their requests appear in your Vana API usage records. This gives you a simple way to check the connection before starting a longer coding task.

§ Understanding the shared bill

Vana API bills per real token, with no monthly fee. Tokens are the units used to measure the text a model processes and generates. Your instructions, supplied code, and the model’s response all contribute to usage according to the selected model’s pricing.

One key does not mean one fixed price for every session. Costs depend on the model and the amount of work sent through it. Begin with small tasks and review usage as you learn how much context each tool sends.

Keep permission settings in mind as well. The API key authorizes model access; each coding tool’s local controls determine whether it can edit files or run commands. Configure those controls independently, even when both tools use the same key.