August 5, 2026
Switching AI Providers in One Line: The OpenAI-Compatible Base URL Setup
A practical walkthrough of pointing your existing OpenAI SDK, curl scripts, or Claude Code setup at TokenTable's OpenAI-compatible endpoint โ no rewrite required.
If you already know you want to switch providers and just need the exact steps, this is that guide. TokenTable AI็ฎๅๅนณๅฐ exposes an OpenAI-compatible endpoint, so if your code currently talks to OpenAI, OpenRouter, or any other OpenAI-compatible relay, migrating is a base URL and API key swap โ not a rewrite.
Step 1: Get your API key
Sign up at tokentable.asia (email or one-click Google), open your dashboard, and find the API Key card. Click to reveal/copy it โ keys are prefixed tt-live-.... There's also a regenerate button if a key ever leaks and you need to rotate it (this invalidates the old one immediately, so update every place it's used before you regenerate).
Step 2: Point your OpenAI SDK at the new base URL
Everything else about your existing OpenAI SDK code stays the same โ you're changing two fields: base_url/baseURL and api_key/apiKey.
Python:
from openai import OpenAI
client = OpenAI(
api_key="tt-live-xxxxxxxxxxxxxxxx", # from tokentable.asia/dashboard
base_url="https://tokentable.asia/v1",
)
response = client.chat.completions.create(
model="auto", # TokenTable's AI router picks the best underlying model per request
messages=[{"role": "user", "content": "Explain the CAP theorem in two sentences."}],
)
print(response.choices[0].message.content)
Node.js / TypeScript:
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.TOKENTABLE_API_KEY,
baseURL: "https://tokentable.asia/v1",
});
const completion = await client.chat.completions.create({
model: "auto",
messages: [{ role: "user", content: "Write a haiku about distributed systems." }],
});
console.log(completion.choices[0].message.content);
Step 3: Raw HTTP / curl, if you're not using an SDK
curl https://tokentable.asia/v1/chat/completions \
-H "Authorization: Bearer $TOKENTABLE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "auto",
"messages": [{"role": "user", "content": "Hello!"}]
}'
This is the same request shape every OpenAI-compatible client and framework (LangChain, LlamaIndex, LibreChat, Open WebUI, Dify, and dozens more) already knows how to send โ point their "OpenAI API" or "custom OpenAI-compatible endpoint" setting at https://tokentable.asia/v1 and you're done.
Using it with Claude Code instead (Anthropic Messages format)
Claude Code doesn't speak the OpenAI schema โ it speaks Anthropic's Messages API, and TokenTable supports that natively too, so you don't need an OpenAI-shim layer. Add this to ~/.bashrc or ~/.zshrc:
export ANTHROPIC_BASE_URL=https://tokentable.asia
export ANTHROPIC_AUTH_TOKEN=tt-live-xxxxxxxxxxxxxxxx
export ANTHROPIC_MODEL=auto
export ANTHROPIC_DEFAULT_HAIKU_MODEL=qwen3.6-plus
One detail that trips people up: the Anthropic base URL should not include /v1 โ Claude Code appends /v1/messages itself, so https://tokentable.asia/v1/v1/messages (with the trailing slash included) will 404. Once the variables are set, restart your terminal and run claude as usual. Tool use / function calling is fully supported.
Which model ID should you actually use?
For most cases, use model: "auto". TokenTable's router looks at the shape of the request and picks an appropriate underlying model automatically โ coding-heavy prompts commonly route to a coding-flagship model like kimi-k2.6, general chat and reasoning can route to models like qwen3.6-plus, and requests that need top-tier reasoning can route to flagship Main models such as Claude Opus 4.8, GPT-5.5, or Gemini 3.5 Flash. If you want a specific model instead of AUTO's judgment, you can pass its exact model ID directly in the model field โ the same way you would with any OpenAI-compatible API โ and it'll be billed against your Main-model quota at that model's rate rather than the AUTO-optimized rate. Side/lightweight models used by AUTO for routine steps don't touch your Main quota at all.
If you got here because you were comparing this against OpenRouter specifically, the practical difference once you're plugged in is billing, not integration effort: same OpenAI-compatible shape, but flat monthly pricing instead of metered per-token billing. Or skip straight to trying it in chat to confirm everything responds the way you expect before wiring it into a pipeline.