Key facts
| How to call it | model="plugsky-fusion" on POST /v1/chat/completions |
| Chain modes | Sequential, parallel and cost-saver, configured per workspace |
| Response | The model field names the underlying model that answered |
| Typical savings | Docs describe 60-80% savings on production traffic versus always running frontier models |
| Configuration | Managed from the Model Fusion section of the dashboard |
| Fallback | Chains route around unhealthy upstreams automatically |
| Plan availability | Model Fusion is a paid-platform capability; the free plan locks it |
| Product status | Live |
TL;DR
- One model name, many models: orchestration moves into the platform.
- Sequential chains refine an answer; parallel chains compare candidates.
- Cost-saver routes easy traffic to cheap models and hard traffic upward.
- The response names the model that answered, so analytics still work.
- Free-plan accounts do not include Fusion — check the live pricing page.
How it works, step by step
- Baseline quality and cost on your real traffic with a single frontier model.
- Create a Fusion chain in the dashboard and choose the mode for the workload.
- Set model=plugsky-fusion in a staging environment and log the returned model per response.
- Compare answer quality, latency and failure behaviour against the baseline.
- Split traffic between fusion and direct calls to measure the effect per segment.
- Promote fusion for the workloads where it wins; keep direct calls where determinism matters.
- Review the chain when the catalogue changes so routing stays intentional.
Try it yourself
Open the LLM cost calculator →
How a fusion chain works
The application makes one ordinary chat completion. Behind that model name, the platform runs the chain your workspace defines:
resp = client.chat.completions.create(
model="plugsky-fusion", # runs the workspace's default chain
messages=[{"role": "user", "content": "Summarise this contract clause"}],
)
print(resp.model) # which model actually answered, e.g. plugsky-microBecause the interface is unchanged, fusion is reversible: remove the model override and you are back to direct calls, with no code to unwind.
The three chain modes
- Sequential: a cheap model drafts, a stronger model refines. Useful for summarisation and rewriting where a second pass improves structure without doubling peak cost on every request.
- Parallel: multiple models answer, and the chain selects or synthesises. Best for high-stakes one-shot questions where latency budget allows a fan-out.
- Cost-saver: a classifier routes simple prompts to small models and escalates only the hard ones. This is the mode that produces the largest savings on mixed traffic.
Pick one default per workload rather than one global chain. Support summarisation and contract review have different economics.
Measuring whether fusion is worth it
Run the comparison as an experiment, not a vibe. Hold the prompt fixed, send the same requests to plugsky-fusion and to your baseline model, and record quality scores from your own eval set alongside latency percentiles and the returned model field. Segment results by task type, because fusion chains help classification and extraction far more than long-form reasoning. Watch for two failure modes: quality regressions on edge cases that the cheap path mishandles, and chains that escalate almost everything, which erases the savings while adding a hop of latency.
Where fusion does not replace engineering
Fusion is not a substitute for retrieval, tool design or evaluation. A cost-saver chain cannot fix a prompt missing context, and a parallel chain cannot validate facts it was never given. If your workload needs deterministic output, pinned model versions or regulated audit of every intermediate step, direct calls with explicit model names are easier to reason about. Fusion is an optimisation layer for teams that already have an eval harness and want the savings without building a router. Check /docs for current chain options and /models for the models available to your chain.
Honest comparison
| Capability | Plugsky Model Fusion | Hand-built router | Single frontier model |
|---|---|---|---|
| Orchestration code | Platform-managed chain | You build and maintain it | None |
| Chain modes | Sequential, parallel, cost-saver | Whatever you implement | Not applicable |
| Savings potential | 60-80% per docs on production traffic | Depends on routing quality | None |
| Observability | Response names the answering model | Your logging only | One model to track |
| Failure handling | Routes around unhealthy upstreams | Your responsibility | Rides one provider |
| Determinism | Lower — chain may vary | You control it | Highest |
Frequently asked questions
What is Model Fusion in one sentence?
It is a platform-managed chain of models behind the single model name plugsky-fusion, so multi-model quality does not require orchestration code in your app.
How do I call it?
Send a normal chat completion with model="plugsky-fusion". The workspace's default chain runs and the response model field names the underlying model that answered.
What are the chain modes?
Sequential (cheap draft, stronger refine), parallel (multiple answers compared or synthesised) and cost-saver (classifier routes easy prompts to cheaper models). Choose per workload in the dashboard.
How much can fusion save?
The docs describe typical savings of 60-80% on production traffic versus running frontier models for everything. Measure against your own eval set before assuming that number.
Is fusion available on the free plan?
No. Model Fusion is locked on the free plan, which includes two free AI models. See the live pricing page for current plan details.
Can I see which model answered?
Yes. The response model field identifies the underlying model, and per-request logs keep model-level observability even when your app calls one fusion name.
Does fusion add latency?
A chain adds at least one hop, and parallel modes add fan-out. Cost-saver chains usually stay close to single-model latency for easy prompts; measure percentiles, not averages.
When should I not use fusion?
When you need deterministic output, pinned model versions or audit of every intermediate step. Direct calls with explicit model names remain the safer choice for those cases.