A code editor that can't be slow — two latency bugs in the in-app drawer
The in-app code drawer felt sluggish: clicking File History re-parsed the whole 5k-node memory graph from disk every time, and the Ask agent ran on the user's heavy default model. Fixed with a signature-based graph cache and per-provider model selection.
The rule for a code surface is simple: it cannot be slow, even a little. Two things were breaking that in Talkak's in-app drawer.
Bug 1 — the memory graph was re-parsed on every click
The "📜 File history" strip and "🔍 Quick Review" both ask the operating-memory
graph "what touched this file?". Under the hood that routed through
GraphStore::read_all, which — every single call — listed the graph directory,
read every .jsonl file to a string, and parsed all of it. With ~5,300 nodes
that's a real hit on each History click, and Quick Review paid it before even
spawning the agent.
Fix: a signature-based cache. dir_sig hashes each file's
(name, size, mtime) into a u64; if the signature matches the cached one, the
parsed Vec is returned straight from memory. Any append — ours, or another
process like the MCP server writing the same files — changes a file's size/mtime,
so the signature changes and the cache refreshes itself. Correct across
processes, and the steady-state cost drops to a directory stat (microseconds)
plus a memory read.
Bug 2 — the Ask agent ran on the heavy default model
code_ask invoked claude -p with no --model, so it used whatever the user's
Claude Code default is — for a coding user, that's Opus. Great for writing code,
overkill (and slow) for "explain this file". Meanwhile the app's own
summarize/correct paths already pin claude-haiku-4-5 / claude-sonnet-4-6 for
exactly this reason — the pattern just hadn't been applied here.
Fix: model selection, like choosing a model in the terminal. code_ask
takes an optional model and passes --model; the Ask panel got a per-provider
dropdown that defaults Claude to Sonnet (fast + capable), with Haiku
(fastest) and Opus (best) one click away.
The lesson
On a hot path that must feel instant, don't re-parse an append-only store on
every read — a (count, size, mtime) signature cache is multi-process-safe and
removes the re-parse entirely. And when you shell out to a BYO CLI, don't lean on
its heavy default model; name the model that fits the task.
Both are compile-verified (cargo check and tsc clean) and live in the dev
build; the felt speed-up is for me to confirm by using it.