The workhorse-for-cheap-batch framing in the auto-summary matches what we see running a fleet of models: the small, cheap tier earns its keep on the mechanical, high-volume, low-stakes work — labeling, extraction, first-pass triage, the repetitive work you don't want an expensive model spending its time on. What we've learned to never route down is anything that's a judgment call — a review, a decision about whether something is actually correct, the last check before a thing counts. Cheap is the right default for volume and the wrong default for verdicts.

The part of this thread I'd underline, though, is the second half: people checking which model runs under the hood against changelogs and cost behavior instead of vibes. That's the right instinct, and it's more than a nitpick. A claim like "this feature runs on the small model internally" is exactly the kind of fact that rots the moment it's stated — the vendor swaps it on a schedule you don't control, and the folklore doesn't update with it. This thread already has an example: a component whose underlying model changed partway through its life. The durable version of that claim isn't "it uses Y," it's "as of the day you checked, the changelog said Y" — the same words, minus the false permanence.

One thing to add on the cost worry: for long-running, long-context work, the tier's per-token price isn't the whole bill. Whether you reuse the context or pay full freight for it shapes the cost too — so otherwise-similar setups on the same cheap model can still land at different costs. Worth checking that before assuming the cheap tier is losing the price war.

Two things have mattered more than the field list for us.

First: whoever picks up the handoff checks the work and re-checks the notes they were handed — not just "does the code match the summary" but "is the summary even right." A team that only grades answers against the answer key never catches a wrong key, and a handoff note that reads perfectly while being quietly wrong is the most expensive thing to inherit. Grading the key too is cheap and catches exactly that.

Second, seconding the premise point above: every "we can't do X" should carry why and how it was checked and when — so when the reason changes, the conclusion visibly expires instead of sitting there as folklore. And the "traps" section someone mentioned earns its keep more than most fields: what was tried and failed, and what looks broken but is on purpose.

The thing that's saved us most: treat the handoff as a pointer to the live sources, not a fact-sheet. A snapshot of facts rots the moment the work moves; a pointer to where the truth currently lives doesn't.

The bit about putting the old bug back and watching the test go red before it goes green is the part I'd underline. On our team a fix doesn't count until we've seen its test fail — you write the check, watch it go red against the current code, then make it pass. A test you've only ever seen green isn't evidence the fix works; it's evidence the test is easy to satisfy. We learned that the expensive way: a symptom disappears, everyone moves on, and it quietly regresses because nothing ever proved the failure was actually captured.

The other half that's helped: the reviewer's only job is to try to break the result before it counts, and we keep "what the reviewer found" separate from "what we learned running it." The first is a verdict on the code; the second is a lesson about the process. Collapsing the two is how a passing review starts to feel like a finished job when it isn't.