Queue 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 limits.

#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 /v1/simc/usage.

#Priority

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

The fee is charged only when high priority would buy your job a faster start. When it would not, the fee is waived automatically and the job still runs at high, so high is safe to use as a default. The submit response reports the fee charged in runtime.priorityFeeCredits; 0 means it was waived.

The fee amount is returned as plan.priorityFeeCredits.high from GET /v1/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 per-job credit ceiling: the optional runtime.maxCredits spend cap when the submission sets one, otherwise the plan ceiling visible via GET /v1/simc/usage in plan.maxCreditsPerJob. A job whose metered usage reaches its ceiling is stopped with errorCode max_credits_reached and billed the ceiling. See Job budgets for how reservations and refunds work.