Build a massively parallel agent orchestrator for Ox Alpha #41

Project

Stress testing Ox Alpha

Sequence

This issue follows the local single-conversation slice in #55. Keep it in To Do until /chat can stream one real Ox Alpha response, cancel it, and expose honest provider and usage state. Do not make /chat wait for large-scale computer fan-out.

Architecture position

The /chat console is the entry point. This issue owns what an explicit dispatch from that console does: fan out OpenCode agent harnesses across OpenAgents cloud computers until provider or compute capacity saturates. The dispatch boundary must be durable and receipt-driven so reloading the browser does not lose or duplicate work.

Outcome

Run the maximum sustainable number of concurrent OpenCode harnesses against stealth/ox-alpha, sharded across providers by measured rate-limit budget.

Compute substrate

Harnesses run on cloud computers under cloud_computer.v1 from Cloud computer platform:

• One logical workspace per harness; compute comes from runtime leases, not reserved instances.
• Quota-broker admission starts at four active standard runtimes per chat, supports an explicitly budgeted eight-runtime operation, and allows up to 30 logical computers per chat. Prove 15-way fan-out before raising the default.
• Admission must account for Google Cloud regional CPU, IP, disk, and instance quotas before it starts work. Queue excess logical computers instead of partially creating them.
• Checkpoint and receipt semantics come from the cloud-computer contract, so a replaced host resumes rather than replays.

Dispatch contract

• Accept an immutable context snapshot and idempotency key from /chat.
• Return a durable parent receipt immediately, then child receipts for every harness.
• Expose queued, admitted, provisioning, running, checkpointing, completed, failed, cancelled, and quota-blocked states.
• Preserve the source conversation and message IDs on every child receipt.
• Cancellation drains or checkpoints each child according to its runtime state; it must not abandon instances.

Dispatch loop

• Pull the next eligible open issue from the backlog, claim it through an authoritative issue update, and spawn one harness with the issue body as its brief.
• Harnesses work from Forge clones, open stacked pull requests, and post closeout comments with commits, tests, and receipts.
• On drain, generate proposed issues from project goals for operator approval instead of silently inventing work.

Saturation rules

• Shard work through the overflow router; never hold dispatches while an admitted lane has measured budget.
• Back off on 429 with jitter and honor reset headers. Escalate sustained throttling to lane failover.
• Track tokens per lane and per harness; report raw and productive usage separately.
• Apply a per-chat concurrency budget, a fleet-wide budget, and a hard cost ceiling.

Acceptance criteria

• One dispatch can prove 4-way, 8-way, and then 15-way fan-out without duplicate work.
• A quota-constrained run queues cleanly and reports the exact blocking resource.
• Browser reload and process restart reconstruct the same parent and child state from receipts.
• Cancellation cleans up or checkpoints every admitted runtime.
• Provider throttling moves only eligible work and preserves request attribution.
• The /chat projection uses shared task, plan, checkpoint, tool, terminal, and artifact components only for real backend events.
• Tests cover idempotency, partial admission, restart recovery, cancellation, quota failure, and lane failover.