Skip to content
Radient LogoRadient Documentation

Radient Automatic

Radient Automatic is the routing layer behind the auto model. Set model to "auto" in any chat request and Radient selects the model that serves it, so you do not have to track which model is best or cheapest for each task — the choice is updated for you without code changes.

bash
curl https://api.radienthq.com/v1/chat/completions \
  -H "Authorization: Bearer $RADIENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [{ "role": "user", "content": "Summarize this release note." }]
  }'

#What auto does today

  • Text and image requests are served by the current default model. Tool use (function calling) is supported on this route.
  • Requests that carry video, audio or file inputs — content the default model cannot read — are routed to a model that accepts every modality, so the request still goes through. That model is billed at its own rate.
  • Only the content steers the choice. The routing decision looks at the request's message content, its content-part types, and whether tools are present. Parameters like temperature, max_tokens and reasoning controls do not influence which model serves the call.
  • If the route cannot serve a request (for example the serving endpoint is unavailable), the call fails with an error rather than silently switching to a different backend.

#Auto effort

reasoning_effort (and its object form, reasoning: { "effort": … }) accepts the special value "auto":

json
{
  "model": "auto",
  "reasoning_effort": "auto",
  "messages": [{ "role": "user", "content": "Plan a migration." }]
}

What "auto" means today:

  • It is a Radient-defined value, not a model value. The server resolves "auto" to the service default — currently "max" — before the request is forwarded. It is not adaptive: the server does not inspect your prompt to pick a depth.
  • Every other value ("low", "medium", "high", or a value the serving model understands) is passed through unchanged.
  • Whether the depth reaches the model depends on the route that serves it; where a model does not accept reasoning controls, the field has no effect.
  • The resolved effort is not reported back — no response field and no header carries it.

#Seeing what served your call

There is no header or field reporting the routing decision itself. What you can read from a response:

  • model — the model that actually served the request (for auto this is the serving model's id, never the string "auto").
  • provider — the serving endpoint, as reported by it.
  • cost — the versioned cost object: the amount in USD deducted from your balance, top level as a sibling of usage; usage.cost mirrors the same figure. When no figure is present, none was available for the call — it does not mean the call was free. See Cost reporting.

The console's usage view shows the same attribution per request.

#What a call costs

  • auto is deducted 1:1 with the serving model's cost — no markup at inference.
  • The default route is billed from its published rate card: currently $0.30 per million input tokens, $1.20 per million output tokens, $0.006 per million cached input tokens. The models listing's auto entry publishes the current figures; if the active route has no published card, its pricing shows -1 and the response's cost object is the record of the charge.
  • A request served by the all-modality fallback model is billed at that model's own rates.
  • Before a call is admitted, the credit gate reserves an estimate for it — for the auto id the reservation is a flat $1.00. The reservation is released as the call settles; the actual charge is written to your ledger. See the credit gate.

#Streaming

auto supports streaming exactly like a named model: "stream": true returns SSE frames as the model produces them, ending with data: [DONE]. With streaming, the final usage frame carries the same usage object alongside the cost object. Send stream_options: {"include_usage": true} to always receive it. See Chat API.

#Failures

Routing failures surface with the same shape as any chat call:

  • A request to auto that cannot be served answers 500 {"error":"Failed to process chat completions request"} (non-streaming). With streaming, headers are sent before the model is contacted, so a later failure cannot change the status — see Chat API.
  • The credit gate can refuse the call with 402 {"error":"insufficient credits"} before anything is sent.

#Related