{"version":"2.1.282","anchor":"new-at-internal-frame-intake-phases-ms-timing-field-in-the-sdk","canonical_anchor":"new-at-internal-frame-intake-phases-ms-timing-field-in-the-sdk","heading":"SDK results can carry an internal breakdown of message intake timing","tier":"internal","area":"SDK","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/new-at-internal-frame-intake-phases-ms-timing-field-in-the-sdk","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### SDK results can carry an internal breakdown of message intake timing\n\nThe SDK result format gains an optional internal field timing each step between a message arriving and being queued\n\n**Unclear.** It is not clear whether Claude Code currently fills in this field.\n\n**What**\n\nThe result format used by the SDK (the kit for driving Claude Code from other programs) has a new optional field, `frame_intake_phases_ms`. It splits the time between a message from the host program arriving and it being queued for Claude into steps: before_read, dedup, flag_settle, receive_hook, attachments, admission_wait, admit_check and other. The format marks the field as internal.\n\n**Why**\n\nThe breakdown helps show where time goes when a message sent to Claude Code is slow to start being handled, for example on a slow first turn in an SDK or remote session. Because it is marked internal, it is not meant to be relied on.\n\n- Area: SDK\n- Names: `frame_intake_phases_ms`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}