[ docs · concepts ]

The ladder & rungs

The ladder is Grist's model lineup, organized the way the money works: four cost-tiered rungs, each holding the best model in its band. You work with rung names — never vendor model ids.

The rungs

RungForCharacter
cheapestRoutine edits, renames, test fixes, formatting, small scriptsThe default. Most tasks in a real codebase live here.
mediumEveryday features, multi-file changes with a pattern to followThe workhorse for substantive but well-understood work.
frontierHard diagnosis, cross-subsystem design, subtle bugsException, not habit — the gate escalates only on evidence.
premiumThe hardest, highest-stakes problemsThe top band, reserved for when nothing else will do.

Each rung is a cost band, not a capability class: the model behind a rung is whichever model currently wins that band, and it can change without your workflow changing. That's the point of naming rungs instead of models — your prompts, scripts, and habits survive model turnover.

Who decides

The Jev gate decides, once per run, from the task itself. Subagent delegations re-gate under the parent's rung as a ceiling, so breaking work down never inflates its price.

You can pin a rung when you really mean it:

grist run -m grist/frontier "diagnose the double-charge in checkout"

Pinning is an override, not the workflow — left alone, the gate is better at this than habit is.

Your ladder, your key

The client — CLI, TUI, desktop, API — only ever names rungs. Vendor model ids exist in exactly one place: the gateway's resolution of rung to model, where they can be governed, priced, and swapped.