Skip to main content
Lynx uses two related concepts for simulation work: batches and jobs.

Batch

A batch is the top-level unit of submitted work, created by a single POST /jobs call. It represents one Monte Carlo study. A batch has:
  • a unique UUID (batch_id)
  • a name you provide
  • a total job count
  • counters for completed and failed jobs
  • an overall status: Pending, Running, Completed, Failed, or Cancelled
  • a created timestamp
A batch is complete when all its jobs reach a terminal state.

Job

A job is one individual simulation run within a batch, created automatically by Lynx when you submit a batch. Each job gets its own sampled parameter set drawn from the dispersions you defined. A job has:
  • a unique UUID (job_id)
  • a reference to its parent batch_id
  • the sampled parameters for this run (run_config)
  • a status
  • retry tracking: retries, max_retries
  • a timeout: timeout_secs
  • timestamps: created_at, claimed_at, started_at, completed_at
  • the ID of the runner that claimed it: assigned_runner
  • an error message if it failed: error_message

Batch vs job

Submitting a batch

Use runs_override to cap the run count without changing your config — useful for quick validation:

Monitoring a batch

The status response includes:
  • jobs_by_status — job count for each status (Pending, Running, Completed, Failed, etc.)
  • throughput_jobs_per_minute — current processing rate
  • estimated_completion_time_mins — time remaining estimate, if computable

Sampling methods

Latin Hypercube Sampling (latin_hypercube) is recommended for most studies. It produces better parameter space coverage than random sampling with the same number of runs.