2 min lesson
Latency is a feature and it has a budget
Rebuild the parts of "Latency is a feature and it has a budget", then say why each one matters.
Step 1 of 2
Latency is a feature and it has a budget
Tab has to feel like it's reading your mind, which means the suggestion has to arrive before you've finished forming the thought. Cross the perceptual threshold and developers stop waiting for it - they type past the ghost text and the habit dies.
- Tab / inline completion
- Sub-perceptible. If it's not effectively instant, it competes with the keystroke and loses
- Inline edit (⌘K)
- Fast enough to stay in flow; a short, visible wait is tolerable because the user asked
- Chat
- Streaming buys patience - first tokens fast, full answer can take seconds
- Agent
- Minutes are acceptable if progress is legible; an opaque spinner is the real failure
The budget tracks how much the user asked for the wait. Tab asked for nothing.
Cloud agents make the budget concrete. They were optimized for reliability first, latency next, and the ~10-minute runtime is acceptable precisely because they run in the background and notify you when done - the user shifted from babysitting to reviewing. The routing rule is the product judgment: foreground work is interactive, ambiguous, decision-heavy and you watch it; background work has clear acceptance criteria and is pure execution. The wait is only a problem when the user is sitting there waiting on it.
At the opposite end, ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. is the inverse bet: Cursor built its own coding model partly because raw speed keeps a developer in flow. A model fast enough to feel instant on execution defends the same flow state Tab protects - latency isn't just a cost, it's what keeps the tool a daily home.