{"version":"2.1.268","anchor":"api-request-telemetry-gains-a-ttft-ms-field-and-firstcontent","canonical_anchor":"api-request-telemetry-gains-a-ttft-ms-field-and-firstcontent","heading":"API request telemetry gains time-to-first-content, per-attempt request IDs, and richer retry data","tier":"internal","area":"Telemetry","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/api-request-telemetry-gains-a-ttft-ms-field-and-firstcontent","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### API request telemetry gains time-to-first-content, per-attempt request IDs, and richer retry data\n\nAPI call telemetry now tracks time-to-first-content, a client request ID per attempt, and more detail on retries\n\n**What**\n\n- The end-of-request telemetry (the `api_request` event and related completion logging) now tracks a `firstContentMs` value \u2014 time to first content \u2014 separately from time-to-first-token, and includes a `ttft_ms` field when that value is available.\n\n- 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`).\n\n- 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 \u2014 success\/failure, status code, error class, attempt number, `clientRequestId`, `requestId` \u2014 plus a `durationMs` field on `tengu_api_success` that excludes time spent on retries.\n\n**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.\n\n- Area: Telemetry\n- Names: `ttft_ms`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}