Migrating from OpenRouter

Move from OpenRouter to Dynoyard with one base-URL change.

Dynoyard speaks the same OpenAI-compatible API as OpenRouter and returns the same OpenRouter-shaped /v1/models and usage.cost. For the overlapping catalog, migration is a one-line change.

1. Swap the base URL + key

  client = OpenAI(
-     base_url="https://openrouter.ai/api/v1",
-     api_key=OPENROUTER_API_KEY,
+     base_url="https://<your-org>.dynoyard.app/v1",
+     api_key=DYNOYARD_API_KEY,   # sk-dyno-...
  )

Get your endpoint + key from the quickstart (sign in, top up $10, create a key).

2. Map model ids

Dynoyard uses short, stable slugs (no vendor/ prefix). Check GET /v1/models for the canonical ids enabled on your org and update your model strings:

OpenRouter-style	Dynoyard slug
`moonshotai/kimi-k2-thinking`	`kimi-k2-thinking`
`deepseek/deepseek-r1`	`deepseek-r1`
`qwen/qwen-max`	`qwen-max-3-7`
`xiaomi/mimo`	`mimo-v2-5-pro`

(Exact availability is whatever /v1/models returns for your org.)

3. Everything else stays

usage.cost — same inline USD field; your existing cost tracking keeps working.
/v1/models — same OpenRouter shape (pricing, context length, capabilities), so LiteLLM / openrouter-* tooling reads it without changes.
Streaming, tools, reasoning_content — identical OpenAI shapes. See OpenAI compatibility.

What you gain

A dedicated per-org subdomain and isolated state.
Per-key access controls + (soon) spend caps.
A native usage dashboard with per-request token/latency/cost.
Transparent per-token pricing — see the pricing page.

Gotchas

Model ids differ — the vendor/model form won’t resolve; use the dynoyard slug.
Provider routing — you don’t pick an upstream provider per request; Dynoyard routes each model to its best backend automatically.
Thinking models — prefer stream: true for long reasoning passes to avoid client-side timeouts.