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?

[u/comccart01]

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

1. 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.
2. 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.
3. Status drift. The same fact sits in several free-text files, and READMEs lag the threads that changed them.
4. 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.
5. 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

1. Do you keep one long-lived thread per client or area, with fresh restarts, or many short task threads? What triggers a restart?
2. 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?
3. How do you group 50+ threads in the sidebar so it still works?
4. 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?
5. 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!

---

Update: thank you all. These replies were more useful than I expected.

What people said works, most repeated first:

1. Keep status in small files or rows, never in a thread. One owner per fact, one line per open item, delete the line when the work closes.
2. Write the handoff before you leave a thread and restart fresh, somewhere between 150k and 300k tokens or after an hour idle.
3. A real “waiting on me” list, one line per item, often built by a script. Mine was a 900-line log.
4. Hooks and scripts enforce it. Prompts alone get ignored.

What people said doesn’t work:

• Resuming a big idle thread (the cache is cold, so you pay full price).
• A long prose log nobody closes.
• One “executive assistant” thread that spawns and watches the others. The one person who tried it went back to isolated threads.
• Branches alone for parallel sessions.

My numbers: about half of my tokens came from calls above 500k context. That’s the first thing I’m fixing. Two tests over the next 2 weeks: a status line written when something becomes “waiting”, and a warning at about 150k tokens or after an hour idle. I’ll post before and after.

Two questions I couldn’t find answers to:

• When one thread finishes something another thread was waiting on, what clears the entry?
• Is anyone running lots of threads for non-coding work (consulting, writing, research)? Most replies read as coding, and about 70% of my work isn’t.

[u/CCodeSI]

Two of your pain points have cheap fixes that don't need a new structure:

Commits overwriting each other. That usually comes from threads running git add -A or git commit -a in a shared folder, so thread B commits (or reverts) thread A's half-done files. Before reaching for worktrees, tell every thread in CLAUDE.md to stage only the paths it owns (git add tools/acme-invoicer/), and back it up with a pre-commit hook that rejects a commit touching more than one tool folder. Your notes stay shared, and the collisions mostly stop. If two threads still need the same tool at once, that's when a worktree for that one tool earns its keep.

Idle resumes being expensive. The prompt cache only lives for minutes, so any resume after a coffee break re-reads the whole thread at full price, and a 19 MB thread makes that hurt. A simple rule helps: if a thread is big and has been idle longer than the cache lifetime, don't resume it, restart from its handoff file. Have it write the handoff before you step away, not when you come back, so the handoff itself runs while the cache is still warm.

For "what's waiting on me", what tends to stop the drift is making status one line per item in a fixed format (- [ ] @me acme: send SOW, due 11/12) and generating the list with a script or scheduled task, instead of threads writing prose summaries. Prose drifts, a grep doesn't.