Headers

Manifest reads a few request headers, and returns a set of X-Manifest-* response headers so clients can see what happened without parsing the response body.

Request headers

Header	Value	Effect
`Authorization`	`Bearer mnfst_<key>`	Required. Authenticates the harness.
`Content-Type`	`application/json`	Required.
`anthropic-version`	`2023-06-01`	Accepted and ignored. Anthropic SDKs send it on their own. Manifest picks the version it sends upstream.
Your custom tier header	your value	Routes the request to a custom tier. You set the key and value when you create the tier, so the exact header name is up to you.
`x-session-key`	any string	Groups requests into a session. Manifest keeps a session on the same upstream where the provider supports it, for sticky routing and prompt caching.

The custom tier header is the only one that changes routing: send the header you configured on a tier and the request goes to that tier’s model. The header wins even when the body names an explicit model ID. See Routing → Custom.

Response headers (routed requests)

Header	Description	Example
`X-Manifest-Tier`	How the request was routed: `standard` after a custom-tier header match, `direct` for an explicit model ID, `simple` when Manifest answered without calling a provider	`direct`
`X-Manifest-Model`	Model that actually served the response	`claude-sonnet-4-6`
`X-Manifest-Provider`	Upstream provider	`anthropic`
`X-Manifest-Reason`	Why that route was picked, for example `header-match`, `direct`, or `default`. Other values exist	`header-match`
`X-Manifest-Output-Modality`	Output modality of the response	`text`
`X-Manifest-Response-Mode`	Whether the response was streamed or `buffered`	`buffered`

Your custom tier’s name appears on the request in the dashboard, never in a header. When Manifest answers a request itself (a spend block, no provider connected, a model it cannot serve), X-Manifest-Model and X-Manifest-Provider both report manifest.

Response headers (fallback only)

When the primary model fails and Manifest succeeds on a fallback, two extra headers are added:

Header	Description	Example
`X-Manifest-Fallback-From`	The primary model that was attempted first	`gpt-5`
`X-Manifest-Fallback-Index`	Position in the fallback chain (0 = first fallback)	`0`

When every model in the chain fails:

Header	Description
`X-Manifest-Fallback-Exhausted`	Set to `true`. The response keeps the primary model’s real error status; the body carries code `fallback_exhausted`.

Reading headers in code

const response = await fetch("http://localhost:2099/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.MANIFEST_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "auto",
    messages: [{ role: "user", content: "Hello" }],
  }),
});

console.log(response.headers.get("x-manifest-tier")); // → "default"
console.log(response.headers.get("x-manifest-model")); // → "gpt-5-mini"
console.log(response.headers.get("x-manifest-provider")); // → "openai"

Header names are case-insensitive in HTTP, but most browser fetch implementations lowercase them when reading. The proxy emits them as X-Manifest-*.

Getting Started

Self-hosting

Features

CLI & MCP

Providers

Integrations

Reference

Request headers

Response headers (routed requests)

Response headers (fallback only)

Reading headers in code

​Request headers

​Response headers (routed requests)

​Response headers (fallback only)

​Reading headers in code

Request headers

Response headers (routed requests)

Response headers (fallback only)

Reading headers in code