Keep Polyaxon sandboxes ready with bounded lifetimes

A coding agent often executes a short command, waits for a model response, and then executes another command against the same files. Creating a new environment for every step can waste preparation time.

A running Polyaxon sandbox service can support that session. The operational question is how long to keep it ready, what state to preserve, and when to stop paying for unused capacity.

Reuse within a defined session

Assign a service to an authenticated session and maintain that mapping in the controller. Before accepting another tool call, verify that the caller owns the session and that the assigned run is still usable.

Use sandbox health checks before dispatching work. A remembered run UUID does not prove that the service is ready or that its Pod has not been replaced.

Do not make a workspace available to a new tenant merely because the previous user became idle. Reassignment requires an explicit, verified reset strategy; creating a fresh environment is often easier to reason about.

Bound the maximum lifetime

Add an absolute termination deadline to a sandbox component:

termination:
  timeout: 14400

This fragment limits the service to four hours, regardless of activity. It is a safety backstop, not a promise that every active session should be interrupted at that point without warning.

The application should communicate the remaining session window and checkpoint useful work before termination. Closing a client connection does not stop the service, so cleanup needs an explicit owner.

See termination configuration for the available controls.

Use activity-aware culling when supported

For deployments supporting service culling, an application-owned activity endpoint can report the last meaningful session activity. The following fragment assumes that endpoint exists on port 8000:

termination:
  timeout: 14400
  culling:
    timeout: 1200
  probe:
    http:
      path: /activity
      port: 8000

The endpoint must return the documented last_activity timestamp format. Update it for actual work, including long-running operations, rather than blindly marking every health probe as user activity.

Review the service timeout guide and version support. Culling stops an idle service; it does not suspend the process and later restore its memory. A plain sleep-based sandbox does not supply this custom HTTP endpoint by itself.

Preserve the work that matters

Use the output persistence workflow to save approved reports, patches, and checkpoints before stopping the service. Scratch files on an emptyDir volume disappear when the Pod is replaced.

Keep durable session metadata outside the sandbox. The controller needs to know which source revision and checkpoint to load when a replacement service starts.

Avoid retaining credentials or every temporary cache in the checkpoint. The goal is to reconstruct useful work, not preserve an uncontrolled machine indefinitely.

Measure whether readiness is worth its cost

Compare the preparation time avoided by reuse with idle resource consumption. Track active command time, session duration, time between requests, and reconstruction failures.

If sessions are brief and infrequent, a prepared image plus fresh execution may be a better fit. If users repeatedly inspect and modify the same repository, bounded service reuse may offer a meaningful improvement.

Polyaxon provides the service lifecycle and execution interface. The session policy turns those primitives into a responsive experience with an explicit resource budget.