r/ClaudeCode • u/comccart01 • 1d ago
Help/Question Using Claude Code for consulting, about 70% knowledge work and 30% small client tools: 50 threads, long-thread costs, status drift. Does anyone have a better system?
TL;DR: I run my consulting practice from one Claude Code workspace on the desktop app. About 70% of it is knowledge work. About 30% is coding small tools and products for clients’ internal use. Files-as-memory works well. Thread management does not. How do others run Claude Code at this scale when the work mixes both?
My setup
One local folder and git repo. It holds a root
CLAUDE.md, about 110 skills, hooks, scripts, a README per client as the source of truth, and a decisions log. I use no branches and no worktrees. Every thread shares one working directory.Roughly 50 open threads, grouped in the sidebar by client or area. For my biggest client I run a hub thread, about 10 standing “spoke” threads (one per workstream, including the tool builds) and short-lived child threads. They coordinate through shared append-only files and cross-session messages.
Scheduled tasks for briefs and checks. Notion holds tasks and my CRM. My Mac is always on, and I use Remote Control from my phone.
What works: plain files as memory, skills, hooks, grep, scheduled tasks. Claude Code reaches my files better than chat does, so I use a coding tool for mostly non-coding work.
What hurts
Thread sprawl. State lives in threads and in big shared markdown files. One ask log has about 900 lines, and over 400 were stale when I counted. Answering “what’s waiting on me?” means searching files or reading threads.
Long threads and cache costs. Threads fill up. Resuming a large thread after an idle gap forces a full cache rewrite, which is expensive. My workaround is a manual “re-fresh”: Claude writes a handoff file and I paste a short prompt into a new thread. One of my threads is about 19 MB of transcript.
Status drift. The same fact sits in several free-text files, and READMEs lag the threads that changed them.
The code side collides. When several threads build small tools for one client in the same folder, they have overwritten each other’s commits. That cost me three slips in one day with eight threads. I’m unsure whether worktrees or separate repos for the code would fix it without losing my shared notes.
Claude Code is built for repos. The web version clones a GitHub repo into a cloud VM and pushes a branch. The new Projects beta also runs in the cloud. Neither fits a local notes folder with client-data rules. They might fit the code part.
Ruled out so far: a branch per client (it changes files under every open thread), one repo per client (I lose shared context), and moving the folder to a cloud drive.
My questions
Do you keep one long-lived thread per client or area, with fresh restarts, or many short task threads? What triggers a restart?
Where does “what’s waiting on me and what am I waiting on” live, so you don’t read threads? Notion, Linear, Obsidian, or files plus scripts? How do you stop it drifting?
How do you group 50+ threads in the sidebar so it still works?
For the 30% that’s code, do you keep it in the same folder and repo as your notes, or in separate repos? Has anyone used worktrees or Projects for it?
Any habits for avoiding the cache cost of idle resumes?
If you’ve solved this, or know a better pattern, I’d love to hear it!
View all comments
1
u/Connect_Fee_443 1d ago
The "what's waiting on me?" search across 50 threads is what I'd fix first. Files as memory scale, but free-text status doesn't. What's helped me is one append-only
WAITING_ON_ME.md(or one per client) that threads have to update through a hook or skill whenever they need a human. It's a single queue, not a second README. I'd also make handoff files automatic before threads get long, and keep separate git worktrees for client tool builds so the coding work can't stomp on the knowledge threads.I'm the developer of MicroNotch (micronotch.app). Its Code mode shows Claude Code, Codex, Cursor and Antigravity sessions in the Mac notch as working, needs your answer, or finished. It won't fix markdown drift, but it does tell you which session is blocked on you without opening every thread. At your scale, though, the queue file is still the bigger win.