Gloo Code Routes Coding Tasks Across AI Models

Gloo Code launched on September 8 as an agentic coding product that routes different development steps to different AI models. The practical proposition is less about picking one “best” model and more about controlling the cost and governance of a multi-model workflow. Gloo says the product is available through fixed-price individual, team and enterprise plans, but its headline performance figures remain preliminary internal benchmarks rather than independent proof.

What Gloo Code routes, and why it matters

Gloo describes a harness that coordinates purpose-built agents for planning, exploration, building, security, quality assurance and testing. The harness decides which model handles each step: a frontier model where its capabilities matter, or a lower-cost model where it is sufficient. Developers can use a terminal interface or macOS app, while the company positions the seat—not metered token consumption—as the unit buyers budget for.

That arrangement addresses a real procurement problem. A coding assistant may look inexpensive on a per-token basis while producing unpredictable monthly bills, or it may save tokens while creating more review work. A fixed seat price makes the invoice predictable, but it does not by itself show whether the output is useful, secure or cheap after human verification.

The product page lists Basic, Pro and Ultra plans for individuals, discounted self-service team seats for groups of two to 25, and custom enterprise terms above that threshold. Each seat includes a monthly allowance rather than unlimited use. That distinction matters for forecasting: a team can know its base subscription bill while still needing to model how often heavy users reach a cap or move to a higher tier.

Gloo Code needs an accepted-change scorecard

Gloo reported roughly 70% on Terminal-Bench 2.1 at about half the cost of selected frontier-model comparisons, and said its run cost was 58% to 67% lower than published results for those models. The release also explicitly warns that the data came from internal testing under specific conditions, may not generalise, and relies on third-party published results. Buyers should therefore treat the figures as a testable hypothesis.

A useful pilot should track cost per accepted change, reviewer minutes, test-pass rate, security findings, rollback frequency and time to merge. It should also preserve which agent and model handled each step. Without that trace, a low-cost route can hide expensive review or weak output. This is the same operational discipline behind evaluating agent orchestration across toolchains and observability for AI agents.

Privacy claims need the same scrutiny. The product page says every plan includes zero data retention and that code, data and intellectual property remain the customer’s. Security teams should still verify model-provider boundaries, retention enforcement, access controls, audit logs and incident handling in the actual contract and technical configuration.

Routing also changes accountability. If one agent plans, another edits code and another checks security, teams need a durable record of which component introduced or approved a change. Repository permissions should follow least privilege, generated diffs should remain reviewable, and automated tests should be treated as evidence—not as a substitute for ownership. These controls are especially important when a routing policy can change without a developer explicitly choosing the underlying model.

What enterprise buyers should test first

Start with a representative mix of small fixes, legacy-code changes, security remediation and greenfield work. Predefine the acceptance tests, reviewer budget and prohibited repositories. Compare the routed workflow with a single-model baseline under identical conditions. The go/no-go decision should rest on reviewed output and operational evidence, not the launch benchmark alone.

Run the pilot long enough to observe allowance limits and failed tasks, then segment results by task type. An average can conceal a router that performs well on scaffolding but poorly on sensitive migrations. Procurement, engineering and security should agree in advance which failures stop deployment and which can be corrected through policy.