Show HN: Maxxwell – The IDE for Optimal Tokenmaxxing (maxxwell.dev)

2 points by mserrano258 ↗ HN
Hi HN! I’m Michael, one of the founders of Rindler (YC S26). We built Maxxwell, which helps you manage a dozen coding-agent sessions’ progress, context, and blockers. This lets you spend more time with the actual high-leverage decisions (and gives you more confidence in stepping away from your computer). We were originally building browser agents that log in to sites with a cached representation of the site to make for cheap and reliable repeat runs. There were a ton of hard challenges like mapping sites, getting past bot defenses, and handling credentialing and 2FA. There was a huge maintenance surface, and we were getting bogged down with technical deliverables.

We tried Cursor, Claude Code, Conductor, and even built an internal Devin. These tools either felt like they were too slow to iterate through large tasks, or became black boxes that I just couldn’t trust with their decisioning (you can’t just tell Devin to “improve the site mapper” and call it a day, unfortunately). So, we eventually settled on twelve Claude Code sessions running across our terminal panes. You get more control over the work being done while still multiplying your output volume, albeit at a cost: you.

Answering questions across twelve terminals is really draining. Also, a lot of the questions are niche code choices that crowd out the stuff actually worth your opinion. It’s not immediately obvious which sessions are making progress, which are stuck on something trivial, or which are getting lost in the sauce of making up new goals. Lastly, I just felt less like a conductor of agents and more like just the human medium connecting Claude to my workspace.

In the pursuit of touching grass again, we jerry-rigged our own system, which has an orchestrator agent focused on keeping other sessions aligned towards their goals and parsing through the agent noise. Now, I primarily message that one orchestrator session alone. It tells me what’s landed, what’s been decided for me, and what actually needs my input. Every worker is an unmodified Claude or Codex process in a real PTY, so you can still attach to any session and interface with it. This functionally results in all the productivity and quality benefits of multiplexing sessions while hopefully keeping you sane.

Here's a 90 second walkthrough of the IDE: https://www.loom.com/share/125c58d597234685b1a632839a83813a

In the last month that we’ve been using this, merged PRs per prompt (at similar semantic weight) has gone from 0.9 to 5, and our revert rate of said PRs has fallen from 0.56% to 0.20%. We are confident letting the orchestrator manage our agent sessions for hours at a time, and it works quite well for overnight runs too.

Maxxwell is BYOK or subscription, and otherwise free and fully local. We’re considering making a hosted service as well to save your local machine’s memory. Check it out! If you’re already running several agent sessions at once, I’d especially like to know:

- What would make you trust that an unattended session stayed aligned? We currently have per-goal checklists that the orchestrator monitors to ensure adherence.

- What’s your preferred balance of agent autonomy and control?

10 comments

[ 0.35 ms ] story [ 30.9 ms ] thread
How do you prevent the orchestrator itself from becoming the new black box? If I’m trusting it to decide which worker decisions need my attention, isn’t a mistake in that judgment potentially worse than a worker making a bad decision?
Yeah, a mistake in that judgment can have a wider impact than a single worker mistake, and adding an orchestrator doesn’t eliminate that risk. I’d like to think that it’s still better than a human trying to parse through like a dozen sessions’ worth of noise, but it’s far form perfect. What helps us is visibility and explicit goal tracking. Each worker is still a normal Claude or Codex session that I can attach to directly. There are per-goal checklists that the orchestrator monitors, so there’s something concrete to check progress against beyond “the AI orchestrator says it’s going well so here’s hoping.”

Our main goal is to keep the observability and control of a bunch of individual Claude sessions, while making the volume manageable. I primarily talk to the orchestrator, but I can still inspect or redirect the underlying work. It’s true that being able to inspect the workers only helps if you actually check. That said, our experience so far has made us more comfortable letting the agent run itself at this point.

What does “fully local” mean here? What leaves the machine, and does any of it pass through your servers?
Does each agent get its own worktree? and who handles getting all their changes back onto one branch?
(comment deleted)