> ## Documentation Index
> Fetch the complete documentation index at: https://docs.airmux.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Request lifecycle

> Follow an inference request from authentication through policy, translation, streaming, and usage export.

One inference request follows the same stages regardless of caller dialect or provider family.

<Steps>
  <Step title="Authenticate">
    The gateway captures its current bundle set and selects the first non-empty credential: bearer token, `x-api-key`,
    then the protected playground cookie. It hashes the selected token and looks up the active inference-key entry.
    Missing, unknown, expired, or not-yet-adopted keys are rejected.
  </Step>

  <Step title="Parse">
    The request path selects its bound ingress adapter. The adapter validates the caller's wire shape and produces
    a canonical request plus any translation adjustments.
  </Step>

  <Step title="Resolve the route">
    The gateway looks up the requested catalog model and provider, then checks required input modalities and
    capabilities such as streaming, tools, reasoning, or structured output.
  </Step>

  <Step title="Evaluate policy">
    Matching rules compose against the original request. A denial stops before any provider call. Credential rules
    filter candidates, and a fallback rule can add bounded backup routes.
  </Step>

  <Step title="Resolve a credential">
    The gateway chooses the most specific populated allowed scope, orders candidates by priority, and resolves the
    selected versioned secret reference. Secret values never enter the bundle.
  </Step>

  <Step title="Reconcile and translate">
    Provider and model profiles re-spell, clamp, forward, or drop parameters. The egress adapter writes the provider
    request by hand and attaches upstream authentication.
  </Step>

  <Step title="Execute and render">
    Buffered responses are translated into canonical and then into the caller's dialect. Streaming responses are folded
    incrementally without buffering the whole completion.
  </Step>

  <Step title="Account">
    `airmux` records tokens, cache usage, estimated status, cost, latency, route, credential metadata, bundle ID, and
    outcome. The event's request ID matches the response's `X-Request-ID` header. The local outbox exports the event to the control plane.
  </Step>
</Steps>

If an eligible failure occurs before response headers, routing can advance to another credential or fallback model
within the attempt and deadline limits. After streaming starts, failures are rendered as events because the HTTP status
has already been sent.