Key facts
| Router model | model="plugsky-fusion" applies a per-client chain (live) |
| Cheap-first chain | Default escalation runs micro to pro to max, keeping routine volume cheap |
| Per-client control | Strategies scoped per workspace or API key, one project per client |
| Cost model | Flat self-serve plans; no per-token charges, fair-use RPM per tier |
| White-label | Deliver under your own brand across all clients |
| Observability | Model, strategy and rule logged per request; tokens returned in every response |
| Residency | Pin each client workspace to the region their contract requires |
| Roadmap | Classifier routing /v1/plugsky/route (model=auto) is coming soon |
TL;DR
- Default every client to a cheap-first chain with automatic escalation.
- Give each client a project, strategy and scoped keys of their own.
- Use flat pricing to keep margins stable as usage grows.
- Show clients routing logs as proof of where their requests ran.
- Escalate selectively — premium models only where tickets are hard.
How it works, step by step
- Standardise a single fusion chain and tune it once, instead of maintaining a model stack per client.
- Create one Plugsky project and key set per client, each with its own default strategy.
- Route triage and routine support to cheap tiers, and let the chain escalate complex tickets automatically.
- Set premium strategies only for clients or queues that pay for them.
- Pin each workspace to the contractually required region and configure retention accordingly.
- Report per-client routing and token telemetry through your portal to demonstrate value and control.
Try it yourself
Open the LLM cost calculator →
Cheap-first economics, per client
An MSP's AI margin is decided by what runs on premium models. With model: "plugsky-fusion", every client workspace can run a cheap-first chain: routine classification, summarisation and answer drafting go to plugsky-micro or plugsky-lite, and only hard or ambiguous tickets escalate up the chain.
Because escalation is automatic, you do not need humans deciding model quality in real time. You tune the chain once, set a strategy per client, and the router handles the rest. Flat self-serve plans remove per-token charges, so more successful resolutions do not shrink the margin on that client.
Per-client isolation and control
A shared blob of AI usage is unmanageable at scale, and clients notice. Give each client a project with scoped keys, its own retrieval collection and its own default strategy. Onboarding becomes a checklist, and offboarding is a key revocation rather than an archaeology project.
- Residency: pin each workspace to the region the contract requires — GCC, EU, US or APAC.
- Overrides: if a client requires a fixed model for compliance, pin it on their key.
- Audit: key and inference events are exportable to your SIEM for incident reviews.
Demonstrating value without per-token billing
Clients want to see value, not model names. Fusion logs give you the story: how many requests ran on fast, cheap models, how many escalated, and how often routing changed the outcome. Token usage returns in every response for internal reporting even though it does not drive billing.
Deliver the whole service white-label, expose only your portal, and keep Plugsky behind the API. When a client asks how costs are controlled, show the routing distribution rather than an invoice breakdown that would leak your unit economics.
Honest comparison
| Concern | Plugsky Model Fusion | Reselling per-token APIs | Self-hosted ensemble |
|---|---|---|---|
| Client unit cost | Cheap-first chains, flat plans | Per-token, variable | GPU plus ops |
| Escalation | Automatic on hard prompts | Manual or none | Custom logic |
| Multi-tenancy | Project and key per client | Account per client | You build isolation |
| White-label | Full brand control | Provider branding leaks | Fully yours |
| Ops burden | Configuration only | Billing reconciliation | You run everything |
Frequently asked questions
How does fusion protect margin?
Most traffic stays on cheap tiers by default and escalates only when a prompt is hard. Flat self-serve plans mean no per-token charges, so volume growth does not become variable cost.
Can each client have a different chain?
Yes. Strategies can be set per workspace or key, so each client can run its own default, premium threshold and override rules.
Is client data kept separate?
Projects and scoped keys separate retrieval, logs and limits. Keys are rotatable and revocable without downtime.
Can we white-label the service?
Yes. Deliver chatbots, portals and reports under your own brand while Plugsky stays behind the API.
How do we prove value to clients?
Share routing summaries and resolution metrics from your portal. Logs record model, strategy and rule for every request, and tokens return in each response.
What about clients with residency requirements?
Pin each workspace to the required region, or use VPC, on-prem and air-gapped deployment for stricter contracts.
How should we start?
Run one client on a balanced or cost_saver strategy, measure quality and routing distribution for two weeks, then template that setup across your book.