feat(connectors): add boxcompute connector (9 endpoints + vm resource)

Summary

This adds BoxCompute (boxcompute.ai), which gives agents their own Linux VMs. With it, an agent on Monid can create a VM, run commands in it, list its files, open a preview URL to a server it started, and stop, start or delete the VM. The catalog has no code-execution provider yet, so this also adds a code-execution category leaf.

A VM is a durable, owned, billable thing, so this is built on the resource lifecycle with saperly as the template. It is the first resource with an ESTIMATED line, because what a VM costs depends on how long it runs.

• Resource boxcompute/vm: one DAY period with one ESTIMATED compute line, carded at the Small rate ($0.000834/minute; Large is 3x).
  • reconcileUsage.compute reads our cost API (GET /api/v2/sandboxes/{id}/costs) and counts each settled run, and the running estimate, for its share of time inside the window. After a delete, it finds the VM's history in GET /api/v2/deleted-sandboxes by sandboxId.
  • It throws rather than billing short if the history is cut at 1,000 runs or the running estimate is unavailable.
  • verify, release and refresh are like saperly's. A state of expired (refused or retired) counts as inactive.
• 9 endpoints. Every call is FREE; VM time is billed by the resource.
  • create-sandbox (provisions). Creates the VM with a run-stable Idempotency-Key and waits up to 100 s for it to boot:
    • running returns 201.
    • Still pending returns 202 and the VM is still provisioned, so it always has an owner.
    • expired (our account limit) returns 429 with nothing provisioned.
  • get-sandbox and list-sandboxes (reads). list-sandboxes reads only utils.resources, never the pooled GET /api/v2/sandboxes.
  • run-command, list-files, open-preview, start-sandbox and stop-sandbox (uses).
  • delete-sandbox (releases). It deletes at once rather than at the period end, so the VM stops billing and frees its slot in the pooled account. A 404 counts as done.
• Pooled tenancy. All Monid workspaces share one BoxCompute account. Every VM-scoped endpoint is ownership-gated, and the provider output drops workspaceId, metadata and createdByApiKeyId.
• Inputs: each endpoint's schema/inputs.ts mirrors the API's own bounds. The connector's tighter limits are applied at the binding in endpoint.ts: only the small and large sizes (default small), a 240 s command timeout (the API allows 900 s), and a working directory with no . or .. segments.
• Spec record: openspec/changes/add-connector-boxcompute/ (proposal, spec, tasks). No engine, compiler or schema change.

Fixtures

Most chains are real recordings against production, made on 2026-10-26:

• create, then refused at the account limit (pending, then expired)
• get
• execute, both exit 0 and exit 3
• file list, both found and missing
• preview
• start
• stop, both 200 and 409
• delete of a VM that is already gone
• live costs, and the deleted-VM cost chain
• an invalid API key on execute, preview and start (recorded 2026-10-27)

The chains live at provider level and are shared by the endpoint and resource tests, as in orbit. The synthetic- chains are built from those real bodies (create reaching running, a slow boot, a busy delete, and the cost-window cases). Account identifiers are scrubbed, and the preview URL's bearer hostname is replaced; that preview was closed right away.

Known gap: 204 replay (#199)

Our DELETE answers 204 with no body. fixtures.ts can't replay that until #199 lands. The two tests that need it (delete-sandbox's happy path and the resource's release) are written but ignored behind NO_CONTENT_REPLAY_BROKEN. Once #199 merges, flipping that flag should be all they need.

Testing

Run with Deno 2.9.7:

• deno task check and deno task lint are clean.
• connectors/ids.lock.json gains only the 9 new ids and the boxcompute/vm resource. ids:check --update also rewrites some existing entries (bytedance, fundable, hunterio and others), so main's lock looks stale. ids:check on main already reports that drift; I left those entries alone.
• Every endpoint has its own endpoint.test.ts: the happy path with the whole usage object, a provider error, and a schema gate with a passing twin. Bound endpoints also test the ownership 404. list-sandboxes never calls BoxCompute, so it has no provider error or gate.
• deno test connectors/boxcompute shared/compiler shared/testing: 87 passed, 0 failed, 2 ignored (the 204 tests above), on 72742cd.
• Full deno task test: 1,322 passed, 2 failed, 223 ignored (28m46s). That run was on the first commit, before a one-line fix to delete-sandbox's toRequest. Its two failures were those delete-sandbox tests. Later changes touch only connectors/boxcompute and the openspec change.

There is no live test, because every live call creates or wakes a billed VM.

Not in this PR

• Raw file read/write (application/octet-stream). run-command covers it.
• Long-running operations, the desktop (computer use), TCP services, logs.
• The xl and xxl sizes.

This PR comes from the BoxCompute team, and we're happy to adjust anything. We'll also email support@monid.ai as the README asks.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added BoxCompute support for creating, listing, viewing, starting, stopping, and deleting sandboxes.
  • Run commands in a sandbox, browse files in its workspace, and open a temporary web preview for a selected port.
  • Sandbox creation supports size, name, and network-blocking options. Newly created sandboxes are checked for readiness before the response.
  • Added daily compute-usage reconciliation based on sandbox run history. Already-deleted sandboxes can be deleted again successfully.