Skip to main content
Claude Code and Codex The gateway speaks the OpenAI and Anthropic wire formats natively, so adopting it is a configuration change rather than an integration project. An application or coding client changes exactly two things: the base URL and the API key.
No public gateway origin is published yet, so there is nothing to point a client at today. This page describes the integration shape and what it produces. Track the launch in Live Evidence; to track your usage now, see Quickstart: Track Your Usage.

​
The integration shape

Requests arrive on the protocol the client already speaks:
  • POST /v1/chat/completions and POST /v1/responses (OpenAI wire formats, the second being what Codex speaks)
  • POST /v1/messages and POST /v1/messages/count_tokens (Anthropic wire format, what Claude Code speaks)
  • GET /v1/models and GET /v1/models/:model for model discovery
  • GET /v1/receipts/:request_id to retrieve the signed receipt for a completed request
Keys are project-scoped tok_ bearer tokens, issued per project in the console. For the exact request and response shapes, see Gateway API. Which setting changes depends only on what the client already speaks:

​
What the client never has to do

This is the part that surprises people, and it is the reason integration is a configuration change rather than a project. A client routed through the gateway holds one API key and nothing else:
  • No wallet, and no signing. The client never sees a private key, never signs a payment authorization, and never submits a transaction. Payment is settled between the gateway, its isolated adapter, and the facilitator.
  • No chain interaction, and no chain awareness. The client does not need an RPC endpoint, a chain ID, a gas balance, or any notion that a chain exists. Per-request settlement happens off the request path.
  • No payment bookkeeping. Credit top-up and per-request settlement are handled between the gateway and the project account. A prepaid-credit project makes ordinary API calls that look exactly like any other provider.
  • No receipt handling, unless it wants one. Receipts are issued whether or not the client asks. A client that wants proof fetches it later at GET /v1/receipts/{request_id} under the same key, including after a stream disconnect.
The one thing a client does gain is that its usage stops being self-reported.

​
Verified by real installed clients

The integration is covered by an acceptance harness rather than by mocked HTTP: Codex and Claude Code each complete paid requests through the gateway as actually installed binaries, and every terminal request is checked for a settled ledger entry and a fetchable receipt. Accounting and privacy assertions run in the same pass, which is what makes “it works with real clients” a checkable statement rather than a claim. Those targets and their markers are in Verification Log.

​
What gateway-verified means for the client user

Tokscale ranks usage evidence on a five-tier ladder: self-reported, consistency-checked, source-verified, gateway-verified, attested. Self-reported usage is forgeable; verified usage is an asset. When a client runs through the gateway, the gateway itself observes the request, the model, the token counts, and the cost, then signs that observation into a UsageReceiptV1 receipt. That is gateway-verified: the data engine saw the work, so the claim no longer depends on what the client’s machine says about itself. When the epoch’s receipts anchor on-chain, the same usage climbs to attested. This is the whole reason the gateway exists. The open-source CLI can only report what a machine tells it, which is why its data sits at the bottom of the ladder however accurate it happens to be. The ladder is explained in Verified Usage and the Evidence Ladder.

​
Next steps