Feature × Audience

How do enterprise architects standardise model choice with Plugsky Model Fusion?

Enterprise architects use Plugsky Model Fusion to collapse dozens of per-team model choices into one governed endpoint. Teams send model="plugsky-fusion"; the platform selects a model from the tier according to a strategy set per workspace, per key or per request, and every decision is logged. Governance, residency and observability become platform properties instead of team-by-team engineering.

Key facts

Standard interfaceOne OpenAI-compatible endpoint for 30+ models
Router modelmodel="plugsky-fusion" selects the model per request (live)
Policy surfaceStrategies and custom rules scoped to workspace, API key or request
Decision logModel, strategy and matching rule recorded for every request
DeploymentCloud, VPC, on-prem, air-gapped and bring-your-own-cloud topologies
ResidencyRegion pinning with data staying in the pinned region
Availability99.9% to 99.95% uptime SLAs, 99.99% on multi-region deployments
RoadmapClassifier routing /v1/plugsky/route (model=auto) is coming soon

TL;DR

  • Give every team one endpoint instead of N provider integrations.
  • Express policy as strategies and rules rather than code reviews.
  • Use decision logs as the evidence layer for audits and chargeback.
  • Choose topology once: cloud, VPC, on-prem, air-gapped or BYOC.
  • Keep deterministic overrides for tier-one and regulated systems.

How it works, step by step

  1. Inventory current model usage by team, including providers, regions and monthly cost drivers.
  2. Define service tiers: what may run on cheap models, what needs strong reasoning, and what must be deterministic.
  3. Encode those tiers as strategies and custom rules per workspace or key.
  4. Choose a deployment topology and residency per workload before migration, not after.
  5. Migrate one workload at a time, comparing quality and cost against its old provider.
  6. Wire routing logs and SLA-relevant metrics into your observability stack, and review rule changes like any other change.
1Inventory currentmodel usage byteam, including2Define servicetiers: what may runon cheap models,3Encode those tiersas strategies andcustom rules per4Choose a deploymenttopology andresidency per5Migrate oneworkload at a time,comparing quality6Wire routing logsand SLA-relevantmetrics into your

Original data

One OpenAI-comStandard interface99.9% to 99.95AvailabilityClassifier rouRoadmapSource: Plugsky facts table · updated 2026-09-26

Try it yourself

Open the agent workflow designer →

One endpoint, many workloads

The architectural win is subtraction. Instead of every team integrating its own provider SDK, key rotation and retry logic, the organisation standardises on one OpenAI-compatible endpoint that fronts 30+ models. Teams send model: "plugsky-fusion" and receive a result; the platform chooses the model.

That single interface also simplifies exit and entry: a new model tier does not require a new integration, and a workload can move between tiers by configuration. Reference architectures that previously needed a gateway, a router and a secrets layer reduce to one dependency with well-defined behaviour.

Policy as configuration

Strategy is where governance becomes concrete. Set balanced as the default for general traffic, cost_saver for batch and internal tools, and max_quality for customer-facing or regulated paths. Custom rules evaluate in order, so you can express things like "documents over 4,000 tokens go to a long-context model" without shipping code.

  • Scope: strategies can be attached to a workspace, an API key or a single request.
  • Overrides: any explicit model name bypasses routing, giving you a deterministic escape hatch.
  • Evidence: each request logs the model, strategy and rule, giving auditors a readable decision chain.

Topology, residency and resilience

Model choice is only half the architecture; where inference runs is the other half. Plugsky supports multi-tenant cloud with region pinning, VPC deployment inside AWS, GCP, Azure or OCI, on-prem Helm installs, fully air-gapped bundles and a bring-your-own-cloud option where inference runs in your account.

Resilience should be designed with the same intent: multi-region deployments carry a 99.99% SLA, while single-region enterprise commitments sit at 99.95%. Pair that with the router's automatic fallback behaviour and a fixed-model override for the systems that cannot tolerate variation, and the platform story holds together under audit.

Honest comparison

ConcernPlugsky Model FusionDIY model gatewaySingle-vendor lock-in
Model access30+ models, one endpointOne integration per providerOne catalogue
Policy controlsStrategies and rules, scopedCustom codeVendor tooling
Decision loggingModel, strategy, rule per requestYou build itVendor logs
DeploymentCloud, VPC, on-prem, air-gapped, BYOCWhatever you hostVendor regions
AvailabilitySLAs to 99.99% multi-regionYour own resilienceVendor SLA

Frequently asked questions

How do we enforce different policies per team?

Attach strategies per workspace or per API key. Teams keep their own keys and limits while the platform applies a consistent default.

Can we prove which model handled a request?

Yes. Every request records the chosen model, the strategy and the rule that fired, plus token, latency, status, key, project and region metadata.

What happens if the preferred model fails?

The router escalates or falls back based on strategy and availability, and you can pin a fixed model where automatic fallback is not acceptable.

Which deployment models exist?

Multi-tenant cloud with region pinning, VPC inside your hyperscaler account, on-prem, air-gapped and bring-your-own-cloud.

What SLA can we expect?

Builder and Scale tiers carry 99.9% monthly uptime with 10% credit on miss, Enterprise 99.95% with 25% credit, and 99.99% on multi-region deployments.

How do we migrate teams off other providers?

Move one workload at a time onto the same endpoint, compare quality and cost, then standardise. The API stays OpenAI-compatible, so client code rarely changes.

Is automatic classifier-based selection available?

Not yet — POST /v1/plugsky/route with model=auto is coming soon. Today, strategies and custom rules handle per-request selection.