{"version":"2.1.277","anchor":"message-enqueue-telemetry-gains-detailed-timing-breakdown","canonical_anchor":"message-enqueue-telemetry-gains-detailed-timing-breakdown","heading":"New detailed timing telemetry for message enqueue and turn start","tier":"internal","area":"Telemetry","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/message-enqueue-telemetry-gains-detailed-timing-breakdown","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### New detailed timing telemetry for message enqueue and turn start\n\nNew telemetry breaks down how long messages take to enqueue and turns take to start, using new frame-timing data\n\n**What**\n\nWhen a message is delivered, Claude Code now records `frameTiming` (a received and an enqueued wall-clock timestamp) on the command.\n\n- The `cli_user_message_enqueued` telemetry event gains new fields: `parse_to_enqueue_ms`, `dedup_ms`, `flag_settle_ms`, `receive_hook_ms`, and, when attachments are present, `attachments_ms`, `attachment_count`, and `inlined_images`, plus `parked_ms` when a park timestamp was recorded.\n\n- A new telemetry event, `cli_turn_started`, is emitted when a turn is dispatched, including the turn's uuid, the batch size, and `enqueue_to_start_ms` (the time from when the turn was enqueued to when it actually started), whenever frame timing info is available.\n\n**Why**\n\nThis gives a more detailed breakdown of where time goes between a message arriving and a turn actually starting, which helps diagnose latency in message handling.\n\n- Area: Telemetry\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}