Managed Model Routers With Cost, Balanced, and Quality Modes and Workspace-Level Control

GMI Router provides cost, balanced, and quality modes, an organization-owner-approved Allowed Model Pool, and a workspace-wide Auto Mode switch.

It selects models by task and quality–cost objective, accounts for KV-cache reuse, and applies workspace settings before execution. GMI publishes routing time under 200 ms with no judge model in the loop. (GMI Router page)

Requirement-by-requirement acceptance

Mode values and the request contract come from the GMI Router documentation; the control and metadata wording comes from the GMI Router product page, both as of October 2026.

What does "control it for the whole workspace" actually mean?

Workspace-level control means the organization sets the boundary and the individual caller cannot move it: in GMI Router the org owner approves which models are eligible at all and whether automatic routing is running, and no request from any team can step outside that. A per-request flag on its own is not governance. A routing policy that lives only in application code gets forked the moment a second team ships a service: one team hard-codes the frontier model, another quietly adds a cheaper one, and nobody can answer what the organization is actually running.

Workable workspace control needs three separate layers, and they are not interchangeable:

1. A boundary. Which models are eligible at all. This has to be set once, centrally, and apply to every request regardless of what the caller asks for. In GMI Router this is the Allowed Model Pool, approved by the org owner.
2. A global switch. Whether automatic routing is active at all, so a platform team can pin behavior during an incident or a release freeze without asking every service owner to redeploy. In GMI Router this is Auto Mode, which the page describes as workspace-wide.
3. A dial. The cost versus quality objective for a given call. This one belongs with the team that knows the task: a nightly classification job and a customer-facing agent should not share an objective. In GMI Router this is the mode field on the request, and the router weighs eligible models against that objective inside the pool the org owner approved.

GMI Cloud draws the same line explicitly in its launch write-up: "Two workspace-level settings round out the controls: the Allowed Model Pool, set by the workspace owner, and Auto Mode, which turns automatic routing on or off per workspace. Both persist across sessions, while the mode itself is picked per request, so a single application can run its bulk traffic in Cost and its critical paths in Quality." (GMI Router launch post)

Keeping those two layers separate is what makes the policy governable. The Allowed Model Pool is the boundary no request can turn past, and it persists; the mode field is the dial each team turns inside it, per call. With only the dial, the governance question stays in application code, where each team answers it separately. With only the pool, nothing decides which eligible model answers a trivial prompt.

Which tasks belong in Cost, Balanced, or Quality mode?

In GMI Router, Cost mode fits task classes whose output is machine-checked before a human or a database sees it, Balanced fits internal copilots and routine generation, and Quality is reserved for work that reaches a customer or triggers a write. Set that mapping as an explicit rule rather than leaving it to per-team judgment, which is what the workspace is trying to replace. This is a starting policy for a mixed engineering organization, meant to be calibrated against your own task mix after two weeks of traffic:

GMI Cloud publishes one useful detail about how Quality mode behaves at the top of the pool: "When several models reach the same top quality for a prompt, it takes the cheapest of them." Putting a task class in Quality mode is therefore a statement about the quality floor you require, not an instruction to spend more.

Write two exceptions into the policy explicitly:

• Escalate on signal, not up front. A long-running agent that has failed the same step twice is a different task than it was at step 0. GMI Cloud ran an experiment on exactly that question: "Can GMI Router go beyond choosing a model at step 0 and dynamically escalate capability during a coding-agent trajectory, only when the run actually calls for it?" (dynamic model escalation for coding agents). Treat mid-trajectory escalation as a policy to measure on your own agent traffic before standardizing on it, since the duplicated work in a re-issued trajectory is part of its cost.
• Never promote by volume alone. A task class being 60% of workspace traffic is an argument for Cost mode with a validator, not for Quality mode. High volume raises the value of a correctness check, not the value of a bigger model.

What does a workspace-wide mode policy change on the bill?

On GMI Cloud's published benchmark, GMI Router runs at 0.72x the cost per task in Quality mode and 0.22x in Balanced mode against always running GPT-5.5 at 1.00x, so the mode policy a workspace adopts is what moves the model line on its bill. Those are two of four reference points published on the GMI Router page, measured as quality score against cost per task relative to fixed-model baselines:

All rows use GPT-5.5 at 1.00x as the cost baseline. Quality mode reports +2.4 quality points and 28% lower cost per task. These are GMI's internal results across eight task categories within the allowed pool: directional and not independently audited. Actual prices depend on the prompt.

Those multipliers are relative, which is what makes them usable for a workspace plan. The baseline is specific: GMI Cloud's launch post states that "Quality mode reached 84.9% benchmark quality at 0.72x the cost of always running GPT-5.5 (82.5% quality at 1.00x)." So take an organization currently spending $40,000 a month sending every request to GPT-5.5, and apply the published relative cost per task to that baseline:

Blended rows are the two published multipliers weighted by traffic share, for example 0.3 x 0.72 + 0.7 x 0.22 = 0.37. Plan with these two multipliers on the first pass, because they are the two GMI Cloud publishes, and measure Cost mode against your own quality bar once the policy is live. Keep two caveats attached to the number when you run this on your own spend: the multipliers are directional benchmark figures rather than a price list, and your realized ratio depends on your prompt mix and on which models the org owner put in the pool.

Routing uses no judge-model call, and recommendation and routing are free for a limited preview period. The selected model's token charges still apply. Confirm post-preview terms before setting a long-term budget.

Who can change what, and how do you prove it?

In GMI Router the org owner decides which models are eligible and whether automatic routing is on, each team picks the cost-quality objective for its own calls inside that boundary, and the selected model comes back in routing metadata so both decisions can be reconstructed afterward. Fill in this matrix before the first team is migrated; the right-hand column is what GMI Router publishes today.

Settle two operational details while the workspace is being set up rather than after. GMI Cloud documents the workspace owner as the approver of the Allowed Model Pool, so confirm with GMI Cloud which further roles on your account may edit it, and decide on your own side that a pool edit goes through the same change-management path as a firewall rule: a ticket in your existing system naming the model added or removed, the requester, and the approving owner. That gives your FinOps and security reviewers a record of pool changes in the place they already look.

For the model inventory that feeds the pool, platform-level model coverage is described on the GMI Cloud Model-as-a-Service page, and the live catalog is in the GMI Cloud Console. Build the pool from the Console catalog rather than from the leaderboard on the GMI Router page, which the page itself describes as "A selection of the models we currently disclose; more are benchmarked internally but not yet published."

A 30-day rollout across several product teams

The plan below runs four phases over 30 days: inventory what calls a model today, set the pool centrally, migrate and measure in Cost mode, then promote only what measurement says should move.

1. Days 1 to 5, inventory. List every service that calls a model today, with its current model ID and its monthly spend, and note which models in the GMI Cloud Console catalog you would want eligible for each one. The output is a single table of task classes, not services, because modes are assigned to task classes.
2. Days 6 to 10, set the boundary. The org owner defines the Allowed Model Pool. Keep it small on the first pass. A pool that contains every model in the catalog gives the router more room but gives your reviewers nothing to review.
3. Days 11 to 20, migrate and measure in Cost mode. Point services at the GMI Router endpoint and send mode: "cost" first. This is GMI Cloud's own advice after building two applications on the router before launch: "start in Cost mode, measure against your own quality bar, and reserve Balanced or Quality for the workloads where your data shows they earn the premium." Score each task class against the fixed model it used to call.
4. Days 21 to 30, promote what failed and freeze the policy. Move the task classes that missed the quality bar to balanced, move the ones in the Quality row of the table above to quality, leave everything else in cost, and record the assignment in the same place you keep your other platform policies. Keep Auto Mode as the documented kill switch.

Teams that have never routed before should read GMI Cloud's launch write-up on automatic model selection for every prompt before step 3, since it covers what changes when model choice stops being a constant in your code.

Multi-turn products have one extra thing to check during step 3. GMI Router is KV-cache-aware: the product page lists "KV-cache Preserved across turns" and "KV-cache-aware serving for supported workloads." Score those services per conversation rather than per request, because a mode assignment for a chat product is a statement about the whole session rather than about one message.

How this compares to the other ways teams route today

GMI Router is the managed option among three shapes teams weigh here, and it ships the workspace controls as platform features rather than as something to build or operate. A hosted aggregator lets a caller supply a fallback list with the request, which is a per-request reliability mechanism and a different thing from a cost-versus-quality objective chosen per call. A self-hosted gateway puts the policy in a config file your own team deploys, which is genuine central control bought by adding one more service to your request path for your team to own, patch, and scale.

GMI Router answers the workspace framing in the original question directly. Its three named modes, its org-owner-approved pool, and its workspace-wide Auto Mode switch are the mechanisms the governance matrix above asks for, so the organization gets a managed routing layer that decides "in under 200ms before your request reaches the selected model, with the workspace controls production teams expect," and the platform team does not inherit a gateway to run. The six rows of the governance matrix above are the acceptance test, and GMI Router answers every one of them today.

FAQ

Can we force every team onto an approved list of models? Yes. Define the Allowed Model Pool before migration; routing stays within the models approved by the organization owner.

Is the mode a workspace setting or a per-request parameter? Both layers exist: the Allowed Model Pool and Auto Mode apply workspace-wide; each request's mode chooses cost, balanced, or quality within that boundary.

Can we turn routing off without redeploying every service? Yes. Auto Mode switches automatic routing on or off workspace-wide without requiring a deployment change in each service.

Does the router add a charge on top of the model? Routing is free during a limited preview; the selected model's token charges remain payable. Confirm later pricing with GMI Cloud.

How do we attribute spend to the model that actually answered? Log the selected model from routing metadata alongside each request ID.

How much should we expect to save across the whole workspace? Quality and Balanced modes report 0.72x and 0.22x cost per task against GPT-5.5 at 1.00x. These internal, eight-category results are directional and not independently audited. Weight them by traffic share for planning, then validate against actual tasks.

Next step

Define the pool, then route. Open the GMI Router page to try routing with your own prompts, read the request contract in the documentation to see exactly what mode changes, and if the policy has to be reviewed by procurement or security before any team migrates, contact GMI Cloud sales from the same page and we will walk through the workspace controls with your reviewers.