Key facts
| Model selection | Per-request model name |
| Aliases | Stable names that point to models; changes documented |
| Automatic substitution | Not on self-serve — no silent model swaps |
| App-level routing | Route by task, cost, latency or region in your code |
| Fallback | Retry and model-switch logic in your application |
| Enterprise routing | Gateway-level failover options in dedicated deployments |
| Models | 30+ models behind one OpenAI-compatible API |
| Product status | Live |
TL;DR
- You choose the model per request — routing is not hidden.
- Aliases give stable names while the underlying model evolves.
- Plugsky does not silently swap models on self-serve.
- Fallback and retry logic live in your application or an enterprise gateway.
- Route by task: cheap models for volume, strong models for hard reasoning.
How it works, step by step
- Classify your request types: extraction, drafting, reasoning, classification, embeddings.
- Assign a model or alias to each class based on quality, latency and cost requirements.
- Keep model names in configuration or a routing table, never hard-coded at call sites.
- Implement fallback: retry, then switch to an alternate model, then fail gracefully.
- Log the model used with every request so quality and cost can be attributed.
- Review routing quarterly as models and workloads change.
Try it yourself
Open the AI workload router simulator →
Explicit routing versus hidden routing
Some platforms advertise automatic routing and then quietly choose models behind a single endpoint name. That is convenient until behaviour changes without notice. Plugsky takes the explicit route: your request names the model, and an alias guarantees a stable name that maps to a documented model — updated transparently rather than swapped mid-flight. The result is predictable behaviour: what you test is what you ship, and any change to a model behind an alias is documented so you can re-evaluate.
Patterns that work
Most teams end up with a small routing table rather than sophisticated automation:
- Task-based: cheap aliases for classification, extraction and rewriting; stronger models for planning, synthesis and code generation.
- Tier-based: a fast default with escalation to a reasoning model when the first answer fails validation.
- Region-aware: route to deployments that keep data in the required jurisdiction.
- Cost-aware: cap spend per surface by pinning an economical model where quality allows.
Keep the router in your code — it is application logic, and you want it versioned, tested and observable. The free plan's two models are a practical place to prototype routing rules before committing.
What we do and what we do not do
What we do: expose 30+ models behind one OpenAI-compatible API, support stable aliases, document model changes, and offer gateway-level failover in enterprise deployments. What we do not do: silently substitute a different model when yours is unavailable. Silent routing changes output behaviour, breaks evaluations and confuses debugging — so on self-serve, a failure is a failure, and your application decides whether to retry or switch. Enterprise deployments can add automatic failover where the contract specifies it. See the model catalogue for current aliases and models.
Honest comparison
| Behaviour | Plugsky self-serve | Automatic router platform | Enterprise Plugsky gateway |
|---|---|---|---|
| Model selection | Explicit per request | Platform-chosen | Policy-based |
| Alias stability | Documented changes | Opaque | Documented |
| Silent substitution | No | Common | Only per configured policy |
| Failover | Your application | Platform-managed | Gateway-managed |
| Observability | Model logged per request | Often limited | Full routing logs |
| Best fit | Predictable, testable behaviour | Minimum-effort defaults | High-availability workloads |
Frequently asked questions
Does Plugsky route my request to a random model?
No. Your request names the model or alias, and that is what serves it. There is no hidden selection on self-serve.
What is a model alias?
A stable name that maps to a model. You pin the alias in code, and the underlying model can be updated with documentation so behaviour changes are visible.
Can I do automatic failover?
On self-serve, implement retry and model-switch logic in your application. Enterprise deployments can add gateway-level failover scoped in the agreement.
How should I choose models per task?
Start with a task-based table: cheap models for classification and extraction, stronger models for reasoning and code. Measure quality and cost per route, then adjust.
Can I route by region for residency?
Yes — choose deployments and aliases that keep processing in the required region, and confirm the region matrix for your chosen models.
Does routing cost extra?
Routing is application logic; you pay for the plan, not per route. See the live pricing page for plan tiers and fair-use terms.
How do I debug routing problems?
Log the model name, alias and request id with every call. When behaviour shifts, the log tells you whether a model changed, a fallback fired, or the prompt is at fault.