hlock
Make your agent harness pinnable, portable, and tunable.
Pin your harness, models, MCP servers, skills, and config in a harness.lock, version it, and rehydrate it anywhere.
Documentation · Quickstart · CLI reference · Design specs
Your agent is more than a model: it's a harness version, MCP servers, skills, plugins,
instruction files, and config, set up by hand on one machine. hlock pins all of it in a
harness.lock you commit to git, catches drift, and brings the same setup back on
another laptop, in CI, or in a container. When you're ready, it measures your stack
against your own tasks and finds a better one.
| You know this from package managers | In hlock |
|---|---|
🔒 uv.lock / Cargo.lock |
harness.lock: every dependency of your harness, pinned and hashed |
📌 pip freeze |
hlock pin: record the setup you already have, and re-pin as it grows |
✅ --locked check |
hlock check: show what changed since the pin |
📦 uv sync / npm ci |
hlock sync: rehydrate the locked setup on any machine |
▶️ uv run |
hlock launch and hlock run: start sessions and run prompts on the locked setup |
Install
Prebuilt wheels cover Linux (x86_64, aarch64), macOS (arm64, x86_64), and Windows (x64)
for CPython 3.9+. For Rust, use cargo add hlock.
[!NOTE]
harness-lockis an alias forhlock. Both names install the same package at the same version, soimport hlockandimport harness_lockare the same API.
Quickstart
Pin the harness you already use (Claude Code, Codex, Pi, OpenCode, Cursor, Gemini CLI, and more), then bring it back anywhere:
For your own work, hlock evals init -t coding (or data, research, support) writes
an eval pack template plus an Agent Skill, so the agent you already use can fill it in
with real tasks from your project. See Eval packs.
See the Quickstart, Pinning your setup, Rehydrating with sync, and Launching a locked harness.
Then make it better
Optimize your harness. Draft an eval pack from the requests you've already made to your
agent with hlock evals init --from-traces (it reads the sessions Claude Code, Codex, and
Pi logged for the project), and review it with your agent using the Agent Skill it writes. List the models, decision models and harnesses to try in a
harness.toml, and let hlock resolve lock the best combination with its success rate,
cost, and latency. hlock tune goes further, into prompts, hyperparameters, and
fine-tuned small models. The built-in reference provider is offline, so you can try the
loop with no API keys:
Go local. hlock localize turns a lock into an equivalent on an open-source harness
and models served by Ollama or LM Studio, keeping your MCP servers, skills, and
instructions.
Let an agent do the busywork. hlock meta hands work that needs judgment (installing
what a lock needs on a new machine, filling in an eval pack, updating skills and MCP
servers) to a pinned agent and checks the result itself. The default is an agent built
into hlock, so there's nothing to install: give it an API key or a local model.
See Finding the best stack, Eval packs, Tuning, and Going local, and The meta harness.
=
= # writes ./harness.lock
=
# {"success": true, "model": "qwen-7b", ...}
How it works
Architecture
A Rust core does all the deterministic work. Anything that needs the Python ML ecosystem or a GPU runs in a Python worker, which can lift each piece of work to a Flyte task on a cluster.
| Path | What lives there |
|---|---|
crates/harness-lock-core |
The core library (pure Rust): manifests, lockfiles, search planning, trial bookkeeping, evidence, lock construction. It orchestrates and aggregates, and never does heavy compute itself. |
crates/harness-lock-py |
PyO3 bindings, compiled into harness_lock._harness_lock and shipped only inside the wheel. |
crates/hlock, crates/harness-lock |
Thin crates that re-export the core (harness-lock is the alias). |
harness_lock/ |
The Python package: the hlock CLI and the heavy-work worker (tasks/worker.py). |
hlock/ |
A shim that re-exports harness_lock, so import hlock works. |
packaging/harness-lock |
The harness-lock PyPI alias, which pins the matching hlock release. |
docs/ |
The documentation site (Zensical), published to GitHub Pages. |
Backends
| Backend | Where trials run | Use it for |
|---|---|---|
local (default) |
in-process Rust reference harness | trying it out, CI, deterministic tests |
devbox |
Python worker on this machine | real LLM calls, your own traces, flyte local |
cluster |
Python worker that lifts each stage to Flyte/Union | GPUs, fan-out, durable caching, shared results |
# real LLM calls: export HL_LLM_BASE_URL=http://… HL_LLM_MODEL=qwen-32b [HL_LLM_API_KEY=…]
See Backends for setup and
the HL_* environment variables.
Development
Development uses uv and a Rust toolchain.
uv run rebuilds the extension automatically when Rust sources change.
Want to help? See the contributing guide. Releases are cut from tags. See RELEASING.md.
Status
What works today: pin, check, sync, and launch for the
supported harnesses, localize, manifest and
lockfile schema v1, a content-addressed store, eval packs (hlock evals) with graders, the
reference provider and harness, grid search with Pareto selection, upgrade
(plan/apply/rollback), tune across the local, devbox, and cluster backends, and the
meta harness. The design specs describe the full design,
much of which is still on the roadmap.