#893
fix: solo/self-hosted deployments inherit expensive sandbox defaults
Self-hosting a solo instance burned ~12h of my Active CPU over ~5 days of no use. Usage was zero on the days before it was deployed, so it's not a leak. Fluid CPU kept growing on days I never opened the app, which points to something running on its own. Possible issues could be:
- Likely root cause: stale
activeStreamIdonly checks the ID is non-null, not that the run is alive. If it's orphaned, the lifecycle workflow (sandbox-lifecycle.ts:95) never hibernates and re-loops every 5s. - Eager provisioning on session create (
sessions/route.ts:408, #880) - abandoned sessions still spin up a sandbox. That + 4 vCPUs per sandbox is significant. - 30-min idle window (
config.ts:31) - sandboxes stay alive 30 min after last activity.
Suggestions (I'll get to these when I have codebase access lol)
- Check run status in
hasActiveStreamForSessioninstead of just non-null, and clearactiveStreamIdserver-side on workflow completion - Document OPEN_AGENTS_RESOURCE_PROFILE=hobby env var in README /
.env.example - Make provisioning lazy (provision on first message)
- Lower / make configurable the idle window
Activity
0No activity yet.