Undercut for Continue
Undercut is a free, MIT-licensed routing rule you drop into .continue/rules/ — the folder Continue auto-discovers on every session and folds into the system message — cheap tier first, escalate only on evidence, never on a vibe. Continue is bring-your-own-model by design, so it has no single built-in cost dial to compare against; this exists because the same overpay-by-default pattern we measured elsewhere in the agent ecosystem (one self-reported ccusage breakdown from a different agent showed 93.8% of tokens going to the top-tier model by default, anthropics/claude-code#27665 — one account's data, not Continue's own) shows up anywhere an agent defaults every task to its strongest model.
How this maps onto Continue
Continue's documented mechanism is a project-level .continue/rules/ folder at the workspace root: any Markdown file dropped in there is auto-discovered when Continue starts and concatenated into the system message for Agent, Chat, and Edit requests alike — no config-file edit required (per Continue's own rules docs). Each rule file carries YAML frontmatter — name (required), plus optional description, globs, regex, and alwaysApply — and files load in lexicographical order, so a numeric prefix (01-…, 02-…) controls sequencing when you're running more than one. Undercut's SKILL.md already ships a name: and description: frontmatter block for other clients, which happens to satisfy Continue's required fields as-is — no rewrite needed, just a copy.
Continue's config.yaml also supports referencing a rule with a rules: block (uses: author/rule-name for a published Continue Hub block, or uses: file://path/to/rule.md for a local file) — a second, more explicit path if you'd rather wire it through config than rely on folder auto-discovery. Both read the same Markdown file; Install below covers the folder path, since it needs no config edit at all.
Undercut's tier names — cheap, standard, frontier, apex — are generic on purpose. Continue is explicitly bring-your-own-model — you wire up any provider (Anthropic, OpenAI, local Ollama models, and more) in config.yaml yourself, so there's no single fixed lineup to map onto. models.md gives the rule of thumb instead of a fixed slug: cheap resolves to the smallest/fastest model in whatever provider lineup you've configured, standard to your default work model, frontier to the highest-reasoning model you have access to, and apex is reserved for the single batched tie-break call when the ladder is exhausted.
Nothing about this sits between Continue and whichever model backend you've configured. It's plain markdown text Continue reads into its system message, same as any other rule — no proxy, no network hop, nothing to route around if you delete the file.
Install for Continue
Run this from the repo root. Continue auto-discovers every Markdown file under .continue/rules/ and loads it at session start — no config.yaml edit needed.
If you'd rather wire it through config than rely on folder auto-discovery, add a rules: entry pointing at a local file — per Continue's own config reference, this is the same uses: file://… syntax used to pull a published Continue Hub rule block.
What's still unverified: skills.sh doesn't currently list Continue among its supported install targets, so npx skills add undercutsh/firstpass has no confirmed Continue path yet — use Option 1 above instead, directly confirmed against Continue's own rules docs. Whether a global, machine-wide rules folder (analogous to a home-directory config) exists alongside the project-level .continue/rules/ is also not documented anywhere we could find; treat this as project-scoped only until Continue's docs say otherwise.
testing/README.md and the raw JSON in testing/results/node src/main.js --mockfirstpass shows up as an active rule before starting mechanical workZero lock-in. It's markdown text Continue reads — delete the file and you're back to status quo.
How it works
The Undercut Rubric · v1This is a named, versioned spec — not internal logic we could quietly change. When the rubric changes (a new flag, a different cap), the version number moves and the changelog says why.
Every unit of work gets scored against six flags, then assigned the cheapest tier that can plausibly handle it. It only moves up a tier when something objective proves it needs to — a failed check, a measured disagreement, an explicit uncertainty flag. It never moves up on a guess, and it never moves back down mid-task.
0 flags → cheap · 1–2 → standard · 3+ or any ownership/judgment call → frontier. Apex only when you can write one sentence stating why the marginal intelligence pays for the cost.
Cheap-to-verify ⇒ cheap-to-generate. If output can be checked mechanically, it starts at the lowest tier regardless of how hard it looks — verification catches failure. Only unverifiable work needs to start high.
The next tier up gets only the failed or uncertain items, plus verification notes. It resolves the residue — it never redoes the batch.
Never de-escalate mid-task. Max one retry per tier. Anything still unresolved goes to a single batched apex tie-break call. One hard file in a 700-file job doesn't drag the other 699 up a tier.
unit of work
|
6-flag rubric
|
+---+----+
| 0 flags|--> cheap
| 1-2 |--> standard
| 3+/own |--> frontier
+---+----+
| fail x2 / disagree / uncertain
v
escalate +1 tier
(residue only)
|
still unresolved?
v
single batched
apex tie-break
Why it holds up
Even when the rubric flags are scored imperfectly, the escalator still routes work to the right tier almost every time — because a wrong flag only ever costs one extra cheap attempt, never a wrong answer or a big bill.
A stock dispatcher model reproduces the rubric flags imperfectly — Haiku hits 90% agreement, Sonnet 93%. The weakest flag (format-strict) is only 60%. None of that matters: under the shipped policy, both dispatchers still route 100% of units to the correct tier. A wrong flag changes the ladder cap, never the base tier — worst case, one extra cheap attempt.
Every rule is a property of the unit of work — verifiable, ambiguous, blast-radius — never a specific model's known weakness. Vendor cards go stale as models change; work properties don't. It's also hard-won — a format-strict rule that worked on Anthropic backfired on Gemini, which is exactly why the rubric no longer encodes per-vendor behavior.
Honest limits
Not a proxy, not a gateway, doesn't auto-flag in production — and Continue's own reliability at scoring the flags hasn't been separately measured the way Claude Code's has (see above); treat that as unverified until tested. It also doesn't pick a model for you: Continue is bring-your-own-model, so resolving each tier to a concrete provider and model is still a choice you make in Continue's own config.yaml. And it doesn't promise a dollar figure for your workload. Full list of general limits, with the finance/procurement note and the paid-tier disclosure, is on the main page.
Nothing about this page expires. What does keep happening is the token bill, one session at a time, on whatever Continue is currently doing with mechanical work.