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.

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.

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.

I built OpenHelm to fix this. It’s a local macOS app that turns your high-level goals into a self-running job queue, built directly on top of your existing Claude Code subscription.

Use it free

- Download it now: https://openhelm.ai/

- GitHub: https://github.com/maxbeech/openhelm

- Video: https://youtu.be/FfEBw1SCl7w

How it works

1. Set a goal, eg. "cold reach out to new leads", "grow my SEO", "audit my app weekly", "keep tests green")

2. OpenHelm puts together a plan combining one-off and recurring jobs to make it happen

3. Whenever a job fails, it will spot this, adjust, and try again

4. It will keep on top of the goal, auto-adjusting what jobs are run to actually achieve it

Key benefits

- Fair Source, on GitHub (free for teams under four people)

- Free to use (all LLM calls use your Claude Code subscription)

- Fully local

- Secure (any tokens/passwords stay in macOS Keychain unless you specify otherwise)

Happy to answer any questions!

Comments URL: https://news.ycombinator.com/item?id=47544695

Points: 3

# Comments: 4

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 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.

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.

Comments URL: https://news.ycombinator.com/item?id=40284047

Points: 1

# Comments: 0

Been really looking forward to sharing this

There are some days after work or on the weekend where I feel super motivated to do something new or just clear up my emails. Some days though, I really don’t.

One thing I have found that has helped me a lot is to actually time these daily tasks to make sure I don’t skimp on them. I have found this to be so useful I really wanted to share the technique with others.

So here it is! Today helps you to turn to-dos into actual habits, giving you the opportunity to actually build that side-project, start that new hobby or just actually get around to checking your emails.

I’d really love to get YOUR thoughts on it, so please do leave a comment and/or give it a review!

️ https://www.producthunt.com/posts/today-build-habits

Comments URL: https://news.ycombinator.com/item?id=24118235

Points: 3

# Comments: 0

With iOS 13 now allowing Shorcuts to modify settings and with 13.1 supporting automation, you can now get a super dark screen at night (cause 0% brightness is not very dark):

Simply set two automations for evening and morning to adjust brightness and crucially toggle white point (the intensity can be changed in settings).

Hope you enjoy as much as I am!

Comments URL: https://news.ycombinator.com/item?id=20836476

Points: 1

# Comments: 0