Follow Discord
Sweep 22 Sep 2026 · 17:19Z Build v2.1.280 501 read Stable v2.1.267 Latest v2.1.280 Next v2.1.280 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.268 ·

API request telemetry gains time-to-first-content, per-attempt request IDs, and richer retry data

API call telemetry now tracks time-to-first-content, a client request ID per attempt, and more detail on retries

TierUnder the hoodhow much it should matter to you
Useful1my rating, 1 to 5
Signal1worth watching, 1 to 5
AreaTelemetrywhat it touches
KindInternal Changesin v2.1.268,
Group of 3 Under the hood

API call telemetry now tracks time-to-first-content, a client request ID per attempt, and more detail on retries

What

  • The end-of-request telemetry (the api_request event and related completion logging) now tracks a firstContentMs value — time to first content — separately from time-to-first-token, and includes a ttft_ms field when that value is available.
  • The main API-call success event, tengu_api_success, now also records firstContentMs, a client-generated request ID (clientRequestId), and the UUID of the originating user message (user_message_uuid).
  • The API call dispatcher now generates a new clientRequestId for each attempt (sent as an extra header) and tracks an attempt counter, reporting request lifecycle telemetry — success/failure, status code, error class, attempt number, clientRequestId, requestId — plus a durationMs field on tengu_api_success that excludes time spent on retries.

Why These fields give much finer-grained visibility into API call performance and retry behavior, making it possible to distinguish slow model responses from network/retry overhead and to trace individual attempts by their request ID.

See this entry in the whole of v2.1.268 →

Feedback