Undercut for Qoder
Undercut is a free, MIT-licensed policy file that drops straight into Qoder's own .qoder/skills/ directory — no adapter, no cross-tool alias. Cheap tier first, escalate only on evidence, never on a vibe. Qoder's agentic platform spans an IDE, a JetBrains plugin, and a CLI, all wired up to whichever model you've configured; the rubric doesn't care which one that is, only whether the unit of work is mechanically verifiable.
How this maps onto Qoder
Per Qoder's own Skills documentation, which the docs say applies identically to Qoder IDE and Qoder CLI, a skill is a folder containing a SKILL.md with required YAML frontmatter — name (lowercase letters, numbers, and hyphens, max 64 characters) and description (max 1,024 characters, used by the model to decide when to load the skill). Skills live at .qoder/skills/<name>/SKILL.md for a project or ~/.qoder/skills/<name>/SKILL.md globally, with one documented precedence quirk worth flagging: unlike most other agents on this site, Qoder's user-level skill wins over a project-level skill of the same name, not the other way around. The full body loads only when Qoder decides the current task matches the description; you can also invoke a skill manually with /skill-name, and an existing session needs /skills reload to pick up a skill added mid-session.
Qoder also documents a separate, always-on Rules mechanism — markdown files under .qoder/rules/, shared via git, capped at 100,000 total characters across all active rule files (excess is truncated), with four apply modes: Always Apply, Model Decision, Specific Files (glob patterns), or Apply Manually via @rule in chat. Separately, Qoder's docs say Qoder now recognizes a root AGENTS.md automatically with no extra configuration — but rules content takes precedence over AGENTS.md content if the two conflict. A scored routing rubric is conditional, invoked-by-relevance guidance rather than a blanket always-on preference, so the native Skills path — not Rules or AGENTS.md — is the documented fit this page installs to.
Undercut's tier names — cheap, standard, frontier, apex — are generic on purpose. Qoder isn't tied to one model vendor, so models.md resolves each tier to a real model for whichever family you've configured. Nothing about this sits between Qoder and your model provider — it's a policy file the agent reads at dispatch time, no proxy, no network hop, nothing to route around if you remove the skill folder.
Install for Qoder
Clone or download undercutsh/firstpass, then copy skills/firstpass/ into .qoder/skills/firstpass/ at the project root. The frontmatter already matches what Qoder's Skills docs require (a name matching the folder, a description under the 1,024-character cap), so nothing needs rewriting.
Qoder also reads a user-level skills root: ~/.qoder/skills/<name>/SKILL.md. Per Qoder's own docs, a user-level skill takes priority over a project-level skill of the same name — the reverse of the usual "workspace wins" rule — so if you also install a project copy later, the global one is what actually loads.
No npx skills add path yet. skills.sh doesn't list Qoder as a supported install target as of this writing — Option 1 or 2 above, both copied directly from Qoder's own documented .qoder/skills/ path, are the confirmed way in for now.
Prefer Rules or AGENTS.md instead? Qoder's docs say it now recognizes a root AGENTS.md with zero configuration, and separately supports always-on .qoder/rules/ files (100,000-character cap across all active rules, excess truncated). Either works if you'd rather keep everything in one convention — but rules content wins over AGENTS.md on conflict, and both are always-on rather than the on-demand, description-matched loading Skills gives you. We've checked all three paths word-for-word against Qoder's published docs, but haven't run this skill inside a live Qoder session ourselves end-to-end — see Validate below.
testing/README.md and the raw JSON in testing/results/node src/main.js --mockZero lock-in. It's a policy Qoder's agent reads — delete the folder 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 enforce anything at the network layer, and doesn't auto-flag in production — Qoder's agent scores the flags itself (measured robust to getting them wrong, see above). Doesn't promise a dollar figure for your workload — savings are workload-dependent, and real workloads escalate more than benchmarks. Every figure on this page is an observation from our tasks and our graders, not a guarantee about your codebase — verification is not proof, it's a reproducible data point you can run yourself. The Skills, Rules, and AGENTS.md mechanics described above come straight from Qoder's own docs, including the user-overrides-project precedence quirk, but we haven't independently run this skill inside a live Qoder session end-to-end — treat that specific claim as unconfirmed until you check it yourself with the steps above. 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 Qoder is currently doing with mechanical work.