Step classifier

The step classifier labels every inbound request with the agent-loop step it represents, so the gateway can route each step to the model that historically wins on that kind of work. A planning step and a tool-arg formatting step have different cost and quality trade-offs; pinning one model for both overpays on the cheap step or underperforms on the hard step. The classifier names the step, and the router plus the capability resolver bias the model pick toward the right tier for that step.

The classifier is per-step routing intelligence. It runs on the prompt text of the last user message and emits a step-class label, a complexity tier, and a thinking budget. The labels are descriptive of the work, not the model tier, so the vocabulary stays stable even as the underlying model picks change.

The step-class vocabulary

The classifier emits one of six step-class labels:

• planner for the decomposition step in an agent loop, where the agent breaks a goal into subgoals or lays out an ordered plan.
• tool-arg-formatter for the step that emits a function call against a JSON schema, where the output shape is the structured argument blob.
• summariser for the step that condenses a long input into a short output.
• extractor for the step that pulls specific fields out of a larger body of text.
• coder for the step that writes or reviews code.
• critic for the step that evaluates a prior output against a specification.

The labels are mutually exclusive; the classifier picks the single label that best fits the step, favouring the most agent-loop-specific signal. When no label clearly applies, the classifier returns no step-class and the request routes on its complexity tier alone.

Complexity tier and thinking budget

Alongside the step-class label, the classifier emits a complexity tier of simple, moderate, or complex, and a thinking budget of none, low, medium, or high. The complexity tier maps to a model family: simple to a cheap fast model, moderate to a mid model, complex to the operator's chosen flagship. The thinking budget controls how much extended reasoning the model spends on the call, where none runs the model with no extended thinking and high unlocks the long-form chain-of-thought a hard planning or synthesis step needs.

The two axes are independent. A short planner prompt can carry a high thinking budget on a moderate complexity tier, because the value is in the reasoning depth rather than the raw model size; a long tool-arg prompt can carry a thinking budget of none because the output shape is the function call and there is nothing for the model to think about.

How the step class biases routing

The step-class label biases the model pick after the complexity tier and the thinking budget are set. A step labelled planner biases toward a thinking-budget-high variant because the planning step rewards the long-form reasoning path. A step labelled tool-arg-formatter biases toward a strict-function-calling model with the thinking budget off, because the schema shape is the output. A step labelled critic biases toward a review-tuned model that lands the evaluation without paying the flagship premium.

The bias composes with the capability resolver's focus-mode bias rather than overriding it. When an operator flips the org's focus mode to cost reduction, the resolver prefers the cheaper variant within the step's tier; when the operator flips to quality mode, the resolver prefers the premium variant. The step-class bias and the focus-mode bias both shift the same model pick, and the two stack so the final model reflects both the kind of step and the operator's cost posture.

Latency and replay

The step classifier runs in the request's fast path. It adds no extra network round-trip and stays off the request's latency budget, so the labelling cost is negligible compared to the upstream model call. The label it returns is persisted to the route-decision row, so the session trajectory can replay the step class the gateway saw for every call in the loop.

Related pages

Routing explains how the classifier output maps to a model family and a fallback chain. Capability aliases explain how a cap: reference resolves to a concrete model, and how the step-class bias composes with the per-org capability table at resolve time.