As noted, I saw a post of another person running 3 agents. The max I'm able to manage is about 4 with 2 managers and auditors. But having a second screen for them is pretty handy. This is just a little 16" portable monitor on a mini arm.
If you use Claude heavily, you've felt this: every session starts from zero. You re-explain context, Claude helps, the window closes, and the next session has no idea what you decided yesterday. The standard workaround is a markdown wiki Claude reads — but as the wiki grows, every "what did we decide about X" question burns thousands of tokens grepping and re-reading whole pages.
I spent the last few weeks building a persistent memory layer to fix both problems. It runs entirely on my own machine, integrates via MCP, and lives between Claude and my existing wiki. Sharing the architecture and what I learned in case anyone wants to build their own.
Inspired by Andrej Karpathy's writing on LLM-native wikis, then formalized into a build spec:
retrieve, crystallize_session, list_sessions, get_l4_node, index_status, reindex, shutdown_models)No cloud, no API keys, $0 marginal cost per query.
Hot-path retrieve was inexplicably stuck at 2241ms p95 even though the embedding model was fully GPU-resident on a 4070 Ti Super. Spent hours blaming GPU offload, prompt cache, KV pre-allocation. The actual cause: every httpx.post() was opening a fresh TCP connection, and Windows localhost handshakes take ~2 seconds. A 5-line change — switching to a persistent httpx.Client with keep-alive — dropped p95 to 39ms. 57× speedup.
Lesson: latency that's suspiciously consistent (2240, 2237, 2241, 2227, 2239 ms) is a fixed cost, not a compute cost. If your local-MCP integration feels slow on Windows, check connection reuse before you blame the model.
<think>...</think> blocks the chat handler strips before populating message.content. With JSON grammar enforced, the model spent all 2000 tokens "thinking" and never emitted JSON. Fix: pass chat_template_kwargs: {enable_thinking: false} via extra_body (requires --jinja on llama-server).~/.claude.json like Claude Code does. The first attempt at MCP registration silently went to the wrong file. The fix was packaging the LKS service as a proper Cowork plugin (.plugin bundle) — Cowork has a plugin system distinct from raw MCP server registration. If you're trying to wire a custom MCP server into Cowork, this is the path.subprocess.CREATE_NEW_PROCESS_GROUP for clean Windows termination)Architecture, phased build narrative, all five lessons-learned bug stories, the setup walkthrough, and the roadmap: https://gist.github.com/tyoung515-svg/5fd5279f46d935f517cda89146c94685
Happy to answer questions on any piece — the MCP integration, the runtime supervisor, the eval harness, the crystallization atomicity contract, whatever's interesting.
I made a prior post at 100M tokens about how pleased I have been with flash v4 performance. Checking in at 170M, and its still going great lol. These are sustained sessions working in the same codebase, so lots of cache hits and a lot of input (detailed task lists also). Still working on finding a spot for Pro v4 largly because flash is so good.
Thought I would share my experience over the last few days using the new flash v4 in open code as a scoped task worker.
My basic work flow is idea making with Claude and turn into spec. Fire up a new instance of Claude opus to be the project manager and to decompose the spec into scoped task lists that then get handed to DS flashv4 instances of open code. Worker reports are fed back to opus, with some checkpoints for deeper audits using Google Gemini.
I started flash at phase 4 through the build out of this 9 phase project. I burned roughly 52M credits 2 instances doing the work over two days.
Very few errors, we are talking 2-3 over 5 phases and they surfaced them. They also caught around a dozen minor bugs and fixed them perfectly themselves and documented the why.
Overall, flash has earned it's spot as my main worker for my coding and automation projects. I have not tested it outside this role, but I use multiple model providers to keep the audits adversarial to a degree. DS Pro V4 may do the job well also, but I saved around $600 on this project at zero hit to quality, that's plenty for me.
10/10 recommend. Used DS API key as Open router had constant rate limit issues.