Tuning tman for Biome
Native speed; supervise it for uniformity, and pin --error-on-warnings.
Recommended starting caps
| cap | start at | what it answers |
|---|---|---|
stall | 5m | hang backstop — no output and no CPU/IO activity for this long |
max-time | 5m | wall-clock budget — the only cap that bounds a run that is working but will never finish |
max-mem | unset — opt in only if it has hurt you | RSS ceiling across the process tree |
max-parallel | 4 | slots per name-and-directory bucket |
These are starting points derived from how Biome behaves, not measurements of your machine. Every one of them should be replaced by a number you took from your own runs — the last section on this page is how.
alias "lint" {
command "npx"
args "biome" "ci" "."
max-time "5m"
max-parallel 4
}Biome is in the same class as Ruff: fast enough that the caps are a backstop against a pathological environment rather than a control on resource use. The interesting choices are about which subcommand the alias pins.
`biome ci`, not `biome check`
biome ci is the non-mutating, fail-on-any-diagnostic mode. biome check --write fixes files in place, which under an agent means the lint alias silently rewrites the working tree and then reports success — you get a green from a command that changed your code rather than one that judged it.
That is the same failure shape as a snapshot test that writes instead of comparing, and as a scaffolded alias that echoes instead of running. In each case the command reports success without doing the work it was asked to do, which produces no signal to act on — so it survives indefinitely.
Give formatting its own alias
One command answering two questions gives you one exit code for two different fixes. A separate format alias running biome format --check keeps "this file is badly formatted" distinguishable from "this code violates a rule", which is exactly the distinction an agent needs to act correctly.
Turn the starting point into a real number
Everything above is derived from how this tool behaves, not from your machine. The numbers that matter come from your own runs, and getting them takes one command:
tman status --json | jq '.runs[] | {name, exit, duration_ms}'Set max-time from the slowest successful run you are willing to wait for, with real headroom — a cap that fires on healthy work teaches everyone to raise the cap, and after a few rounds of that it bounds nothing. Set stall from the longest stretch the command legitimately produces no output and no CPU, then double it.
Exit 124, 125, and 126 are findings, not flakes. 124 is a wall-clock timeout, 125 a stall, 126 a resource cull. Widening the cap that fired is the right response only after you know why it fired — the first two times a suite trips
max-mem, the interesting question is what is holding the memory.
Frequently asked
Should the tman lint alias run `biome check --write`?
No. A writing lint rewrites the working tree and then reports success, so you get a green from a command that changed your code rather than one that judged it. Pin `biome ci`, which is non-mutating and fails on any diagnostic.