Key facts
| Router model | model="plugsky-fusion" with strategies and ordered rules (live) |
| Strategy catalogue | cost_saver, balanced, max_quality and custom; scoped per workspace, key or request |
| Override policy | Explicit model names bypass routing where determinism is required |
| Decision log | Model, strategy and rule recorded per request, exportable to SIEM |
| Availability | Fallback and escalation behaviour configured per strategy |
| SLA | 99.9% to 99.95% single-region, 99.99% on multi-region deployments |
| Residency | Region pinning plus VPC, on-prem, air-gapped and BYOC topologies |
| Roadmap | Classifier routing /v1/plugsky/route (model=auto) is coming soon |
TL;DR
- Publish a strategy catalogue instead of letting every team pick models ad hoc.
- Encode exceptions as scoped overrides, not informal tribal knowledge.
- Use the decision log as your governance and chargeback evidence.
- Plan availability behaviour per workload class, not globally.
- Standardise on one endpoint to shrink integration and secret sprawl.
How it works, step by step
- Define workload classes with quality, latency and compliance requirements.
- Map each class to a strategy and decide where deterministic overrides are mandatory.
- Scope strategies per workspace or key so teams inherit policy by default.
- Track model availability and fallback behaviour as part of service management.
- Wire routing logs into your observability and audit stack.
- Change rules through normal change management, with an evaluation set and a rollback plan.
Try it yourself
Open the model availability tracker →
A strategy catalogue for the organisation
Routing's biggest architectural benefit is that model choice becomes a small, reviewable catalogue instead of a per-team decision. Define three or four strategy profiles — interactive, standard, high-assurance, batch — and map them to your workload classes. Teams opt in by sending model: "plugsky-fusion" and inheriting the profile attached to their workspace or key.
The catalogue also gives you a place to record exceptions. When a system needs a fixed model for reproducibility, that becomes a documented override on a specific key, not an undocumented habit that outlives the engineer who set it.
Availability and failure behaviour
Every routing strategy implies a failure model. Cost-first strategies fall back or escalate when the cheap model cannot handle a prompt; balanced escalates on hard inputs; fixed overrides fail on their own terms, so you must decide retry and degradation behaviour for them explicitly.
- Track availability: treat model availability as a first-class dependency with the same monitoring as any API.
- Design degradation: decide what users see when a premium tier is unavailable — a slower answer, a queued answer, or an explicit apology.
- Multi-region: multi-region deployments carry a 99.99% SLA versus 99.95% single-region Enterprise commitments.
Governance, evidence and change control
Governance is easier when the platform produces the evidence. Each request logs the chosen model, the strategy and the rule that fired, alongside tokens, latency, status, key ID, project and region. That becomes your audit trail for model risk reviews and your source of truth for internal chargeback.
Change control should treat a routing rule like production code: behind a review, deployed gradually, and revertible. Because an explicit model name bypasses the router, rollback of a misbehaving rule can be as simple as pinning the affected endpoint while you investigate.
Honest comparison
| Concern | Plugsky routing | Custom API gateway | Per-team model choices |
|---|---|---|---|
| Policy surface | Strategy catalogue plus ordered rules | Custom plugins | Informal decisions |
| Decision evidence | Model, strategy and rule per request | You build logging | Inconsistent |
| Availability behaviour | Configured per strategy | Custom fallback code | Varies by team |
| Deployment | Cloud, VPC, on-prem, air-gapped, BYOC | Wherever you host | Provider-specific |
| Governance overhead | Configuration review | Platform maintenance | Audit surprises |
Frequently asked questions
How do we enforce routing policy across teams?
Attach strategies per workspace or API key so teams inherit the default for their workload class, and make overrides an explicit, reviewed exception.
Can we audit why a model was chosen?
Yes. Each request records the model, strategy and matching rule, with token, latency, status, key, project and region metadata available for export.
What happens when a model is unavailable?
Fallback and escalation follow the strategy; deterministic endpoints pin a model and need an explicit degradation plan.
What SLAs are available?
Builder and Scale carry 99.9% monthly uptime, Enterprise 99.95% with 25% credit on miss, and 99.99% on multi-region deployments.
How do we plan residency per business unit?
Pin each workspace to a region, or use VPC, on-prem, air-gapped and bring-your-own-cloud topologies for stricter requirements.
How should migrations be sequenced?
Move one workload class at a time onto the standard endpoint, compare against its previous provider on your own evaluation set, then standardise the next.
Is automatic classifier routing available now?
Not yet — /v1/plugsky/route with model=auto is coming soon. Strategies and ordered custom rules are live today.