Labtasker

Labtasker is a small, Python-native task queue for running independent ML inference, evaluation, and experiment jobs in parallel.

Documentation: https://luocfprime.github.io/labtasker/

LLM Documentation: https://luocfprime.github.io/labtasker/latest/llms.txt

Source Code: https://github.com/luocfprime/labtasker

Labtasker distributes independent ML jobs across multiple processes and machines. It adds dynamic control, failure recovery, and structured Task records without requiring each project to build its own task system.

The key features are:

• Effortless and flexible parallelism: Run the same Task queue with multiple Workers. Submit new Tasks, change priorities, or cancel Tasks without interrupting the Workers.
• Resumable and failure-resistant experiments: Retry failed Tasks automatically and recover work when a Worker stops. Restart Workers without rerunning completed Tasks. These lifecycle behaviors are covered by unit and end-to-end tests.
• Structured task records: Keep each Task's arguments, metadata, status, errors, and structured result in one place for inspection.
• Easy to adopt and use: Add Labtasker to existing Python code in fewer than 10 lines, or wrap an existing command with no code changes. The API, non-interactive CLI, Agent Skill, and agent-readable documentation allow an agent to operate Labtasker end to end.

When to use Labtasker

Labtasker is designed for independent ML work such as:

• model inference over prompts, samples, or dataset shards;
• evaluation across checkpoints, benchmark cases, and random seeds;
• generation and ablation experiments across parameter combinations;
• independent data-processing or analysis jobs.

Labtasker becomes useful when several processes share the work, you need to resume after an interruption without rerunning completed jobs, or you need to add, cancel, or reprioritize jobs during a run.

When NOT to use Labtasker

• A simple loop can be sufficient for a small experiment with a few short jobs that can be rerun in full.
• Use a workflow or DAG system when jobs depend on outputs from earlier jobs.
• Use a cluster or resource scheduler when you need to allocate GPUs, start machines, or manage compute capacity.
• Use an artifact store for model checkpoints, generated media, and other large outputs. Labtasker records their paths or URLs, not the files themselves.

Labtasker is deliberately designed to be conceptually simple and easy to hand over to agents.

Read Why Labtasker? for a fuller comparison with project-specific experiment scripts and the design decisions behind v2.

How it works

Submit every independent experiment case as a Task. Then start one or more Workers on the CPUs, GPUs, or machines where the jobs should run. Each Worker claims one compatible Task, executes it, records the outcome, and asks for another.

The Server stores Task state and coordinates claims. A route labels which Worker implementation can run a Task. A Queue groups Tasks that should be managed together.

Read How Labtasker works for retries, recovery, routes, Queues, and the boundary between the Server and Worker processes.

Choose a starting point