Ha ha advert that appears (at least for me) under this is for Kilo code. I used kilo code for about a week recently when something else had gone wrong with cursor agents. Kilo's transparency on what agents are doing, costs and token consumption is amazing.

They use third party service for billing instead of tying to roll their own.

With the potential charging for runtime usage, would you consider adding support for some sort of 'hard stop' option when sending prompts? I'm imagining a CI/CD scenario, where I've got a pipeline sending prompts to OH, potentially in multiple conversations. It would be good to add a flag (e.g. via a CLI option) to explictly tell the runtime "when you believe you've finished this task, commit the changes, push to origin, then shut yourself down" Otherwise I am potentially looking at a hefty bill for a bunch of short one-prompt conversations that then sit and wait for another prompt that's never coming

Do I understand correctly, both • the LLM via AH available on the Cloud service, and • the OpenHands Provider available in the OpenHands project would be at the respective regular API pricing? Is it actually the same provider, is that right? I admit, I did think that you could also add a small markup here (on the cloud), but now that the OH provider is in the project, I strongly suggest that these should be and work the same. People will think they're the same, IMO, and you know, the expectations thing is... a thing 😅

If they're not the same thing, please please name them differently!

Brand new today from Cursor: "You are projected to reach your usage limits by 7/23/2025 based on your current usage. Consider switching to Auto for more requests, asking for smaller changes, or enabling pay-as-you-go to avoid interruptions until your cycle resets on 8/15/2025." This sort of thing is super helpful. (It would have been even more helpful if it knew that pay as you was already enabled and would project when the allocated funds would be depleted at current pace.) I really prefer the OpenHands Cloud approach: we pay ahead into an account and spend happens from there instead of being billed. Cursor isn't doing themselves any favors by using billing instead of keeping an account balance and auto-replenishment approach used by most model providers. It means Cursor's logic is much more complex (and buggy) when users change spend limits during the cycle. None of those problems exist when users spend from a bucket to which they can add funds ad hoc and via monthly top off. On the other hand in OpenHands I need better safety spend limits (per request) and visibility into spend and projected spend.