Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
Remote ControlArea: what it touches
Internal ChangesKind: in v2.1.277,
Internal ChangesSection of the release
What
The remote transport used for Remote Control sessions now tracks, per message, the wall-clock time a user message frame actually arrived over the wire. It does this through a new transport callback, setOnUserFrameReceived, which populates a bounded map of arrival timestamps, and a method, takeUserFrameReceivedWallMs, that reads and clears the timestamp for a given message.
The base (local, non-remote) session read-loop class also gained a takeUserFrameReceivedWallMs method, but it always returns undefined there since there's no network transport to time. Only the remote-transport subclass has the real implementation.
Why
This timestamp feeds into other latency telemetry (such as flag-settle timing), letting Claude Code measure delays specific to remote sessions without affecting local sessions, which have no equivalent network hop to measure.
