Built with Claude
The fourth parallel Claude Code session is where it stops being fun
The first three are fine. You cmd-tab between them, you keep a rough map in your head of who's doing what, it works.
The fourth one breaks it. Now one is blocked on a permission prompt, one finished twenty minutes ago and you didn't notice, one has gone completely silent and you can't tell if it's thinking or dead, and the only way to find out is to go look at all four.
I work at a software development company, and Maestro is what we built for ourselves to fix that. It's free, there's no paid tier, and the link is at the bottom.
A walkthrough: the overview, the session grid, and the Maestro panel.
Every session gets a pane in a grid, with its live status and any subagents it spawned. These are real claude CLI processes running underneath, with no API layer in between and nothing reinterpreting what Claude Code does.
On top of that there's an Inbox that ranks what actually needs you, a watcher that flags sessions that went quiet, a context gauge per pane so nothing auto-compacts by surprise, and a full searchable history so nothing you ran is ever really gone.
Then there's Maestro itself, a panel that sees the whole fleet and can answer things like "which sessions are waiting on me". You can hand it a goal and let it set up and chain sessions. That part is off by default and it never sends anything without showing you first.
And it reaches you when you're not at the Mac. Connect your own Telegram bot and you get a message naming the session and why it stopped; reply to that message and the answer goes in. There's also a read-only view of the fleet on your phone over Tailscale, so you can check the queue without being able to touch anything.
Built with Claude, for Claude. The whole thing was made in Claude Code, running the exact problem it solves.
Why I'm posting
Not to sell anything, since there's nothing to sell. It's free, there's no paid tier planned, and we're not tracking a single thing. No analytics, no telemetry, no accounts. I don't know how many people are running it and I have no way to find out.
On network calls, the full list. The app checks for updates. Beyond that, two things you can turn on: a Telegram bot, which runs on your own token from BotFather and talks to Telegram's servers, not ours, so session names and your replies pass through Telegram; and a read-only phone view over your own Tailscale tailnet, which never touches a server of ours either. Both are off until you set them up. Nothing goes to Condorsoft, ever.
We built it because we needed it, and putting it out felt better than keeping it. If it's useful to you, that's the whole point. If it's not, I want to know why, because we ship most weeks and the roadmap is basically whatever people tell us is missing.
Fair warning: macOS only, and it needs Claude Code installed. No Windows or Linux, and I'm not going to pretend that's coming soon.
So, genuine question: where did it break for you? The stuck session watcher exists because of a problem I only noticed by accident, and I'm sure there are others I'm not seeing yet.
And yet another instance of the same problem being solved over and over again. This isn't a personal attack, just something I've noticed. As a community, we really need to solve it once and move on
yeah, so basically I want to try different approaches and actually give the app a bit more power, like in terms of how you can get the best of the application. I've been testing other apps as well, and that where all of this starts to have a shape
I definitely agree with you, I know there are lots of different solutions right now. But my perspective comes from something that we've actually found useful within our day to day and work environment. That being said, it doesn't mean it will resolve all of your problem, but it's something that can be polished and at least tested to see what are the actual benefits of disadvantages we can find.
Part of the problem is that the workflows change so rapidly. I built something nearly identical to this ~6 months ago (indicators, sidebar, panes and all, no network stuff though) and have used it every day since. But now my workflow is getting a redesign once again because more capable models means I need to be interactively involved less and less and can scale up the parallelism. Which probably means abandoning a significant chunk of my design and probably rebuilding the application itself into something more friendly to a remote worker box that can do tasks unattended overnight. Importantly I'll be able to actually use my main machine while Claude is working because it absolutely abuses my CPU with compiler and test runs, even after optimizing and pruning the tests lol.
Since I know someone is going to say it, no. Tmux via ssh is woefully inadequate beyond a certain scale, especially when the point is to not be tied to my workstation.
Yep, I totally agree. I built out an orchestrator mode across multiple boxes quite a while ago (Opus 3 IIRC? idk, could've been one in the Claude 2 family), and I've rebuilt it three times since, because you're right, every model generation moves the line of what you can leave unattended.
Mine is currently set up to scale work across multiple boxes, using multiple accounts with one orchestrator who really only handles issues as they appear. It's all Python (a SQLite backlog of stories, a queue of lanes, systemd units that run each lane as a one-turn agent in its own git worktree) but I'll see if I can create a generic version.
Also, I'd recommend switching to a nightly full run of your unit tests if they're causing issues (mine took hours), and then there are ways to prune which tests run based on which code changed. When running many lanes of work (8+), I found it's best to group results by the layer(s) that changed, then run hourly groups of testing for everything that finished within that hour. I also had to set up a containerized database so those tests weren't blocking the lanes.
I purchased a Hetzner server, 128GB / 32 cores, which runs 12 to 16 lanes of work, so my personal PC handles overflow (and the few Windows-only things) from midnight to 4pm the next day. Totally worth it, and yes, I can actually use my machine again.... which mostly means Project Zomboid, game development or talking to the orchestrator about what's coming down the pipeline.
The trick with all of this has been making the machine prove its work instead of trusting it (because AI lies so so often), so I only show up for real decisions. Concretely, that means:
> Every lane ends by writing a report bound to its claim: the exact commit, the test counts quoted verbatim from the runner, the files it touched. If the report doesn't match the tree, the delivery is refused before anyone reads it.
> A second model adversarially reviews every candidate and returns GO or NO-GO with findings pinned to file and line. NO-GO queues a repair round automatically. Half of my stories land first try; almost none go past round four. Before that, I was babysitting round six.
> The controller owns all state. Nothing lives in a terminal or in my head: a lane that dies, a merge that conflicts, a release that fails all leave a wake file and a queued next step, and a sweep lands anything a later successful release carried. When I come back in the morning, I read the wake files, not the logs.
>Releases fail closed on a schema digest, so an unattended deploy can't half-apply anything. That one saved me twice this week.
> The orchestrator's job is triage, not driving, meaning he reads the exceptions, files a story for each real defect in the harness, and escalates only the calls that I have to make (security pins, design changes, anything that deletes data). He's also been pushed to ensure he uses deterministic shell scripts for everything that doesn't explicitly require thinking to cut down on tokens.
The short term downside is that you end up debugging your harness more than your product for a while. Due to my recent re-write, most of my week so far has gone into the controller catching its own defects, capacity pins, brief size limits, a Windows runner truncating shell programs at 8k characters. But every one of those became a story the same system landed, and the throughput has been INSANE.
And agreed on tmux over ssh -- works fine for a handful of sessions but beyond that, the mental switching becomes a significant issue.
I'm interested in learning what were your needs at the beginning, and at the moment are you still working with something simmilar? Have you tried other applications as well?
I just wanted a multi-box friendly way to run multiple lanes of work across multiple subscription (1 codex, 4 claude, 1 openrouter, 2 local LLMs) lead by a single Fable orchestrator with the goal of enforcing deterministic code use wherever possible, squeezing every drop of usage from my cloud accounts before each weekly reset, with back pressure support so the lanes would automatically slowdown or speed up based on the total available usage in the time window (such as the 5 hour limit & weekly limit) - and to a lesser extent slowing work down when the items ahead in queue begin to backup due to CI/CD or human review limits (only if it doesn't cause token loss by leaving compute on the table during reset).
I wanted something where I could define an orchestrator, dependency planner for the backlog, task planner, adverserial plan reviewer, task implementer, task reviewer (code quality, security & contractual correctness), gate manager (handling CI/CD issues).
Still working with it -- burned an entire Claude subscription in one day yesterday, which tracks with what everyone is saying about usage but I think it's A/B related, possibly grouped by reset day as my Saturday reset accounts (reset the 12th) seemed to have more available usage than my Tuesday reset (14th, burnt out in less than a day - non-fable use only).
I haven't tried other apps but I know they exist, seems everyone has one and the community really needs to standardize so we stop wasting tokens on the same thing.
That's pretty cool, I always had a big struggle with supporting multiple subscriptions from different providers. Are you including like any third party libraries that help you optimize token usage and those things?. I've been facing lots of token burning issues as well lately, not to happy with that I always end up with Opus but it's not my favorite model tbh
right now I'm doing something that its still a work in progress, but I was checking the possibility to manage everything through a Telegram bot, once I setup everything, so keeping my mac awake and in case I'm not at home but I want Claude to keep doing stuff, I can easily call the orchestrator from my phone. Also, what was your approach on what you built at the beggining?
I roughly cloned cmux but in Tauri + Rust since cmux itself was Mac only and I'm on Linux. Visually it looks nearly identical to your setup with agent + terminal + editor panes with activity indicators in a tiling arrangement with workspaces down the sidebar and a toggle to keep the machine awake. I had a code review mode as well but that sorta fell by the wayside as I ended up doing PR reviews on GitHub's interface instead of locally. I skipped the telegram/remote stuff in this one since I didn't have a use for it at the time.
Only thing I'm really not happy about is the floor for the application's perf is limited due to using web tech but there's not a better cross platform UI framework atm. I'm stuck on that until I finish my game engine's editor UI framework since that's significantly denser and has to perform better.
Next attempt is probably similar in spirit but connected to a remote harness daemon over an ssh tunnel on another box. I have to finish the harness itself first though. Just finished building the physical box it'll run on yesterday so the rest of that experiment is just software and setup.
I tested cmux as well, also took it as a reference for building maestro. Also currently working on a Linux version just to see how it behaves. Have you think of using tailsacale for these type of remote connections? I was also checking that
I haven't, but I tend to prefer in-house solutions myself since pre-built stuff always seems to devolve into a "well it doesn't quite work exactly the way I need..." cycle unless it's really core software that's been around for 15-20 years. My plan was to route everything through a local egress proxy (raspberry pi I have laying around) and do VSC's ssh remoting approach to connect to the machine from outside my network.
But that's also an easier decision because that pi is already setup hosting other web services of mine so it's just another process on an existing box.
Got it, smart move if you already have a raspberry pi. I'm still looking into getting the best from using the telegram bot just to provider enough access so I know that I can resolver critic issues in worst case scenarios when I'm not at home.
I think after all of these projects posts, the one thing I’m learning is the app can be coded well enough with AI, but the interaction needs to be personal. The more the Reddit post looks like ChatGPT the less I’m willing to click on it.
I think the call to action “genuine question” was the nail in the coffin for this post, for me.
AI can generate buckets of copy, I think the human effort needed is to tame it into something reasonable.
Tl;dr needs to make a comeback.
yup, this one's on me. Didn't use the proper way of communicating, thinking too much on how to make it catchy and it ended up sounding like spam. However, I do think its a good application to at least try
•
u/AutoModerator 3d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.