Key facts
| Router model | plugsky-fusion runs a default chain and escalates per request (live) |
| Strategies | cost_saver, balanced, max_quality and custom rules per workspace or key |
| Models | 30+ models from free tiers to frontier behind one endpoint |
| Escalation signals | Length, retries, tool errors, low confidence and high-value paths |
| Pricing | Flat monthly self-serve plans with no per-token charges on self-serve |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
| Roadmap | Classifier routing (/v1/plugsky/route, model=auto) is coming soon |
| Audit | Which model answered each request is logged and exportable |
TL;DR
- Default to cheap tiers; escalate only on measurable signals.
- Keep high-value paths on a fixed strong model via custom rules.
- Set strategies per key so batch and live traffic do not share policy.
- Watch retries and escalations — they reveal bad thresholds.
- Recheck routing monthly as traffic and prompts drift.
How it works, step by step
- Define routing tiers by task: classify, draft, extract, reason, act.
- Choose a default strategy per workspace or key, starting with cost_saver for bulk work.
- Add escalation signals: input length, retry count, tool failure, low confidence, known high-value intents.
- Pin critical paths with custom rules so they always use a strong model.
- Instrument which tier answered every request and how often escalation fired.
- Run a fixed task set at each tier and compare quality, retries and latency.
- Tune thresholds monthly and document why each rule exists.
Try it yourself
Open the AI workload router simulator →
What routing policy actually decides
A routing policy answers one question per request: which model is sufficient here? The cheapest correct answer is usually a small model for routine traffic and a large one for the tail. Implementing that as per-call engineering does not scale, so encode the policy: a default tier, escalation signals, and exceptions for paths that must never be downgraded.
Signals should be observable before or during the call — prompt length, task type, retry count, tool errors, confidence from a cheap pre-check. Avoid policies that escalate on vibes; if you cannot explain why escalation fired, you cannot tune it later.
Strategies, keys and custom rules
Use fusion strategies as named policies and scope them per workspace or key. A batch summarisation key can run cost_saver while a customer-facing assistant key runs balanced, and a compliance review path runs max_quality with a custom rule that prevents downgrades entirely.
- Keep one key per workload so limits and policies stay separable.
- Export routing logs to your analytics warehouse and join them with task outcomes.
- Version policy changes like code and annotate them with a reason.
- Reserve custom rules for a short list of paths; long exception lists defeat the default.
Proving that cheaper is still correct
Savings claims need evidence. Build a fixed task set per workload with expected outcomes, run it under each strategy, and compare success, retry and escalation rates. If a cheaper tier matches quality on the evaluation set, widen it; if it needs twice the retries, the policy is misclassified, not the model.
Review monthly. Traffic mix shifts, models improve, and prompts change; thresholds set in January are often wrong by spring. Self-serve flat plans make the cost side predictable while you tune — see the live pricing page — and the free plan with plugsky-micro and plugsky-lite is enough to build the evaluation harness before scaling.
Honest comparison
| Routing choice | Tiered routing on Plugsky | Single frontier model | Manual per-call selection |
|---|---|---|---|
| Default behaviour | Cheap tier with escalation | Strong model for everything | Engineer decides each time |
| Escalation | Automatic on signals | Not needed, but costly | Manual and inconsistent |
| Policy scope | Per workspace or key | Global | Per developer |
| Visibility | Per-request model logs | Uniform | Tribal knowledge |
| Quality evidence | Evaluation set per tier | Uniform but expensive | Rarely measured |
Frequently asked questions
What signals should trigger escalation?
Observable ones: prompt length, task type, retry count, tool errors and low confidence from a cheap pre-check. High-value intents can be pinned with custom rules instead of relying on signals.
Do fusion strategies cover everything?
They cover the common patterns — cost_saver, balanced and max_quality — and custom rules cover exceptions. Classifier routing with model=auto is coming soon for automatic per-request classification.
Will routing add latency?
Fan-out or a pre-check can add overhead. Measure it against your latency budget and use cost_saver or balanced for interactive paths, reserving heavier routing for asynchronous work.
How do I stop a critical path from being downgraded?
Pin it with a custom rule or a dedicated key that runs max_quality. Keep the list of pinned paths short and documented.
How do I audit routing decisions?
The router logs which model answered each request and why escalation fired; export those logs to your warehouse and join them with task outcomes to prove quality per tier.
What happens on self-serve flat plans?
There are no per-token charges, so routing mainly affects latency, throughput and fair-use headroom rather than a variable bill. See the live pricing page for plan details.
How often should I re-tune thresholds?
Monthly at minimum, and after any prompt redesign, model release or traffic shift. Routing policies age faster than people expect.
Can I evaluate routing for free?
Yes. Start with plugsky-micro and plugsky-lite on the free plan, and use the 14-day full-access trial to compare stronger tiers on your own task set.