OpenRouter

OpenAI, Anthropic, Llama and DeepSeek in one list

Six, deliberately spanning vendors:

• or-gpt-4o, or-gpt-4o-mini: OpenAI via OpenRouter
• or-claude-sonnet → claude-sonnet-4.5, or-claude-haiku → claude-haiku-4.5
• or-llama-70b → llama-3.1-70b-instruct
• or-deepseek → deepseek-chat

Why route through OpenRouter at all

One credential reaches several model families, which makes it the cheapest way to A/B a routing posture across vendors without provisioning accounts with each. The tradeoff is an extra hop and OpenRouter’s own margin, worth it for breadth, less so for a workload that has settled on one vendor.

Live model discovery runs against OpenRouter’s /models endpoint, so newly available models appear without a ZopNight release.

OpenRouter traffic bypasses ZopNight infrastructure

ZopNight never sits in your request path. The gateway runs on hosted LiteLLM; ZopNight configures it, meters it and enforces the budget, but your prompts and completions do not traverse our infrastructure. That distinction is why per-request cost attribution is possible without us reading request bodies.

One OpenRouter key per team, with a hard budget

Each team gets a virtual key with a hard USD budget and its own model allow-list. When a key hits its cap it stops working. This is a limit, not an alert. Keys rotate and revoke independently, so a leaked key is contained to one team’s budget rather than the org’s.

Routing postures across OpenRouter vendors

Three postures decide which model serves a request: Cost-saver, Balanced and Quality-first. Requests are classified into four semantic categories (coding, analysis and reasoning, extraction and classification, chit-chat) and routed accordingly, so cheap models take the traffic that does not need an expensive one.

A semantic cache sits in front, with strictness settings from strict (0.98 similarity) to loose (0.90). On repetitive workloads the cache is usually a larger saving than the routing itself.