# Measuring the Everyday

By Morgan Linton · Published 2026-11-01 · No. 1 · 766 words · https://myrovingmind.com/essays/measuring-the-everyday/

This morning I'm working on a new eval suite for [VulcanBench](https://vulcanbench.com), Routine v2.

I can't stop thinking about a gap that exists in benchmarking today.

And I don't think I'm effectively filling that gap yet.

I think what me, and many other benchmarks find ourselves doing is trying to challenge the frontier.

To be clear, I think we should all keep doing this. I know for me and many others, building eval suites that truly challenge the ever-changing frontier is one of the most interesting things you can do right now.

It is very likely, the hardest thing I've ever done in my life, and I'm really loving how much harder it gets each month. In many ways I find something so satisfying about seeing my eval suites get saturated, it pushes me to find new ways to experiment and learn about models.

At the same time, I think the challenge with most benchmarks today, including my own, is that we tend to focus too much on trying to give models super hard tasks. Like I just said, a new set of models comes out, an eval suite saturates, and it's off to try to build a harder one.

But what is still missing is real signal around what models we all need for just normal daily coding tasks.

This was originally my goal with VulcanBench, then I got too interested in challenging the frontier and my core eval suite, now Frontier v4 became my focus.

Now I'm working on v5 because I'm addicted to challenging the frontier and really can't stop at this point...but I also want to get back to my original mission.

So I'm working on a new kind of benchmark, something I think is uniquely different from anything else out there.

The goal is not to challenge the frontier, because most of the daily coding work engineers are doing, isn't really that challenging to the frontier, it's normal daily work.

And I think many people are very lost now trying to figure out what model and effort level they need for regular daily work.

While model routers exist, they are in a very nascent stage today. I don't think there's any model router that has the sophistication to know, ah, this is a medium-sized Python repo, doing mostly Pandas stuff, let's use this model and effort level.

I just don't think current model routers would know the difference between this, and say, a medium-sized Python repo, mostly doing say supervised ML with SciKit Learn.

Instead, model routers today mostly just pick an orchestrator, executor, and code review model, that will be cheaper than someone using one model for all three. Sure, it's better than just using Opus 5.5 High in Claude Code for everything, but it's not actually optimized in any way to the codebase size, programming language, etc.

I really want to be able to help people understand. Okay, what model do I want to use for planning, execution, and code review for a repo of a specific size, with a specific programming language, and for certain types of tasks leveraging specific libraries.

This also means rethinking how to score benchmarks, because every frontier model should be able to pretty much ace most routine tasks. So instead we need to look at things like accuracy, cost, time, and code quality, all together vs. just looking at something like accuracy and cost-per-task on a pareto chart.

All of what I have shared above, will become the Routine v2 eval suite, along with a new benchmark/scoring system designed to provide signal on routine tasks, broken down by language and repo size.

My goal is that I can essentially create a system where you can select your codebase size and programming language, and rank the difficulty of the tasks you're doing, and get a model and effort level out of it.

For example, you might select:

- Repo size: Medium
- Programming language: Python
- Difficulty: Easy

and it might recommend Opus 5.5 Medium for planning, GPT-6.1 Terra Medium for execution, and DeepSeek V4.1 Flash High for code review.

This would be very different than if you used most of the model routers out right now, they might never use GPT-6.1 Terra Medium. They might always use the same model at the execution layer, and yes, it's 30% or 40% cheaper than if you just used Opus 5.5 High for planning, execution, and code review, but it's not actually the optimal model combination.

As usual, I like getting things out of my head, and into the world, so here it is, out there, in the world now.