Clicky could explain whatever was on my screen. It just made me sit in silence first.
The obvious fix was a faster model. The actual fix was to stop making independent work wait in a queue.
I timed the wait, not the whole request
My useful metric was first audible word. On the multi-sentence benchmark, the original path took about 3.7 seconds: capture the screen, transcribe the question, prepare the model, generate the answer, then synthesise all the speech.
Only some of those steps depended on each other.
The moment the hotkey is released, Clicky now starts screen capture, memory recall and provider setup together. It streams text sentence by sentence. As soon as the first sentence is complete, speech begins while the model keeps writing.
That moved the measured multi-sentence path from 3.7 seconds to 1.7 seconds without changing the model.
Memory stayed inspectable
I skipped a vector database. Each app keeps plain Markdown the user can open or edit, with SQLite handling the index. It follows Karpathy's LLM-Wiki pattern and is much easier to debug.
Playback needed its own pipeline
Starting speech early created a new problem. If synthesis and playback shared one buffer, every sentence boundary could produce an awkward pause.
Clicky uses a double buffer instead. While one sentence plays, the next is synthesised into the other buffer. Playback swaps only when the next clip is ready.
This is not a blanket sub-two-second claim. Short single-sentence prompts can still take roughly four to six seconds because there is less work to overlap. The useful improvement is that long answers start speaking much sooner and keep speaking smoothly.
Latency work gets easier when the metric matches what the user feels.