Key facts
| Definition | Fusion chains several models behind one request — draft, verify or escalate |
| Pattern: draft and verify | A cheap model drafts; a stronger model checks or rewrites the answer |
| Pattern: escalation | Small models handle routine traffic; hard cases route up a tier |
| Pattern: ensemble | Run two models and reconcile when accuracy outweighs cost |
| Building blocks | 30+ models behind one OpenAI-compatible endpoint |
| Routing | Model choice is a runtime decision — no code rewrite |
| Cost control | Self-serve plans are flat monthly with fair-use usage |
| Product status | Live |
TL;DR
- Fusion is a chain of models, not a single magic model.
- Most traffic stays on cheap tiers; strong models handle only what fails.
- Draft-and-verify protects quality without upgrading every request.
- Escalation on validation failure is the highest-leverage pattern.
- Measure the saving with your own evals — never assume it.
How it works, step by step
- Baseline quality and usage: how often does a single cheap model actually fail?
- Define an objective validator — schema check, citation check, unit test or judge rubric.
- Implement draft-and-verify: cheap model first, stronger model only on validation failure.
- Cap escalation attempts per request so a bad case cannot loop.
- Log which model answered, why it escalated and what the outcome was.
- Compare cost and quality against the single-model baseline before rolling out.
- Review routing thresholds monthly and after every model-card change.
Try it yourself
Open the LLM cost calculator →
What model fusion actually means
Fusion is an architecture, not a product feature: several models cooperate on one request instead of one model doing everything. The common shapes are a draft-and-verify chain (cheap model answers, stronger model reviews), an escalation chain (small model answers, hard cases route up), and an ensemble (two models answer and a reconciler or judge picks one).
The key is that only a minority of requests need the expensive path. If your validator can reliably spot the failures, the strong model is paid for on the tail, not on every call.
Where the savings come from
The economics are simple: if routine requests pass validation on a small tier and only a fraction escalate, the blended cost sits close to the small model. That ratio — the escalation rate — is the number to measure, because it decides whether the chain saves anything at all.
- Keep the first hop on the free or smallest tier that passes for the task.
- Use deterministic validation wherever possible: schemas, citations, tests, regexes.
- Cache answers for repeated questions instead of re-running the chain.
- Send the failing evidence, not the whole conversation, to the stronger model.
On Plugsky, self-serve plans are flat monthly with fair-use usage rather than per-token billing, so check the live pricing page for how plans map to your volume.
Implementing fusion safely
A fusion chain is production code, so treat it like one: version the prompts, cap retries, and make the failure path explicit. If validation fails after the escalation cap, return a safe fallback or hand the request to a human rather than looping.
Log model name, escalation reason and outcome for every request — that data tells you whether thresholds should move. Start with two models and one validator; add more only when the data justifies it. See model routing for the routing layer that makes model choice a configuration decision.
Honest comparison
| Pattern | How it works | Cost profile | When it pays off |
|---|---|---|---|
| Single small model | One cheap model handles everything | Lowest cost, weakest tail | Simple, low-risk tasks |
| Draft and verify | Cheap draft, strong review | Low with occasional strong calls | Structured outputs and code |
| Escalation | Route only failures up a tier | Low, scales with failure rate | High pass rate on the cheap tier |
| Ensemble | Two models plus a reconciler | Highest | High-stakes decisions |
| Router plus chain | Classify first, then chain per task | Tunable per task type | Mixed workloads |
Frequently asked questions
What is model fusion in plain terms?
It is using more than one model to answer a single request — for example a small model drafts and a stronger model verifies, or a router sends only hard requests to an expensive tier.
Does Plugsky have a fusion endpoint?
Plugsky exposes 30+ models behind one OpenAI-compatible endpoint, so fusion is implemented as a chain your code controls. Check the docs for the current status of platform-side routing features.
How much can fusion save?
That depends entirely on your escalation rate and validator. Measure the share of requests that must reach a stronger model; the lower that share, the closer the blended cost sits to the cheap tier.
What makes a good validator?
Anything deterministic: JSON schema checks, citation verification, unit tests, regex rules or a scored rubric. Weak validators let bad answers pass and erase the saving.
Can I build this on the free plan?
Yes — plugsky-micro and plugsky-lite are free with no card required, which is enough to prototype a draft path. Use the 14-day full-access trial to test the stronger tiers in the chain.
How do I stop runaway escalation?
Cap attempts per request, send compact failure evidence, and return a safe fallback or human handover after the cap instead of looping.
How is pricing structured?
Self-serve plans are flat monthly with fair-use usage rather than per-token billing. See the live pricing page for current plans and limits.