Setting up Codex CLI, Claude Code, Cursor, and a terminal assistant can mean managing four integrations: four keys to create, four places to paste an endpoint, four sets of settings that drift apart. One API key for multiple AI models, served from a single OpenAI-compatible endpoint, removes most of that work. Each tool keeps its own config file, but the values stop changing from tool to tool: one base URL for OpenAI-style clients, one entry point for Claude Code, one key to rotate.
This guide works through four configuration surfaces using String AI's endpoints as the example: the endpoint contract, the three mistakes that break setups most often, and a verification routine to run before pointing any agent at your code.
Why four tools become four integrations
The friction rarely shows up in model benchmarks. It shows up in the onboarding document: create an account, generate a key, find the settings screen, paste an address, restart the client, hope the model names match. When a key needs rotation, the update list has grown again. When you want to try another model, you re-check every tool to see whether it follows.
Each coding tool ships its own authentication flow and assumptions about where models live. For a while those assumptions pointed at the vendor's own account. That has changed: Codex CLI supports custom model providers, Claude Code treats gateway setups as a first-class workflow, Cursor exposes a base URL override, and utilities like CC Switch coordinate the resulting settings. A shared access layer is now a normal configuration; the work is knowing which fields each tool reads.
The contract behind one API key for multiple AI models
When a tool talks to an OpenAI-compatible endpoint, it relies on a small contract:
- Authentication. Every request carries a bearer token in the Authorization header. One key covers every tool that can present it.
- Routes under /v1. Chat completions handles conversations, and a models list at /v1/models reports what the key can access. That route doubles as a connectivity check.
- Streaming. With stream set to true, the endpoint returns server-sent events, and the request should carry Accept: text/event-stream. CLI tools use this to display answers as they arrive.
- Tool calls. Agent-style clients send tool definitions and act on structured calls in the response. Without tool-calling support, an agent can chat but cannot reliably edit files or run commands.
One nuance shapes everything that follows: clients do not all speak the same dialect of that contract. Some expect the classic chat completions shape; Codex CLI is built around the Responses API and declares this with wire_api = "responses". The endpoint must serve the dialect the client sends, which is why "works with every tool" deserves scrutiny in both directions.
String AI's documentation exposes two entry shapes: the OpenAI-compatible base URL https://www.string.ink/v1 for OpenAI-style clients, and the site root https://www.string.ink, no /v1 suffix, for Claude Code's gateway variables. Beyond chat, the documented interfaces include text and vision inputs, image generation and editing, and the models list, so one key stretches past the four tools here.
Codex CLI: a custom model provider in config.toml
Codex CLI and the Codex extension for VS Code read one file: ~/.codex/config.toml. The setup has two parts, a provider block that describes the endpoint and lines that select the provider and model.
model_provider = "OpenAI"
model = "gpt-6-astra"
[model_providers.OpenAI]
name = "OpenAI"
base_url = "https://www.string.ink/v1"
wire_api = "responses"
requires_openai_auth = truemodel_provider names the provider Codex should use. Inside the provider block, base_url is the endpoint, wire_api = "responses" declares the protocol, and requires_openai_auth = true says the provider authenticates with OpenAI-style credentials. Keep the provider name identical in both places; Codex reserves a few built-in IDs, including lower-case openai, which is why the block uses OpenAI. The Codex configuration reference documents every field shown here.
Credentials live next to the config, in ~/.codex/auth.json:
{
"OPENAI_API_KEY": "YOUR_STRING_AI_KEY"
}Restart Codex, or your editor, after saving. The platform documentation lists gpt-6-astra, gpt-5.6-sol, and gpt-5.6-luna as the model IDs available on this path, and includes a one-click script for Windows PowerShell that writes both files for you. One migration note: if you previously signed in through an OAuth session, older conversations may not appear under the new provider until you run the included migration script, which supports a dry run first.
Claude Code: ANTHROPIC_BASE_URL and the credential pair
Claude Code speaks Anthropic's protocol rather than OpenAI's, so it reads a different pair of variables:
export ANTHROPIC_BASE_URL="https://www.string.ink"
export ANTHROPIC_AUTH_TOKEN="YOUR_STRING_AI_KEY"Notice what is missing: the /v1 suffix. Every OpenAI-style field in this guide ends at /v1; this one stops at the root, because Claude Code appends its own paths to the base URL you declare.
The credential variable deserves the same care. Anthropic's gateway documentation draws a line between ANTHROPIC_AUTH_TOKEN, which sends the key as a bearer token in the Authorization header, and ANTHROPIC_API_KEY, which sends it in an x-api-key header. The wrong variable delivers the credential in a header the other side is not reading, and the symptom is a 401. The String AI documentation directs Claude Code users to ANTHROPIC_AUTH_TOKEN.
Two practical notes from the platform docs. Create the key in the Claude API group when you generate it; a key from another group will not connect through the Claude API channel. And when the variables are managed through CC Switch, the same page also sets CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC to 1 and CLAUDE_CODE_ATTRIBUTION_HEADER to 0.
After launch, run /status inside Claude Code. The status view shows the Anthropic base URL when a gateway address is set, and names the active credential source. If it reads ANTHROPIC_AUTH_TOKEN, the gateway credential is in charge rather than a leftover login.
CC Switch: one Universal Provider for the toolbox
CC Switch is a desktop application that manages provider settings and sessions for Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw, Hermes, and other tools in one place. Configure the endpoint once, then switch tools to it.
The relevant section is the Universal Provider tab. Add a provider with four values:
- Name: String AI, or anything you will recognize later
- Base URL: https://www.string.ink/v1
- API Key: your String AI key
- Default model: gpt-6-astra
Run the built-in Health Check, and migrate your tools only after it passes. With no files to edit by hand, this is the least error-prone of the four surfaces. One caveat applies throughout: most tools read provider settings at startup, so restart the terminal or CLI after switching.
Cursor: flip the OpenAI base URL override
In Cursor, open the settings screen (the gear icon), select Models, and expand the API Keys section. Paste the key into the OpenAI API Key field, turn on Override OpenAI Base URL, and enter https://www.string.ink/v1. The override toggle is the step people skip; without it, the key sits in settings while Cursor keeps calling its default endpoints. Cursor's documentation describes the same fields.
Model IDs go in exactly as the platform lists them: the request leaves your machine with the string you typed, and a mismatch comes back as model-not-found rather than a helpful suggestion.
Three mistakes that break the setup
Most broken configurations trace back to one of these.
1. The /v1 convention is not universal. OpenAI-style fields (Codex's provider block, CC Switch's Universal Provider, Cursor's override) take https://www.string.ink/v1. Claude Code's ANTHROPIC_BASE_URL takes the site root with no suffix. Clients append their own path segments to whatever you give them, so the wrong convention surfaces as a 404, or as an authentication error that sends you debugging the key instead of the URL. Learn the pair once: /v1 for OpenAI-shaped fields, bare root for Claude Code.
2. Credential variables are not interchangeable. API key and auth token are distinct variables in Claude Code, and Codex reads its key from auth.json rather than from config.toml. Where several sources exist, know which one wins. Anthropic's documentation notes that when a shell export and a settings-file env block set the same variable, the settings-file value applies, and that a gateway credential takes precedence over a saved login. The Codex installer script from the platform docs makes a friendlier promise: it prefers a STRING_AI_API_KEY variable when one exists and deliberately ignores any OPENAI_API_KEY left over from other tools, so a stale key cannot silently take over. Change one source at a time, and restart the client. If you keep an OPENAI_API_KEY export for other software, do not assume Codex picks it up; on this setup the key lives in auth.json.
3. Model IDs are exact strings. The platform documentation uses identifiers such as gpt-6-astra, gpt-5.6-luna, and claude-opus-4-8. Whatever you configure must match the platform's current list exactly. A typo, or a name borrowed from another provider, returns model-not-found, which is a string mismatch, not a broken endpoint.
Verify small, then split failures in two
Catch problems at the HTTP layer before any agent touches your codebase. The platform docs suggest starting with the models route:
curl https://www.string.ink/v1/models \
-H "Authorization: Bearer YOUR_STRING_AI_KEY"A response with object: "list" and a data array means three things at once: the key is valid, the base URL is right, and the network path is open. Nothing about your editor is proven yet, which is the point; once this level checks out, later failures almost certainly belong to the client configuration. A single minimal chat completion is a reasonable second step.
For Claude Code, the equivalent is the /status view described above plus one test prompt; Anthropic's documentation includes a one-token request against the gateway for the same purpose.
When something still fails, classify it before touching anything:
- 401: the credential was rejected. Check which variable the client sends, the key's group, whether a settings file overrides your shell export, and whether the client was restarted.
- model-not-found: authentication succeeded and the ID did not. Compare against the models list instead of guessing at spellings.
- Protocol errors, such as streams that never start or tool calls that never arrive: the client and endpoint disagree about the dialect described earlier. Check the client-side protocol setting, then the tool's page in the platform documentation.
Split that way, configuration problems stay with the client, and contract problems go to whoever runs the endpoint.
Where the shared-endpoint approach stops
Two boundaries keep this honest. First, compatibility is a property of a client and an endpoint together, not a slogan. A tool that speaks a protocol the endpoint does not serve will not be rescued by a base URL field, which is why Claude Code gets its own entry point and Codex declares a wire protocol. Before adding a fifth tool, check that its protocol appears in the platform's tool list.
Second, client configuration is versioned software. Field names move and screens get redesigned, so treat the platform documentation and each tool's own docs as the live references; read this article for the shape of the setup: one key, two URL conventions, one verification loop.
Start with one key, then migrate one tool at a time
The sequence that avoids rework: create the key, keeping the Claude API group in mind if Claude Code is on your list. Run the models check once. Configure whichever tool you use most, verify it on a real task, then move through the rest in the same order. Keep a short note in the team wiki with the two URL conventions and where the key lives; those are the details that would otherwise cost the next person an afternoon.
Related reading
- Stop asking every AI model to do everything: assigning research, writing, and review to different models without adding coordination work.
- Developer articles: setup guides and integration notes for the platform.
- Downloads: installers for the desktop apps and launcher.
- FAQ: account-level questions, including key groups.