Reasoning Models

Some models on the Draven AI platform "think" before answering — spending extra output tokens on an internal reasoning pass before writing the final reply. Whether a model does this at all, and whether you can tune how much it reasons, is a per-model capability — never assume it from one model to the next.

How it works

Draven AI's API is a single, OpenAI-compatible surface in front of many different underlying models. Reasoning is not something Draven AI adds uniformly on top of every model — it's a capability each model either has or doesn't, implemented however that model's own architecture implements it. The API normalizes the request and response shape (the same thinking / reasoning_effort fields, the same message format, regardless of which model you call) but it cannot normalize what a model is technically capable of doing with its own reasoning process. That's why support fragments into distinct tiers instead of one universal on/off switch.

Concretely: a reasoning pass consumes output tokens before the visible reply is written, which is the mechanism behind the general trade-off — more reasoning tends to mean a slower, more expensive, but more carefully worked-through answer. Exactly how much slower or more expensive is model-specific and not something this page quotes numbers for, since it varies request to request.

Three tiers of support

Every chat model on the platform falls into exactly one of these three tiers. Knowing which tier a model is in tells you which of the two request fields (thinking, reasoning_effort) actually do something for it.

Two things worth being explicit about, since they're easy to get wrong:

• Tier 2 is not "tier 1 with worse UI." A model can reason without exposing any effort dial. Sending reasoning_effort to a tier-2 model isn't rejected, but it's a no-op — the request goes through, the model reasons exactly as it always does, and the field you sent is discarded before it reaches the model. Do not treat "the model thinks" as evidence that "the model has configurable effort" — they're independent facts about a model, not a package deal.
• Tier 3 fails silently, not loudly. If a model has no reasoning capability, sending thinking and/or reasoning_effort to it does not raise a 4xx error. Both fields are simply dropped server-side before the request is forwarded to the model. If you're testing whether a field "worked," an absence of errors tells you nothing — check the model's capability flags instead.

Checking support before you rely on it

The public, unauthenticated GET /v1/models endpoint (see Models) returns every model with two booleans you should check before sending either reasoning field:

These two booleans are the only reliable, always-current source for which tier a model is in — the catalog changes over time, so resolve this at runtime rather than hardcoding a list of model ids per tier.

The thinking field

This field is the on/off switch for reasoning, independent of how much reasoning happens. It accepts three equivalent shapes, kept for compatibility with different client conventions:

If omitted, reasoning is enabled by default for any model that supports it (tier 1 or tier 2) — you have to explicitly opt out, not opt in.

Turning reasoning off is not guaranteed to behave the same way across models. This is the single most important nuance on this page. Depending on the model, thinking: false resolves to one of three different behaviors server-side, and which one applies is not something the client controls or is told:

1. A genuine off. Some models have a real "off" state and stop reasoning entirely when asked.
2. A step below the model's normal floor. Some models don't have a real off switch, but the provider serving them does recognize a special, even-lighter effort level than the lowest step of the ordinary low–max scale (an internal value, not one you can request directly via reasoning_effort — it's only ever reached by sending thinking: false to one of these specific models). It's the closest thing to "off" that model's provider understands, but it isn't literally zero reasoning.
3. The model's normal lowest effort step, unchanged. The rest of the models with no real off switch and no special lighter-than-low level just keep reasoning at whatever their lowest ordinary step is — from the outside, indistinguishable from never having sent thinking: false at all.

This is a real limitation of specific models' own APIs, not a bug in how the request is relayed — there is nothing on the client side that forces a model to do something its own inference stack doesn't support. If a request needs to guarantee no reasoning tokens are spent, don't rely on thinking: false against a tier-1 or tier-2 model; pick a model where thinking is false in the model list (tier 3) instead.

The reasoning_effort field

This field controls how much a tier-1 model reasons — it does nothing on tiers 2 or 3. It's a string. The platform's core ordered scale, from least to most reasoning, is low–max below; minimal is included in the table to show where it sits relative to that scale, but read the note under the table before relying on it.

No model is guaranteed to accept the full five-step scale (low–max). A given tier-1 model might only recognize two adjacent values from that list (say, its own "on" and "off" ends of the range), three, or all five — that's an attribute of the individual model, not something this page can enumerate generically. What's guaranteed platform-wide is that the accepted values are always drawn from this ordered list, in this order. minimal is shown in the table above to make its position clear, but it isn't part of that guaranteed five-step set — see the callout right below for exactly which models take it as-is.

What happens if you request a level a model doesn't support

The request is never rejected for an unsupported or unrecognized reasoning_effort value. Instead, it's automatically mapped to the closest level that model actually accepts, using this rule:

1. If the value you sent is one of the five recognized strings and this model accepts it, it's used as-is.
2. "minimal" is honored as its own real wire value only on the specific models whose provider supports it (see the callout above); on every other model it's treated as a request below the bottom of the scale and resolved by rule 3.
3. Otherwise (including any level below this model's floor, above its ceiling, an unrecognized string, or "minimal"/"none" on a model that doesn't specially support them), the platform looks for the closest accepted value below what you asked for (or below the default of medium, if what you sent wasn't a recognized string at all) — i.e., it prefers to fall back to something cheaper and faster rather than more expensive than requested.
4. If nothing accepted exists below, it looks upward instead and uses the closest accepted value above.

In practice this means: asking a model for a level below its floor gets you that floor; asking for a level above its ceiling gets you that ceiling; and an unrecognized string falls back from the platform default (medium) using the same rule. You will never get an error for this — you may simply get a different effort than the one you asked for, so if precise effort matters, check the model's actual behavior rather than assuming your requested string was honored verbatim.

What you get back

The reasoning pass is internal to the model call. /v1/chat/completions returns only the final answer in message.content, formatted exactly like a response from a non-reasoning model — there is no separate reasoning-trace field in the response body, streamed or not. Setting thinking and reasoning_effort changes how the model arrives at its answer (and therefore the token usage and latency you're billed and measured on), not what shape the response takes.

Request examples

Replace your-model-id with a real id from Models whose capabilities you've already checked.

Tier 1 — requesting a specific effort level:

{
  "model": "your-model-id",
  "messages": [{ "role": "user", "content": "..." }],
  "reasoning_effort": "high"
}

Tier 1 — requesting "minimal" directly (honored as-is only on models whose provider supports that exact wire value; clamped to that model's floor, reasoning still on, everywhere else):

{
  "model": "your-model-id",
  "messages": [{ "role": "user", "content": "..." }],
  "reasoning_effort": "minimal"
}

Tier 1 — requesting "none" directly (equivalent to thinking: false):

{
  "model": "your-model-id",
  "messages": [{ "role": "user", "content": "..." }],
  "reasoning_effort": "none"
}

Tier 1 or 2 — asking the model not to reason (best-effort, see caveat above):

{
  "model": "your-model-id",
  "messages": [{ "role": "user", "content": "..." }],
  "thinking": false
}

Tier 2 — effort field sent but has no effect, since this model has no effort control:

{
  "model": "your-model-id",
  "messages": [{ "role": "user", "content": "..." }],
  "reasoning_effort": "max"
}

Accepted (HTTP 200). The model reasons at its own fixed internal default; "max" is discarded server-side and never reaches the model.

Tier 3 — both fields sent to a model with no reasoning support:

{
  "model": "your-model-id",
  "messages": [{ "role": "user", "content": "..." }],
  "thinking": true,
  "reasoning_effort": "high"
}

Accepted (HTTP 200). Both fields are dropped before the request reaches the model; the response is identical to one sent without either field.