Response headers

DirectInference returns a few headers that let you observe how a request was handled — without ever exposing the model behind it.

X-DI-Request-Type

Every response on the DI surface carries an X-DI-Request-Type header naming the request type the call was classified as — pro, code, vision, document, long, json, reason, or flash. It is a fact about your own request (a PDF makes it a document request), so it is safe to surface; the model that served it stays private.

Python

# The OpenAI SDK exposes raw response headers via with_raw_response.
raw = client.chat.completions.with_raw_response.create(
    model="gpt-5.5-mini",
    messages=[{"role": "user", "content": "Refactor this function."}],
)

print(raw.headers.get("x-di-request-type"))   # -> "code"

resp = raw.parse()                             # the usual typed completion
print(resp.choices[0].message.content)

TypeScript

// .withResponse() hands back the raw Response alongside the parsed data.
const { data, response } = await client.chat.completions
  .create({
    model: "gpt-5.5-mini",
    messages: [{ role: "user", content: "Refactor this function." }],
  })
  .withResponse();

console.log(response.headers.get("x-di-request-type")); // -> "code"
console.log(data.choices[0].message.content);

curl

# -D - dumps response headers to stdout; the body still streams as normal.
curl -sS -D - -o /dev/null https://api.directinference.com/di/v1/chat/completions \
  -H "Authorization: Bearer llm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5-mini",
    "messages": [{ "role": "user", "content": "Refactor this function." }]
  }' | grep -i "x-di-request-type"

# x-di-request-type: code

HTTPie

# --print=h prints only the response headers; the body is discarded.
echo '{ "model": "gpt-5.5-mini", "messages": [{ "role": "user", "content": "Refactor this function." }] }' \
  | https --print=h POST api.directinference.com/di/v1/chat/completions \
      Authorization:'Bearer llm_live_...' \
      Content-Type:application/json \
  | grep -i "x-di-request-type"

# x-di-request-type: code

Go

var raw *http.Response

resp, err := client.Chat.Completions.New(
  context.TODO(),
  openai.ChatCompletionNewParams{
    Model: "gpt-5.5-mini",
    Messages: []openai.ChatCompletionMessageParamUnion{
      openai.UserMessage("Refactor this function."),
    },
  },
  option.WithResponseInto(&raw), // capture the underlying *http.Response
)
if err != nil {
  panic(err)
}

fmt.Println(raw.Header.Get("X-DI-Request-Type")) // -> "code"
fmt.Println(resp.Choices[0].Message.Content)

Where it appears

The header is set on the DI surface (…/di and …/di/v1), not on /v1. It is allow-listed in Access-Control-Expose-Headers, so a browser client can read it cross-origin. The value matches the names in Request types; the same vocabulary rolls up in Usage & analytics.

Rate-limit headers

If the calling key — or your account — has a spend cap set, successful responses carry standard rate-limit headers that express the cap as a request budget, so an SDK can self-throttle. Keys with no cap (the default) receive none.

On the OpenAI and Gemini surfaces:

• x-ratelimit-limit-requests — the cap expressed as a whole-request budget
• x-ratelimit-remaining-requests — budget left in the current window
• x-ratelimit-reset-requests — seconds until the window resets

The Anthropic surface uses that provider’s spelling — anthropic-ratelimit-requests-limit, anthropic-ratelimit-requests-remaining, and anthropic-ratelimit-requests-reset (an RFC 3339 timestamp). All are allow-listed in Access-Control-Expose-Headers. When a request is actually blocked by a cap, the 402 carries a Retry-After instead — see Spend & limits.

A budget, not a backend price

The request budget is derived from your own spend cap using a fixed nominal per-request figure — it is a self-throttling signal, not a quote, and it never reflects what any backend model costs. The cap itself is yours; the model that serves you stays private.

What DirectInference never returns

There is no resolved-model header. Other services hand back the model they picked; DirectInference does not — not in a header, not in the body, not in a trailer. The response echoes the model id you sent and nothing about the candidate, provider, version, cost, or trace that produced it.

Opacity is the contract

Because no backend identity is ever returned, your logs, dashboards, and eval pipelines cannot accidentally capture — or come to depend on — a specific model. That is what lets DirectInference move traffic to a better or cheaper model at any time with zero changes to your code. The only classification signal you get back is the request type above.