tokenroute
Case studies

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 placesOne LITELLM_API_KEY per product deploy
Fallback logic inlined into every skillServer-side, transparent to agent code
Spend visibility per provider, not per use casePer-key in tokenroute usage, plus per-tenant if you scope keys
KYC + payment with each vendorParadigx fronts upstream costs, customers top up tokenroute

See also

On this page