This post walks through the setup for Claude Code, the Python SDK, and the TypeScript SDK, then shows a tiny local "echo" server you can use to see exactly what each client sends, without an API key. The examples use Wokey as the gateway, but every step works the same with any Anthropic-compatible endpoint.

Disclosure: this post is published by the Wokey team. All commands were run on 2026-11-11 with Claude Code 2.1.322, anthropic (Python) 2.8.0 and @anthropic-ai/sdk (TypeScript) 1.8.0. Calls that need a real gateway key were not run with one; where that matters, it is called out.

What "Anthropic-compatible" means in practice

An Anthropic-compatible gateway exposes the Messages API at POST /v1/messages, accepts the same JSON body (model, max_tokens, messages, optional system, tools, stream, and so on), and returns the same response and Server-Sent Events (SSE) stream shapes.

The client builds the full URL by appending /v1/messages to whatever base URL you give it. Keep that in mind; it explains the most common failure later on.

Step 1: Find model IDs the gateway actually serves

Claude Code picks a model ID for you unless you set one, and a gateway only accepts the IDs it knows. So start by listing them. Many gateways expose an OpenAI-style GET /v1/models; on Wokey it is public, so this runs without a key:

# list_models.py - list Claude-family model IDs a gateway exposes
import json, sys, urllib.request

url = sys.argv[1] if len(sys.argv) > 1 else "https://api.wokey.ai/v1/models"
with urllib.request.urlopen(url, timeout=15) as resp:
    models = json.load(resp)["data"]

for m in sorted(models, key=lambda m: m["id"]):
    if "claude" in m["id"]:
        print(f'{m["id"]:<28} context={m.get("context_length")} max_out={m.get("max_completion_tokens")}')

python3 list_models.py

Output on 2026-11-11 (trimmed):

claude-haiku-4-5             context=200000 max_out=64000
claude-haiku-5-5             context=1000000 max_out=128000
claude-opus-5-5              context=1000000 max_out=128000
claude-sonnet-4-6            context=1000000 max_out=128000
claude-sonnet-5              context=1000000 max_out=128000
claude-sonnet-5-5            context=1000000 max_out=128000

The same script accepts another feed URL, for example python3 list_models.py https://openrouter.ai/api/v1/models. Field names differ between providers (OpenRouter returns IDs like anthropic/claude-sonnet-5 and has no top-level max_completion_tokens), so treat the output as a starting point and always copy IDs exactly.

Step 2: Point Claude Code at the gateway

Claude Code reads two variables: ANTHROPIC_BASE_URL and a credential. According to the Claude Code environment variable reference, ANTHROPIC_AUTH_TOKEN is sent as Authorization: Bearer <value> and ANTHROPIC_API_KEY is sent as an X-Api-Key header. Use whichever header your gateway reads; Wokey's setup guide uses ANTHROPIC_AUTH_TOKEN.

export ANTHROPIC_BASE_URL="https://api.wokey.ai"
export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY"
export ANTHROPIC_MODEL="claude-sonnet-5-5"   # optional: pin an ID from Step 1
claude

On Windows PowerShell, the same thing is $env:ANTHROPIC_BASE_URL = "https://api.wokey.ai" and so on; values set this way last for that terminal only.

To persist the setup, put the variables in the env block of ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.wokey.ai",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY",
    "ANTHROPIC_MODEL": "claude-sonnet-5-5"
  }
}

Three details from Anthropic's gateway connection guide:

1. When both a shell export and a settings-file env block set the same variable, the settings-file value wins.
2. Never put the credential in a project's .claude/settings.json; that file is meant to be committed. Use ~/.claude/settings.json or a git-ignored .claude/settings.local.json.
3. Inside Claude Code, /status shows an Anthropic base URL line and which credential source is active. If the base URL line is missing, the variable never reached the session.

If you also want the sonnet, opus and haiku aliases to resolve to IDs your gateway serves, Claude Code has ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL and ANTHROPIC_DEFAULT_HAIKU_MODEL. The Haiku one is also used for background tasks.

One scope note: Anthropic's LLM gateway page says it "doesn't support routing Claude Code to non-Claude models through any gateway". Some gateways accept other model families on their Messages endpoint, but for Claude Code, stick to Claude model IDs.

Step 3: Check the URL and key with curl before blaming the client

A single request rules out most problems:

curl -sS -w '\n%{http_code}\n' -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-5-5", "max_tokens": 1, "messages": [{"role": "user", "content": "."}]}'

With a real key, a 200 and a body starting with {"id":"msg_ means the base URL and credential work (not run here; no key). What I could run is the failure path. With a deliberately invalid key, the live endpoint returned an Anthropic-shaped error:

{"type":"error","error":{"code":"invalid_api_key","message":"Malformed API key. Wokey API keys start with sk-; ...","type":"authentication_error"}}
401

A 401 means the request reached the gateway and the route exists. A 404 means the path is wrong, which brings us to the main gotcha.

Step 4: The same check from the Anthropic SDKs

Both SDKs take a base URL and, like Claude Code, append /v1/messages themselves. Both also read ANTHROPIC_BASE_URL from the environment if you don't pass one. The script below sends one request and prints what came back, including response headers:

# probe.py - send one Messages request and show which model answered
import os
from anthropic import Anthropic

client = Anthropic(
    base_url=os.environ.get("ANTHROPIC_BASE_URL", "https://api.wokey.ai"),
    api_key=os.environ["GATEWAY_API_KEY"],
)

raw = client.messages.with_raw_response.create(
    model=os.environ.get("MODEL", "claude-sonnet-5-5"),
    max_tokens=64,
    messages=[{"role": "user", "content": "Reply with one short sentence."}],
)
msg = raw.parse()

print("requested model :", os.environ.get("MODEL", "claude-sonnet-5-5"))
print("response model  :", msg.model)
print("gateway req id  :", raw.headers.get("x-wokey-request-id"))  # Wokey-specific header
print("upstream req id :", raw.headers.get("request-id"))
print("tokens in/out   :", msg.usage.input_tokens, "/", msg.usage.output_tokens)
print("text            :", msg.content[0].text)

The TypeScript version uses .withResponse() to get the raw Response:

// probe.mjs - same check with the TypeScript/JavaScript SDK
import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic({
  baseURL: process.env.ANTHROPIC_BASE_URL ?? 'https://api.wokey.ai',
  apiKey: process.env.GATEWAY_API_KEY,
})

const { data: msg, response } = await client.messages
  .create({
    model: process.env.MODEL ?? 'claude-sonnet-5-5',
    max_tokens: 64,
    messages: [{ role: 'user', content: 'Reply with one short sentence.' }],
  })
  .withResponse()

console.log('response model :', msg.model)
console.log('gateway req id :', response.headers.get('x-wokey-request-id')) // Wokey-specific
console.log('upstream req id:', response.headers.get('request-id'))
console.log('text           :', msg.content[0].text)

request-id is the header Anthropic documents on every API response (errors reference). Wokey's Messages reference says a successful response carries both its own x-wokey-request-id and the upstream request-id; I could only confirm that against the local server below, not with a live key. Against the real endpoint with an invalid key, both scripts raise an AuthenticationError (401) with the JSON shown in Step 3.

Step 5: See what your client really sends, with no key at all

When a client misbehaves, it helps to stop guessing and look at the raw request. This roughly 30-line server (standard library only) logs the method, path, credential header and model, then returns a minimal Messages response:

# echo_server.py - a fake Anthropic-style endpoint that logs what clients send
import json
from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        body = json.loads(self.rfile.read(int(self.headers["Content-Length"])))
        print(f"{self.command} {self.path}")
        for h in ("x-api-key", "authorization"):  # credentials: print a prefix only
            if self.headers.get(h):
                print(f"  {h}: {self.headers[h][:12]}...")
        print(f"  anthropic-version: {self.headers.get('anthropic-version')}")
        print(f"  model={body.get('model')} max_tokens={body.get('max_tokens')}")
        if self.path.split("?")[0] != "/v1/messages":
            self.send_response(404); self.end_headers(); return
        out = json.dumps({
            "id": "msg_local", "type": "message", "role": "assistant",
            "model": body.get("model"), "stop_reason": "end_turn",
            "stop_sequence": None,
            "content": [{"type": "text", "text": "hello from the echo server"}],
            "usage": {"input_tokens": 1, "output_tokens": 1},
        }).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.send_header("x-wokey-request-id", "local-test-123")
        self.send_header("Content-Length", str(len(out)))
        self.end_headers()
        self.wfile.write(out)

    def log_message(self, *args):  # silence default access log
        pass

HTTPServer(("127.0.0.1", 8787), Handler).serve_forever()

Run it in one terminal, then point clients at it in another:

python3 echo_server.py
# second terminal
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 GATEWAY_API_KEY=sk-test-0000 python3 probe.py
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 ANTHROPIC_AUTH_TOKEN=sk-test-0000 \
  ANTHROPIC_MODEL=claude-sonnet-5-5 claude -p "say pong"

What the log showed in my run:

• Python and TypeScript SDKs: POST /v1/messages with Authorization: Bearer ..., even though the key was passed as api_key/apiKey. That matches Wokey's note that current Anthropic SDKs send the key as a Bearer token. The SDKs sent anthropic-version: 2026-10-21.
• Claude Code: POST /v1/messages?beta=true with anthropic-version: 2023-06-01. Because this server never streams, two requests showed up before Claude Code printed the echo text. A gateway that rejects unknown query strings would break here, so the ?beta=true detail is worth knowing.
• Claude Code with no model set asked for claude-opus-5-5 on this version. Defaults change between releases and account types, which is one more reason to pin ANTHROPIC_MODEL.

Gotchas, in the order you'll probably hit them

1. A trailing /v1 in the base URL. With ANTHROPIC_BASE_URL=http://127.0.0.1:8787/v1, every client requested /v1/v1/messages. The SDKs raised NotFoundError: 404. Claude Code reported: "There's an issue with the selected model (claude-sonnet-5-5). It may not exist or you may not have access to it." The model was fine; the path wasn't. The live Wokey endpoint returns Route POST:/v1/v1/messages not found for the same mistake. OpenAI-style clients are usually configured with /v1 in the base URL; Anthropic clients are not.
2. Two credentials at once. With both ANTHROPIC_AUTH_TOKEN and ANTHROPIC_API_KEY set, Claude Code sent both an x-api-key and an Authorization header. Wokey's error docs list headers that disagree as a cause of 401, and Anthropic's guide warns about auth conflicts. Unset the one you don't use. The Python SDK, given both variables, warned and used ANTHROPIC_API_KEY.
3. A global ANTHROPIC_BASE_URL reroutes every SDK script. Exporting it in ~/.bashrc for Claude Code also changes the destination of any Python or Node code that calls Anthropic() without arguments. If you only want Claude Code rerouted, setting the variables in ~/.claude/settings.json keeps them out of your normal shell sessions.
4. Features tied to a claude.ai login. Anthropic's guide notes that Remote Control is disabled when ANTHROPIC_BASE_URL points at a non-Anthropic host, and voice dictation is unavailable while a gateway credential is active.
5. Usage numbers aren't always comparable. Wokey's Messages reference notes that for Claude models input_tokens excludes cached tokens, as Anthropic's API does, while for converted non-Claude models it includes them. Check your gateway's docs before building cost dashboards on usage.

What the model field tells you, and what it doesn't

The echo server above returned whatever model the client asked for, and every client accepted it. That's the point: the model field in a response is a string the server writes. It's useful for catching configuration mistakes (an alias resolving to an unexpected ID, a client ignoring your pin), but it isn't evidence of which model produced the text. Wokey's own verifiable-API feature page puts it plainly: "A relay can put anything in the model field of its JSON."

Request IDs help with support tickets, not with proof. Some gateways, Wokey included, can attach a signed attestation produced in an AWS Nitro Enclave on certain raw passthrough routes. That shows the response bytes came from the upstream provider's TLS endpoint; it does not show which model the provider ran internally.

Takeaways

• Base URL without /v1 for Anthropic clients; the client appends /v1/messages.
• Pick one credential variable: ANTHROPIC_AUTH_TOKEN for Bearer, ANTHROPIC_API_KEY for x-api-key. Not both.
• Pin ANTHROPIC_MODEL to an ID copied from the gateway's model list.
• Test with curl first, then with /status, and keep a local echo server around for anything confusing.
• Read the model field as a config check, not as proof.

This post builds a small Python script (about 65 lines, standard library only) that reads a public /models pricing feed and estimates what a session costs with and without caching. It works with any feed that uses the OpenRouter-style schema, so you can point it at OpenRouter, at the gateway you already use, or at both.

Disclosure: this post is published by the Wokey team. The script is vendor-neutral and every number below comes from public pricing feeds fetched on 2026-11-04.

The pricing feed format

OpenRouter's GET https://openrouter.ai/api/v1/models returns one object per model with a pricing block. Prices are USD per token, written as decimal strings:

"pricing": {
  "prompt": "0.000002",
  "completion": "0.00001",
  "input_cache_read": "0.0000002",
  "input_cache_write": "0.0000025",
  "input_cache_write_1h": "0.000004"
}

Some other gateways expose the same shape so that OpenAI-compatible tooling can read it. For example GET https://api.wokey.ai/v1/models (no API key needed) returns the same prompt / completion / input_cache_read / input_cache_write fields. Not every model has every field: some models list no input_cache_write because their provider doesn't charge extra to write the cache.

Two things to keep in mind:

• Use Decimal, not float. Per-token prices like 0.00000003 are exactly the kind of number floats round badly.
• input_cache_write is the price for the default (5-minute) cache; input_cache_write_1h is the longer-lived option on Anthropic models. The script below uses the 5-minute price.

How an agent session actually spends tokens

A simple but honest model of an agent session:

1. Turn 1 sends a fixed prefix (system prompt plus tool definitions, often 10k to 30k tokens for coding agents) and the first user message.
2. Every later turn re-sends everything from before (prefix plus all earlier messages and replies) plus some new tokens (your message, tool results).
3. Each turn produces some output tokens, which become part of the history for the next turn.

Without caching, all of that re-sent history is billed at the full input price, every turn. With prompt caching, the part the provider has already seen can be read from cache at a much lower rate, and new tokens are written to the cache so the next turn can read them.

Caching isn't free or automatic everywhere, and the details matter:

• On Anthropic models, the request must mark cache breakpoints with cache_control (Claude Code does this for you). Per Anthropic's prompt caching docs, the default cache lives 5 minutes, refreshed each time it's used, with a 1-hour option at extra cost, and there is a minimum cacheable prompt length per model.
• A cache miss doesn't just cost the normal input price; on providers that charge for cache writes, the missed tokens are written again at the write price.

So the realistic question isn't "caching on or off", it's "what's my hit rate?"

The script

Save this as session_cost.py:

#!/usr/bin/env python3
"""Estimate what a multi-turn agent session costs, using any
OpenRouter-style /models feed (per-token prices as decimal strings)."""
import argparse
import json
import urllib.request
from decimal import Decimal

def load_pricing(models_url, model_id):
    req = urllib.request.Request(models_url, headers={"User-Agent": "session-cost/0.1"})
    with urllib.request.urlopen(req, timeout=30) as resp:
        data = json.load(resp)["data"]
    for m in data:
        if m["id"] == model_id:
            return {k: Decimal(v) for k, v in m["pricing"].items()
                    if isinstance(v, str)}
    raise SystemExit(f"model {model_id!r} not found in {models_url}")

def session_tokens(turns, prefix, per_turn_in, per_turn_out):
    """Yield (fresh_input, cached_prefix, output) per turn.
    Turn 1 sends the prefix plus the first message. Every later turn
    re-sends everything from before (prefix + history) plus new tokens."""
    history = 0
    for i in range(turns):
        seen = prefix + history if i else 0
        fresh = per_turn_in if i else prefix + per_turn_in
        yield fresh, seen, per_turn_out
        history += per_turn_in + per_turn_out

def cost(p, turns, prefix, per_turn_in, per_turn_out, hit_rate):
    """hit_rate=None means no caching at all."""
    total = Decimal(0)
    for fresh, seen, out in session_tokens(turns, prefix, per_turn_in, per_turn_out):
        if hit_rate is not None and "input_cache_read" in p:
            # a hit reads seen tokens from cache; a miss writes them again.
            # new tokens are written so the next turn can read them.
            write = p.get("input_cache_write", p["prompt"])
            hit = seen * hit_rate
            total += hit * p["input_cache_read"] + (seen - hit + fresh) * write
        else:
            total += (seen + fresh) * p["prompt"]
        total += out * p["completion"]
    return total

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--models-url", required=True)
    ap.add_argument("--model", required=True)
    ap.add_argument("--turns", type=int, default=40)
    ap.add_argument("--prefix", type=int, default=20000, help="system prompt + tool schemas")
    ap.add_argument("--turn-in", type=int, default=3000, help="new input tokens per turn")
    ap.add_argument("--turn-out", type=int, default=800, help="output tokens per turn")
    ap.add_argument("--hit-rate", type=Decimal, default=Decimal("0.95"),
                    help="share of previously seen tokens read from cache")
    a = ap.parse_args()
    p = load_pricing(a.models_url, a.model)
    args = (a.turns, a.prefix, a.turn_in, a.turn_out)
    total_in = sum(f + s for f, s, _ in session_tokens(*args))
    print(f"model: {a.model}")
    print(f"input tokens sent over {a.turns} turns: {total_in:,}")
    rows = [("no caching", None), (f"cache, {a.hit_rate:.0%} hits", a.hit_rate),
            ("cache, 100% hits", Decimal(1))]
    for label, rate in rows:
        print(f"{label + ':':<19} ${cost(p, *args, rate):.4f}")

if __name__ == "__main__":
    main()

It needs Python 3.8 or newer and nothing outside the standard library. On Windows, run it with py session_cost.py ... and put each command on one line.

Running it

With the defaults (40 turns, a 20k-token prefix, 3k new input tokens and 800 output tokens per turn, 95% cache hits) against OpenRouter's feed:

python3 session_cost.py --models-url https://openrouter.ai/api/v1/models \
  --model anthropic/claude-sonnet-5

model: anthropic/claude-sonnet-5
input tokens sent over 40 turns: 3,884,000
no caching:         $8.0880
cache, 95% hits:    $1.8494
cache, 100% hits:   $1.4188

Nearly 3.9 million input tokens for a 40-turn session, even though you only typed a few thousand of them. Output (32,000 tokens here) is a small part of the bill; re-sent context is most of it.

Now drop the hit rate to 50%, which is roughly what you get when something keeps breaking the cache:

python3 session_cost.py --models-url https://openrouter.ai/api/v1/models \
  --model anthropic/claude-sonnet-5 --hit-rate 0.5

no caching:         $8.0880
cache, 50% hits:    $5.7244
cache, 100% hits:   $1.4188

The same session costs about four times as much as at full hits. That gap is why hit rate deserves as much attention as the price list.

Because the feed format is shared, you can run the same session against another gateway by changing two arguments. Here is the same model on Wokey's public feed (model IDs differ between feeds, so check /models first):

python3 session_cost.py --models-url https://api.wokey.ai/v1/models \
  --model claude-sonnet-5

model: claude-sonnet-5
input tokens sent over 40 turns: 3,884,000
no caching:         $1.2132
cache, 95% hits:    $0.2774
cache, 100% hits:   $0.2128

All of these figures are from the feeds as published on 2026-11-04. Prices change, so rerun the script rather than trusting the numbers here; each provider's own models page is the authoritative source.

What breaks the cache in practice

Your hit rate is set mostly by your client and your habits, not by the provider. Common causes of misses:

• Idle time. If you step away for longer than the cache lifetime (5 minutes by default on Anthropic models), the next turn re-writes the whole prefix.
• Changing the prefix. Editing the system prompt, adding or removing tools, or switching models mid-conversation invalidates everything after the change.
• Routing to a different upstream account or endpoint. Caches belong to the upstream account, so a gateway that spreads one conversation across accounts turns hits into writes.
• Per-request data at the top of the prompt. Anything that changes every request (a timestamp, a request ID) placed before the cached content defeats caching on gateways that cache on the request body.

Wokey publishes weekly measured cache hit rates by client and model, including a breakdown of why misses happen, which is a useful reference for what "normal" looks like for Claude Code, Codex, and others.

Limitations of this estimate

Be clear about what the script does and doesn't model:

• It assumes a steady session: the same new input and output per turn. Real sessions are lumpy (a big file read, a long tool output), so treat the result as an order-of-magnitude estimate.
• It ignores context compaction, which agents use to shrink history on long sessions.
• It uses the 5-minute cache write price and ignores input_cache_write_1h.
• It ignores long-context price tiers. OpenRouter lists these in an overrides array on some models (for example, higher prices above 200,000 prompt tokens); the script doesn't read it.
• Models with no input_cache_read price are treated as uncached.

Takeaways

• For agents, input tokens from re-sent context dominate the bill, not output.
• Cache hit rate moves cost by multiples. Estimate with a realistic rate (try 0.5, 0.8, and 0.95), not 100%.
• Read prices from the provider's /models feed as Decimal, and rerun estimates when prices change.
• When comparing gateways, compare the same session profile at the same hit rate, and check the hit rate you actually get from your usage records.

A different approach is to have the relay's egress run inside a trusted execution environment that signs what it actually received from the upstream API. Then you check that signature yourself, offline, without trusting the relay.

Disclosure: this post is published by the Wokey team.

This tutorial walks through one open-source implementation of that idea, proof-of-observation (MIT/Apache-2.0), as deployed by the Wokey API gateway. We'll:

1. point an existing OpenAI / OpenRouter-style client at a new base_url,
2. capture a streaming response that carries a proof,
3. check it locally with a short Python script and then with the official verifier,
4. be precise about what a passing check does and does not tell you.

How the proof is produced

Per the repo README and the protocol spec (docs/proof-of-observation-protocol-v1.md), for each request an AWS Nitro Enclave:

1. terminates the upstream TLS connection inside the enclave, validating the upstream's certificate against a CA bundle compiled into the measured image;
2. streams the response back while hashing it (no full-body buffering);
3. signs a tee-exchange-v2 statement with an Ed25519 key that is generated at boot and never leaves the enclave. The statement covers nonce, upstream-host, upstream-path, http-method, http-status, resp-content-type, request-body-sha256 and response-body-sha256;
4. attaches a Nitro (NSM) attestation that binds that signing key and the enclave image measurement (PCR0) to the AWS Nitro root certificate.

On your side, you check that the attestation chains to the AWS root, that PCR0 equals a value reproducible from the public source, that the signing key is the one the attestation binds, and that the bytes you received hash to what was signed.

What a green result proves, and what it doesn't

Read this before you write any code.

A passing proof shows: an enclave running the published, reproducibly built image fetched these exact response bytes over TLS from the upstream host named in the signed statement (for example api.anthropic.com), and nobody changed a byte after that, the relay included.

It does not show:

• Which model the provider actually ran. The model field you see sits inside the signed upstream bytes, so the relay can't rewrite it. But it is still the provider's own self-report. In the words of the pi-wokey README: "It cannot prove that OpenAI or Anthropic served the model you asked for, because neither signs its responses."
• That your exact request was sent. The gateway rewrites some requests before they reach the enclave (Responses requests get fields filled in, for example). In that case request-body-sha256 won't match your local body. Wokey's own docs say Responses proofs "currently prove the response only", and pi-wokey records request binding as unavailable on both proven routes.
• Confidentiality. This is an integrity guarantee. The relay still handles plaintext in transit.
• That all of your traffic was attested. Proofs are per exchange. A response without a proof is simply unproven (spec §10.5).
• Freshness across byte-identical retries. Wokey's docs note that the verifier cannot tell an old response being replayed apart from a new one when the requests are byte-identical.

You also still trust AWS (the Nitro root and its attestation service), the TEE's isolation, and the published enclave source. A reproducible build shows the running code is that source, not that the source is bug-free (spec §10.7).

So the honest summary is that this removes the relay from your trust chain. It doesn't remove the model provider.

Step 1: Switch your client's base URL

Wokey's docs list https://api.wokey.ai as the base URL. The gateway accepts paths with or without /v1, so OpenAI SDKs can use https://api.wokey.ai/v1. Endpoints: POST /v1/chat/completions, POST /v1/responses, POST /v1/messages, GET /v1/models.

If you're coming from OpenRouter (https://openrouter.ai/api/v1), the change is the base_url, the key, and the model ID. Wokey uses bare IDs like claude-sonnet-5 instead of anthropic/...-style slugs.

# pip install openai
from openai import OpenAI

client = OpenAI(
    base_url="https://api.wokey.ai/v1",   # was https://openrouter.ai/api/v1
    api_key="YOUR_WOKEY_KEY",
)

resp = client.chat.completions.create(
    model="gpt-6-sol",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

Node is the same idea:

// npm install openai
import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.wokey.ai/v1",
  apiKey: process.env.WOKEY_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "gpt-6-sol",
  messages: [{ role: "user", content: "Hello" }],
});
console.log(resp.choices[0].message.content);

The live model list is public:

curl -s https://api.wokey.ai/v1/models | python3 -c \
  "import json,sys; print([m['id'] for m in json.load(sys.stdin)['data']])"

Important: a Chat Completions response like the one above carries no proof. Proofs only exist on raw passthrough routes, where the gateway forwards the upstream bytes untouched:

Converted responses (such as Claude through Chat Completions), image generation, and requests that fell back while the enclave was unavailable carry no proof. If you ask for a multipart proof on a route that can't pass through raw bytes, you get HTTP 422 tee_proof_multipart_requires_raw_passthrough, not a fake proof.

One detail worth knowing: pi-wokey pins the signed upstream for the GPT Responses route as chatgpt.com + /backend-api/codex/responses (OpenAI's Codex backend), not api.openai.com. The Claude route is pinned to api.anthropic.com + /v1/messages. Check the upstream_host and upstream_path in each proof yourself rather than assuming.

You also need to turn on "Official verification" for your API key on Wokey's API page. Without it, responses don't carry a proof.

Step 2: Capture a streaming response with its proof

The verifier needs the exact bytes, so save them with curl -o. On Windows, use curl.exe -o. PowerShell > redirection or re-saving in Notepad changes line endings or encoding.

curl -sN https://api.wokey.ai/v1/messages \
  -H "x-api-key: $WOKEY_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":256,"stream":true,"messages":[{"role":"user","content":"Hello"}]}' \
  -o captured-response

The file should end with something like:

event: message_stop
data: {"type":"message_stop"}

event: tee.proof
data: {"v":2,"alg":"ed25519","public_key":"...","nonce":"...","upstream_host":"api.anthropic.com","upstream_path":"/v1/messages","http_method":"POST","http_status":200,"resp_content_type":"text/event-stream","request_body_sha256":"...","response_body_sha256":"...","signature":"...","attestation":"...","pcr0":"..."}

If there's no tee.proof at the end, treat the response as unproven.

Per Wokey's docs, the proof arrives as a final tee.proof event at the end of the stream when Official verification is enabled on your key. If your capture doesn't end with one, check that setting first.

Step 3: A quick sanity check in Python

Before running the full verifier, it helps to see the core idea with nothing but hashlib. Everything before the final event: tee.proof record is the upstream body, and its SHA-256 must equal response_body_sha256.

# check_proof.py: hash check only, NOT a full verification
import hashlib, json, sys

MARKER = b"event: tee.proof\n"

raw = open(sys.argv[1], "rb").read()
idx = raw.rfind(MARKER)
if idx < 0:
    sys.exit("No tee.proof event found: treat this response as unproven.")

body = raw[:idx]
data_line = raw[idx:].decode("utf-8").split("\n")[1]
proof = json.loads(data_line[len("data: "):])

for k in ("upstream_host", "upstream_path", "http_status", "pcr0"):
    print(f"{k:16}: {proof[k]}")

# The model as the upstream reported it, inside the hashed bytes
for line in body.decode("utf-8").split("\n"):
    if line.startswith("data:") and '"message_start"' in line:
        print(f"{'reported model':16}: {json.loads(line[5:])['message']['model']}")
        break

ok = hashlib.sha256(body).hexdigest() == proof["response_body_sha256"]
print("body hash matches signed hash" if ok else "MISMATCH")
sys.exit(0 if ok else 1)

python3 check_proof.py captured-response

I tested this against the SSE fixture shipped in the pi-wokey repo. It matches, and flipping a single word in the body makes it print MISMATCH. Two limits apply. It doesn't check the signature or the attestation, so a malicious relay could just recompute a hash. And slow streams may contain : wokey-transport-keepalive-v1 comment lines, which the official verifier strips (only when the result matches the signed hash) and this script doesn't. Use it to build intuition, not as a security check.

Step 4: Full offline verification with the official verifier

The real verifier is TypeScript in the same repo. It needs Node; tsx is installed as a dev dependency.

git clone https://github.com/focuxdot/proof-of-observation
cd proof-of-observation/verifier
npm install
npx tsx tee-verify-stream.ts ../../captured-response \
  --pcr0 <CANONICAL_PCR0> \
  --host api.anthropic.com

• --pcr0 is required. Take it from the repo's README / docs/tee-reproducible-build.md, or better, reproduce it yourself (below). As of this writing (October 2026), the published production value is 437cbab8c2e5dd11a35ae5b062fe115623a013910b7c26b333e2b3af477944d630fb1dcd76fa9a9b1eefdf1d1021dec2. Don't copy it from a blog post, though; check the repo.
• --host is optional. If you pass it, the verifier checks that the signed upstream_host matches. If you leave it out, it only displays the host.

The verifier checks the COSE/ECDSA-P384 attestation chain up to the AWS Nitro root, whose SHA-256 fingerprint is pinned in verify-attestation-cose.mjs (64:1A:03:21:…:79:BB:5B; compare it against AWS's documentation). It then checks PCR0, the key and nonce binding, the Ed25519 statement signature, and the body hash. A pass on everything exits 0, and any failure exits 1.

Two practical notes:

• The CLI output labels are in Chinese. Check marks (✅/❌) and the exit code are enough to script against.
• Verify soon after capturing. The Nitro leaf certificate is short-lived (hours), and the verifier checks certificate validity against the current time. The check runs fully offline, but an old capture will fail that step.

As a negative test, running it on pi-wokey's synthetic fixture (test-fixtures/anthropic-opus-5-5.sse, which has a placeholder attestation) shows the host and statement-signature checks passing and the attestation check failing, so the overall verdict is ❌. That's the behavior you want: no real attestation, no green.

There's also a browser verifier that runs locally in the page; its source is docs/tee-verify.html in the repo. For non-streaming requests, add -H "x-wokey-tee-proof-mode: multipart" and save the whole multipart/mixed body. The same CLI accepts it.

Optional: reproduce PCR0 yourself

The whole scheme rests on PCR0 being something you can recompute, not a number the operator gives you:

cd proof-of-observation/enclave
git checkout <revision listed in docs/tee-reproducible-build.md>
bash reproducible-build.sh   # double --no-cache build, two byte-identical PCR0s

This needs an aarch64 host with Docker and the AWS Nitro CLI. The pinned versions are in docs/tee-reproducible-build.md, which also names the source revision behind the current production value.

If you live in a coding agent

If you use the pi coding agent, the community extension pi-wokey (pi install npm:pi-wokey) does all of this on every response. It vendors the verifier code, pins PCR0, and warns when a reply fails or can't be proven. It's an independent project, not affiliated with Wokey, and its README is the clearest statement of the limits above.

Takeaways

• Changing base_url is the easy part. Chat Completions responses aren't proven, so if you want proofs, use streaming Messages / Responses or the multipart header.
• Save exact bytes (curl -o), verify with a pinned PCR0 and the AWS root, and do it soon after capture.
• A pass means the relay didn't alter what the upstream TLS endpoint sent. It doesn't mean the provider ran the model it named. No relay can prove that today, because the providers don't sign their responses.

If you'd rather just try the flow end to end, Wokey is the deployment used here. The verifier and enclave source are open, so you can check them before you trust the result.