Classification API: taxonomy labels, typed extraction, or decision scores
A classification API takes text in and hands back a label: what this page is about, which of my types appear in this document, which choice wins. Buyers searching this product type meet two walls of noise. One is the chat-model marketing that treats labeling as a prompt-engineering chore. The other is the enterprise suite that sells the same three routes at suite prices. The decision that actually matters is simpler: name the labeling job, and the route follows. This platform's classification category is built as three routes over that choice, and this page states where each one stands. All six lanes answer calls as of September 25, 2026. What follows is the framework for choosing a route, what the model classes behind them are, and what the open-weights road looks like.
Last verified: 2026-09-25
What a classification API does
The service contract is a small one, and that is the point. Text goes in. A label, or a set of labels with scores, comes out. Everything a buyer needs to know is in how the label set is defined.
Three ways to define it cover the market. One is a fixed standard label set, owned by an industry body. Every participant labels against the same list, so a label means the same thing on both sides of a transaction. Another is a caller-owned label set, where the types travel with the request and change per call. The last is a choice set: the caller supplies the options, and the model returns a score per option. Those three definitions produce three different products, and the strongest search results rarely separate them.
Two neighbors get folded into the same searches and should not be. A chat model generates text. Used for labeling, it generates an answer that then needs parsing, at generation prices. An embedding model maps text into a coordinate space where you find neighbors by similarity. Nothing labels anything until you build that layer yourself. Classification is the direct route: the API answers with a label from a set both sides agreed on in advance.
Three routes for three labeling jobs
This platform's classification category is three routes, each with an open-weight model class behind it. Each lane page carries its complete working contract.
Taxonomy labels: the IAB lanes
The fixed-standard route. The IAB Content Taxonomy is the advertising industry's shared label set for content, maintained by IAB Tech Lab. It is the reason a publisher's "news" and a buyer's "news" can shake hands. Version 2.x is the line most live ad stacks still label against today. The 3.1 revision rebuilt the tree. The Tech Lab frames the move as roughly 400 categories growing to more than 1,500. The official files count 1,196 named entries in 2.2 including descriptor groups, and 704 in 3.1 after the restructure. That restructuring, not size alone, is why a migration industry exists around it. There is no official hosted API for the taxonomy from the Tech Lab itself, which is the gap a hosted lane fills. Two lanes cover it here. The 2.x categorization lane is for stacks that still label against the legacy line. The 3.1 lane carries the cross-version map for stacks moving forward. A guide listed with this page works the 2.x to 3.1 migration end to end.
Typed extraction: zero-shot, no training loop
The caller-owned route. GLiNER is the open model class introduced in its 2023 paper. It takes a type list as part of the request and finds mentions of those types in text it has never seen, with no fine-tuning step on your data. Swap the type list, and the same call extracts invoice fields, contract clauses, or safety-relevant mentions. Adding a type is a text edit rather than a retrain. That property is what made the class a standard building block. The extraction lane page carries the request shape, the honest comparison against prompting a chat model for the same job, and the limits.
Decision models: score instead of generate
The choice-set route. The class became visible through one vendor's closed-weight decision system, and a family of open-weight classmates has since landed. The 421M parameter fast lane scores in tens of milliseconds. The 2B causal lane is for passes that need the bigger reasoner. The encoder lane is built for text batch work at volume. All three answer the same call shape: choices in, scores out. Cost shape is the story: scoring a choice is a smaller job than generating prose. The flows that run thousands of scores an hour, routing, ranking, triage, approval, are where the class costs less than the generate-then-parse pattern. The decision-model guide listed with this page explains the family from the ground up. It covers the closed-weight original and what the open classmates do and do not carry over.
One more model belongs to this set, and it is not a classifier. It is a multimodal embeddings model for text, images, and video. It belongs to the embeddings category, and its lane page carries it.
Choosing by the job
The fastest route to a decision is to name the labeling job, not the model.
| The job you have | The route | Why |
|---|---|---|
| Label ad inventory against the industry standard | IAB lanes | The label set is fixed by the standard; correctness means version fidelity and coverage |
| Find your own types in text, types that change per request | Typed extraction | The type list travels with the call; no training loop, no retrain to add a type |
| Score choices at volume: route, rank, triage, approve | Decision models | A score is cheaper and faster than generated prose; the call shape is choices in, scores out |
| Search by similarity across text, images, video | Embeddings | Nearest-neighbor search is a different job; no label set involved |
One honesty note belongs next to that table. A fixed taxonomy is only as good as its version discipline. Labels applied against 2.x do not mean the same thing as 3.1 labels, and the migration between them is real work, which is why it gets its own guide here. Zero-shot is strong at finding mentions but is not a substitute for a trained model when the label set is stable and the accuracy bar is high. The extraction lane page states where that line sits.
The classification catalog on this platform
This section states the offering at offering level. The models table on this page is machine-generated from the platform's own model data, and that data decides what serves. The table renders the taxonomy and extraction lanes; the three decision lanes are chat-route rows, so they render in the chat catalog and link from here.
Every lane named above is a serving model page: the model identity, its license, the use cases, and the exact request the hosted lane takes. The aliases answer calls, the lanes meter, and each rate renders on the pricing page. The models index shows every row's current state at any moment.
The metering is live. The taxonomy lanes meter by the page, the extraction lane by the search, and the decision lanes by the token, all paid from the prepaid wallet. A call that arrives after the balance is gone is refused with a named error rather than overrunning the deposit. A request the gateway turns away before relaying is never metered, so refusals cost nothing. Each rate renders on the pricing page from the platform's model data, which is why no number is typed here.
Running the models yourself
Every model class behind these lanes ships open weights, so the weights are not what a hosted lane sells. GLiNER trains and runs on a single GPU and has a plain Python path. The decision family spans three sizes on permissive weights: Apache 2.0 for the fast lane, Apache 2.0 for the causal lane, and Apache 2.0 for the encoder lane. That lane's deberta base is the MIT one. The smallest of them is laptop-scale. The IAB taxonomy itself is a published standard, so the label set was never the moat either. What a hosted lane sells is the service around the models. That service is an endpoint that stays up through a labeling spike, meters every request, and leaves the model-ops work on someone else's desk.
Running it yourself wins when the text must not leave your boundary, when volume is high and steady enough to justify a machine, or when you are tuning the model itself. The hosted lane earns its keep under the opposite conditions. The labeling is a means to an end. The type lists change per customer. Or the accuracy drift of a self-run open model on your own data is a risk nobody on the team owns. The lane pages each carry their own version of that trade.
Getting started
- Request an invitation through the console. The beta is invite-only for now; the wallet, API keys, and full spend history live there, and an account opened today can call every classification lane.
- Name the labeling job before the model. The table above routes the job to the lane; the lane page then carries the exact request to copy.
- Read the guide that matches the job. The migration guide covers the 2.x to 3.1 jump; the decision-model guide covers the fast, causal, and batch lanes from the ground up.
- The models index is the availability truth. Every row's rate renders on the pricing page, and the index shows each row's current state.
Everything else the platform serves is mapped on the models index. Chat, speech, transcription, embeddings, rerank, document parsing, and image generation all draw from one wallet.