botu — production agent runtime on tokenroute
How botu (an OpenClaw-derived AI assistant runtime) routes all its LLM traffic through tokenroute with multi-model fallback.
botu on tokenroute
botu is the Paradigx production runtime for AI assistant skills — a fork of OpenClaw running on agent.botu.io. All LLM traffic from botu sandboxes goes through tokenroute as the upstream gateway, with Claude Haiku 4.5 as primary and Sonnet 4.5 as fallback.
What's wired
botu's openclaw.json config points its built-in LLM router at tokenroute's OpenAI-compatible endpoint:
{
"llm": {
"providers": [
{
"type": "openai",
"baseUrl": "https://api.tokenroute.io/v1",
"apiKey": "${LITELLM_API_KEY}", // sk-tr-* from `tokenroute keys create`
"models": [
{
"id": "anthropic/claude-haiku-4-5",
"name": "Claude Haiku 4.5 (via tokenroute)",
"role": "primary"
},
{
"id": "anthropic/claude-sonnet-4-5",
"name": "Claude Sonnet 4.5 (via tokenroute)",
"role": "fallback"
}
]
}
]
}
}LITELLM_API_KEY is injected via the host .env file — botu containers never see a real Anthropic key. To upstream agents inside botu sandboxes, this is transparent: they call https://api.anthropic.com-shaped APIs and tokenroute does the routing.
Why this matters for agent-first
This is the agent runtime half of the agent-first story:
- Tenant isolation: each botu tenant gets its own sk-tr key. Per-tenant spend visible in
tokenroute usage. - Provider fallback for free: if Anthropic Haiku has a quota event, tokenroute auto-routes the next request to Sonnet (or any other configured tier) without the agent code knowing.
- One bill: Paradigx pays tokenroute, tokenroute pays Anthropic/OpenAI/etc. No N-way invoice reconciliation across providers.
- Cost cap per agent run: botu sandboxes use
tokenroute keys create --name <session>per session, so any runaway agent loop hits a per-key balance ceiling rather than draining the whole org credit.
How a botu deploy uses tokenroute end-to-end
# 1. Operator creates a tokenroute API key for the botu deployment
tokenroute keys create --name botu-prod --json
# → {"raw":"sk-tr-..."}
# 2. Inject it into the botu host .env (alayion in our case)
ssh alayion 'echo "LITELLM_API_KEY=sk-tr-..." >> /opt/botu/.env'
# 3. Compose up botu — it reads .env, container env vars resolve
# ${LITELLM_API_KEY} in openclaw.json, and every LLM call from skills
# inside botu sandboxes routes through tokenroute.
ssh alayion 'cd /opt/botu && docker compose up -d'Replace ssh alayion ... with whatever your deploy story is — Render, Fly, Hetzner, K8s. The botu side is just "set one env var".
Phase A → Phase B closure
This is the proof of concept for tokenroute's bet that AI products want a gateway layer between them and the half-dozen LLM providers:
| Before (per-product per-provider) | After (botu via tokenroute) |
|---|---|
| Maintain Anthropic + OpenAI + Gemini keys in 5 places | One LITELLM_API_KEY per product deploy |
| Fallback logic inlined into every skill | Server-side, transparent to agent code |
| Spend visibility per provider, not per use case | Per-key in tokenroute usage, plus per-tenant if you scope keys |
| KYC + payment with each vendor | Paradigx fronts upstream costs, customers top up tokenroute |
See also
- botu deploy compose:
paradigx-deploy/alayion/docker-compose.yml— note theANTHROPIC_API_KEY=sk-ant-real-key-is-tokenroute-not-heredecoy - Live:
https://agent.botu.io/healthz