One API Key for Every Coding Agent: Claude Code, Codex, OpenCode and Crush

Most developers end up with two or three coding agents installed: one for the terminal, one in the editor, one they're trying out. Each wants its own provider settings in its own file format. This tutorial shows how to use one API key for every coding agent with the Tokens CLI, which writes the settings for Claude Code, Codex CLI, OpenCode and Crush in a single run, plus the manual settings for editor agents it doesn't touch.

curl -fsSL https://tokens.bd/cli/tokens.mjs -o tokens.mjs
node tokens.mjs setup --base-url https://tokens.bd

What the setup command does#

The CLI is one JavaScript file with no dependencies. It needs Node.js 18 or newer. Because you're downloading a script that edits config files in your home directory, open tokens.mjs and skim it before running it. It's short enough that this takes a few minutes, and that's a good habit with any script you fetch with curl.

Running setup goes through these steps:

1. Sign in. Without --key, it starts a device login: it prints a code like ABCD-EFGH and opens your browser at /dashboard/connect/cli, where you check the code matches and approve. Approving creates a new key named CLI (<label>), where the label describes your machine. With --key tok_live_... it skips this and uses that key.
2. Read the gateway config. It fetches https://tokens.bd/api/gateway/config to learn the OpenAI-compatible base URL (https://tokens.bd/v1) and the Anthropic-compatible one (https://tokens.bd).
3. List your models. It calls GET /v1/models with the key. If the list is empty, it stops and tells you to subscribe or add funds first, since a key with no models available would configure agents that can't do anything.
4. Pick a default model. It shows the first ten models and asks for a number. To choose a model further down the list, pass it directly with --model.
5. Save your credentials to ~/.config/tokens/credentials.json with mode 600 (on Windows, %APPDATA%\tokens\credentials.json).
6. Detect agents. An agent counts as installed if its config directory exists or its binary is on your PATH.
7. Show the plan. It lists every file it's about to change and asks Continue? [Y/n].
8. Back up, then write. Each existing file is copied to <file>.tokens-backup-<timestamp> before it's changed. Settings are merged into what's there; your other providers and options stay.

If a file has comments or a format the CLI can't parse safely, it skips that file, says so, and points you to the copy-and-paste snippet at /dashboard/connect?agent=<id> instead of guessing.

Flags for a controlled run#

node tokens.mjs setup --base-url https://tokens.bd \
  --model deepseek/deepseek-v4.1-flash \
  --agents claude,opencode \
  --dry-run

Two behaviours worth knowing. A dry run doesn't save credentials or touch agent files, but without --key it still runs the browser sign-in, and approving that creates a key. If you want a dry run that creates nothing, pass an existing key with --key. And when there's no terminal to answer the prompt (a script, a CI job), the confirmation defaults to no; add --yes when you mean it.

What changes in each agent's config#

Claude Code#

Claude Code uses the Anthropic Messages format, so its base URL is https://tokens.bd without /v1; Claude Code adds /v1/messages. The CLI sets only the three core variables. If you want the opus, sonnet and haiku aliases or subagents on specific models, add ANTHROPIC_DEFAULT_*_MODEL and CLAUDE_CODE_SUBAGENT_MODEL yourself. Running Claude Code with other models explains why that's worth doing and what Anthropic doesn't support.

Codex CLI#

Codex reads its key from an environment variable, so the CLI writes no secret into config.toml. It adds a block between two marker comments (# >>> tokens ... and # <<< tokens <<<), and running setup again replaces that block in place:

[model_providers.tokens]
name = "Tokens"
base_url = "https://tokens.bd/v1"
env_key = "TOKENS_API_KEY"
wire_api = "responses"

[profiles.tokens]
model = "deepseek/deepseek-v4.1-flash"
model_provider = "tokens"

Then export the key and start Codex with the profile:

export TOKENS_API_KEY="tok_live_your_key"
codex --profile tokens

The profile leaves your default Codex setup alone; plain codex still uses whatever it used before. If your Codex version doesn't pick up the profile, set model and model_provider = "tokens" as top-level keys at the start of config.toml instead.

Codex only speaks the OpenAI Responses API, so it calls POST /v1/responses. Whether that works depends on the upstream behind the model. If Codex errors on a model, test the same model with a direct curl to /v1/responses (the Responses docs have one) before changing Codex settings. If another [model_providers.tokens] table already exists outside the managed block, the CLI skips the file rather than produce invalid TOML.

OpenCode#

The CLI adds a tokens provider using @ai-sdk/openai-compatible and sets the default model to tokens/<model id>. It writes the key into the file as options.apiKey. If you keep opencode.json in a dotfiles repo, change that to "{env:TOKENS_API_KEY}" and export the variable instead. Also add limit.context and limit.output for the model; the CLI doesn't, and OpenCode needs them for compaction to work well.

Crush#

The CLI writes a tokens provider into crush.json with a placeholder context window of 128,000 and default_max_tokens of 8,192. Adjust both to the model's real limits from the catalog. Crush's newer configuration format is a crushrc file of shell-style commands, and the project now describes crush.json as supported but deprecated. If you've already moved to crushrc, add the provider there:

provider add tokens --type openai-compat --name "Tokens" \
  --base-url "https://tokens.bd/v1" --api-key "${TOKENS_API_KEY:?set TOKENS_API_KEY}"

Windows#

The PowerShell version of the install line:

iwr https://tokens.bd/cli/tokens.mjs -OutFile tokens.mjs; node tokens.mjs setup --base-url https://tokens.bd

Everything else behaves the same, with Windows paths: credentials go to %APPDATA%\tokens\credentials.json, Claude Code's settings are at %USERPROFILE%\.claude\settings.json. Mode 600 is a Unix permission, so on Windows the credentials file is protected by your user profile's normal access rules. For Codex, the CLI prints a setx TOKENS_API_KEY "..." line. setx saves the variable for new terminals but not the one you're in, so open a new window before running codex --profile tokens.

Undo, log out, check usage#

To revert one agent, copy its backup over the file. The backups sit next to the originals, named <file>.tokens-backup-<timestamp>.

node tokens.mjs logout deletes the saved credentials file on this machine. It doesn't disable the key, and the agent config files still contain it (except Codex's). To actually stop the key working, revoke it under API keys.

Two more commands are handy day to day. node tokens.mjs models lists the model IDs your key can call. node tokens.mjs usage prints your plan, usage windows as bars, wallet balance and the key's cap; add --json for the raw response from GET /v1/tokens/usage.

Editor agents: Cline, Kilo Code, Continue, Zed#

The CLI doesn't touch editor extensions, but all four take the same three values: base URL https://tokens.bd/v1, your key, and a model ID.

• Cline: in settings, set API Provider to "OpenAI Compatible", then fill in Base URL, API Key and Model ID. Under Model Configuration, set the context window and max output tokens to the model's real limits.
• Kilo Code: Providers tab, then Custom provider. Provider ID tokens, Provider API "OpenAI Compatible", the base URL and key. Models can be fetched from /v1/models or added by hand. Kilo also reads a kilo.json in the same format as OpenCode's.
• Continue: add a model to ~/.continue/config.yaml with provider: openai, apiBase: https://tokens.bd/v1, the model ID, and capabilities: [tool_use] so Agent mode works.
• Zed: add a provider under language_models.openai_compatible in settings.json with api_url and available_models. The key doesn't go in settings.json; enter it in the Agent Panel or set TOKENS_API_KEY (Zed derives the variable name from the provider name).

name: Tokens
version: 0.0.1
schema: v1
models:
  - name: DeepSeek V4.1 Flash (Tokens)
    provider: openai
    model: deepseek/deepseek-v4.1-flash
    apiBase: https://tokens.bd/v1
    apiKey: ${{ secrets.TOKENS_API_KEY }}
    roles: [chat, edit, apply]
    capabilities: [tool_use]

Connect your agent in the dashboard has a ready snippet for each of these with your values filled in, and a connection test that sends one small request.

One key everywhere, or one key per agent?#

One key across all your agents is the least setup, and for interactive use, where you're watching every request, it's fine. The trade-off is that spend caps and allowed-model lists belong to a key, and they can't be edited once the key exists. As soon as one of your agents runs unattended or in CI, give it its own key with its own cap, so a runaway loop there can't eat the budget your editor depends on. Active keys are limited by your plan (three by default), so plan the split: one shared key for interactive tools and one per unattended agent is a reasonable starting point. Spend caps for coding agents walks through setting that up.

If you're ready, download the script, read it, and run setup with --dry-run first. The Tokens CLI docs are the reference for every flag.

Third-party agent configuration details checked on 2026-10-03.

Sources: https://code.claude.com/docs/en/llm-gateway-connect · https://learn.chatgpt.com/docs/config-file/config-advanced · https://opencode.ai/docs/providers/ · https://github.com/charmbracelet/crush · https://docs.cline.bot/provider-config/openai-compatible · https://kilo.ai/docs/providers/openai-compatible · https://docs.continue.dev/customize/model-providers/top-level/openai · https://zed.dev/docs/ai/use-api-access