Observe

Once a job is submitted, the CLI and Simulo Console let you follow it from queued to finished, stop it, and retrieve its results, models, recordings, and outputs. CLI commands that take a job id accept an optional id and default to your most recent job.

List jobs

simulo jobs

JOB ID                   JOB    STATUS     STARTED               EXIT
job_swift-falcon-3nqk8n  train  completed  2026-07-10T18:02:11Z  0

When a listed job failed, the table adds a REASON column with the curated reason code. Use JSON for complete, untruncated machine records:

simulo jobs --json

Use Simulo Console

Open Simulo Console and choose Jobs. The organization view shows jobs from your active organization; switch to Mine to match the default simulo jobs scope. Select a job to inspect its summary, logs, models, outputs, and result, or to open a live view when streaming is available.

The Console can browse jobs and assets, download job outputs, open live views, and cancel queued or running jobs. Creating and submitting apps, and validating or publishing assets, remain CLI workflows.

Stream logs

simulo logs --follow

Streams live output and exits mirroring the job’s own outcome (0 on success, 1 otherwise) — safe to use in a script. Without --follow it just prints what exists so far and returns immediately.

Pressing Ctrl-C stops following the logs in your terminal, but it does not stop the cloud job. Reattach at any time with simulo logs <job-id> --follow.

For a failed or cancelled job, the terminal reason and human detail are shown even when the job produced no log lines. The reason is platform-curated (for example asset_missing), not a raw service traceback.

simulo logs <job-id>              # a specific job, full history
simulo logs --follow --tail 200   # follow, starting from the last 200 lines
simulo logs --from-start          # full history from the beginning

***REDACTED*** in the output is expected

simulo logs serves the uploaded copy of a job’s log — the bytes the worker sent to the platform, where everyone in your organization can read them. Before upload, the worker scrubs credentials (Authorization headers, Bearer tokens, AWS keys, *_TOKEN= / *_SECRET= / *_PASSWORD= assignments) and host-identifying details (the worker’s username and home directory, instance ids, internal hostnames). Those become ***REDACTED***:

[RLPlayer] Loaded JIT policy: ***REDACTED***/volumes/checkpoints/policy.pt

It is a redaction, not an error, and the job is unaffected.

Only production expires job logs

While a job runs, its output streams live. Once the job finishes, Simulo stores the log as the only copy of it — there is no second copy to recover, in any environment. Production also removes that stored copy on a schedule; staging and local development do not remove it automatically:

Environment	Job logs are kept for	After that
Production	90 days	the log is permanently unavailable
Staging	no limit	nothing is removed automatically
Local development	no limit	nothing is removed automatically

Reading a log past that window tells you so directly rather than showing an empty log:

Logs for job job_a1b2c3 are no longer available. Simulo keeps a finished
job's logs for a limited time after the run ends, and this job's log has
passed that window.

simulo logs exits non-zero in that case, so a script cannot mistake it for a run that printed nothing. If you need a run’s output to outlive that window, save it while the job is recent: simulo logs <job-id> --from-start > run.log.

What is on this clock, and what is not. A job’s status, result and outputs summary are records, not files, and are never removed by log retention. Its downloadable files — models and recordings — are:

Environment	Models and recordings
Production	kept; only logs expire, at 90 days
Staging	kept; nothing is removed automatically
Local development	kept; nothing is removed automatically

So “only the log expires” is a statement about production — staging and local development have no automatic expiry for logs or files at all. That is not a durability guarantee: nothing here is backed up, and staging remains subject to deliberate cleanup by the team operating it, outside this schedule.

Very rarely, Simulo cannot store a finished job’s log at all. That is reported as a distinct condition (“Simulo could not save this job’s log output…”) so you can tell it apart from an ordinary retention expiry.

Separately, a log can be temporarily unreadable — a storage hiccup rather than an expiry. That answers with its own message (“could not be read right now — this is temporary, not a lost log”); retrying works.

Stop a job

simulo cancel <job-id>

Naming the job id makes the target explicit and skips the CLI’s confirmation prompt. If you omit it, simulo cancel selects your most recent job and asks before acting. In Simulo Console, select a queued or running job and use Cancel; the Console asks for confirmation too.

Fetch the result

For the training starter created by simulo create, fetch the returned training summary:

simulo result

{
  "checkpoint": "/out/mybot_final.pt",
  "num_envs": 4096,
  "best_reward": 294.65,
  "iterations": 200
}

These fields come from the training starter. Other apps define their own result shape. The reward number is an illustrative example, not a measured benchmark — your run will land somewhere different.

A result only exists once the job completes successfully — for anything still running or failed, simulo result prints a clear error pointing at simulo jobs or simulo logs --follow.

Retrieve trained models

The training starter configures resumable checkpoints, so its completed job lists latest.pt and best.pt:

simulo models

NAME       KIND    SIZE      SHA256        CREATED               MODEL ID
latest.pt  latest  2148728   b7e410c92a55  2026-07-10T18:05:02Z  51aa...
best.pt    best    2148728   3f9c2ab81d04  2026-07-10T18:04:18Z  8c2f...

simulo models <job-id> best.pt # download it, digest-verified

Other jobs only list models they actually create, and may have no models.

Full detail on downloading and verifying models: Retrieve and verify models.

Retrieve any output

simulo outputs combines a job’s downloadable models and recordings in one list:

simulo outputs
simulo outputs <job-id> best.pt
simulo outputs <job-id> --all -o ./job-outputs/

See Retrieve job outputs for the complete list and download workflow.

No job id needed

Every observe command above takes an optional job id. Omit it and the command resolves the most recent job for you, announcing what it resolved to on stderr:

simulo logs                                       # most recent job
simulo logs job_swift-falcon-3nqk8n               # a job's full friendly id
simulo logs 5a2f                                  # a PREFIX of a job's legacy UUID form (4+ characters)
simulo logs 5a2f9c1e-7d43-4b21-9e0f-2c8a51d6b39f  # the full legacy UUID form

A friendly id is matched by exact equality only — give it in full. An id prefix is accepted only for the legacy UUID form some jobs from before friendly identifiers still carry (4+ characters, resolved like a Git short SHA); it works anywhere a job id is accepted — simulo logs, simulo result, simulo models, simulo recordings, simulo outputs, simulo cancel, and --from (see Continue training) all understand it. An ambiguous prefix is refused with the list of candidates — it never silently picks one.

Next

Continue training from a finished job’s checkpoint, or take the policy off the platform entirely with Export a policy to ONNX — simulo models hands you a checkpoint that still needs Simulo to run, while simulo export hands you a bundle that does not. For every flag these commands accept, see the CLI Reference.