Queue & Runtime Expectations

Submitted jobs queue until compute capacity is free, then run to a terminal status. This page covers status transitions, queue timing, priority, ETA signals, and runtime caps.

#How Jobs Move Through the System

Every job transitions through these statuses:

• pending / queued: waiting for available compute capacity
• running: SimulationCraft is executing
• completed / failed / cancelled / timed_out: terminal state, job is done

Track a job's current state in real time via GET /simc/jobs/{id}/status. Poll until status is one of the terminal values: completed, failed, cancelled, or timed_out.

#Queue Timing

Queue wait depends on current system load. The target is for standard jobs to start within a few minutes of submission.

Jobs are not allowed to wait indefinitely. If a job ages past its queue timeout it fails with queue_timeout, meaning it never started rather than ran and failed. It is safe to resubmit.

You can set a per-job queue timeout via runtime.maxQueueSeconds at submission. The value must be a positive integer and cannot exceed your account limit. If omitted, your account's default queue timeout applies. Your current queue cap is visible via GET /simc/usage.

#Priority

Each job is submitted at one of two priority levels: standard or high. Higher priority is picked first; jobs at the same priority run in submission order. Default is standard.

The fee is returned as limits.priorityFeeCredits.high from GET /simc/usage. If a high-priority submission is rejected with code: "insufficient_credits_liability", the response also includes the applicable priorityFeeCredits so you can decide whether to add credits or fall back to standard.

#ETA Signals

The status endpoint exposes queue.estimatedStartSeconds, a best-effort countdown to when the job is expected to start.

#Runtime Limits

Every job runs under a maximum runtime cap. Jobs exceeding the limit are marked timed_out. Your current limit is visible via GET /simc/usage in limits.maxRuntimeSeconds. You can request a specific cap per job via runtime.maxRuntimeSeconds at submission, subject to your account limits.