Latency is a budget, not a headline.

The fastest part of a workflow rarely explains how long the whole workflow takes.

A useful latency discussion starts by naming the operation being measured. Connection setup, interface observation, model inference, input injection, and application rendering are separate costs. Putting the smallest number from that chain on a landing page does not make the complete task fast.

Separate the layers

Our control-layer target is approximately 100ms for an individual warm action. That is a target, not a universal measurement. In a recent home-screen comparison, the controller returned a full screen in 447ms and a compact view in 306ms. Those values exclude the model’s decision and the application’s next network request.

task time = observation + reasoning
          + action + application response
          + verification + recovery

Optimize repeated work first

Keeping a connection alive avoids setup on every action. Parsing one observation into reusable references avoids redundant extraction. Returning a new view with an action can remove a tool round trip. These improvements reduce repeated work without pretending an application has finished before it has.

Measure useful completion

The meaningful endpoint is the user’s intended state: the right page open, the correct query present, or the requested track visibly playing. A test that checks only a command’s return value can miss all three.

Record both typical and slow cases. Include cold starts and recovery. If an optimization makes the common path faster but causes more retries, the end-to-end result may get worse. A mature performance story explains the conditions of a number and the boundary of what it proves.