Summary: OpenRouter launched Classifiers in beta on July 24, automatically tagging generations with user-defined taxonomy values in logs and Activity Explorer. Classification runs asynchronously after requests complete, uses structured outputs, and can apply different sampling rates to separate compliance, cost attribution, department, audience, task, engineering, agent complexity, or capitalization questions. Beta pricing numbers were not disclosed, and asynchronous metadata is suited to reporting rather than real-time enforcement.
Scale up AI usage and the governance questions arrive on its heels: who is using it, on which tasks, what portion of the spend is reportable, and which outputs will someday sit in front of a regulator. The answers have been sitting inside every generation all along — what was missing was a structured form for expressing them. On July 24, OpenRouter launched Classifiers in beta, pulling classification into the platform itself: every generation is automatically tagged with labels you define and written into logs as filterable, aggregatable metadata, giving AI usage reporting structured data to stand on for the first time.
What follows is a teardown of the mechanism, the template lineup, the path tags travel from logs into Activity Explorer, and the way sampling rate keeps cost in check — including the part of the pricing the announcement leaves as a shape without numbers.
Mechanism: a four-part config, run asynchronously
Configuring a classifier takes exactly four elements: a taxonomy, a classification prompt, a model, and a sampling rate. A taxonomy holds at most eight dimensions, each with values you define; the classification prompt travels to the classifier model as a system message; the model reads the prompt plus the generation in question and emits a label; the sampling rate sets what share of traffic gets classified at all.
The design decision that carries the most weight is where execution happens: classification runs asynchronously once a request finishes, entirely off the inference path, so latency stays untouched. On the output side, structure is enforced — no freestyle answers allowed; the model must pick from the dimensions and values the taxonomy spells out. That single constraint unlocks everything downstream: a tag is a value in a schema, never a guess dressed up in natural language.
For the classifier model, OpenRouter’s recommendation is Gemini 3.5 Flash Lite — cheap, accurate on structured outputs (the vendor’s own claim) — and swappable at any time.
Six templates: copy first, then customize
Nobody has to design a taxonomy from a blank page. Six preset templates ship out of the box — Department, Audience, Task type, Engineering work, Agent complexity, and Capitalizable software expense — and each one answers 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 of the templates repay a closer read. Audience promotes “who will see this output” to first-class metadata — an output headed for regulators and one meant for internal use carry compliance obligations that live in different worlds, and labeling before an incident beats excavating logs after one. Capitalizable software expense wires the feature straight into accounting: deciding which AI-assisted engineering effort counts as development (capitalizable) versus maintenance or operations (expensed) is a live question on any balance sheet where AI spend keeps climbing.
From logs to Activity Explorer: how tags become decisions
Once classifications land in logs, consumption happens on three levels. Level one is filtering: classified generations carry their tags, so a filter like department: legal is one condition away. Level two is per-request inspection: the generation detail panel enumerates every classification dimension and value for that record. Level three is where the real payload sits — Activity Explorer aggregates traffic along any classifier dimension, laying out spend distribution across models and departments, and classifier filters persist across the Activity tabs (explore, trends, guardrails), letting one filter ride the whole trend line.
There is also a validation feature that is easy to overlook: any classifier can be run on demand against a past generation. Designing a new taxonomy no longer has to be guesswork — replay it against historical traffic, study the label distribution, and iterate before going live. Taxonomy design turns from a one-time decree into a testable engineering loop.
The cost model: sampling rate as the multiplier
The announcement sketches the shape of classifier costs but withholds the numbers: cost equals the classifier model’s price times the fraction of traffic actually classified. Specific pricing is absent — worth saying plainly — though the control knob is explicit.
The vendor’s demo pattern is worth lifting directly: a compliance classifier samples 100% of traffic, because regulatory contexts leave no room for misses; a cost-attribution classifier samples 10% of the very same traffic, because attribution calls for statistical representativeness, not a census. Two classifiers can watch one traffic stream at different sampling rates, decoupling cost from oversight intensity.
Trade-offs and limits
Beta status comes first: both the feature and its pricing are still in motion. Second, classification is asynchronous — tags materialize only after a request completes — which positions it for after-the-fact analysis and reporting rather than real-time policy enforcement (an inference drawn from the async design, not an official statement). Third, output quality is bounded by the classifier model and the prompt: the vaguer the values in your taxonomy, the weaker the trust in the labels. On the plus side, two engineering details were handled well: classifiers continue to work with input and output logging switched off, so a no-content-storage, metadata-only posture holds; and models are swappable, meaning you can start cheap and upgrade when the results disappoint.
Builder guidance
A three-step opener: first, put the Department and Task type templates to work for a week and read the actual traffic distribution in Activity Explorer before sketching a custom taxonomy. Second, put every new classifier through the on-demand replay against past generations — if the label distribution looks off, adjust the values and run it again. Third, codify the sampling policy as an explicit rule: 100% for compliance and 10% for attribution is the vendor’s starting point, and your correct ratio depends on how much you can afford to miss.
Teams already pushing scale traffic through OpenRouter gain the exact piece AI usage reporting lacked: structured data generated by the platform itself. Teams not yet at scale should still bank the pattern — classification metadata ought to 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.