Curious how you guys are thinking about the difference between project-specific and project-agnostic harnesses and tooling. For me, it feels like a lot of the work is project specific and I'm not sure how to abstract that.
P.S. The code is not working for me.
My experience, particularly with Sol is that agents are generally really bad at knowing when to stop 'iterating' and will continue covering off ever-more obscure edge cases. How does Hoplite solve for this?
This specificity helps Sol stay on track (most of the time). It doesn't work as well when the comment questions a complex piece of the architecture though.
I also have another setup which is a self-hosted docker compose behind my vpn with one container with claude code agents managed using agent of empires[0] and another container with playwright with sse. Using this setup, my agents get access to actual browser where it can test things live and I can access the app started by agent on domain:port. This is something I don't get with Claude. [0] https://github.com/agent-of-empires/agent-of-empires
Using us means losing freedom and control with regards to infrastructure, however we think that's a tradeoff people would want to make in exchange for easier onboarding and a more polished experience.
Are you offering browser access to the agents in your setup?
But the key thing here for me is "Every sandbox boots your app on a live URL." Cursor doesn't easily have that, and that's what would allow me to ditch my local env entirely - the ability to actually try out a PR without needing to check it out locally.
So on that note: how does that work? We've had trouble with getting our dev env running in other cloud envs because it requires a few things (clickhouse, localstack, pg, etc) running which we manage via docker compose locally.
Also, some minor pricing feedback: it'd be really great if there were a version with pay-as-you-go and a cheaper fixed cost. I think your 99/seat/mo model is fine for professional work, but it's a lot to commit to for personal work.
Noted the pricing feedback! We're still figuring out exactly what works best so it's still very much so subject to change.
What does your current setup look like? And are you using an open source solution like OpenInspect for your in-house version, or building it from the ground up?
I've been wondering what the alternatives to things like Github Copilot Cloud and Codex Cloud might be, especially ones that might be flexible wrt models, and this seems at least to have some of those behaviours.
If that perception is correct, please would you explain what it offers against those sorts of services (those in particular) and how the pricing compares - eg. their base levels are $20 a month, yours starts at a higher level - I can see there seems to be more brought in from the local IDE world (and similar), which seems very useful compared to the standard "prompt against repo, repeat" of the normal cloud agents but it would be useful to understand the targets and intents.
Our pricing is higher than other providers because we do not upcharge on token or sandbox costs. We believe that people should be running as many agents as they possibly can handle, and an upcharge would create a monetary incentive for us to say that, when it's a genuine belief we hold.
We also offer features out of the box that would usually be behind enterprise gating (e.g. sandbox baking).
Best of luck to you!
My main issue with Modal is that their autoscaling is not as good as Daytona's. You have to stop the machine, resize, then start it, which takes ~3s and terminates all running processes. Daytona supports scaling up (but not down) without stopping the VM.
Also would recommend checking out ColeMurray/background-agents if you're planning to self host. Very good alternative! And the team behind it are great
We also have an MCP server that you can use to delegate tasks (e.g. research, debugging, SRE work) to Hoplite via your existing local setup.
I think it comes down to whether configuration or ease of use is valued more, and Hoplite favours the latter a bit more. (They shouldn't really be mutually exclusive, but we have a long way to go before we're happy claiming that we match/beat self-hosting in that area)
As the repo says no longer maintained
I actually checked HN rules and just saw this:
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
So, there you go, I guess.