Go-Live Checklist

Before sending production traffic:

• Keep API keys, authorization headers, prompts, generated content, and raw provider errors out of application logs.
• Log response.provider, response.model, response.id, and response.policy_version_id on every request. These correlate behavior changes to provider, model, and policy shifts.
• Pass a seed value for requests whose output you need to reproduce, such as tests and eval suites. Check response.determinism.seed_honored to know whether the selected provider honored it.
• Handle errors by error.category, not just HTTP status code. See the Error reference for the full table.
• Track these rates in your analytics: upstream_error_rate, model_output_rate, and fallback_to_deterministic_rate.
• Page on silent routing degradation — see the routing observability playbook below.
• Pre-check payload sizes against the limits object from GET /v1/me instead of hardcoding limits.
• Send Idempotency-Key on transcription requests so a retried upload can never double-transcribe or double-bill.
• Honor error.retryable — including NO_HEALTHY_PROVIDER with retryable: false, which is a configuration gap that retries cannot fix.
• Pin the preferred model in your routing policy for requests whose behavior must not change without an explicit policy edit. Otherwise LatentKit can route to another healthy eligible model as policy, provider health, or failover state changes.

Minimum log payload

{
  "latentkit_request_id": "req_abc123",
  "provider": "openai",
  "model": "gpt-4o-mini",
  "policy_version_id": "pol_v_xyz789",
  "input_tokens": 1234,
  "output_tokens": 567,
  "seed_honored": true
}

For failures, log:

{
  "latentkit_request_id": "req_abc123",
  "error_code": "UPSTREAM_ERROR",
  "error_category": "upstream",
  "provider": "anthropic",
  "model": "claude-sonnet-4-6",
  "retryable": true
}

Routing observability playbook

Two routing outcomes are successful responses from the wrong model — they return 200, surface in no error rate, and are visible only on the response envelope:

The alerting rule: count both signals per purpose in your metrics pipeline and page when either is non-zero for a purpose that matters. There is no other way to see them — they are not errors, and no error-rate alert will fire.

purpose_sent = "meeting-transcription"
source = response.get("lk_purpose_source")
if purpose_sent and source in ("fallback_purpose_exhausted", "purpose_unknown"):
    metrics.increment("latentkit.purpose_degraded", tags=[f"purpose:{purpose_sent}", f"source:{source}"])

The LatentKit SDKs also surface these as a warnings callback (see SDK resilience features); the console's analytics view charts degradations per purpose as a backstop, but your own paging is the primary alarm.

Related

• Response contract
• Determinism and reproducibility
• Error reference
• Routes & policies