ClearML Agent: a queue-driven execution daemon for ML workloads
ClearML Agent - MLOps/LLMOps made easy. MLOps/LLMOps scheduler & orchestration solution
At a glance
- What is it?
- ClearML Agent turns a GPU box into a worker that pulls Draft experiments off a ClearML queue and builds each one its own environment. The README is explicit about the trade-off: it is a fire-and-forget agent, not a cluster scheduler you configure by hand.
- Who is it for?
- Adopt ClearML Agent if you already run a ClearML Server and want GPU machines to pull work from named queues without writing YAML per job. Do not adopt it if you have no ClearML Server, or if you want a scheduler that owns placement, quotas and preemption without a separate controller.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The queue is the interface, and that is the whole design
The problem ClearML Agent addresses is narrow and concrete: a researcher has a script that runs on one GPU machine, and now needs it to run on six, some on-premises and some rented. The README states the agent "is a job scheduler that listens on job queue(s), pulls jobs, sets the job environments, executes the job and monitors its progress." That sentence is the architecture. There is no central placement algorithm inside the agent binary. There is a queue, and there are processes that poll it.
Who it is for follows from that. The README targets DL/ML R&D DevOps, and lists the needs it was built around: adding and removing machines from a cluster, reusing machines without dedicated containers or images, combining GPU resources across cloud and on-prem, and avoiding "yaml / json / template configuration of any kind." If your team already writes Kubernetes manifests by hand for every training run, this is aimed at removing that step. If your team's bottleneck is something else, the agent does not help.
The unit of work is a ClearML experiment. The README is specific: "Any 'Draft' experiment can be scheduled for execution by a ClearML agent." A previously run experiment becomes Draft either through the Reset action, which the README says "will clear any results and artifacts the previous run had created," or through Clone, which creates a new Draft experiment. That distinction matters operationally. Reset is destructive to prior outputs; Clone is not.
What the agent actually does between pull and process start
The data flow visible in the material runs through the ClearML Server. The server holds the queue and the experiment definitions. The agent registers against it, watches one or more queues, and when a job appears it takes responsibility for that job's environment.
The README gives two execution environment modes: "virtualenv or fully docker containerized." In the virtualenv path the agent builds an isolated Python environment for the job on the host. In the Docker path the job runs inside a container. The README describes this as deploying execution environments "with zero effort," which is the marketing register, but the mechanism underneath is ordinary: the agent resolves the job's requirements, constructs the environment, starts the process, and monitors it.
Beyond plain execution, the README lists launch-and-forget service containers, cloud autoscaling, a customizable cleanup service, and pipeline building and execution. Each of those is a separate service with its own documentation page linked from the README, not a flag on the agent. That is worth noting before you plan a rollout: the agent is the execution primitive, and the surrounding conveniences are additional components you deploy and maintain.
The Kubernetes path is described as a glue mode. Rather than the agent running jobs directly, a controller pulls from the ClearML queue and prepares a Kubernetes job "based on provided yaml template." Inside each pod, the README states, "the clearml-agent will install the job (experiment) environment and spin and monitor the experiment's process." So the agent still runs, one level down. The README says this mode is available either through the ClearML Agent Helm Chart or by running the clearml-k8s glue example on a CPU node.
Getting an agent onto a machine
The README's five-step path is short. Stand up a ClearML Server, either self-hosted from the clearml-server repository or on the free tier at app.clear.ml. Then run `pip install clearml-agent` on any GPU machine. Then create a job, either as a ClearML task or by adding the clearml package to your code, which the README describes as two lines of code. Then change parameters in the UI and schedule the job for execution, or automate it with a pipeline.
What the README does not give in the text supplied here is the agent configuration file contents, the exact `clearml-agent` subcommands, or the queue registration keys. Those live in the linked documentation at clear.ml/docs rather than in the README body. Anyone evaluating this should treat the README as the orientation and the docs site as the reference; do not expect to configure a production agent from the repository front page alone.
The Kubernetes route has a concrete artifact to look at instead: the docker folder in the repository holds Dockerfiles, and the Helm chart lives in the separate clearml-helm-charts repository under charts/clearml-agent. The glue example is at examples/k8s_glue_example.py. Those three paths are the ones to read before deciding whether the Kubernetes mode fits, because the glue approach requires you to supply a Kubernetes job YAML template, and the shape of that template determines what your pods can request.
One README claim deserves scrutiny rather than repetition. The bootstrap section says agents can be booted "up to 10x faster" with git, git-lfs, agent, ssh and UV precompiled for x86 and arm. No measurement, baseline or hardware is given for that figure. Treat it as a vendor claim, not a benchmark.
Where the design pushes work back onto you
The README's own hedge is the most useful line in it: "epsilon - Because we are and nothing is really zero work." The configuration-free promise applies to job definitions, not to the platform. You still choose and operate a server, still decide which machines join which queues, and still own the environment resolution when a job's dependencies do not build.
The environment build is the sharpest failure mode implied by the design. In virtualenv mode the agent constructs a Python environment on the host for every job. Jobs with conflicting or unpinned dependencies, or with compiled extensions that need a specific CUDA toolchain, will fail at build time rather than at scheduling time. Docker mode moves that problem into image selection, which means your base images become part of your operational surface. Neither mode is described in the README as validating dependencies before the build starts.
The Kubernetes glue mode has a structural cost the README does not dwell on. The controller prepares Kubernetes jobs from a YAML template, and inside each pod a clearml-agent installs the experiment environment. That is two layers of job management, and the second layer is doing package installation inside a running pod. The README lists the benefit as "Kubernetes full view of all running jobs in the system," which is real, but it comes with the pod-level installation step as a recurring cost per job.
Finally, the README separates enterprise features from the open agent: RBAC, vault, multi-tenancy, scheduler, quota management and fractional GPU support appear under Enterprise Features in the Kubernetes section. If your requirement is quota enforcement or sharing one GPU across isolated containers with memory and compute limits, the open source agent described here is not the component that provides it.
Kubernetes-native tooling is the alternative, and the difference is who schedules
The obvious comparison is running training jobs as Kubernetes Jobs directly, with something like Kubeflow or a plain controller watching a queue. The difference is not the container runtime; both end in a container. The difference is where the job definition and the scheduling policy live.
In a Kubernetes-native setup, the job spec is the source of truth. You write the manifest, the image is pinned in it, and the cluster's scheduler places the pod. ClearML Agent inverts this. The experiment is the source of truth, the environment is built at execution time from the experiment's requirements, and the ClearML queue decides order and priority. The README frames the benefit as adding "the missing scheduling capabilities to your Kubernetes cluster" and letting users work without direct Kubernetes access. The cost is that what actually runs inside the pod is determined at pull time, not at apply time, which makes the running system harder to reproduce from the cluster state alone.
A second comparison is Slurm, which the README supports and links to in the documentation. Slurm is an HPC batch scheduler with its own resource model and its own job submission language. ClearML Agent's model is a queue of experiments with a UI on top. If your institution already runs Slurm and your users know sbatch, adding ClearML Agent means adding a layer rather than replacing one, and the README gives no detail on how the two schedulers negotiate resources.
There is also the simplest alternative: a shell script and a cron entry that pulls from a git branch and runs training. That has no UI, no artifact tracking and no priority, but it also has no server to operate. ClearML Agent is worth its overhead only if you want the queue, the UI and the experiment tracking together.
Version cadence, licence and what to check before you commit
The repository is Apache-2.0 and not archived. Recent releases listed are v3.0.1 on 2026-05-06, v3.0.2 on 2026-05-25 and v3.0.3 on 2026-06-02: three patch releases inside a month. That cadence suggests active maintenance, and it also means a pinned version is worth having in any deployment you automate, since patch releases at that rate can change behaviour between a staging agent and a production one.
Apache-2.0 permits commercial use and modification, and it includes a patent grant. It does not oblige you to publish changes. This is a description of the licence text, not legal advice; if you are embedding the agent in a product, have your own counsel read the terms. The README also points to enterprise features that sit outside the open repository, so a licence review should cover the whole deployment, not just this package.
The upgrade cost is mostly environmental. Because the agent builds job environments on the host or in a container, an agent upgrade can change how those environments resolve. The README's bootstrap section is aimed at exactly this kind of churn: precompiled git, git-lfs, agent, ssh and UV for x86 and arm, so that bootstrapping a machine does not require installing those at runtime. If you run agents on ephemeral cloud instances, that bootstrap is the piece that determines how long a new node takes to become useful.
Python is the primary language, and the package is distributed on PyPI. The README claims support for Linux, macOS and Windows, but the operational examples that matter (Kubernetes glue, Helm charts, cloud autoscaling) are Linux-shaped. If your fleet is mixed, verify the non-Linux paths yourself rather than assuming parity.
Editorial conclusion
Adopt ClearML Agent if you already run a ClearML Server and want GPU machines to pull work from named queues without writing YAML per job. Do not adopt it if you have no ClearML Server, or if you want a scheduler that owns placement, quotas and preemption without a separate controller. Before committing, verify three things on your own hardware: that your CUDA driver and Python version survive the virtualenv build path, that the Docker mode you plan to use can pull your base image, and that the agent's cleanup policy will not delete artifacts you need. The README's own framing is the honest one: this is epsilon DevOps, not zero.
Community notes