API docs

Base URLs

Stick to these two forms. Keep /v1 for OpenAI-compatible clients: without it, /chat/completions, /responses, /images/generations, and GET /models still work, but /embeddings returns 404 unknown_route. Anthropic-style clients add /v1 on their own, so a base URL that already ends in /v1 doubles the segment and also returns 404.

Authentication

Use a key created on the API keys page; your Portal sign-in session does not work for API requests. Recommended headers by protocol:

These are recommendations, not requirements: the gateway accepts the same set of authentication headers on every endpoint. With an official client, keep its default behavior.

• Only Authorization strips a Bearer prefix. Adding Bearer to x-api-key or any other header returns 401 invalid_api_key.
• Do not put your key in URL query parameters; proxies and access logs record URLs.
• The gateway sends no CORS headers, and browser OPTIONS preflight requests get a 404. Call the API from your server, and never ship your key in front-end code.
• Keys look like sk-ThinkAPI_…, though older keys may use another format. You can usually copy a key again from the API keys page; some older keys cannot be revealed, so create a new key if you need the full value. Keep your keys private, and disable or delete a key right away if it leaks.

Check your balance

The two self-check commands in this section and the next are free and confirm that your key and base URL are correct. First store your key in the THINKAPI_KEY environment variable, as Connection setup does:

export THINKAPI_KEY='<your-api-key>'

$env:THINKAPI_KEY = '<your-api-key>'

GET /v1/usage returns the amount you can currently spend and this key's credit usage. It works even for a key that has reached its credit limit.

curl -sS "https://api.thinkapi.org/v1/usage" \
  -H "Authorization: Bearer $THINKAPI_KEY"

$headers = @{ Authorization = "Bearer $env:THINKAPI_KEY" }
Invoke-RestMethod -Uri "https://api.thinkapi.org/v1/usage" -Headers $headers | ConvertTo-Json -Depth 5

{
  "balance": 12.5,
  "isValid": true,
  "is_active": true,
  "key": {
    "limited": true,
    "quota_micros": 20000000,
    "remaining_micros": 12500000,
    "used_micros": 7500000
  },
  "quota": {
    "remaining": 12.5,
    "unit": "USD"
  },
  "remaining": 12.5,
  "unit": "USD"
}

• remaining, balance, and quota.remaining hold the same amount: what you can spend right now, in the currency given by unit (your account currency, USD by default). If the key has a credit limit, this is the lower of your account balance and the key's remaining credit; otherwise it equals your account balance, shown as 0 when the balance is negative.
• key.limited: whether this key has a credit limit.
• key.quota_micros, key.used_micros, and key.remaining_micros: the key's credit limit, amount used, and credit remaining, in micros (1,000,000 micros = 1 currency unit). Without a credit limit, key.remaining_micros is 0, which does not mean nothing is left.
• Responses from this endpoint do not include X-Request-Id.

List models

GET /v1/models lists the models currently available to this key's service group. It uses the THINKAPI_KEY variable set above.

curl -sS "https://api.thinkapi.org/v1/models" \
  -H "Authorization: Bearer $THINKAPI_KEY"

$headers = @{ Authorization = "Bearer $env:THINKAPI_KEY" }
(Invoke-RestMethod -Uri "https://api.thinkapi.org/v1/models" -Headers $headers).data | Select-Object id, owned_by

{
  "object": "list",
  "data": [
    {
      "id": "<model-id>",
      "object": "model",
      "owned_by": "anthropic",
      "display_name": "<model name>"
    }
  ]
}

• The format does not depend on the protocol you use: it is always the OpenAI-style list above. owned_by, display_name, and description may be omitted.
• Results are filtered by the key's service group, so moving the key to another group changes the list. See Models & pricing for prices and supported protocols.
• It is free and works even when your account balance is negative.
• It lists the models the platform has synchronized and enabled. It does not query upstream providers, so it answers quickly, and it reflects the platform's latest synchronization rather than live upstream state, so do not use it as a health check. If the model list cannot be read, it returns 502 models_unavailable.

Claude Code: recommended setup

Claude Code connects through two environment variables: set ANTHROPIC_BASE_URL to https://api.thinkapi.org and ANTHROPIC_AUTH_TOKEN to your API key. Do not add /v1 to the URL: Claude Code appends /v1/messages itself, so another /v1 duplicates the path and returns 404.

We recommend putting both in your user settings file, ~/.claude/settings.json (%USERPROFILE%\.claude\settings.json on Windows). If the file already exists, merge the two keys into its env block instead of replacing your other settings. Save it and start a new Claude Code session.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.thinkapi.org",
    "ANTHROPIC_AUTH_TOKEN": "sk-ThinkAPI_xxxxxxxx"
  }
}

Why this setup:

• Values in a settings file's env block take precedence over shell variables of the same name, and background agents may not inherit shell variables, while the settings file reaches them too.
• ANTHROPIC_AUTH_TOKEN is sent as an Authorization: Bearer header and takes effect without a confirmation prompt.
• You can use ANTHROPIC_API_KEY instead. It is sent as an x-api-key header, which the gateway also accepts, but interactive mode asks you to approve it once.

• Do not put your key in a project's .claude/settings.json; that file is usually committed to the repository.
• A project's .claude/settings.json and .claude/settings.local.json, and managed settings from your administrator, take precedence over user settings, so leftover variables such as ANTHROPIC_BASE_URL there override yours. Use /status to see the URL and credential in effect.

Claude Code: environment variables, VS Code and desktop

To try it in the current terminal only, set environment variables as the official docs show. They last for that terminal session, and values in a settings file override them.

export ANTHROPIC_BASE_URL=https://api.thinkapi.org
export ANTHROPIC_AUTH_TOKEN=sk-ThinkAPI_xxxxxxxx
claude

$env:ANTHROPIC_BASE_URL = "https://api.thinkapi.org"
$env:ANTHROPIC_AUTH_TOKEN = "sk-ThinkAPI_xxxxxxxx"
claude

VS Code extension: run Preferences: Open User Settings (JSON) from the Command Palette and add claudeCode.environmentVariables. The extension's own sign-in check does not read ~/.claude/settings.json, so with only that file it may still ask you to sign in.

{
  "claudeCode.environmentVariables": [
    { "name": "ANTHROPIC_BASE_URL", "value": "https://api.thinkapi.org" },
    { "name": "ANTHROPIC_AUTH_TOKEN", "value": "sk-ThinkAPI_xxxxxxxx" }
  ]
}

The Code tab in the Claude desktop app does not take its gateway settings from ANTHROPIC_BASE_URL or ~/.claude/settings.json. Open Help → Troubleshooting → Enable Developer Mode, then Developer → Configure Third-Party Inference. In Connection, set Inference provider to Gateway, enter https://api.thinkapi.org as the Gateway base URL and your API key as the Gateway API key, and leave the rest at their defaults. If your administrator has distributed a configuration, the form is read-only.

Claude Code: choosing a model

Claude Code does not switch to your group's models on its own, and its default model may not be in your group. Choose a model in one of these ways, copying the model ID exactly as shown on Models & pricing or returned by List models:

• Run /model in a session and pick or enter the model ID.
• Pass it at startup: claude --model <model-id>.
• Make it the default: add ANTHROPIC_MODEL to the env block in ~/.claude/settings.json, as in the example below. If CC Switch manages that file, edit the provider in CC Switch instead; see Importing into Claude Code.

Optional: set CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY to 1, and Claude Code asks the gateway for your group's models at startup and adds them to the /model list. Note that:

• Only models whose ID contains claude or anthropic are listed.
• The gateway answers from the models the platform has synchronized, usually well within the default 3-second timeout. On a timeout, Claude Code silently falls back to the previously cached list or its built-in list; on a slow network, raise the timeout with CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS (in milliseconds; requires Claude Code v2.1.269 or later).
• It only adds entries; it does not change the default model.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.thinkapi.org",
    "ANTHROPIC_AUTH_TOKEN": "sk-ThinkAPI_xxxxxxxx",
    "ANTHROPIC_MODEL": "<model-id>",
    "CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY": "1",
    "CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS": "10000"
  }
}

Model IDs with a [1m] suffix, such as <model-id>[1m], also work, and Requests shows the ID without the suffix. Whether you actually get a 1M-token context depends on the model, group and upstream provider, and is not guaranteed.

Claude Code: checking the setup

1. Run /status in Claude Code and check that it shows an "Anthropic base URL" line with https://api.thinkapi.org and an "Auth token" line.
2. Send a real message, then find the request by time and model in Requests and check its status and cost.

Common errors: 403 non_client_disabled (shown as "Please upgrade your Claude client."), 400 unsupported_client_platform, and 400 unsupported_client_feature or unsupported_client_profile are covered in Client restrictions by group. For 401 (invalid key) and 402 (insufficient balance), see Error codes.

Codex: surfaces and setup options

This applies to the Codex CLI and the Codex IDE extension (openai.chatgpt) in VS Code, Cursor and Windsurf. Codex in the ChatGPT desktop app reads the same configuration. Codex cloud, /cloud delegation and Realtime voice do not go through ThinkAPI.

Put the settings in your user-level ~/.codex/config.toml (%USERPROFILE%\.codex\config.toml on Windows; a CLI running in WSL uses the Linux ~/.codex, which is not shared with Windows). Provider-related keys in a project's .codex/config.toml are ignored, so do not put them there. Top-level keys such as model must come before any table header, such as [model_providers.thinkapi].

If in doubt, use option 1. Both options need the model ID filled in by hand; see Codex: models, checks and troubleshooting.

Codex option 1: API key sign-in

Add these three lines at the top of ~/.codex/config.toml, before any table header. If the file already has a model, openai_base_url or forced_login_method line, change its value instead of adding another line; a duplicate key stops Codex from starting. If you have ever picked a model with /model, the file usually has a model line already.

model = "<model-id>"
openai_base_url = "https://api.thinkapi.org/v1"
forced_login_method = "api"

Then sign in with your API key. Store the key in the THINKAPI_KEY environment variable as shown in Check your balance, then run:

printenv THINKAPI_KEY | codex login --with-api-key

$Env:THINKAPI_KEY | codex login --with-api-key

The official docs have no PowerShell example; this version passes the key through standard input in the same way. If you see No API key provided via stdin., THINKAPI_KEY is empty. You can also sign in without the command line: in the IDE extension, choose "Use API Key" on the sign-in screen; in the desktop app, choose "Sign in another way"; then paste your key.

To keep your ChatGPT sign-in in the CLI as well, create a separate directory for ThinkAPI to use as CODEX_HOME (the directory must already exist), put the three lines above in the config.toml inside it, sign in with that CODEX_HOME, and pass it every time you start Codex. In this setup, leave ~/.codex/config.toml unchanged; Codex started without CODEX_HOME keeps using your ChatGPT sign-in. In Windows PowerShell, create the directory, run $Env:CODEX_HOME = "$HOME\.codex-thinkapi", then sign in and start Codex in the same terminal (the variable lasts only for that session).

mkdir -p ~/.codex-thinkapi
# Put the three lines above in ~/.codex-thinkapi/config.toml, then sign in once:
printenv THINKAPI_KEY | CODEX_HOME="$HOME/.codex-thinkapi" codex login --with-api-key

# Start Codex with ThinkAPI; add this prefix every time, or save it as an alias:
CODEX_HOME="$HOME/.codex-thinkapi" codex

• Do not leave out forced_login_method = "api"; without it, a cached ChatGPT sign-in token would be sent to the gateway.
• A red "OpenAI base URL is overridden …" warning when you open /model in Codex is expected. That list shows Codex's built-in models, not the models in your group. Do not pick from it: your choice is saved to model in config.toml and replaces the model ID you entered. To switch models for one run, use codex -m <model-id>.
• See Codex authentication in the official docs.

Codex option 2: custom provider

Option 2 leaves your Codex sign-in alone, so it can coexist with a ChatGPT subscription sign-in. Add the following to ~/.codex/config.toml:

model = "<model-id>"
model_provider = "thinkapi"

[model_providers.thinkapi]
name = "ThinkAPI"
base_url = "https://api.thinkapi.org/v1"
env_key = "THINKAPI_KEY"
wire_api = "responses"

• model and model_provider are top-level keys and must come before any table header. If the file already has a model or model_provider line, change its value instead of adding another line; a duplicate key stops Codex from starting.
• You do not need codex login, and do not add requires_openai_auth. codex login status showing Not logged in is expected.
• To go back to ChatGPT, delete the top-level model_provider and model lines; your sign-in is untouched.

Codex reads the key from the THINKAPI_KEY environment variable. On macOS or Linux, add it to your shell startup file; on Windows, set a user environment variable:

# Add to ~/.zshrc (zsh) or ~/.bashrc (bash), then open a new terminal
export THINKAPI_KEY="sk-ThinkAPI_xxxxxxxx"

# Saved for your Windows user; takes effect in new terminals
[Environment]::SetEnvironmentVariable('THINKAPI_KEY', 'sk-ThinkAPI_xxxxxxxx', 'User')

# Current PowerShell session only
$Env:THINKAPI_KEY = 'sk-ThinkAPI_xxxxxxxx'

The IDE extension and desktop app may not see shell variables. In that case, put the key in ~/.codex/.env (%USERPROFILE%\.codex\.env on Windows) and restart the editor or desktop app:

THINKAPI_KEY=sk-ThinkAPI_xxxxxxxx

• .env is plain text; never commit or share it.
• Values in .env override shell variables of the same name, and variable names starting with CODEX_ are ignored.
• For more, see Codex advanced configuration in the official docs.

Codex: models, checks and troubleshooting

With either option, fill in model with a model ID from your group, copied exactly from Models & pricing or List models. Codex does not read the gateway's model list, so the startup notice "Model metadata for <model-id> not found. Defaulting to fallback metadata" means the ID is not in Codex's built-in model catalog and Codex falls back to default model settings.

• To switch models for one run: codex -m <model-id>. Do not switch with /model: it lists Codex's built-in models, and your choice is saved to config.toml, replacing the model you entered.
• Newer models may require a recent Codex version, so keep Codex on the latest release.

By default Codex passes its environment variables, including THINKAPI_KEY, to the commands it runs. To prevent that, add the filter below to ~/.codex/config.toml (do not also use the older exclude or include_only arrays in the same file; Codex rejects that combination):

[shell_environment_policy.filters]
"THINKAPI_KEY" = "exclude"

To check the setup with option 1, first run this command in a terminal; it should show Logged in using an API key.

codex login status

Then start Codex and run /status to check the Model and Model provider entries: openai for option 1, thinkapi for option 2.

/status

The real test is sending a message and finding the request in Requests. Codex does not show the X-Request-Id. Option 1 sends over WebSocket by default; each turn still appears in Requests but has no request ID returned to the client. Find the request by time and model.

When troubleshooting:

• Start Codex with codex --strict-config to have unknown configuration keys reported as errors, which catches typos. A configuration imported by CC Switch may contain keys Codex no longer recognizes, such as disable_response_storage, and they are reported too. Such keys do not affect a normal start without --strict-config, so you can ignore that error or delete the line.
• Do not set an OPENAI_BASE_URL environment variable; current Codex versions do not read it.
• Do not write wire_api = "chat"; that value has been removed and causes a configuration error.
• Do not write [model_providers.openai]: built-in providers cannot be overridden, and Codex fails to start with "model_providers contains reserved built-in provider IDs".
• Do not use [profiles.<name>]; Codex stopped reading it in 0.134.0.
• Do not point model_catalog_url at the gateway; its model list format is not compatible with Codex.
• On managed work computers, an administrator may restrict sign-in methods or settings, in which case option 1 may not be available.

One-click import with CC Switch

CC Switch is a desktop app that manages provider settings for Claude Code, Codex and other clients. The Portal can hand it your base URL and API key through a ccswitch:// link, so you do not have to edit configuration files by hand.

• Install: download it from GitHub Releases or the official site, ccswitch.io. On macOS you can also run brew install --cask cc-switch.
• Version: v3.16.0 or later is required, or the Portal's Claude Code options are lost on import. The latest release is recommended.
• Key: its status must be Ready and it must be revealable. If an older key says it cannot be revealed, create a new one.
• Group: the key must belong to a Claude or an OpenAI / Codex group, which imports into CC Switch's Claude or Codex panel respectively.

Start the import from either place:

• On API keys, choose Setup on the key, then Import to CC Switch. Pick the API URL and options in the dialog, then choose Import to CC Switch.
• In Connection setup, set Client to Native client in step 01, then choose Import to CC Switch in step 02.

Then:

1. Allow your browser to open CC Switch when it asks.
2. Review the name, endpoint and configuration in CC Switch's import confirmation dialog, then choose Import.
3. In CC Switch's Claude or Codex panel, choose Enable on the newly imported provider card. The Portal does not enable it for you; it is enabled automatically only if it is the first provider in that panel.
4. Start a new Claude Code session, or restart Codex.

CC Switch: importing into Claude Code

For a key in a Claude group, CC Switch writes ANTHROPIC_BASE_URL (https://api.thinkapi.org) and ANTHROPIC_AUTH_TOKEN to ~/.claude/settings.json, the same as the recommended setup. The four options under Claude Code settings in the dialog are all checked by default:

The ~/.claude/settings.json that CC Switch writes applies to the Claude Code CLI and the JetBrains plugin. The VS Code extension still needs the same two variables in claudeCode.environmentVariables, and the Claude desktop app needs its own Third-Party Inference setup; see other surfaces.

CC Switch: importing into Codex

For a key in an OpenAI / Codex group, CC Switch writes a custom provider to ~/.codex/config.toml and saves the key in ~/.codex/auth.json. It also works with groups that accept only native clients, which has been confirmed in the ChatGPT client. If a client returns 403 non_client_disabled, set up option 1 by hand instead.

• Unlike option 2, it does not coexist with a ChatGPT sign-in: enabling the provider makes CC Switch overwrite ~/.codex/auth.json with your ThinkAPI key, and your previous ChatGPT sign-in is not kept. To go back to ChatGPT, switch to the official login preset in CC Switch and sign in again.
• The model is always set to gpt-5.5 with high reasoning effort, regardless of the model you chose in Connection setup, and requests fail if your group does not offer that model. After importing, edit the provider in CC Switch and change model in its config.toml (model_reasoning_effort is in the same place), or use codex -m <model-id> for one run.
• The URL CC Switch writes has no trailing /v1, unlike the manual setup. Keep the imported value as is.
• Restart Codex after changing its configuration.

CC Switch: balance and caveats

CC Switch refreshes the balance every 30 minutes through GET /v1/usage (see Check your balance), but only while that provider is the one currently enabled. It shows the lower of your account balance and the key's remaining credit.

• When you enable or switch providers, CC Switch rewrites the whole of ~/.claude/settings.json, or ~/.codex/config.toml and auth.json, from that provider's settings plus its shared config, so other settings you added to the original file by hand, such as permissions or hooks, do not carry over. Back up the original files before you enable a provider, and keep settings you want in every provider in CC Switch's shared config snippet.
• CC Switch ignores CLAUDE_CONFIG_DIR and CODEX_HOME. If you set either one, point CC Switch's configuration directory setting at the same path, or the import has no effect.
• If Claude Code still does not pick up the import, check whether a project's .claude/settings.json or .claude/settings.local.json sets the same variables, and run /status in Claude Code to see the URL and credential in effect.
• With groups that accept only native clients, let the client connect to the gateway directly and do not turn on CC Switch features that proxy requests.

If nothing happens when you choose Import to CC Switch, make sure CC Switch is installed and registered for the ccswitch:// protocol. On macOS, run this command to register it again:

/usr/bin/open -a "CC Switch" --args --register-protocol

Client restrictions by group

Open a model's details on Models & pricing; the Client access field shows what the group requires. Native client means only official clients are accepted; Standard API means other requests that follow the protocol are accepted too; Unconfirmed means compatibility is not settled yet, so contact support first. The field is a guide, and actual request results take precedence.

In groups that accept only native clients:

• Only the official Claude Code and Codex work, including setups imported with CC Switch. When configuring Codex by hand, option 1 is recommended.
• Requests must be sent unmodified by the official client: do not change the User-Agent or other headers, and do not route through proxies or third-party tools that rewrite headers.
• Use a recent official release.
• The online test in Connection setup is not available. Make a real request from your client, then find it by time and model in Requests (Claude Code and Codex do not show the X-Request-Id, and Codex uses WebSocket by default). To check it in step 03 of Connection setup, copy the request ID from the request details and select the same key, group and model in step 01.

See Error codes for the full list.

Unsupported endpoints

Sub-resource endpoints such as GET /v1/models/{id}, GET /v1/responses/{id}, and /v1/messages/batches are not supported. They, like any other path the gateway does not recognize, return 404 unknown_route.

Responses WebSocket

Send a GET request to /v1/responses with Upgrade: websocket to open a WebSocket connection. The handshake checks your key and account balance, and failures come back as ordinary HTTP errors.

• Send {"type":"response.create", ...} to start a turn; apart from type, the fields match the POST /v1/responses request body. Send {"type":"response.cancel"} to cancel the current turn.
• The server sends each Responses streaming event as a JSON frame. Every turn ends with a response.completed, response.incomplete, response.failed, or error event.
• Each connection handles turns one at a time. While a turn is running, one more can wait in the queue; further requests return 429 response_queue_full.
• Every turn is authenticated, rate limited, and billed separately. A failed turn returns an error frame shaped like {"type":"error","status":N,"error":{...}}, and the connection stays open.
• A single frame can be up to 32 MiB; a larger frame closes the connection.
• Cross-origin browser connections are rejected based on their Origin header.
• Individual turns do not expose an X-Request-Id. For troubleshooting, note the time (with time zone) and the key name.

Response headers

Error formats

Error bodies come in two formats. When the gateway rejects a request itself, the format is the same whichever protocol you call:

{
  "error": {
    "type": "Unauthorized",
    "code": "invalid_api_key",
    "message": "The API key is not valid."
  }
}

error.type is the HTTP status phrase. Limit errors such as 429 user_rpm_exceeded also include error.reason and error.details.

When you call a model through its own protocol, request errors (4xx) from the upstream provider keep the provider's original status and body. For example, with Anthropic Messages:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "<upstream error message>"
  }
}

These responses carry X-Should-Retry: false, X-ThinkAPI-Error-Code (for example invalid_request_error), and X-ThinkAPI-Error-Action (for example correct_request). With cross-protocol translation, upstream errors are converted to the format of the protocol you called, and their type fields are not the provider's original values.

Identifying errors

• Identify errors by the HTTP status plus error.code. Do not rely on error.type.
• When the body is in the upstream format, error.code may be missing or hold the provider's own value, so check the X-ThinkAPI-Error-Code header instead. That header appears only on some errors; when it is absent, go by error.code.
• One status can have different causes. A 429, for example, may mean your account hit a rate limit, the platform is protecting capacity, or the key reached its credit limit, and each calls for a different response.
• A misspelled or unavailable model can return 403 model_not_allowed, 400 model_not_supported or model_disabled, a 503 (such as no_account_available) or a 502, or an upstream 404 in the provider's own format (such as Anthropic's not_found_error). A 404 means the path does not exist only when the body is in the gateway format and error.code is unknown_route.

Error codes

The table lists common error codes and how to handle them. Filter by category to narrow it down.

Retries and rate limits

• If a response includes Retry-After, wait at least that many seconds before retrying.
• If a response includes X-Should-Retry: false, the gateway advises against automatic retries. Handle it based on the error code.
• Official SDKs and clients retry 429 and 5xx responses by default. Retrying does not help with 429 api_key_quota_exhausted or 429 account_security_cooldown: the first needs a higher credit limit or another key, and the second clears only when the cooldown ends.
• Requests per minute (RPM) and maximum concurrency apply to your whole account and are shared by all its API keys, so switching keys does not help. Find your limits under API request limits in Settings.
• Capacity errors such as 429 all_accounts_busy and 429 upstream_rate_limited mean the platform is protecting its capacity. Retry after Retry-After, and open a ticket if they persist. The limit and used values in the items of their details.reasons[], when present, describe platform capacity, not your account limits.
• If your service group queues requests, a request waits for capacity first, so you see higher latency instead of an immediate 429.

Failover and timeouts

• When an upstream provider fails, the gateway may retry or switch to another available upstream within the same request. This is transparent to you and X-Request-Id stays the same, though latency may increase.
• Once a streaming response has started, the gateway no longer switches. If the stream breaks, you are billed for the usage produced so far.
• 502 upstream_delivery_uncertain and first-output timeout errors (when the platform enables them, such as 504 upstream_first_output_timeout) are not replayed automatically. The request may already have run upstream, so retrying it yourself can run it twice.
• A request with no data flowing in either direction for a long time is cut off: before the response starts you get 504 upstream_idle_timeout, and after it starts the stream ends early. Give your client a generous read timeout.

Balance and credit limits

• Your account balance is a wallet shared by all your API keys. Add funds and review transactions on Billing; available payment methods depend on platform settings.
• A credit limit caps spending for a single key. Set it when you create or edit a key on API keys; 0 means no limit. It counts settled charges, and once reached, requests return 429 api_key_quota_exhausted. A top-up does not reset key usage, so raise the limit or use another key.
• Billing is postpaid: new requests need a balance above zero, and requests already in progress can push it below zero. At zero or below, requests return 402 insufficient_balance until you top up.
• Credit limits are also checked only when a request starts, so requests in progress can take a key slightly past its limit.
• Use GET /v1/usage to check what you can spend at any time; see Check your balance.

Cost breakdown

Cost per request ≈ model unit price × usage in each billing dimension × group multiplier. Dimensions include input, output, cache reads, and cache writes. Some models add dimensions such as cache write duration, reasoning, or long context. Model details on Models & pricing only note that a model has additional pricing dimensions and do not list those rates; the settled amount in Requests is final.

• Charges are in your account currency (USD by default).
• Models & pricing shows a snapshot of current prices with your group multiplier applied. It is not a price lock, and a price shown as “—” does not mean free.
• The settled amount in Requests is the final charge.

What is not billed

• Requests the gateway rejects before forwarding them, such as authentication failures, insufficient balance, rate limits, and malformed requests.
• Upstream attempts that fail before the gateway switches to another upstream.
• 502 upstream_delivery_uncertain.
• GET /v1/models, GET /v1/usage, and Anthropic's POST /v1/messages/count_tokens (which still needs a balance above zero).
• POST /v1/responses/input_tokens: the gateway estimates it locally from the request text, and the response carries X-ThinkAPI-Token-Count: estimated. The number is approximate (a balance above zero is still needed).
• Connectivity probes answered locally: a bare greeting may get a reply from the gateway itself, with the X-ThinkAPI-Local-Probe header, and appear in Requests as “Probe request · Not forwarded”. It only proves you can reach the gateway, not that the model is available. It still needs a balance above zero and counts toward your RPM.

Service status

Service status shows the health of public service groups over the last 24 hours. It refreshes about every 30 seconds, and intervals without requests count as healthy. For dedicated groups, sign in and open Service status in your workspace.

Tracing a request

• Model responses normally include an X-Request-Id header (except 503 gateway_draining and individual Responses WebSocket turns). Save it in your logs.
• Open /app/requests/{request_id} in the Portal (replace {request_id} with the request ID) to see the request details, which show the execution status, HTTP status, billing status, and error details. Opening /app/usage?request_id={request_id} shows only that request in the Requests list.
• If you have questions about the outcome or the charge, choose Get help with this request on the details page. The ticket is linked to that request automatically.
• Some HTTP clients merge repeated headers into one comma-separated value. If you see two request IDs, use the first 32-character hexadecimal value.

Missing request records

These requests do not appear in Requests:

• Errors in the Authentication category of Error codes (401, 403, and 500 authorization_failed), plus 429 api_key_quota_exhausted. They include an X-Request-Id but return before a record is written.
• 404 unknown_route: the method or path is not recognized (for example because of a wrong base URL). It includes an X-Request-Id but returns before authentication and is never recorded.
• Model list requests (GET /v1/models, GET /models): they include an X-Request-Id but are never recorded.
• 503 gateway_draining: the gateway is restarting, and this response has no X-Request-Id.

In these cases, include the time (with time zone), the key name, and the error code in your ticket.

Clients such as Claude Code and Codex usually do not show you the X-Request-Id, and individual Responses WebSocket turns do not receive that header at all; the req_… in Claude Code errors is an upstream ID. These requests are still recorded, so look them up in Requests by time, model, and key.

Contacting support

When you open a ticket in Support, include as much of the following as you can:

• X-Request-Id
• When it happened, with time zone
• HTTP status
• error.code and error.reason, if present
• Key name (never paste the key itself)
• Model ID
• Client name and version
• Whether the request was streaming

If you cannot sign in, reach support through the channels on Contact us.