Trying to wrap my head around how it differs from my current on-the-go setup that is claude code. On claude's phone app or web app I can choose a repo, ask it for a feature and it writes the code, runs my tests + add more tests and creates a new branch. Then I can click on create PR or configure claude code to auto create PR.
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
show comments
kristianc
>> It opens a pull request
>> Then keeps iterating as review comments land, in the same thread, with the same context.
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?
show comments
xander_north
Really interesting. I've been working on building out more self-sufficient agents with harnesses to match, and this feels like the next logical step. I'd love to try this.
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.
show comments
fishtoaster
Took me a minute to see the value - my first thought was "this is just cursor's cloud agents..."
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.
show comments
r5Khe
Looks neat! I've been using Amp (https://ampcode.com/) for a while (Which seems to be doing something very similar), and I really appreciate this type of workflow. One thread = one VM feels like a solid model going forward.
show comments
Bnjoroge
What’s the experience like going from an active on-going thread to a cloud-hosted one? I dont wanna always work on the cloud, and want my current setup to be exactly the same as in the cloud, and should be pretty seamless. Only folks i’ve seen solve these are folks who run the sandboxes locally and take that to the cloud like smolvm/microsandbox.
show comments
asdev
just a data point, at my company we are building this internally. if you're targeting people building from scratch it might work, but there's no way you can port any somewhat mature infra stack, nor will the org want to. you'll need to deal with the variable complexity of everyone's dev environment which already doesn't work locally for thousands of different reasons.
show comments
mellosouls
Firstly: good luck!
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.
show comments
lionls
Amazing work, I am currently in the process of building something similar on my server for personal use, but yours looks really promising. Especially running sandboxes on your own can be tedious. Why have you opted for Modal instead of Firecracker or a similar micro VM solution?
Best of luck to you!
show comments
FailMore
Looks interesting. Does this mean I would use this as my day to day harness? Or is it something additional to an established workflow?
show comments
abtinf
Why would I use this over exe.dev?
show comments
mkagenius
If you ever need to switch sandboxes, would be happy to chat.
Suggestion: showing an actual screenshot or video of your app is a much better indicator of effort than a generic Claude made animation. I've seen AI slop landing pages on far too many YC-backed startups. Not saying yours is one, but parts of it smell.
Trying to wrap my head around how it differs from my current on-the-go setup that is claude code. On claude's phone app or web app I can choose a repo, ask it for a feature and it writes the code, runs my tests + add more tests and creates a new branch. Then I can click on create PR or configure claude code to auto create PR.
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
>> It opens a pull request >> Then keeps iterating as review comments land, in the same thread, with the same context.
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?
Really interesting. I've been working on building out more self-sufficient agents with harnesses to match, and this feels like the next logical step. I'd love to try this.
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.
Took me a minute to see the value - my first thought was "this is just cursor's cloud agents..."
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.
Looks neat! I've been using Amp (https://ampcode.com/) for a while (Which seems to be doing something very similar), and I really appreciate this type of workflow. One thread = one VM feels like a solid model going forward.
What’s the experience like going from an active on-going thread to a cloud-hosted one? I dont wanna always work on the cloud, and want my current setup to be exactly the same as in the cloud, and should be pretty seamless. Only folks i’ve seen solve these are folks who run the sandboxes locally and take that to the cloud like smolvm/microsandbox.
just a data point, at my company we are building this internally. if you're targeting people building from scratch it might work, but there's no way you can port any somewhat mature infra stack, nor will the org want to. you'll need to deal with the variable complexity of everyone's dev environment which already doesn't work locally for thousands of different reasons.
Firstly: good luck!
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.
Amazing work, I am currently in the process of building something similar on my server for personal use, but yours looks really promising. Especially running sandboxes on your own can be tedious. Why have you opted for Modal instead of Firecracker or a similar micro VM solution?
Best of luck to you!
Looks interesting. Does this mean I would use this as my day to day harness? Or is it something additional to an established workflow?
Why would I use this over exe.dev?
If you ever need to switch sandboxes, would be happy to chat.
Naming conflict with https://www.hoplite.gg
Suggestion: showing an actual screenshot or video of your app is a much better indicator of effort than a generic Claude made animation. I've seen AI slop landing pages on far too many YC-backed startups. Not saying yours is one, but parts of it smell.
Your website text reads like Claude slop