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.

Where your OpenRouter requests go

Requests pass through the ZopNight-hosted LiteLLM gateway on their way to OpenRouter. ZopNight configures it, meters it and enforces the budget, and the complexity router reads each prompt to choose the cheap or strong tier. Cost attribution works from per-request usage data: key, model, tokens and cost.

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.