GPT-5 Routing: Speed at the Cost of Clarity?

GPT-5’s biggest change isn’t in capability. It’s in how you get your answers, as instead of a single model responding to every prompt, it uses a routing system that decides which variant should handle your request. The router might keep you on a lightweight, fast model for most queries and escalate to a heavier reasoning engine when it thinks you need it. You can nudge it with intent tags like "think hard" or "be concise", but the decision-making still sits with the system.

In theory, that means less manual overhead, more consistent costs, and a better match between task and tool. In practice, it also introduces a layer of complexity you can’t always see and in legal, that can be a problem.

Why Automatic Routing Appeals

A well-tuned router can take away some of the operational pain. It might learn that your NDA party extraction is always a quick path job, while your share purchase agreement analysis calls for deep reasoning and retrieval. You don’t have to build that decision tree yourself; the system does it on the fly.

That can cut latency, help hit deadlines, and keep spend predictable. It may even smooth output quality by matching simpler jobs with simpler models and giving complex ones the attention they deserve.

The catch is that this consistency depends entirely on the router’s decision rules aligning with your needs. If the thresholds are wrong, or if two similar queries get routed to different models then you’ll see differences in style, accuracy, or even substance. In legal work, those inconsistencies aren’t just cosmetic; they can fundamentally change risk.

The Opacity Problem

Routing adds a hidden layer between your prompt and the model that answers it. Unless the vendor exposes full logs, you don’t know which model variant was used, how much reasoning depth it applied, or whether that changed mid-matter.

That matters if you ever have to defend the work. “We used GPT-5” won’t hold up if one answer came from a minimal-reasoning mini-model and another from a long-thinking variant with different data handling. Without transparency, you can’t fully reconstruct the process for audit, dispute resolution, or regulatory inquiry.

It also makes change management harder. Routing policies can be updated without notice. A query that took the deep read path last week might take the quick scan path this week, producing a different answer under the same prompt. That’s not a bug, it’s how the system is designed, but it still changes your risk profile.

Why You Might Need Your Own Router

The convenience of GPT-5’s built-in routing comes with trade-offs: you’re accepting its logic, its updates, and its evaluation criteria - none of which you control.

For legal teams, that loss of control can be a problem. A better approach may be to run your own evaluations across all available models like GPT-5 variants, other closed models, and local deployments and design routing rules that fit your workflows.

If your due diligence summaries run faster and more reliably on a smaller model with retrieval, you can make that the default. If high-risk contract analysis always demands the heavier reasoning path, you can lock that in, because you own the routing, you can log every decision and preserve it alongside the output. That creates a defensible audit trail you can produce when it matters.

What Legal-Owned Routing Should Capture

If you build your own routing layer, the most valuable part isn’t just the decision logic, it’s the record it leaves behind. For every AI-assisted action, you’d want a routing receipt that captures at least:

Stored alongside the output, this is what turns "AI helped with this" into "here’s exactly how AI helped with this."

The Vendor Conversation on Day One

When a vendor announces GPT-5 integration, especially in the first week of release, the questions to ask aren’t about model size or speed, they’re about governance:

• Who controls the routing? Is it GPT-5’s own router, a custom vendor-built one, or a mix?
• What transparency do I get? Will I see which model handled my request, the reasoning depth, and any tool calls?
• How are routing decisions logged? Will I get a structured “receipt” per request, or just a generic claim that GPT-5 was used?
• Can routing be fixed for high-risk tasks? Or will vendor updates change the path without warning?
• What’s the rollback plan? If a routing policy update degrades results, how quickly can they revert or let you pin to a known configuration?
• What’s their evaluation story? Have they tested routing against legal-specific workloads, or are they relying on general benchmarks?

If a vendor can’t answer those on day one, you’re not buying a GPT-5 integration, you’re buying a black box with a GPT-5 sticker.

Routing is a powerful tool, one I've called for in the past. When it's done well, it brings real efficiency gains and can reduce certain kinds of variation in output. Done blindly, it introduces a new category of risk of invisible process changes that undermine trust.

GPT-5 makes routing accessible, but accessibility shouldn’t replace accountability. In law, speed only matters if you can explain how you got there. That’s why the real question isn’t "should we use routing?" (because the answer is yes) It’s "whose routing logic are we willing to trust and can we prove it works for our tasks?"