chachaml, experiment tracking for Clojure teams
Open-source experiment tracking and a model registry for teams that do machine learning in Clojure, like MLflow is for Python. An AI agent can query it over MCP. We use it for our own ML work.
What it shows
That machine-learning operations can be REPL-first and Clojure-native, experiment tracking, a model registry, tracked pipelines and dashboards run from the same interactive session that trains the model, rather than bolted on through a foreign toolchain.
Built with
Clojure · SQLite / Postgres · MCP server
chachaml is Flexiana’s answer to a gap that anyone doing machine learning in Clojure runs into: the operations layer, tracking, registry, pipelines, assumes you live in Python. chachaml puts that layer where a Clojure team works: at the REPL, in the same session that trains the model.
What it is
An MIT-licensed library, shipped at v0.7.0 and published on cljdoc. It tracks experiment runs, stores their artefacts, and keeps a model registry with stage promotion so a model can move from a candidate to a serving stage under an explicit, recorded decision. Pipelines are tracked as first-class objects, and threshold alerts fire when a tracked metric crosses a line you set.
A web UI provides run dashboards and Vega-Lite charts over the recorded history, so the same data you queried at the REPL is visible without one. Storage is SQLite by default, nothing to stand up on a laptop, with Postgres for teams that need a shared, concurrent store.
The agent surface
chachaml exposes its tools over an MCP server. That means an LLM agent can query the experiment history directly, ask which runs beat a threshold, compare two registered models, retrieve an artefact, and there is a chat-with-data path over the same store. The tracking layer is not just for humans reading a dashboard; it is a structured surface an agent can reason over.
For teams that need it, there is optional interoperability with scikit-learn via libpython-clj2, so a Python model can be trained and its results tracked in the same Clojure workflow. That path is available but off the default road: the design centre is Clojure-native.
Why it sits in the Lab as a productised proof of concept
The evidence status is in-production: chachaml is shipped, versioned and documented, and it is the tracking layer we ourselves run against, most concretely as the operations backbone of our BDH port, where every run, checkpoint and evaluation is auto-tracked. Its honest boundary is scope. chachaml is an operations layer, not a modelling framework. It will not choose or train a model for you. And it is Clojure-native on purpose: a team with no Clojure and a pure-Python stack may still prefer MLflow, and that is the right call for them. The claim it proves is narrower and more useful: that MLOps can be REPL-first and native, not an imported afterthought.
Method disclosure
The method is published.
MIT-licensed and on GitHub, read the implementation.
We publish open-source, academic and pro bono work in full. When a client pays for the method, we show the result and keep the method private.
Limits
chachaml is a tracking and operations layer, not a modelling framework, it records and organises work, it does not train models for you. It is Clojure-native by design; a Python-only team with no Clojure in its stack may be better served by MLflow. Interop with the Python ecosystem is available but optional, not the default path.