Many teams can already report "how many tokens we used," but cannot answer a more practical question: were those tokens spent on bug fixes, new features, code review, or a long-running agent repeatedly retrying? OpenRouter introduced Classifiers in beta on July 24 to close this accounting gap.
How it works
The approach is straightforward. Users define a taxonomy for their requests, then specify a classification model and a sampling rate. The classifier runs asynchronously after the original request completes, so it does not block the inference path, and writes structured labels back into logs. The official configuration supports up to 8 dimensions, with 6 built-in templates: department, audience, task type, engineering work, agent complexity, and capitalizable software spend.
Why it matters for AI coding
The most useful template for coding teams is Engineering work, which classifies requests into:
- Feature development
- Bug fixing
- Documentation
- Refactoring
- Code review
- OpenRouter announcement: https://openrouter.ai/blog/announcements/classifiers
- Classifier docs: https://openrouter.ai/docs/guides/features/classifiers
- Activity Explorer: https://openrouter.ai/activity/explore
Agent complexity additionally labels tasks by difficulty and task family. This means teams no longer have to look only at a model's average price—they can see which engineering task types use which models, whether complex tasks are being repeatedly retried by cheap models, and which department's agent bill is growing fastest.
From logging to governance
This looks like a logging feature, but it is closer to runtime governance. Enterprise model procurement has long relied on a coarse-grained ledger: input tokens, output tokens, per-model unit price. Once coding agents enter production, costs are jointly determined by context length, tool-call counts, retries, caching, approvals, and human rework. Without task types, managers only see a bill; with classification, there is finally a chance to view spend alongside output, risk, and department budgets.
OpenRouter also offers a realistic usage pattern: compliance-oriented classifiers can be sampled at 100%, while cost-attribution classifiers can sample just 10%. The classifier model itself is swappable—OpenRouter recommends Gemini 3.5 Flash Lite as a cost-effective option. Classification results are constrained to user-defined dimensions and values, making trends easy to aggregate in logs and the Activity Explorer.
Caveats
This does not automatically produce truth. Classifiers read request and generation records, so label quality depends on the taxonomy, classification prompts, and the model's judgment. A "refactoring" request may also contain bug fixes; an agent task's complexity may shift mid-execution. Sampling saves money but makes trends unstable for departments with small samples. The more realistic risk is treating model labels as financial fact—especially for judgments like "capitalizable software spend," which ultimately still require the enterprise's own accounting and compliance rules.
Perspective
What matters more is that this pushes AI coding competition from "model selector" toward "workload ledger." When Cursor, Claude Code, Codex, or self-built agents can all route across multiple models, what enterprises really need is an explainable routing table: which tasks go to whom, why, what they cost, and who is accountable when something breaks. Classifiers are still in beta, but they have already moved this question from the finance spreadsheet into the agent logs themselves.
Links: