As AI usage scales, the governance questions arrive right behind it: who is using it, for which tasks, what spend is reportable, and which outputs end up in front of regulators. The answers already live inside every generation — they just lack a structured form. On July 24, OpenRouter shipped Classifiers in beta, moving classification into the platform itself: every generation gets automatically tagged with labels you define, written into logs as filterable metadata that can be aggregated, so AI usage reporting finally has structured data to work from.
This piece breaks down the mechanism, the templates, the analysis path from logs to Activity Explorer, and how sampling rate controls cost — including the pricing part the announcement leaves as a shape without numbers.
Mechanism: a four-part config, run asynchronously
A classifier’s configuration has exactly four parts: a taxonomy, a classification prompt, a model, and a sampling rate. The taxonomy holds up to eight dimensions, each with custom values; the classification prompt is sent to the classifier model as a system message; the model reads the prompt and the generation and emits a label; the sampling rate decides what fraction of traffic gets classified at all.
The execution placement is the design decision that matters: classification runs asynchronously after each request completes, off the inference path, so it adds no latency. The output is coerced into a structured format — the model cannot freestyle; it picks from the dimensions and values the taxonomy defines. That constraint is what makes everything downstream possible: tags are values in a schema, not guesses in natural language.
OpenRouter recommends Gemini 3.5 Flash Lite as the classifier model — cheap, with high accuracy on structured outputs (the vendor’s own claim) — and the model can be swapped at any time.
Six templates: copy first, then customize
Taxonomy design does not have to start from zero. Six preset templates ship out of the box — Department, Audience, Task type, Engineering work, Agent complexity, and Capitalizable software expense — each mapping to a different governance question:
| Template | What it tags | Governance question |
|---|---|---|
| Department | Which team made the request | Cost allocation per unit |
| Audience | Output recipient: internal, client-facing, regulators, public | Compliance routing |
| Task type | Purpose: coding, agentic work, data processing | Whether model choice fits the job |
| Engineering work | Feature dev, debugging, docs, refactoring, code review | Tracking AI-assisted output |
| Agent complexity | Difficulty tier from trivial tool calls to frontier-expert, plus task family | Cost structure of multi-tier agents |
| Capitalizable software expense | Development vs maintenance/operations/support | Capitalization for accounting |
Two templates deserve a second look. Audience turns “who will see this output” into first-class metadata — outputs bound for regulators and outputs for internal use carry entirely different compliance obligations, and labeling before an incident is cheaper than excavating logs after one. Capitalizable software expense plugs straight into accounting: which AI-assisted engineering work counts as development (capitalizable) and which counts as maintenance or operations (expensed) is a live question on any balance sheet with growing AI spend.
From logs to Activity Explorer: how tags become decisions
Once classification lands in logs, there are three layers of consumption. The first is filtering: every classified generation carries its tags, so you can filter directly on department: legal. The second is per-request inspection: the generation detail panel lists every classification dimension and value for that record. The third layer is the real payload — Activity Explorer aggregates traffic by any classifier dimension, showing spend distribution across models and departments, and classifier filters carry across the Activity tabs (explore, trends, guardrails), so one filter follows the whole trend line.
One validation feature is easy to miss: you can run a classifier on demand against any past generation. Designing a new taxonomy does not have to be guesswork — replay it against historical traffic, look at the label distribution, and iterate before it goes live. That turns taxonomy design from a one-time decree into something testable.
The cost model: sampling rate as the multiplier
The announcement gives the shape of classifier costs but not the numbers: cost is the classifier model’s price multiplied by the fraction of traffic actually classified. Specific pricing is not listed — worth stating plainly — but the control is explicit.
The vendor’s example pattern is worth copying: a compliance classifier samples 100% of traffic, because regulatory contexts cannot tolerate misses; a cost-attribution classifier samples 10% of the same traffic, because attribution needs statistical representativeness, not a census. Two classifiers can watch the same traffic at different sampling rates, decoupling cost from oversight intensity.
Trade-offs and limits
Beta comes first: both the feature and its pricing are still moving. Second, classification is asynchronous — tags appear after the request completes — so this fits after-the-fact analysis and reporting, not real-time policy enforcement (an inference from the async design, not an official statement). Third, classification quality is bounded by the classifier model and the prompt: the vaguer the values in your taxonomy, the less trustworthy the labels. Two engineering details did get handled: classifiers keep working even with input and output logging disabled, so a no-content-storage, metadata-only posture is viable; and models are swappable, so you can start cheap and upgrade when dissatisfied.
Builder guidance
A three-step start: first, run the Department and Task type templates for a week and read the actual traffic distribution in Activity Explorer before deciding what a custom taxonomy should look like. Second, validate every new classifier with the on-demand replay against past generations — if the label distribution looks wrong, fix the values and run it again. Third, write the sampling policy down as an explicit rule: 100% for compliance and 10% for attribution is the vendor’s starting point; your correct ratio depends on how much you can tolerate missing.
Teams already routing scale traffic through OpenRouter get the piece AI usage reporting was missing: structured data generated by the platform. Smaller teams should at least remember the pattern — classification metadata should be platform-generated, asynchronous with the request, and cost-controlled through sampling — because those three properties are worth demanding from any platform, not just this one.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.