How does plugsky-fusion model routing work?

Key facts

Router model	Set model: "plugsky-fusion"
Strategies	cost_saver, balanced, max_quality, custom
Inputs	Token count, tool calls, prompt heuristics, workspace setting
Scope	Per workspace, per API key or per request
Overrides	Send a specific model name to bypass routing
Audit	Logs record chosen model, strategy and matching rule
Classifier routing	POST /v1/plugsky/route (model=auto) is coming soon
Product status	Live (plugsky-fusion)

TL;DR

• plugsky-fusion picks a model per request instead of one fixed model.
• balanced is the default; cost_saver, max_quality and custom change the bias.
• Set the strategy per workspace, per API key or per individual request.
• Specific model names bypass routing when you need determinism.
• Every decision is logged with the model, strategy and rule.

How it works, step by step

1. Choose a default strategy for the workspace in the dashboard.
2. Set model to plugsky-fusion in your requests (or per API key).
3. Add custom rules if your workload has clear markers, such as refactor prompts.
4. Test routing decisions against a sample of real traffic.
5. Read the request logs to confirm which rule fired and which model answered.
6. Override with a fixed model for latency-critical or regulated endpoints.

Try it yourself

Open the model picker →

How routing decides

When a request arrives with model: "plugsky-fusion", the router inspects the request before inference: input token count and expected output size, whether tools are present and how complex they are, prompt heuristics such as domain, language and length, and the strategy configured for the workspace. It then selects a model from your tier. The router runs inside the API gateway, so there is no extra network hop in your client.

The four strategies

• cost_saver — picks the cheapest model that can handle the call and falls back to a stronger model on failure.
• balanced — the default: mid-tier for most calls, cheap for trivial prompts, strong for hard ones.
• max_quality — always the strongest model available in your tier.
• custom — evaluates your dashboard rules in order, first match wins.

Strategy can be set per workspace, per API key or per request, which makes it practical to run cost-sensitive batch jobs and quality-sensitive interactive traffic on the same account.

Writing custom rules

Custom rules map a condition to a model. Typical examples from the reference: prompts containing a keyword such as refactor go to a coding model; prompts above 4,000 input tokens go to a long-context or frontier model; traffic from free-plan users goes to a free model; business-hours traffic goes to a stronger default. Rules evaluate in order and the first match wins, so put the most specific conditions first and leave a sensible default for everything else.

Overriding, auditing and caveats

To bypass routing for one call, send a concrete model name instead of plugsky-fusion. Every request log records the chosen model, the strategy and, for custom rules, the rule that fired, so routing is observable rather than magic. One caveat: classifier-based routing through POST /v1/plugsky/route with model=auto is listed as coming soon in the docs and is not accepted by chat completions today. Use plugsky-fusion for production routing now.

Honest comparison

Capability	plugsky-fusion	One fixed model	Self-built router
Model choice per request	Automatic	None	You write classifiers
Cost control	cost_saver strategy	Manual	Custom logic
Quality control	max_quality strategy	Fixed	Custom logic
Rules	Dashboard rules, first match wins	Not applicable	Code deployments
Audit trail	Model, strategy and rule logged	Model only	You build logging
Maintenance	Managed	None	Ongoing engineering