100,000 leads in your database. Pick a build and do the work. Watch the tokens, but also feel the wait.
| 1 · No widget | 2 · Careless widget | 3 · Done right | |
|---|---|---|---|
| Changing the view | Type a new instruction and wait | Click, then wait on a model turn | Click, it responds immediately |
| Who is in the loop | you → model → server | you → widget → model → server | you → widget → server |
| Data you look at | Retyped by a language model, so it can be garbled | Rendered from the payload, accurate | Rendered from the payload, accurate |
| Freshness | Frozen text, stale the moment it prints | Refreshes, but each refresh costs a turn | Can poll or stream, free |
| Does the model see your every click |
Yes, you typed it | Yes, every one routes through it | No, only what you deliberately send |
| At 100,000 rows | Impossible, exceeds the window | Impossible, same reason | Fine, the widget pages through them |
| When it fails | Context blows, you lose the thread | Context blows, you lose the thread | A tool call errors, the widget shows it |
38 tokens. The model-facing tool returns 200 rows per call.
Retyping a table costs the model about 25 tokens per row, and those output tokens stay in
the transcript. The correct build's opening summary is 50 tokens and the final handoff of
the selected leads is 500. Window is 1,000,000.
Latency: a model turn that also retypes a table is 2.6s, a model turn without retyping is
1.5s, and a widget-to-server call is 0.12s. Timings are illustrative of the
round trips involved, not measured from your stack. No real API is called; every number is arithmetic
on these constants.