Skip to main content

Client identification guide

Cortega records which application made each governed request so operators can answer "which system called this?" without minting a virtual key per app.

What appears in Observability​

On Observability → LLM Queries (and the other traffic tables), the first column is Agent Stack, above Timestamp Source.

Agent Stack is composed from request headers Cortega captures on every call:

SourceHeaderRole
Application name (recommended)X-Cortega-ApplicationStable name you choose for the workload
HTTP client identityUser-AgentWhat the client library or tool already sends
OpenAI / Stainless SDK metadataX-Stainless-Lang, X-Stainless-Package-Version, X-Stainless-Runtime, X-Stainless-Runtime-Version, X-Stainless-OS, X-Stainless-Arch, X-Stainless-AsyncLanguage, runtime, OS, and SDK version
Anthropic API pinanthropic-versionAnthropic SDK API version when present

Example Agent Stack values:

  • billing-reconciler · pydantic-ai/2.25.0 · python CPython · Windows · sdk 2.53.0
  • cortega-console/model-playground · cortega-console/model-playground
  • curl/8.7.1 (no application header set)

Gateway config must have been published after this capture was added; older gateways only start recording these fields after their next config reload.

Set X-Cortega-Application from your app​

Send a short, stable name for the workload on every request to the gateway:

POST /v1/chat/completions HTTP/1.1
Host: gateway.example.com
Authorization: Bearer <virtual-key>
X-Cortega-Application: billing-reconciler
User-Agent: my-service/1.4.0
Content-Type: application/json

Python (openai SDK):

from openai import OpenAI

client = OpenAI(
    base_url="https://gateway.example.com/v1",
    api_key="<virtual-key>",
    default_headers={
        "X-Cortega-Application": "billing-reconciler",
    },
)

Naming tips:

  • Prefer a durable workload name (claims-intake, nightly-summarizer), not a host or pod name that changes every deploy.
  • Keep it under a few dozen characters; avoid secrets or PII.
  • One shared virtual key can still separate traffic when each caller sets a distinct application name.

What the Cortega Console sends​

Console-originated gateway calls set both User-Agent and X-Cortega-Application so playground and diagnostic traffic is obvious next to customer apps:

SurfaceValue
Model Playgroundcortega-console/model-playground
MCP Playgroundcortega-console/mcp-playground
Provider diagnosticscortega-console/provider-diagnostics
LLM benchmarkscortega-console/llm-benchmark
AI Verifiercortega-console/edge-verifier

You do not need to configure these; the management backend adds them when it originates the governed call.