chachaml, REPL-first MLOps for Clojure
A Clojure-native experiment tracker and model registry, the Clojure answer to MLflow, where runs, artefacts and pipelines are managed from the REPL and queryable by an agent over MCP.
What it proves
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 selectively and say which. Open-source, academic and pro bono work is published in full. Where the mechanism is the commercial asset we publish the result, the evidence grade and the boundary, and state that the mechanism is withheld, and never write around the gap.
Limitations & novelty boundary
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.