---
url: https://cubesandbox.com/guide/usecases/ouc-online.md
---

# OUC Online: Session Isolation and Lifecycle Practices for an Agent Code Execution Layer

## Business Context

OUC Online is building a Manus-like Agent platform for education and office scenarios, supporting user-defined Agents, Skills, Tools, knowledge bases, and MCPs. Typical tasks include knowledge-base-driven XLSX reports, PPTX courseware generation and validation, document parsing and re-processing, scripted data analysis, and multi-Agent collaboration. The platform has five layers: lea-agent (LLM main loop), lea-config (configuration), lea-tools (tool gateway + sandbox session management), CubeSandbox (isolated execution), and NFS/OBS (session workspace and deliverable storage). It is currently in evaluation, not yet in production.

## Key Challenges

* **Execution boundary for untrusted code**: arbitrary Python/Shell/Node scripts may be generated by the model; ordinary containers/shared VMs are unfit as the boundary.
* **The lifecycle dilemma**: deleting a session sandbox immediately makes the next message pay a cold start again; keeping it long-term consumes sandbox slots and host resources.
* **Mistaken reclamation under multi-replica**: app-local timestamps only reflect what one replica has seen, and service restarts zero them out.
* **Deployment freeze at documented resources**: on 4C8G/16G machines, loading the PVM KVM module via `modprobe kvm_pvm` froze the server with system-level OOM.

## Solution with Cube Sandbox

* **Three-stage lifecycle**: create (on first code execution, tagged with lea.session\_id / lea.tenant\_id) → keep-alive (auto-pause after 15 idle minutes via `on_timeout=pause` + `auto_resume=true`; auto-resume on the next message with the working directory intact) → reclaim (a platform loop scans Cube every 60 seconds, reclaiming only sandboxes carrying the platform session tag and already paused).
* **Reclamation criteria converge on platform-side state**: using Cube-returned state and endAt instead of app-local timestamps — all replicas see the same facts, eliminating mistaken deletion.
* **Data outlives the sandbox**: the session /workspace persists independently via NFS host-mount; long-term deliverables stay in OBS.
* **Deployment troubleshooting**: lowering `kmem_cache.max_num` from the default 16000 to 2000 let the module load — pinpointed to system-level memory exhaustion during module loading (without journald persistence, the root cause could only be confirmed down to "memory exhaustion").

## Results and Benefits

* After warm-up, sandbox creation takes 0.3–0.6s; first execution ~2.8s end-to-end (light samples, no stress test).
* Four distilled evaluation-stage suggestions: verify the resource floor yourself; base lifecycle criteria on platform-side state; finish log persistence before deploying; design the reclamation strategy during evaluation.

## References

* Full case study: [Building an Agent Code Execution Layer on Cube Sandbox: Session Isolation, a Three-Stage Lifecycle, and Deployment Troubleshooting](/blog/posts/2026-11-06-ouc-online)
* Cube Sandbox source: [TencentCloud/CubeSandbox](https://github.com/TencentCloud/CubeSandbox)