Many teams can already count "how many tokens were used," but they cannot answer a more practical question: were those tokens spent on fixing bugs, building features, doing code review, or on a long-running agent repeatedly retrying? OpenRouter introduced Classifiers in beta on July 24 to fill in this layer of the ledger.
The approach is straightforward. Users define a taxonomy for their requests, then specify a classifier model and a sampling rate. The classifier runs asynchronously after the original request completes, without blocking the inference path, and writes structured labels back to the logs. Official configurations support up to 8 dimensions, with 6 built-in templates covering department, audience, task type, engineering work, agent complexity, and capitalizable software spend.
The most useful template for AI coding is Engineering work. It categorizes requests as feature development, bug fixing, documentation, refactoring, code review, and so on. Agent complexity tags tasks by difficulty and task family. This means teams no longer need to look only at a model's average price — they can see "which engineering tasks used which models," "whether complex tasks are being retried repeatedly by cheaper models," and "whose department's agent bill is growing fastest."
This looks like a logging feature, but it is closer to runtime governance. In the past, enterprises bought models with a coarse-grained ledger: input tokens, output tokens, per-model pricing. 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 a chance to view the bill alongside output, risk, and department budgets.
OpenRouter also offers a pragmatic usage pattern: compliance-oriented classifiers can sample 100% of requests, while cost-attribution classifiers can sample only 10%. The classifier model itself is swappable, with the company recommending Gemini 3.5 Flash Lite as a cost-effective option. Classification results are constrained to user-defined dimensions and values, making it easy to aggregate trends in logs and the Activity Explorer.
But this does not automatically produce truth. Classifiers read the request and generation record, and label quality depends on the taxonomy, the classification prompt, and the model's judgment. A "refactoring" request may also include bug fixes; an agent task's complexity may change during execution. Sampling saves money but makes trends unstable for small departments. A more realistic risk is treating model labels as financial fact — especially for judgments like "capitalizable software spend," which ultimately still require a company's own accounting and compliance rules.
What I care about more: this shifts AI coding competition from "model selection" toward "workload accounting." When Cursor, Claude Code, Codex, or in-house agents can all connect to multiple models, what enterprises really need is an explainable routing table: which tasks go to whom, why, how much they cost, and who is responsible when something breaks. Classifiers are still beta, but they have already moved this question from beside the financial statements into the agent logs themselves.
Original sources:
- OpenRouter official announcement: https://openrouter.ai/blog/announcements/classifiers
- Classifier documentation: https://openrouter.ai/docs/guides/features/classifiers
- Activity Explorer: https://openrouter.ai/activity/explore