Key facts
| Router model | Set model="plugsky-fusion" to fan out, select and escalate per request (live) |
| Fan-out | Parallel fan-out across model tiers with best-result, vote and merge selection |
| Escalation | Default chain escalates from plugsky-micro to plugsky-pro and frontier tiers on hard prompts |
| Strategies | cost_saver, balanced (default), max_quality and custom rules |
| Decision log | Every request records the chosen model, strategy and matching rule |
| Cost shape | Flat self-serve plans; no per-token charges, fair-use RPM per tier |
| Residency | Region pinning plus VPC, on-prem and air-gapped deployment |
| Roadmap | Classifier routing POST /v1/plugsky/route (model=auto) is coming soon |
TL;DR
- Keep high-volume triage on cheap tiers and escalate regulatory drafts automatically.
- Set the strategy per workspace, per API key or per request.
- Every fusion decision is logged with model, strategy and rule.
- Flat plans remove per-token surprises from multi-model patterns.
- Pin inference to a region and keep deterministic overrides for regulated endpoints.
How it works, step by step
- Classify workloads by risk and volume: alert triage, document extraction, analyst drafting, regulatory reporting.
- Set a default strategy per workspace and per key, starting with balanced.
- Opt in by sending model="plugsky-fusion" and test routing against historical traffic.
- Add custom rules for predictable markers, such as long documents or policy keywords.
- Keep a fixed model name on endpoints where determinism is mandatory.
- Read the request logs to confirm which model answered and why, then export audit events to your SIEM.
Try it yourself
Tiering that matches the bank's risk model
Not every request deserves a frontier model, and not every request can use a cheap one. Plugsky Model Fusion maps that judgement to configuration: send model: "plugsky-fusion" and the router fans out across tiers, selecting the strongest result where quality matters and the cheapest adequate result where it does not.
The default chain escalates from plugsky-micro to plugsky-pro and frontier models when prompts are hard, long or tool-heavy. Banks typically keep alert triage and document extraction on the cheap end, then let drafting, policy questions and regulatory summaries escalate.
Defensible decisions and audit
Regulators ask two questions about AI: what did it decide, and who can prove it. Fusion answers both with a decision log. Every request records the model chosen, the strategy and the rule that fired, alongside request metadata such as tokens, latency, status, key ID, project and region.
- Export: key lifecycle and inference events stream to Splunk, Sentinel, QRadar or Chronicle.
- Determinism: send a specific model name to bypass routing for endpoints that require a fixed decision path.
- Residency: pin workspaces to me-central-1, sa-central-1, eu-west-1, eu-central-1, us-east-1, us-west-2 or ap-southeast-1.
Cost, capacity and rollout
Self-serve plans are flat monthly with unlimited fair-use usage, so multi-model patterns do not multiply your invoice the way per-token billing would. The only operational limit is the fair-use request rate for your tier, which is easier to plan around than variable token spend.
Pilot on one workflow with a fixed evaluation set, compare fusion against your current single-model baseline on both quality and cost, then widen the scope. Where data cannot leave the bank, the same API runs in your VPC, on-prem or air-gapped. The classifier endpoint for automatic model selection is coming soon; today's strategies and rules cover most routing needs.
Honest comparison
| Concern | Plugsky Model Fusion | Manual model selection | Always-frontier |
|---|---|---|---|
| Tiering | Automatic fan-out and escalation | Engineer decides per call | One strong model for all calls |
| Escalation | Default chain micro to pro to frontier | Manual retries | Not applicable |
| Decision logging | Model, strategy and rule per request | Partial or none | Single model, no choice |
| Cost shape | Flat plans, fair-use RPM | Varies by tokens | Highest quality cost |
| Residency | Region pinning plus VPC and air-gapped | Provider dependent | Provider dependent |
Frequently asked questions
What exactly is Model Fusion?
It routes each request across multiple models: Plugsky fans out to several tiers, selects the best result, and escalates to stronger models when a prompt is hard. You opt in by setting model="plugsky-fusion".
Which models does fusion consider?
The router selects from your tier across the platform's 30+ models, from plugsky-micro and plugsky-lite up to plugsky-pro and frontier tiers, with usage-based fine-tuned options on enterprise plans.
How do we know which model answered?
Every request logs the chosen model, the strategy and the rule that fired, alongside tokens, latency, status, key ID, project and region.
Can we force one model for regulated flows?
Yes. Sending a specific model name bypasses routing entirely, which keeps deterministic endpoints deterministic.
Does fusion add latency?
Fan-out and escalation add some overhead versus a single fixed model. For latency-critical flows, use cost_saver or balanced, or pin a fixed model — measure on your own traffic before deciding.
Can we run fusion in our own environment?
Yes. The same routing layer runs in your VPC, on-prem or air-gapped deployments.
How do we start without a procurement cycle?
Validate on the free plan with plugsky-micro and plugsky-lite, benchmark paid tiers on the 14-day full-access trial, then choose a plan. See the live pricing page for details.