kkrlstrm/runtune

**Your agents already generate the data needed to improve their runtime. RunTune closes the loop.**
RunTune is a runtime learning loop for coding agents. It brings evidence from Claude Code,
Codex, Cursor, Google Antigravity and model-router traffic into a common process for improving
the harness around them. Different agents produce different traces; RunTune turns their repeated
successes and failures into proposed capabilities, constraints and routes, then verifies and
measures approved changes.
- **Success → capability.** Working patterns that repeat become skills, CLI paths, specialized
sub-agents, or better routes.
- **Failure → constraint.** Failures that repeat become guard rules and routing checks.
- **Change → measurement.** Every adopted change is measured against a control, then kept,
reviewed, or retired.
**It tunes the harness, not the model.** RunTune doesn't teach an agent to remember yesterday.
It changes tomorrow's runtime based on what happened yesterday.
No weight training, and no autonomous self-modification: RunTune proposes evidence-backed
changes, and a human decides what enters the runtime.
RunTune is the feedback loop of an internal platform for GTM engineers.
It reads what the agents actually did, proposes the narrowest change that would fix a repeated
failure or capture a repeated success, and measures each approved change against a control. It
was developed against about 238,000 recorded tool calls and model requests from one team's
production agents, and its evidence doc keeps the five recommendations that
changed once checked against production.
The loop, and what it tunes
A coding agent is a model inside a harness: the skills it can load, the sub-agents it can spawn,
the guards on its tools, and the routes its model calls take. The model is someone else's to
train; the harness is yours to tune.
This is the difference from agent memory: the next agent runs in a different environment,
whether or not it recalls anything.
Observability should close the loop
Most agent observability ends at a dashboard: runs → traces → a person reads the dashboard.
Traces tell you what happened. RunTune asks what the runtime should learn from it, turns the
answer into a gated, approved change, and then checks on future runs whether the change worked.
Try it in 60 seconds
This uses only the transcripts already on your machine: no accounts, no database, no network.
To keep it running, runtune install prints the hook for Claude Code, Codex, Cursor and Antigravity (you
paste it, because RunTune never edits host settings), and runtune schedule --install sends a
weekly digest, reading Cursor's store first when Cursor is installed.
From local loop to continuous operation
RunTune can stay on your laptop, or run continuously around a deployed agent system. On a small
VM it reads evidence from a shared telemetry database that your agents' recorders write to
(warehouse sources), snapshots the model provider's bill daily, and derives
and reviews weekly. It sends each digest to Slack or email, and every hour it checks for a
decision. The first valid answer on any channel wins, and
the other channels are told it was handled. An approved change becomes a branch and a pull
request against the agent's harness, and measurement starts only once that change is merged.
RunTune needs permission to open a pull request, not to change what is deployed. Git remains
the deployment boundary. Channels and deployment →
What it can change
| from | artifact | what it writes |
|---|---|---|
| repeated failure | **constraint** | a guard rule, capped at what its failure rate supports (nudge, deny, or block) |
| repeated success | **capability** | a SKILL.md naming the commands that have worked, for code agents keep re-deriving |