I’ve tried the various alternatives (opencode, pi.dev) but for “have several physical machines, each running an orchestrator and 5-10 agents, and each agent spawning its own subagents to do work in parallel, all of that on a tanky GitHub project boards” level of work only Claude was doing work dependably.
I can have a few orchestrator leads which I talk to and brainstorm, and let them file tickets, organize them and assemble teams of agents to work of the various problems. And all of that with just a smidge of custom tooling on top of Claude Code’s default.
Plus don’t have a budget to spin all of this on cloud runners so I made sure to do as much as I can with local work on several machines I own. Was quite easy to achieve with Claude.
Do you have something similar built on top of a open source harness, or is it from scratch?
So that I'm not just relying on one or a few agents to accomplish a task. I work on the whole product and just drive the direction of tickets and their "what done looks like" requirements, and let the machine organize things on its own, usually 10-20 independent agents (each spawning their own subagents). I think i might have capacity to handle more, just don't have the subscription tokens to fuel it and the budget for the hardware to run it.
Haven't worked in BigCo so no idea how that compares to their tooling. I'm sure it works much more efficiently and on a bigger scale, just being curious about how it all plays out.
claude: Help me, Obi-Wan Kenobi. You're my only hope.
me: who is obi-wan kenobi
claude: oh you have to log in again.
me: <logs in>
me: play the whole message
claude: what message?
But ultimately I find it a silver lining more than a problem. I am building and changing tooling so fast, and the models tooling itself is changing so fast, that by the time I establish a workflow, I either A) have solved the original problem so no longer needed, B) have built other tooling that distorts the picture, or C) the labs have released something new and cool that changes the equation drastically so your previous setup is gone anyway.
For example I built some procedure on how to split work between fable and opus and sonnet to optimise token usage, then opus 5.5 came along and made all of this obsolete.
Not per “token usage” mind you, opus is still expensive, but more “effort per task time finish” kind of metric. If I want to close things faster while still being relatively within budget, it is just easier to send all to opus - it will now just solve thigns quicker so you still use similar amount of tokens / money, but quicker, which is a trade I’ll make any day.
And every time “the system is working” I either just stumble onto the next resource constraint, or I feel uncomfortable and start refactoring to make things better and inevitably destabilise the whole “machine”
We won't know the answer to this until IPO and until each company reveals the economics of their models (training and serving).