Admission and lifecycle
This page documents the platform’s admission and workload-lifecycle behavior as observed on the deployed platform: what happens when you launch a workload, while it runs, and when it stops.
Admission
Section titled “Admission”- Identity check — the request is attributed to your verified identity; ownership is derived server-side from your sign-in, not from request fields.
- Entitlement check — resources needing an entitlement (GPU, billable tiers) are denied unless your account holds it. GPU/billable access is never auto-granted.
- Quota check — the request must fit your project’s quota; otherwise it waits for headroom.
- Scheduling — admitted workloads are placed through fair-share, queue-aware scheduling; queued workloads start when capacity frees up.
Lifecycle
Section titled “Lifecycle”| Event | Verified behavior |
|---|---|
| Notebook idle for 30 minutes | Session is stopped automatically |
| Notebook reaches 24 hours of runtime | Session is stopped automatically |
| Stop | Compute (including GPU reservation) is released immediately; files stay on your volume |
| Start | Reservation is re-acquired through the scheduler; files are byte-identical to before |
| Delete notebook | Notebook is removed; its volumes are kept |
| Long-stopped workloads | Cleaned up by the platform (stale stopped workload reconciliation) — data on volumes is unaffected |
Why automatic stopping exists
Section titled “Why automatic stopping exists”Automatic stopping keeps shared accelerator capacity fair and keeps costs honest: idle sessions should not hold expensive compute. Nothing on your storage is deleted by stopping — restart anytime from the dashboard.