The ladder
Much of what the runner and the weekly jobs do is bounded text work: summarise a recording, digest a session, propose a command for a repeated prompt, name an automation candidate. That work goes to a local model first, and to Claude only when the local answer fails.
A loaded local model answers first, through the gateway of 1-llm. A deterministic check, written for the task, reads the draft. Haiku judges every draft until the task has passed 5 judgments in a row, and one in five after that. A draft that fails its check, or a local call that fails, gets one more local try. A second failure, a failed judgment, or a local model that cannot be used sends the call to Haiku, which answers instead. Two failed judgments in the last ten demote the task to Haiku for 14 days. Every call leaves one line in a log, and that line never holds the input or the answer.
The recording notes, the transcript digests, the prompt miner's proposals and the automation finder's text all go through it.
commit-push
commit-push turns a commit into one command: it stages, writes the message, commits and pushes in one call. The session gives it an intent in one sentence, and the message comes from the first free or plan-included cloud model with quota, through 1-llm, else from Haiku, else it is the intent itself. A commit never waits on a model.
Nothing from a repository marked as work or from a notes repository goes to a third-party cloud, and neither does a diff that looks like it holds a secret. A place the gate does not know fails closed. Hooks always run, and a push goes only to the branch of the same name, never forced. Exit 3 means the commit was made and the push failed, and the next run pushes it.
What it does not do well yet is on its own to-do list. The cloud rewrite sometimes swaps the commit's type or scope, so a fix can come out labelled a feature. And when a draft keeps less than half of the intent's words, a repair step appends the whole intent. That counts shared words, not meaning, so a draft that kept the reason in other words says it twice. In one week, 206 of one model's 450 commits were repaired, and 3 of the 6 checked had already said it.
The lane helper
A lane session has bounded chores of its own. lane_helper takes six of them: a commit message, a summary of a diff, review findings on a diff, the triage of a failing test, an index line for a file, and a lookup that answers from git grep hits with a file and line for each claim. Each goes to the first model that is listed, allowed and answers: the local models already loaded, then the gateway's free cloud models, never a paid one or one that would switch the local model. A deterministic check reads every answer.
A cloud model is refused where the repository may not leave the machine, or where a line that looks like a secret would be sent. All the tries share 100 seconds. When no model answers, the helper prints HELPER UNAVAILABLE: <why> -- do this step yourself and exits 3, and the session does the step itself. When a log is set, it keeps one line per chore, and never the text.
suite-run
suite-run runs a Python unittest suite and prints one line: the count, OK or FAILED, and the failing test ids. On a failure it keeps the whole output in a log file, and a green run keeps none. -n runs a suite several times and reports one that fails only some of the time as flaky.
It replaces a pipeline my sessions typed about 50 times a week, often twice: once for the verdict, and once more to read what failed. The automation finder found the pattern, and a session of mine built it.