The last two posts covered why CODR routes across twelve providers instead of committing to one, and the dispatcher-versus-aggregator distinction that shapes its architecture. This post goes one layer deeper: before CODR can route a task anywhere, it has to decide what kind of task it’s actually looking at. This is the classification step, and it’s where most of the hard problems in a dispatcher architecture actually live.

Why Classification Has to Happen First

Routing is only as good as the classification feeding it. A dispatcher that routes correctly 95% of the time but misclassifies the other 5% doesn’t fail gracefully, it silently sends a large refactor to a provider tuned for quick completions, or a one-line fix to a provider with high latency and unnecessary overhead. The classification layer is the part of CODR that has to be right before anything downstream matters.

Signals the Classifier Looks At

A handful of task properties matter more than others when deciding which provider is the right fit:

• Scope of the change. A single-function edit and a cross-file refactor touching a dozen files are fundamentally different jobs, and the signal for scope comes from how much surrounding context the task actually references.
• Task type. Scaffolding new code, debugging existing code, and reviewing or explaining code are distinct categories, each with providers that tend to perform better or worse at them.
• Context window pressure. Some tasks need a provider that can hold a large amount of surrounding codebase in context at once; others don’t need that headroom at all, and paying for it would be wasted latency and cost.
• Language and framework. Provider strength isn’t uniform across languages, so the classifier factors in what’s actually being worked on, not just what kind of task it is.
• Urgency and cost sensitivity. Not every task is equally time-critical, and the classifier weighs that alongside raw capability when a faster, cheaper provider would do the job just as well.

None of these signals is decisive on its own. The classification is a composite judgment across all of them, which is exactly why this layer, not the adapter layer, is where CODR’s actual intelligence lives.

Where Classification Breaks Down

No classifier is perfect, and it’s worth being honest about where this one struggles rather than presenting it as a solved problem.

The hardest case is a task that looks small on the surface but is actually large in scope, a one-line change request that turns out to require understanding a much bigger piece of the system to do safely. Surface-level signals underestimate the true scope in these cases, and the classifier can send it to a provider that isn’t equipped for the context it actually needs.

The second hard case is task type ambiguity: a request that’s phrased as a bug fix but is really a design question, or vice versa. Natural-language task descriptions don’t always map cleanly onto the categories the classifier is trying to sort into, and some genuinely straddle two categories at once.

The manual override that exists in CODR isn’t just a convenience feature for power users, it’s the release valve for exactly these misclassification cases. When a developer notices the routing decision doesn’t fit the task, overriding it is the correct response, and that signal is also useful feedback for refining the classifier over time.