Overmind turns production traces into fine-tuned models for your own agent

The SDK is MIT, the platform behind it is not

The licensing split is stated in the first screen of the README, and it is unusual enough to be the first thing an adopter should read. The SDK and CLI you install with pip install overmind are MIT, while the platform behind them is AGPL-3.0 and can be self-hosted, with details in a licence section further down. The repository is a monorepo whose own layout shows two separate code trees, with an overmind/ directory for the SDK and CLI and an overbae/ directory for the Django platform, and the docker-compose file sets the Django settings module to overbae.settings. There is a third tree, sandbox/, which the compose file mounts at the root of the container and points at through a SANDBOX_URL. So the split is not only a licence boundary but a code boundary, and a team that installs the MIT client and never self-hosts the platform is on one side of it, while a team that runs the full stack is on the other.

The first step is scanning the repo into a capability graph

The mechanism starts with a static view of what your agent actually is. The README describes a graph of your agent, with capabilities, prompts, tools and tasks, scanned from the repo, and the hosted flow is built around that. You sign up at the console, pick your coding agent on the get started screen, with Cursor, Claude Code, OpenCode and Codex listed, and paste the onboarding prompt into it with your agent's repo open. It then installs the overmind CLI, runs overmind init and overmind sync, and builds the context graph. Everything after that is a slash command in the same chat, and the table of commands is the clearest statement of what the product does. overmind ensure-tracing inspects traces and instruments the agent, overmind dataset builds, cleans, uploads or exports a dataset, overmind finetune fine-tunes, deploys and smoke-tests a model, overmind optimise runs prompt and code optimisation, and overmind backtest compares models against the agent's own traces.

Traces are the training signal, and they are scored as they arrive

The observability layer is where the data comes from, and it is described as OpenTelemetry traces scored as they arrive and matched to the capability that produced them. That matching is the point, because a trace that fails is only useful if you know which part of the agent produced it, and the capability graph is what makes the attribution possible. The datasets layer takes production traces or uploaded files and turns them into versioned eval and training datasets, and the eval layer is described as what good means per capability, measured on live traces and in batch. The optimisers layer runs prompt, tool and control-flow experiments in your repo, and the result of an experiment is described as a winner that is a git diff, which is a more reviewable output than a dashboard of scores. The whole design assumes an agent with observable steps rather than a black box call, and the README is explicit that a mutation of the model is benchmarked against the eval metrics you define.

Self-hosting means a specific set of services

The self-hosted path is a clone and a compose file, and the README stresses that the hosted and self-hosted stacks are the same code. The sequence is three commands:

git clone https://github.com/overmind-core/overmind.git && cd overmind
cp .env.example .env    # set the required keys below
docker compose up -d    # Postgres, Redis, API on :8000, Console on :5173, Celery workers, beat, Grafana on :3001

@@C1@@The compose stack is larger than a typical application. The README's comment lists Postgres, Redis, the API on port 8000, the Console on port 5173, Celery workers and beat, and Grafana on port 3001, and the docker-compose file confirms the shape with a Postgres service, a Redis service, an API service and a build context that mounts the overbae, modal_shared and sandbox directories. The environment file shows the same breadth, with a database URL, a Celery broker and result backend pointing at Redis, a DATA_ROOT under /data with media and tmp subdirectories, and separate provider keys for OpenAI, Anthropic and Gemini, plus OpenRouter, Together and Hugging Face tokens. The API is a Django service, with a manage.py at the root, a Celery application and a drf-spectacular setup for the OpenAPI schema, and the README notes that migrations and the built-in evaluators are seeded on first boot, with Swagger served at the API docs path.

The API refuses to start without provider credentials

This is the operational fact that decides whether a self-hosted evaluation is even possible for you. The README says the API refuses to start until every required key is set, and that the error names each missing one, with .env.example documenting every key. The required table starts with an OpenRouter key, used for judges, evals, trace scoring, optimiser scoring and frontier inference, then Modal token id and secret for the Modal training and serving workers, with the environment set explicitly, then an inference API URL and key for serving trained models, described as the endpoint printed by the modal deploy command and its shared secret, then AWS credentials and a bucket name for the fine-tuning checkpoint archive. There is also an encryption key for stored provider credentials,

| `OPENROUTER_API_KEY`                                            | Judges, evals, trace scoring, optimiser scoring, frontier inference                   |
| `MODAL_TOKEN_ID`, `MODAL_TOKEN_SECRET`                          | Modal training and serving workers (set `MODAL_ENVIRONMENT` explicitly)               |
| `INFERENCE_API_URL`, `INFERENCE_API_KEY`                        | Serving trained models — the endpoint printed by `modal deploy` and its shared secret |
| `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_BUCKET_NAME` | The fine-tuning checkpoint archi

generated with a one-line Python command using the cryptography library's Fernet, and a Clerk key pair for the hosted console sign-in, with a local email and password path that the environment file says is used when the self-hosted flag is set and the publishable key is blank. In other words, judging a trace is not a local operation.

Inference is one OpenAI-compatible endpoint, and the weights are yours

The serving side is described as trained and frontier models on one OpenAI-compatible API, which is what lets an existing agent client point at it without rewriting its client code. The models layer is separate, with fine-tunes you own, trained on your data and benchmarked against production. The README's most important line for anyone worried about lock-in is that the weights are yours to download, retrain or roll back, and the fine-tuning section says the winner of an optimisation is delivered as a git diff you can review. The training backend is configurable, with the compose default set to modal, which matches the Modal tokens in the required list and the modal_shared/ directory mounted into the build context. The inference and training jobs run outside the compose stack, so the data leaves your network even in a self-hosted deployment unless you point the backend at your own.

Document handling is local OCR with hard limits

The detail that stands out in the configuration is the document pipeline, and it is a good example of a project making its boundaries explicit. Uploads include local English OCR for scanned PDFs, embedded images and direct PNG, JPEG and WebP uploads, with direct images capped at 100 MB and 64 megapixels, and animated images not supported. The Docker image includes Tesseract and its English and orientation data, and for workers or backend tests outside Docker you install the tesseract-ocr packages on Debian or Ubuntu, or brew install tesseract on macOS, and no external OCR service is required. The Python dependency list backs this up, with pytesseract-style tooling alongside pandas, scikit-learn, scipy, numpy, tiktoken for tokenisation, langdetect and rapidfuzz for language detection and fuzzy matching, duckdb and pyarrow for local data work, and the anthropic-style OpenAI client at version 1.0.0 or newer. The licensing boundary is also in the badge row: the platform is AGPL-3.0 and the SDK is MIT.

Editorial conclusion

Overmind suits a team that already runs an agent in production, has real traces to learn from, and wants to own the resulting weights rather than keep changing prompts. It does not suit a team without production traffic, since the whole loop is built on traces as the training signal, and it does not suit an organisation that cannot route data through third-party model providers, because the API refuses to boot without a provider key. Before adopting, read the required environment variables in .env.example, and note that the last push to the repository was on 2026-10-20 with v0.1.9 tagged the same day, under a platform AGPL-3.0 licence and an MIT-licensed SDK.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. overmind-core/overmind on GitHub
3. Project website
4. README
5. Releases