MoM: One File That Picks the Right Model

Every AI coding tool asks you to pick one model, and then it uses that model for everything. The hard debugging session and the typo fix both go to the same brain, at the same price. I think that is the wrong shape, so I built something else.

MoM stands for Model Manifest. It is a small YAML file, mom.yaml, that sits in your repo and decides which model handles each problem. You name a cheap model for everyday work and a strong one for hard work, write a few rules anyone can read, and the tool follows them. The whole policy fits on one screen.

The test

I wanted a number before I announced anything, so I ran a benchmark called HumanEval. It is a set of 164 small coding problems, and each one has tests, so a model’s answer is either right or wrong. No judges, no vibes.

First I ran every problem on Claude Opus 5, the strongest model on my board. It solved 163 of the 164 problems. The run cost $1.34.

Then I ran the same 164 problems through one 15-line mom.yaml. Every problem started on Qwen3 Coder Next, a model that costs about 40 times less than Opus. When a problem failed its tests, the file escalated it to Claude Sonnet 5. When it failed again, it went up to Opus.

Eight problems escalated. One of them needed Opus. The other 156 never touched an expensive model at all.

The result: all 164 problems solved, for 9 cents.

The file beat the strongest single model and cost 93 percent less. Not because any single model got smarter, but because most problems are not hard, and the file only paid for intelligence where it was needed.

What the file looks like

This is the entire policy from the benchmark run:

mom: "1.0"

models:
  everyday:
    prefer: [qwen/qwen3-coder-next]
  thinker:
    prefer: [anthropic/claude-sonnet-5]
  best:
    prefer: [anthropic/claude-opus-5]

start-with: everyday

switch:
  - when: stuck          # tests failed
    use: thinker
  - when: { stuck: 2 }   # still failing
    use: best

That is it. You can read every line, change a number, commit it, and share it with your team. The design bar I set for the spec: someone with no programming background should be able to open another person’s mom.yaml, understand it, and edit it.

Inside a live coding session, MoM goes further than waiting for failure. A small, cheap model reads each incoming message and routes it before any work starts. A typo fix stays on the cheap model. A request to redesign a subsystem goes to the strong model on its first attempt. Rules always win over the router, and if anything errors, the tool falls back safely to your default.

Why a file and not a product

There are routing products you can pay for. They sit between you and your models, and you trust their judgment. MoM is the opposite: the policy is yours, it lives in your repo, and every switch is recorded with its reason. When you ask why the expensive model ran, the answer is a line in a log, not a shrug.

MoM is an open protocol, not a feature of my tool. The spec, a JSON schema, and starter files are public, and any harness can implement it. Aster, the coding agent I build, is the reference implementation. If another tool reads the same file and follows the same rules, that is the point.

The prices that make this matter are not subtle. On my benchmark board, two models from the same family scored identically, and one costs 31 times more than the other. As long as that spread exists, a readable file that picks the right model per problem pays for itself on the first day.

The spec lives in the Aster repository, under specs/mom.md.