TL;DR: MiniMax M2.5 is now the most-used model on OpenRouter by token volume, processing over 2.45 trillion tokens in a week as of February 2026, while Chinese AI models reached 61% market share and the model delivered near frontier performance at far lower cost, according to WorkOS. The governance issue is no longer model quality alone but routing, escalation, and control boundaries across AI agent workloads.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: MiniMax M2.5 is dominating OpenRouter usage because its cost, speed, and capability profile make it a strong option for model routing.
Why it matters: IAM and identity teams should care because routing decisions are becoming governance decisions, especially when AI agents need different trust, escalation, and control boundaries across tasks.
By the numbers:
- MiniMax M2.5 is the number one most-used model on OpenRouter by token volume, with over 2.45 trillion tokens processed in a single week as of February 2026.
- Chinese AI models now hold 61% of OpenRouter's market share.
- M2.5 scores 80.2% on SWE-Bench Verified, compared with 80.8% for Claude Opus 4.6.
- MiniMax says M2.5 completes SWE-Bench tasks 37% faster than its predecessor, M2.1.
Context
Model routing is the practice of sending each request to the model best suited to that task, rather than forcing every workload through one default model. In this article, WorkOS uses MiniMax M2.5 to show that routing has become a governance problem, because cost, latency, capability, and escalation now need explicit control boundaries.
For identity and access teams, the significance is not which model is fashionable. The issue is whether AI workloads have a defined decision path for when a fast general model handles a task, when a stronger model takes over, and who is accountable for those transitions.
In a production AI agent, routing choices shape trust boundaries as much as permissions do. When a frontline model handles most requests and escalates only specific work, the organisation is really managing privilege, delegation, and review thresholds across machine-driven actions.
Key questions
Q: How should security teams govern model routing in AI agent workflows?
A: Security teams should treat model routing as a policy decision, not a performance shortcut. Define which requests stay on the front-line model, which must escalate, and which are blocked entirely. Tie those rules to data sensitivity, tool access, and audit logging so that routing decisions are reviewable and consistent across environments.
Q: Why does using a cheaper model still require governance controls?
A: A cheaper model still makes a governance decision whenever it handles user data, calls tools, or triggers downstream actions. Cost reduction does not remove the need for escalation rules, logging, or oversight. If the organisation cannot explain why one model handled a task instead of another, routing has become an ungoverned control boundary.
Q: What breaks when AI systems route every task through one default model?
A: One-default-model designs break when task complexity, sensitivity, and reasoning depth are not uniform. They either waste money on routine work or underperform on harder work, and both outcomes create operational risk. More importantly, they hide when a workflow should have escalated to a better-suited model.
Q: What should security teams monitor in self-hosted open-weight model deployments?
A: Security teams should monitor where the model is hosted, who can access it, how it is updated, and whether routing rules are being changed without review. Self-hosting removes vendor dependency, but it increases responsibility for availability, change control, and lifecycle governance across the model estate.
Technical breakdown
Model routing as a control plane for AI workloads
Model routing is the policy layer that decides which model receives a request, which model handles follow-up work, and when a harder task gets escalated. In practice, it behaves like a control plane because it separates low-cost routine work from high-cost or high-risk reasoning. That matters when agents can call tools, write code, or trigger downstream actions. If routing is ad hoc, model choice becomes an invisible governance decision. If routing is explicit, teams can align model capability, cost, and risk with the task being performed.
Practical implication: define routing rules as part of AI governance, not as a developer convenience.
Why cost and capability create escalation thresholds
MiniMax M2.5 is presented as fast, inexpensive, and capable enough for routine chat, coding, and tool use, but not the strongest choice for deeper reasoning or specialised workloads. That combination creates escalation thresholds: the point where a workflow should move from a general model to a specialist model. The technical issue is not just accuracy. It is whether the system can recognise when the current model is outside its safe or effective operating envelope. Without a threshold, organisations either overspend or underperform, and both outcomes are governance failures.
Practical implication: set explicit task classes that trigger escalation to higher-trust models.
Open weights change governance and dependency assumptions
Open-weight models change the operational model because teams can download, run, fine-tune, and host them independently. That reduces vendor dependency, but it also shifts responsibility onto the organisation for availability, patching, configuration, and deployment hygiene. For identity and access governance, the relevant shift is that the model is no longer only a service consumed through a vendor boundary. It becomes part of the internal control surface, with its own lifecycle, access paths, and operational dependencies. In other words, portability increases, but so does governance burden.
Practical implication: treat self-hosted models as governed internal services with defined ownership and lifecycle controls.
NHI Mgmt Group analysis
Model routing is now an identity governance problem, not just an optimisation problem. Once AI workloads can be split across general and specialist models, the routing layer becomes the place where trust, cost, and escalation are decided. That decision point deserves the same governance attention as an access policy, because it determines which system is allowed to act first and which system is allowed to override it. Practitioners should treat routing as part of the control plane for AI work.
Escalation thresholds are the new boundary in AI operations. WorkOS' example shows why a single model is rarely the right answer for all tasks. Fast models absorb the bulk of routine traffic, while deeper reasoning models should be reserved for harder work. The governance question is where the threshold sits and who can move it, because an ungoverned threshold quietly turns cost optimisation into risk acceptance. Practitioners need a documented escalation policy for AI workloads.
Open-weight models introduce control trade-offs that identity teams cannot ignore. Open availability reduces platform dependency, but it also moves accountability for hosting, access, and lifecycle management into the enterprise. That changes the security boundary from vendor service governance to internal system governance, where ownership, change control, and auditability matter more. Practitioners should assume that portability comes with a larger operational burden, not a smaller one.
Model selection is becoming a delegated decision, and delegated decisions need auditability. When an AI agent decides which model to use for a task, the organisation is delegating a capability choice that can affect outputs, cost, and downstream actions. That requires a named concept for the control gap: routing discretion: the ability of a workflow to choose its own model path without a documented governance rule. Practitioners should make routing choices observable and reviewable.
The market signal is consolidation around good-enough defaults, not universal frontier models. The article suggests that many real workloads no longer justify premium reasoning by default. That means governance teams should stop designing around a single highest-end model and start designing around differentiated task classes, fallback paths, and exception handling. Practitioners should expect model portfolios to look more like access tiers than like one-size-fits-all platforms.
What this signals
Routing discretion: the control gap is not model quality alone but who can decide, at runtime, which model handles a task and when the system escalates. That decision path should be visible to IAM, platform, and security owners because it behaves like delegated authority.
AI portfolios are starting to resemble tiered access models. Routine work is handled by the lowest-cost capable option, while harder or higher-risk work moves up the stack, which means governance must define who can change tiers, under what conditions, and with what audit trail.
For practitioners
- Define model routing policies Classify AI workloads by task type, required reasoning depth, latency tolerance, and cost sensitivity so routing choices are explicit and repeatable.
- Set escalation thresholds for complex tasks Reserve specialist models for multi-step reasoning, subtle debugging, and high-impact decisions, and document the conditions that trigger escalation.
- Inventory open-weight deployment paths Map where open-weight models are downloaded, hosted, fine-tuned, and accessed so the internal control surface is visible to security and platform teams.
- Make routing decisions auditable Log which model handled each task, why it was selected, and when the system escalated, then review those decisions during governance and incident analysis.
- Separate cost optimisation from trust policy Ensure budget-driven model selection cannot override security constraints, approval requirements, or data handling rules for sensitive workflows.
Key takeaways
- AI governance is moving from model selection to model routing, because task-by-task escalation now matters more than picking one default system.
- Open-weight models improve deployment flexibility, but they also shift more operational responsibility into the enterprise control surface.
- Practitioners need explicit routing policy, escalation thresholds, and audit trails so model choice is governed rather than improvised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST AI RMF and NIST CSF 2.0 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Model routing determines which agentic workflow gets authority to act and escalate. |
| Recommendation — Define routing approvals so agentic workflows cannot self-select higher-privilege paths without governance. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governance of AI model choice, escalation, and accountability. |
| Recommendation — Assign governance ownership for model routing decisions and review them under AI management controls. | ||
| ISO/IEC 42001:2023 | AI management system | Model routing, escalation, and lifecycle oversight are core AI management system concerns. |
| Recommendation — Treat routing rules, escalation thresholds, and model ownership as controlled AI management system processes. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The article shows that model routing must align with business task classes and operational context. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Routing decisions act like delegated authorisation over which model handles sensitive work. | |
| Recommendation — Document which AI tasks are allowed to use each model class and why that choice is acceptable. Apply authorization logic to AI routing so sensitive tasks only reach approved models and paths. | ||
Key terms
- Model routing policy: Model routing policy is the logic that decides which model, cluster, or workflow step handles a request. It shapes cost, latency, quality, and exposure because it controls when requests are escalated, when fallbacks happen, and which identities are used along the path.
- Escalation Threshold: An escalation threshold is the rule that determines when a request should move from a lower-cost or lower-trust model to a more capable one. It is a governance control, not a performance tweak, because it sets when higher-risk reasoning or action is permitted.
- Open-Weight Model: A model whose parameters can be downloaded and run locally by the operator. In practice, that means safety behaviour can be altered outside the provider’s environment, so governance has to focus on the runtime, the operator, and the abuse path, not only the model brand.
- Routing discretion: Routing discretion is the ability of a workflow or agent to choose its own model path without a documented governance rule. For AI programmes, it is a control issue because discretionary routing can hide who authorised a model choice, when escalation happened, and why the decision was made.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org