E2B sandbox concurrency control room and capacity planner

Build me a control room for E2B sandbox concurrency. My team's E2B plan has a hard ceiling on how many sandboxes can run at once, and when we hit it new sandboxes stop launching for real customers. I need one screen that shows how much headroom is left and lets a human decide what to reclaim. This is a staffed decision surface, not an automation: nothing is ever paused or killed unless someone clicks a button.

The concurrency ceiling has to be a setting. The E2B API does not tell the app what our plan allows, so app settings should hold the ceiling as a number I type in (20 on Hobby, 100 on Pro, higher with purchased add-ons), plus the two thresholds where the headroom gauge changes color (default warning at 70 percent and critical at 85 percent), the default extension length used by the Extend button, the Slack channel the capacity memo is posted to, and which sandbox metadata keys should be read as owner and job. Persist these for the app so everyone on the team sees the same ceiling.

The first tab is the live floor. At the top, a headroom gauge: running sandboxes right now versus the ceiling, shown as a big number, a percentage, and a band that fills and turns amber then red as we approach the limit. Get the running count from List Sandboxes filtered to running state, following the cursor pagination until there are no pages left so the count is accurate rather than capped at a single page. Show the paused sandbox count alongside it, since paused sandboxes do not hold a concurrency slot but their snapshots do keep consuming storage.

Below the gauge, one row per running sandbox, built from List Sandboxes joined to List Sandboxes Metrics batched over the sandbox IDs on screen. Each row shows the sandbox ID, how long it has been alive, its template, the owner or job pulled from the sandbox metadata, the time left on its TTL as a live countdown, and current CPU and memory. Sandbox metadata is free-form, so use the key mapping from settings and fall back to displaying the raw metadata when nothing matches. Clicking a row opens a detail drawer backed by Get Sandbox.

Sort so the least defensible slot holders float to the top. Rank rows by a reclaim score that combines near-zero CPU across the most recent metrics samples, greatest age, and how many times the sandbox has been extended, counting refresh and timeout events per sandbox from the lifecycle history. Show the reason each row ranked where it did in plain words, something like 'idle 40 minutes, 6 hours old, extended 4 times', so I can defend the call to whoever owns it. Let me re-sort by any column and filter by template or owner.

Every row gets Pause, Kill and Extend. Pause calls Pause Sandbox, Kill calls Kill Sandbox, and Extend calls Set Sandbox Timeout with the default from settings, or Refresh Sandbox when I only want to reset the existing TTL. Make Pause the visually primary action, because it snapshots filesystem and memory and the sandbox can be resumed later. Treat Kill as destructive: red styling, a confirmation that states plainly that the sandbox cannot be recovered, and never the default. Next to the Extend control, note that a timeout is measured in seconds from now and replaces the existing TTL rather than adding to it, and that plans cap it at 3600 seconds on Hobby and 86400 seconds on Pro.

Add checkbox multi-select with a bulk reclaim bar. Selecting rows shows how many slots the action would free and what the gauge would read afterwards, then a confirmation step that lists every affected sandbox by ID, owner and age before anything runs. Bulk Pause and bulk Kill both go through that step, with Kill requiring an explicit typed confirmation. Run the calls one sandbox at a time, show per-sandbox success or failure, and refresh the gauge when the batch finishes. Pausing takes roughly four seconds per GiB of RAM, so show progress instead of freezing the screen.

The second tab is peak concurrency history. Page through List Team Sandbox Lifecycle Events and replay created, resumed, paused and killed events in time order to reconstruct how many sandboxes were running at each moment, then chart the daily peak against the ceiling line so I can see how close each day actually got. Break the peaks down by template and by owner so I can see what drives them. That data is offset paginated at a maximum of 100 events per page, so the window is bounded: state on screen the earliest event the app could reach and say the history starts there, rather than implying it covers all time.

Put a 'Draft the capacity case' button on the history tab that kicks off a background agent. The agent reviews the reconstructed peaks, the template and owner breakdown, and the current live table, then works out which of two stories is true: we are genuinely growing into the ceiling and should buy capacity, or we are leaking abandoned sandboxes and should fix the code that forgets to close them. It writes a short memo either way, no longer than a page, naming the evidence, the peak days, the templates and owners responsible, and one clear recommendation. Save the memo in the app so past memos stack up in a list I can reopen and compare, and post it to our platform channel using the Slack Send a Message operation with the channel from settings. Show the run status on the button, and drop the finished memo into the list when it lands.

Keep the whole surface focused on headroom and capacity decisions rather than idle cleanup. Refresh the live tab on an interval and on demand, show when the data was last fetched, and if E2B returns a rate limit error, surface it plainly, since that is the same failure our customers hit when we run out of slots.