Why It Feels Fast
A slow agent can still feel fast. You build that gap out of three moves. Stream each word as it lands, run the independent chores together. Start the next tool before the message ends. Latency is a product decision.
Two clocks run on every task. One says when the work is done. The other says when you first see anything at all. You only feel the second one.
Latency model
Two moves make a slow job feel quick. Both of them work on the waiting.
It shows you each word the moment it writes one, like reading over a shoulder. You never sit in front of a blank screen wondering whether it is stuck.
It also runs the boring chores while it thinks, instead of after. The work stays the same size. The waiting shrinks.
Early on I treated speed as one number. The model runs at the speed it runs, and the work takes the time it takes. So I stopped trying to shrink the work and started spending the wait instead. Replay the pair below and watch when each lane first says anything.
01Being fast and feeling fast are different problems
The two clocks come apart. A slow agent still feels alive when it shows you something in the first half-second. A fast agent feels dead when it sits silent and drops the whole answer at the end. People forgive slow, and they read silence as broken. So the first thing to cut is the time to the first sign of life.
02Streaming is the cheapest speed there is
Streaming is the first move I reach for. Show each word the moment the model writes it, instead of holding the answer back until the end. The work does not change. The first thing you see moves from the end of the run to the start. You read along while the agent writes. The mode toggle below removes streaming so you can feel the difference.
The best speed work
I filed streaming under polish for too long. It attacks the wait you feel, and it leaves the clock alone. No other speed move here pays back as well. Start talking twice as soon and you feel twice as fast.
03Do the independent work at the same time
Most of what an agent does has no link to the rest: three file reads, two independent searches. Run them in a line and the waits pile up. Run them together and the total falls to about the slowest single one.
The tool system already holds the rule. Read-only tickets go through in a batch, and anything that writes goes alone. Telling those two apart is the whole job. Batch two chores that reach for the same file and you trade a little waiting for a broken result.
04Start the next thing before the last one ends
The quietest win is overlap. The moment a tool request appears in the stream, the agent starts that tool. The rest of the message is still arriving. The pairing rule still holds: the result lands right behind the request that asked for it. Thinking and doing run at once. Below, the two lanes differ only in when the tool starts.
05This is where slowness creeps in
Felt speed is built, so it comes apart with nothing breaking. A blocked stream drops you back into the dark. Chores that once ran in a batch go back into a line. Touch the front of the prompt and you lose the free prefix, so you pay for the tail again.
Nothing throws an error, and the agent goes slow and silent again. Speed is a thing you maintain, and it leaks the moment you stop measuring it.
The cost
Felt speed can hide real slowness. A confident wrong answer shown right away beats a slow correct one on feel. It wins your trust before it earns it. Running many chores at once trades a little waiting for the chance that two of them collide. Work on the feel alone and the bill and the clock grow while no one looks. Run the two tests below against the clock as well as the feel.
Decision
I order the work by the first sign of life, then by the total. The test is one hard task and two clocks. How long until you see it doing anything? How much of the independent work runs at the same time? Silence until the end, or plainly separate steps walked one by one, leaves the cheapest speed on the floor. Once the fast part is over, the question is what the agent keeps between sessions.