Moving from OpenRouter to Dynoyard in one base-URL swap

If you’re already calling LLMs through OpenRouter with the OpenAI SDK, switching to Dynoyard is a one-line change. Same request shape, same streaming, same tool calls, same usage accounting — you keep your code, you change a string.

Here’s the whole migration.

The only change that matters

Point your client at Dynoyard’s base URL and use a Dynoyard key. That’s it.

Before (OpenRouter):

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-...",
)

After (Dynoyard):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-org.dynoyard.app/v1",
    api_key="sk-dyno-...",
)

Every call below stays identical:

resp = client.chat.completions.create(
    model="glm-5-2",
    messages=[{"role": "user", "content": "Refactor this function..."}],
    stream=True,
)

No SDK swap. No request rewrites. No new auth dance.

What stays the same

Dynoyard is OpenAI-compatible by contract, not by coincidence. The things you depend on carry over:

/v1/chat/completions — same body, same roles, same parameters (temperature, top_p, stop, max_tokens, …).
Streaming — standard SSE data: chunks with delta. Your existing stream parser just works.
Tool / function calling — tools, tool_choice, and parallel_tool_calls are passed through and returned in the canonical shape.
usage — every response carries prompt_tokens, completion_tokens, and total_tokens, including on the final streaming chunk, so your cost and token tracking keeps reporting.
/v1/models — list the live catalog the same way you do today.

If your code targets the OpenAI spec, it targets Dynoyard.

What changes (for the better)

Pricing. Frontier open-weight models — Qwen, GLM, Kimi, MiniMax, Gemini — at a fraction of closed-model rates, billed per request straight from your credits. Pay-as-you-go, no minimums.
One stable surface. Your base URL is your org’s endpoint. Models come and go in the catalog; your integration doesn’t move.
Transparent token accounting. The usage block reflects what you’re actually billed for, per request.

Migration checklist

Create an account and an API key at dynoyard.app.
Top up credits.
Change base_url and api_key in your client config.
Map any model names to Dynoyard’s catalog (check /v1/models or the docs).
Run your existing test suite. Because the contract matches, it should pass unchanged.

Most teams are switched over in the time it takes to redeploy.

A note on speed

A fair question when changing gateways: “will it be slower?” In practice, for frontier-class models, the overwhelming majority of end-to-end latency is the model generating tokens — not the gateway in front of it. A thin, compatible proxy adds negligible overhead. You’re choosing on price and model quality, not on milliseconds of routing.

Try it: swap one base URL and run your own workload against it → dynoyard.app

Questions, or want help mapping your model list? Email hello@dynoyard.app — we usually reply within a few hours.