Architecture
Component map plus request data flow for Sandbox.Turing.Com — Agent, Harbor, and CodeEdit.
How the platform is put together, and how a request moves through it. Use the component pictures to see what exists; use the flow diagrams to see order and hand-offs.
High-level components
| Band | What it is |
|---|---|
| L4 | Your apps (Prism, CTP, …) — HTTP clients only |
| Edge | Gateway, /docs, OpenAPI |
| L3 | Harbor API, Agent API, CodeEdit, shared Harbor worker |
| Elasticity | Pub/Sub job queue + KEDA worker scale |
| L2 | Catalog, per-tenant/project quota policy + admit, Redis |
| L1 / L0 | KeyHive, drivers, gVisor trial pods, GCS |
How Agent / Harbor traffic flows
Agent and Harbor are async: you get 202 immediately; work runs on the
shared worker fleet.
Step by step:
- Gateway authenticates and routes to Harbor or Agent.
- API writes a job to Pub/Sub and returns
202+job_id. - KEDA scales
harbor-workerfrom the queue depth (dev: 2 → 8). - Worker admits a per-project slot, leases a model key, runs the trial pod.
- You poll (or SSE) until terminal; artifacts land in GCS.
If the project is at its concurrent cap, the job stays queued (redelivered), it does not fail as a hard error. See capacity notes in Errors and limits.
How CodeEdit differs
CodeEdit is sync: one HTTP call waits for stdout/stderr. It may claim a warm pool pod (~200ms) or create one (~6s). It does not use the Agent/Harbor job queue.
Low-level packages
| Column | Role |
|---|---|
| HTTP edge | Thin FastAPI services behind the gateway |
| Libraries | harbor_service, agent_service, control_plane |
| Ports | JobQueue, ObjectStore, KeyHive, SandboxDriver |
| Runtime | Worker Deployment, KEDA, trial pods, ResourceQuota |
Import direction is one-way: services → *_service → control_plane → sandbox_core.
Agent never imports Harbor’s library.