Skip to main content
hiloop runs agent and research workloads in isolated Kubernetes sandboxes. A request names an environment and the resources it needs; the control plane places it without exposing a pod, container id, or node name to the caller. Four ideas define the current architecture:
  • Sandbox identity is durable; runtime instances are replaceable. The control plane reconciles desired and observed state, and the state you read is evidence of what the runtime is doing.
  • The environment is named exactly. A sandbox starts from an OCI image, a snapshot, or the platform default image, pinned to a digest by the deployment.
  • Workspace state is explicit. Code and data belong at /workspace; /tmp is bounded scratch space. Whether /workspace has a lifetime of its own is the storage class’s job, chosen when the sandbox is created.
  • Execution is brokered. Buffered commands and SSH sessions are authorized per request by the control plane and carry stable execution records. No in-sandbox control daemon is required.
The hosted and on-prem products use the same API, workspace, and capability contracts. An on-prem deployment supplies its own Kubernetes cluster, registry mirrors, storage, networking, and trust roots.

​
Current boundaries

The sandbox runtime serves CPU workloads, bounded execution, a fixed public-internet/private-network egress floor, durable /workspace storage, and snapshot and branch. Accelerator requests and injected model credentials are refused at admission rather than partly served. Automatic activity capture has no create-time switch; its trusted in-sandbox attachment is still landing. What’s live today is the current list. Start with sandboxes, run-scoped observability, and the quickstart.