Key facts
| Router model | model="plugsky-fusion" includes a balanced default out of the box (live) |
| Strategies | cost_saver, balanced, max_quality and custom rules |
| Scoping | Per workspace, API key or request — set dev and prod apart |
| Overrides | Explicit model names bypass routing |
| Free plan | Two free AI models — plugsky-micro and plugsky-lite — with no card |
| Trial | 14-day full-access trial for paid-tier models |
| Cost shape | Flat self-serve plans; no per-token charges on self-serve |
| Roadmap | Classifier routing /v1/plugsky/route (model=auto) is coming soon |
TL;DR
- Ship on balanced first; it handles most early-stage traffic well.
- Give dev and CI keys cost_saver so experiments do not matter.
- Add a long-input rule when you start handling documents.
- Pin models for customer-critical endpoints you must reproduce.
- Keep flat pricing so growth does not arrive with a bill spike.
How it works, step by step
- Turn on model="plugsky-fusion" with the default balanced strategy and ship.
- Separate keys per environment and put development on cost_saver.
- Watch which requests escalate for two weeks before writing any rule.
- Add one rule at a time — start with a token threshold for long inputs.
- Pin a fixed model for any endpoint where customers would notice variation.
- Revisit strategies monthly; remove rules that no longer earn their place.
Try it yourself
The default that just works
Early-stage teams should not spend a sprint building a router. The balanced strategy is the default for a reason: mid-tier for most calls, cheap for trivial prompts, strong for hard ones. Turning it on is a model-string change, and it behaves sensibly across the messy mix of prompts a young product actually receives.
Keep it boring until you have data. Routing logs tell you which requests escalated and which stayed cheap; that distribution, not intuition, is what should drive your first rule.
The first rules worth writing
When you do add rules, start with the ones that pay for themselves immediately. A token-threshold rule keeps long inputs off small models. A development-key strategy keeps CI and demos on cost_saver. A pinned model on your signup or billing assistant gives reproducibility where a customer will notice.
- One at a time: add a rule, watch the logs, keep it only if the distribution improves.
- Clear markers: token count, environment, key and tool use are reliable; sentiment or topic heuristics are not.
- Instant rollback: an explicit model name bypasses routing, so you can always fall back.
Cost predictability while you scale
The startup-specific risk of multi-model systems is that experimentation multiplies spend. Flat self-serve plans with unlimited fair-use usage and no per-token charges remove that risk: you can test strategies without watching a meter, and a growth spurt changes request volume rather than your invoice shape.
The free plan with plugsky-micro and plugsky-lite is enough to build the first version, and the 14-day full-access trial covers benchmarking paid tiers. Keep the OpenAI-compatible endpoint in place, and if you outgrow self-serve, the same API scales with you rather than forcing a rewrite.
Honest comparison
| Concern | Plugsky routing | Building a router | One cheap model |
|---|---|---|---|
| Time to value | One model string | Weeks of work | Immediate |
| Quality on hard prompts | Escalates by strategy | Depends on your logic | Capped by model |
| Dev versus prod | Strategies per key | Custom flags | Same model everywhere |
| Observability | Model and rule logged per request | You build it | One model |
| Cost shape | Flat monthly, fair-use RPM | Per-token infrastructure | Per token or flat |
Frequently asked questions
Do I need routing on day one?
No. Start with balanced and ship. Add rules when the logs show a pattern worth optimising, not before.
What is the cheapest setup?
The free plan includes plugsky-micro and plugsky-lite with no card; development keys can then run cost_saver on paid plans during the 14-day full-access trial.
How do I keep CI costs down?
Give development and CI their own API key with a cost_saver strategy, separate from production keys.
Can I change models later?
Yes. Explicit model names bypass routing, and the API stays OpenAI-compatible, so model changes remain a string change.
Will routing hide quality problems?
No, the logs show which model answered each request. If a cheap model is answering something it should not, the escalation pattern makes it visible.
What if we raise a round and scale fast?
Self-serve plans are flat with unlimited fair-use usage, so scaling traffic changes your request rate rather than per-token cost. Enterprise terms cover higher volumes.
Is there a classifier mode?
It is coming soon as POST /v1/plugsky/route with model=auto. Today, balanced plus explicit rules covers the same ground manually.