A few weeks ago, I fell deep into the vibe-coding rabbit hole. I’m on the Claude Max 5x plan, spending pretty much every spare moment building a project I’ve had in mind since my computer science days. For years, it remained just an idea because I knew building it alone would take years. Recent improvements in AI coding models finally convinced me to give it a shot. I started with Codex, then added Claude, and eventually upgraded to Max 5x. Every upgrade initially felt like an incredible productivity boost. But after a while, I’d start noticing limitations, inefficiencies, and opportunities to optimize. I’m learning something new almost every day, and my workflow is definitely improving. Still, sometimes it feels like I have to take half a step backward before making one step forward. I could probably burn my entire weekly usage allowance trying to perfect the workflow, but at some point I have to remind myself that the goal is to build the actual project, not the perfect development process. Anyway, I’m starting my fourth week on Max 5x, and here’s what I’ve learned so far.
- Desktop Projects with a cloud coordinator My first setup used Claude’s default Projects workflow: an Opus coordinator running in the cloud, managing multiple local sessions. Honestly, the coordination itself was excellent. Opus did a great job supervising workers, keeping track of progress, and making sure information flowed between sessions. After tweaking instructions, skills, and hooks, I also managed to noticeably reduce token consumption in the worker sessions. The problem was the coordinator’s overhead. Based on my telemetry, roughly 40–50% of total token usage went into coordination alone. There were also limitations in how much I could customize the workflow. Eventually, I decided to try fully local sessions.
- Local coordinator in Desktop I switched to a local Opus session acting as the main coordinator. This required noticeably more babysitting. In my setup, the coordinator doesn’t seem to react proactively to messages from other sessions. I have to send it a message before it processes updates and communicates with workers. Basically, every now and then I have to poke the coordinator so it can poke the workers. Not exactly autonomous orchestration. However, coordination overhead dropped from around 40–50% to roughly 10% . For me, that’s a worthwhile tradeoff. The next challenge was controlling context growth and avoiding repeated compaction. I implemented an automated (well, semi-automated, since the coordinator still needs a poke) workflow: At around 250k context, generate a structured handoff. Clear the session. Continue the task using the handoff. But then I noticed another problem: the initial context was already enormous. Worker sessions were starting with roughly 80k tokens before doing any meaningful work. After several rounds of trimming instructions, skills, and other overhead, I got that down to around 50–60k. Claude claimed that was about as low as I could realistically go in Desktop.
- Moving workers to Claude Code CLI This is what I’m experimenting with right now. Simply launching sessions directly through CLI reduced the initial context to around 30k tokens. That’s already a pretty substantial improvement, and I suspect there’s still room to optimize it further. I’m also considering exploring how much control I can get over the default instructions and system prompt overhead. But now I’m facing another question: what’s the best way to handle multi-agent coordination entirely through CLI? When I asked Claude, it insisted that my coordinator needed to stay in Desktop and manage CLI sessions from there. According to it, Desktop was necessary to create sessions, communicate between them, and maintain a convenient overview of everything. It also suggested I’d lose some of the integrated UI functionality. However, I’ve since come across the CLI Agent Teams documentation, which seems to contradict at least part of that explanation. So now I’m trying to figure out what’s actually practical, rather than just theoretically supported. What I’m looking for Is anyone here running a primarily CLI-based workflow with a coordinator managing multiple persistent worker sessions? I’d particularly love to hear about: Coordination: Are you using Agent Teams, subagents, independent CLI sessions, or some custom orchestration? How autonomous is your coordinator? Visibility: How do you monitor multiple agents, inspect their conversations, and intervene when necessary? Context management: How do you minimize startup overhead and handle long-running tasks without excessive compaction or losing important information? Token efficiency: Have you found a good balance between coordination quality and the amount of usage spent on managing agents rather than implementing features? UI and testing: How do you handle app previews, screenshots, and visual testing when working primarily in CLI? I’m particularly interested in workflows people have actually used for weeks on substantial projects, rather than setups that look great in theory. I don’t mind investing time in improving my tools, but I’m starting to suspect that workflow optimization can easily become its own form of procrastination. Would love to hear what has actually worked for you, especially if you’ve made a similar transition from Desktop to CLI. submitted by /u/Stoodent220
Originally posted by u/Stoodent220 on r/ClaudeCode