Notes from building Metis in public — what we tried, what broke, and what worked.
Every entry so far ran on borrowed weights. Today a model trained from scratch on this MacBook — on our own code, for zero dollars — answered inside OpenCode. It's tiny, it's bad, and it changes what this project is.
We tried to push Metis's founding bet — that verifying is cheaper than generating — to its logical extreme, and measured it. The bet is real, but it splits in two: recognizing a true answer is free, rejecting a plausible false one is not, and the second half doesn't scale with model size.
If the architecture does the work, the model should be replaceable. We swapped the 1.7B generator for a 0.6B one, 62% less model, and measured what broke.
We built a harder benchmark to test whether 0.6B really equals 1.7B. It doesn't. But the bigger surprise was an architecture bug that was quietly costing the larger model nine right answers.
The fast path was answering questions it had no business answering. The fix wasn't to remove it — it was to teach it which questions are actually shortcuts.
Frontier models waste most of their parameters storing facts. What if you put the facts somewhere else?
Before writing a line of code, you have to be honest about what fits in 4 GB and what doesn't.
The most important finding in the research: a small model with retrieval routinely beats a model 25 times larger without it.
The first version that actually works end to end: local inference, retrieval, verification, citation.
A single configuration variable was turning a 3-second answer into a 7-minute one. This is how we found it.
The research finding that makes the whole GVS architecture work: verifying a claim against evidence is fundamentally easier than producing a correct one from scratch.
We ran qwen3:1.7b bare vs inside Metis on the same 14 questions. Same weights, same hardware, different architecture.
More entries coming as the build progresses.