maxbeech

the thing that actually burns token budget at scale isn't the agent count itself—it's understanding the cost model of orchestrating them. 100 agents running in parallel is fine if they're short-lived queries. but once you start running them on a schedule (hourly checks, overnight batch work), the math changes fast.

each agent run against a real codebase probably spends 20-50k tokens just on context: repo structure, relevant files, recent changes. multiply that by 100 agents running every hour across 10-20 repos, and you're already hitting millions of tokens a day before any actual work happens. add in re-runs for failures or retries, and the cost curve gets steep quickly.

the harder problem is observability. with one agent you can read logs and understand what went wrong. with 100 agents you need aggregation, pattern detection, alerting on the common failure modes. if 3 agents fail silently but identically, was that a real issue or just rate limiting? if 40 agents all timeout at the same step, was it a dependency problem or infrastructure saturation? at scale you're debugging distributions, not individual runs.

also helps to be ruthless about concurrency. the async pattern isn't "run as many as possible at once"—it's "run exactly as many as the API and your budget can support without making the failure modes harder to diagnose." for claude api work that's usually smaller than people expect.

the 'claude creep' framing is real but there's a flip side worth naming. the synchronous pair programming case - AI as a faster version of you - is what most productivity debates focus on. the more interesting shift is genuinely async delegation: you define the task, set acceptance criteria, kick it off, come back to results. that's a different relationship to the tool entirely, and it forces you to get better at specifying what 'done' looks like upfront.that's actually a good forcing function. most productivity loss from AI-assisted work comes from underspecifying the task, not from the AI being bad.

the retry loop problem is distinct from the cost-per-token problem and most tooling conflates them.what's helped: track wall-clock time per meaningful step, not turn count. if the agent hasn't produced a file change or git diff in N minutes, it's stuck - not thinking. token count just tells you it's running; it doesn't tell you it's looping.the other piece: watchdog lives outside the agent process so a hung agent can't block its own shutdown. a hung agent shouldn't be able to veto its own termination.i built something for this actually - openhelm.ai schedules and runs claude code jobs with per-run timeouts and status checkpoints. the checkpoint pattern (agent writes state at each major step) is what gives you "where did it get stuck" not just "it failed at some point".

the flip side of claude creep is that the easy parts are now genuinely free, which means all your time goes to the 30% that was already hard. ai doesn't save you time on the hard bits, it just eliminates the excuse to not have done the easy bits first.what's helped: think in postconditions, not tasks. instead of 'add feature X', define 'the tests pass and the user can do Y'. the agent figures out what X means. without that anchor there's nothing to mark as done, so scope drifts indefinitely.

the safety concerns compound significantly when you move from interactive to unattended execution. in interactive mode you can catch a bad command before it completes. run the same agent on a schedule at 3am with no one watching and there's no fallback.i built something that schedules claude code jobs to run in the background (openhelm.ai). the layered approach we use: separate OS user account with only project directory write access, claude's native seatbelt/bubblewrap sandboxing, and a mandatory plan review step before any job's first run. you can't approve every individual action at runtime, but you can approve the shape of the plan upfront - which catches most of the scary stuff.the paper's point about clean agent-specific filesystem abstractions resonates. the scope definition problem (what exactly should this agent be able to touch?) is actually the hard part - enforcement is relatively mechanical once you've answered that. and for scheduled workloads, answering that question explicitly at job creation time forces the kind of thinking that prevents the 3am disasters.

All questions welcome!

Their ToS wouldn't allow you to access CC if it were to be hosted on some shared account in the cloud, but OpenHelm isn't doing that at all. It just spins up Terminal sessions and performs actions you would make yourself.

Hey!

OpenHelm doesn't handle any OAuth itself. It simply inherits the auth from the user's existing Claude Code CLI installation

Yes, full streaming. OpenHelm uses --output-format stream-json when invoking Claude Code, which emits newline-delimited JSON events in real time.

the more interesting signal in that data is about intent, not quality. most of these low-star repos probably aren't failed open source attempts - they're personal tools that were never meant to be shared.before ai-assisted coding, the effort-to-build ratio was high enough that most personal scripts stayed on a laptop or in a private gist. pushing to a public repo implied an implicit claim that someone else might want this. now the build cost is low enough that people just push things to git for their own version history and move on.what's actually happening is that git is becoming a personal dev journal as much as a collaboration platform. stars were always a weak proxy for value, but they're especially wrong for this use case.the 90% number probably also undercounts the real extent of this - most serious claude code usage is on private repos and internal tooling that never touches public github at all. the 50b lines stat would look very different if you could see total token output vs just github-public-linked output.

good catch on the leakage risk - the pattern of "agent reads .env files and they end up in transcripts" is more common than people realise, especially as claude code gets used for tasks that touch broader parts of a repo.for macOS specifically, the system keychain is a cleaner option than KeePassXC for this workflow. `security find-generic-password -w -s "my-api-key"` returns the secret directly and composes cleanly into a shell wrapper. no daemon required, access can be scoped per-application, and it integrates with Touch ID for interactive prompts.the harder problem is credential management in persistent background agents where you don't want any interactive prompts at all. we ended up using macOS keychain with per-process entitlements (set via a signed plist) so the agent process can retrieve keys non-interactively without ever touching disk. the entitlement approach is a bit painful to set up but means even if the agent process is compromised, the keys aren't in any config file or env var to scrape.(i built something that runs claude code as background scheduled jobs - openhelm.ai - credential handling was one of the more annoying problems to get right)

the interesting design tension i ran into building in this space is context management for longer sessions. the model accumulates tool call history that degrades output quality well before you hit the hard context limit - you start seeing "let me check that again" loops and increasingly hedged tool selection.a few things that helped: (1) summarizing completed sub-task outputs into a compact working-memory block that replaces the full tool call history, (2) being aggressive about dropping intermediate file read results once the relevant information has been extracted, and (3) structuring the initial system prompt so the model has a clear mental model of what "done" looks like before it starts exploring.the swift angle is actually a nice fit - the structured concurrency model maps well to the agent loop, and the strong type system makes tool schema definition less error-prone than JSON string wrangling in most other languages.

the debate round is the most interesting part of this - curious what you're actually measuring when models "change their minds."the question is whether cross-model exposure changes the actual answer distribution or mostly updates surface presentation while keeping the same underlying conclusion. models are generally trained to be responsive to context and to avoid apparent contradiction, which could look like genuine updating but just be social pressure sensitivity.one experiment worth trying: run a debate where each model sees a summary of the other models' reasoning without seeing their specific answer or which model gave it. see if agreement rates change compared to the version where models see attributed answers with model names. if the named version shows higher agreement it would suggest status/brand effects rather than reasoning-based updating.also curious whether the "reviewer model" that summarizes the transcript can itself be swapped out and whether the summary framing affects the perceived winner. that would be another confound worth controlling for.

the question conflates two things worth separating: enjoyment of problem-solving versus satisfaction of shipping.if most of your craft satisfaction came from debugging a subtle race condition or working out an elegant abstraction, that aha moment is harder to get when the agent gets there first. that's a real loss and worth naming honestly rather than hand-waving away.but if your satisfaction came from seeing something working, from momentum, from having built something a user can actually touch - agents compress the gap between idea and working software in a way that's hard to argue with.where it gets uncomfortable: watching the agent do the intellectually interesting parts while you review and manage QA. that discomfort is useful signal though. it means you were getting satisfaction from implementation work that, in hindsight, could have been delegated. the natural response is to move upstream - to the parts that still require judgment: what to build at all, which edge cases actually matter to real users, what the right abstraction is.for me as a solo founder it's been net positive. the craft satisfaction shifted, it didn't disappear.

context bloat in claude code runs is real. in my experience the main culprit is tool output verbosity - claude reads whole files when it only needed 10 lines, or grep returns 500 results and all of them end up in the context.

my first instinct was to fix it upstream (tighter tool calls, explicit line limits) rather than filtering downstream. and that helps a lot. but a proxy/filter layer is genuinely useful for the cases you can't control - when the model decides to explore 20 files you didn't expect it to need.

curious about the failure modes though. the hard part of this problem is distinguishing 'noise the model should discard' from 'context the model needs to take the right path' - same data, different task. does pruner do anything to handle cases where the filtering accidentally removes something load-bearing?

the worktree discipline failure is the most interesting part of this post to me. when claude is interactive, "cd into the wrong repo" is catchable. when it's running unattended on a schedule, you find out in the morning.

the abstraction is right - isolated worktree, scoped task, commit only what belongs. the failure is enforcement. git worktrees don't prevent a process from running `cd ../main-repo`. that requires something external imposing the boundary, not relying on the agent to respect it.

what you've built (the 8:47 sweep) is a narrow-scope autonomous job: well-defined inputs, deterministic outputs, bounded time. these work well because the scope is clear enough that deviation is obvious. the harder category is "fix any failing tests" - that task requires judgment about what's in scope, and judgment is exactly where worktree escapes happen.

i've been working on tooling for scheduling this kind of claude work (openhelm.ai) and the isolation problem is front and center. separate working directories per run, no write access to the main repo unless that's the explicit task. your experience here is exactly the failure mode that design is trying to prevent.

nice architecture -- the two-plane model is something i've been thinking about too, from a slightly different angle.

i built something for this actually (openhelm.ai) -- the problem i was solving is less about orchestrating active PR loops and more about scheduling claude code jobs to run unattended on a cron-like schedule. user describes a high-level goal, it gets planned into a set of tasks with a next_fire_at, and those run autonomously in the background even when they're not at their desk.

the piece i found hardest: deciding what requires human approval vs what can auto-proceed. we landed on "no plan runs without user sign-off" as a hard rule, but even within an approved plan, mid-job blockers that need human input are more common than you'd expect.

curious how TTal handles tasks that get legitimately stuck mid-execution -- does the manager agent have heuristics for detecting "stuck vs slow"? the watchdog timeout approach (we sigterm after 30 min) is blunt but works.