Blends: I Think We’re Using Coding Models Wrong

I spend an unhealthy amount of time bouncing between Codex, Claude, Cursor, Grok and whatever new model everybody decides is amazing that week, and the conversation around all of them is usually the same; which one is actually the best? Is Fable better than Astra, is Sol MAX actually the better value, is Grok underrated, should I just pick the strongest model available, crank reasoning to max and let it go?

Maybe, and honestly I do that all the time, but the more I use these tools the more I keep coming back to a different question. Why are we using the same level of intelligence for every part of the job?

Just to get this out of the way, I’m obviously not claiming I invented subagents or agent orchestration. Claude Code already has subagents, Codex already has delegation and agentic workflows, and pretty much every serious coding harness is moving in this direction. An agent giving another agent a task isn’t the interesting part to me anymore.

What I’m interested in is what happens after delegation itself becomes normal, when you stop asking “can this agent spin up another agent?” and start asking which model should be doing which part of the work, how much context should it actually have, and how much intelligence is that part of the job worth paying for?

That’s what I’ve been calling Blends.

The basic idea

The idea is pretty simple. Use the really capable, expensive models for the parts where judgment matters, then push specific execution work down to cheaper models once the problem has been understood well enough that you don’t need to pay frontier prices for every step.

And beyond the fact that The Sopranos is the best show ever made, it also happens to use a pretty efficient organizational structure. Everybody has a lane, responsibility gets pushed down, useful information comes back up, and the guy at the top isn’t personally going out and handling every little thing himself. I felt like the terminology fit what I was trying to do better than calling everything a planner, coordinator, executor, worker, manager, or whatever other boring name we give agents.

The main session thread is the Consigliere.

If I’m already three hours into a Codex session, that session knows what I’m building, what I rejected an hour ago, what weird shit we found in the repo, what I specifically told it not to touch, and why some idea that looked good earlier turned out to be wrong. Creating another frontier model above it just so that model can reread a compressed version of everything and become a second boss doesn’t make much sense to me. The main thread already has the highest value context and should keep the overall job.

So the Consigliere is something at the top end of the stack; Astra MAX, Fable MAX / 5.1, Sol MAX, whatever proves best for the kind of work I’m doing. Its job is to understand the full problem, decide how risky it is, figure out whether it should even delegate anything, decide which parts deserve their own owner, and set the boundaries for those missions.

Underneath that are Capos, and this is one part I changed my mind on while thinking through this.

My first instinct was that the models should simply get cheaper as you go down the hierarchy; smartest model at the top, slightly weaker model underneath it, really cheap models at the bottom. The more I thought about what the Capo actually has to do, the less sense that made.

If one Capo owns auth, I want that model to understand auth extremely well. It has to figure out what actually needs to change, recognize assumptions that turned out to be wrong, decide what needs to be investigated, turn what it learns into good assignments, recognize bad work coming back from its workers, and change direction when necessary.

That is still frontier-model work.

So I think the Consigliere and Capos can come from basically the same pool; Astra MAX, Fable MAX / 5.1, Sol MAX, whatever ends up proving best. The difference between them isn’t really intelligence, it’s how much of the total problem they own.

Then you get to the Soldiers, and this is where I think the economics start getting interesting. That pool looks more like Luna MAX, Claude Opus 4.8, Grok 4.6, and potentially Kimi or GLM when the assignment is scoped tightly enough and the context is good.

The Soldier doesn’t need to be dumb. It just doesn’t need to be the most expensive model in the building every single time.

What actually happens after a Capo gets a mission?

This was one of the first things I had to work through because there’s a really stupid version of this where a Soldier tells the Capo what it found, the Capo tells the Consigliere, the Consigliere decides what to do, then tells the Capo, who tells another Soldier, and suddenly we’ve created an expensive telephone game that is slower than just letting one good model do the whole thing.

I don’t think that’s how it should work.

The Consigliere should give a Capo a mission with authority, not a list of individual instructions.

Say we’re doing an auth migration. The Consigliere might tell the auth Capo something along the lines of: own the auth migration, preserve our internal user IDs and existing sessions if possible, figure out any billing dependencies before changing the identity model, and come back to me if the solution requires changing a shared contract that affects another workstream.

At that point the auth Capo owns auth. It doesn’t need to ask permission every five minutes.

The Capo may start by reading the important code itself, because sometimes sending another agent to read five files and explain them back is actually more expensive and slower than just reading them. At the same time, it may see two or three questions that are easy to investigate in parallel and send Soldiers out as scouts.

One Soldier could trace everywhere the external provider ID is being treated like our own internal user ID. Another could trace session creation and refresh behavior. Another could inspect whether billing stores or depends on anything coming directly from the auth provider.

Those Soldiers come back to the Capo, not the Consigliere.

Now the Capo has actual information instead of assumptions and can form its own implementation plan. Maybe it discovers that billing barely depends on auth and the existing internal user ID can stay completely intact. Great, the Consigliere doesn’t need a status report explaining every file that was opened. The Capo can move into execution.

This is where it starts giving the Soldiers much more specific work. Luna MAX might be told to implement the new provider adapter behind an existing interface, only touch three files and run a specific test suite. Opus 4.8 might get something where I want a little more judgment inside the assignment. Grok 4.6 might get a debugging or implementation task that benefits from more independent exploration. Kimi or GLM might handle a clean implementation, test-writing or inspection job if that’s where the data says they actually perform well.

The important part is that none of those models are being told “migrate auth.” The Capo already did the thinking required to turn “migrate auth” into jobs with a much smaller decision surface.

Then those jobs come back to the Capo again. The Capo reviews the work, checks whether the worker actually satisfied the assignment, looks at the test results, gives the worker more context if something was missing, or retries the job with a stronger Soldier if the first one clearly wasn’t getting it.

The Capo owns that mission through completion.

The Consigliere only gets pulled back in when something stops being local to that mission. If the auth Capo discovers that preserving our user IDs is impossible without changing the billing schema, now it affects another part of the system and the decision goes back upstairs. The Consigliere can look at the larger picture, talk to the billing Capo if one exists, change the global plan and send the updated decision back down.

That feels much more efficient to me than having every finding travel through the entire hierarchy.

The point of the hierarchy should be to reduce communication, not create more of it.

So the full flow is basically this

The main session starts with the original request and decides whether the work should stay in that session or get broken apart. If it is worth breaking apart, the Consigliere creates actual missions, not tiny tasks, and gives those missions to Capos with a goal, constraints, relevant global context, a budget and clear boundaries around what they can decide for themselves.

The Capos explore their areas, either directly or with Soldiers where parallel investigation makes sense. Once they understand the mission well enough, they turn the findings into execution jobs and send those jobs to the Soldier pool.

The Soldiers execute, test and report back to the Capo. The Capo reviews the results, retries work when needed and integrates its own mission into one coherent result.

Only when something crosses mission boundaries, changes the global architecture, substantially changes risk or requires a tradeoff between two different workstreams does the Consigliere come back into the decision.

Once the missions are done, the Consigliere can look at the completed workstreams together and decide whether the whole thing fits. If this was one Capo doing one contained feature, there may not even need to be another big integration step. If three Capos changed three connected pieces of the system, then maybe that final integration does deserve another frontier pass.

And after the intelligent decisions are made, normal software handles normal software things. Git, worktrees, commits, file locks, queues, test commands and budget enforcement don’t need an agent sitting around thinking about them.

That’s the actual flow in my head.

Why bother?

Right now I can give a strong coding agent a feature and it can basically do all of this itself. It reads the request, explores the repo, figures out what matters, makes architecture decisions, writes code, runs tests, debugs its own mistakes, rereads files, changes direction and eventually gives me something that usually works.

That’s amazing, plain and simple, and if one agent continues being the best answer for a task then Blends shouldn’t get in its way.

The thing that bothers me is that we’re using roughly the same level of intelligence for a bunch of steps that clearly don’t have the same requirements.

“Figure out how to replace our auth provider without breaking existing users, billing or sessions” is a hard problem.

Once somebody has already solved that problem conceptually, “change these two functions, preserve this interface and run these tests” is not the same problem anymore.

If a really strong model can convert one vague, expensive problem into six jobs that Luna MAX, Opus 4.8, Grok 4.6, Kimi or GLM can reliably execute, I want to know whether that is actually cheaper and just as good as letting the frontier model carry every single step itself.

Maybe it is.

Maybe it isn’t.

That’s what I want to measure.

Context is part of it, but not the entire idea

When I first started thinking about this I put a lot more weight on context savings. Long coding sessions get huge and obviously there’s some value in not handing every agent every conversation you’ve ever had.

That argument is still part of it, but it doesn’t really account for how much better the providers are getting at managing long sessions themselves.

Claude already uses compaction to summarize older parts of a long conversation instead of carrying every raw message and tool result forever, and Claude Code can keep subagent exploration inside separate contexts so the main session doesn’t necessarily need every single thing a worker saw.

OpenAI is also moving beyond the normal idea of repeatedly summarizing old context. With the newer Astra work in Codex, they’ve been experimenting with keeping notes across context windows while still allowing the model to retrieve information from older windows later, which matters because every time you compress something there is always a chance that a detail you eventually need did not survive the summary.

So I don’t think the argument for Blends is that the providers don’t know how to manage context. They do, and they’re getting better at it quickly.

The difference I see is that provider compaction is mostly trying to answer: how does this one agent remain useful through a really long session?

Blends is asking another question: why did this particular agent need all of that information to begin with?

Say the main session and I have been working for three hours and we’ve discussed auth, deployment, pricing, some frontend redesign and an analytics problem we happened to find along the way. Now a Soldier has one job, fix a loading state in two components.

Even if the main model can perfectly search everything that happened during those three hours, I’m not convinced the Soldier needs access to any of it except the small part that affects its assignment.

The Capo can simply tell it what the bug is, what files are relevant, what behavior must remain intact and what conditions mean the job is finished. If the Soldier discovers something outside those boundaries, it comes back and asks for more.

That isn’t really compaction. We’re not trying to take a giant history and summarize it for the Soldier; we’re trying not to create that giant history for the Soldier in the first place.

The providers already have orchestration, which is kind of the point

I also don’t want to make this sound like I discovered agents talking to agents. Claude Code already has subagents. Codex already has agentic delegation. These products are going to continue making their own orchestration, context handling and memory better, and honestly I want them to.

If Claude becomes the best way to maintain a long-running Capo session, use Claude. If Codex becomes insanely good at carrying context across a huge project, use Codex. If Kimi or GLM gets ridiculously good at bounded implementation work, use that.

Blends should sit above those capabilities instead of trying to replace them.

The question is not whether we can spawn another agent. We already can.

The question is whether we should, and if we do, what kind of intelligence we should buy for that particular job.

Does this deserve Astra MAX?

Should Fable 5.1 own this mission?

Can Sol MAX run the Capo without giving anything up?

Can Luna MAX execute this part?

Does Opus 4.8 make sense here?

Would Grok 4.6 be a better fit for this specific task?

Did Kimi or GLM just release something that completely changes the economics of the Soldier pool?

Or is this whole thing unnecessary because the main session can finish the task itself faster than it can explain it to somebody else?

That’s the part I find interesting.

The cheaper model side could make this really weird, really fast

This is probably one of the areas I’m most curious about because the Soldier does not necessarily need to be a model that can independently understand an entire product and redesign it.

If the Capo layer actually works, a Soldier may only need to be extremely good at taking a specific technical contract and executing against it.

That gives Luna MAX, Opus 4.8, Grok 4.6, Kimi and GLM a very different bar to clear.

They don’t necessarily have to beat Astra MAX, Fable 5.1 or Sol MAX at being the model I want sitting in the main session for four hours. If they can consistently take a good assignment that says “here are the files, here is the exact behavior, here are the constraints, make the change and prove it works,” then they could still end up doing a huge amount of the actual coding.

Maybe Luna MAX becomes the obvious high-volume worker. Maybe Opus 4.8 costs a little more but almost never comes back with something the Capo rejects. Maybe Grok 4.6 turns out to be unusually good when the bounded task still has some debugging inside it. Maybe Kimi or GLM gets close enough that it makes no economic sense to use anything else for certain categories.

And if one of those models eventually gets good enough to move up into the Capo pool, move it up.

I don’t care about preserving a hierarchy of model brands. I care about preserving a hierarchy of responsibility.

How Blends learns

At first Blends doesn’t know which model belongs where, because neither do I.

Benchmarks are useful, but my repo isn’t a benchmark, my prompts aren’t a benchmark and the way I actually work isn’t a benchmark. Even the same model can behave differently depending on the harness, the context it received and how much ambiguity was left in the assignment.

So run the jobs and keep the receipts.

What kind of task was it? How ambiguous was it when it started? What language and framework? How many files? Which model was the Consigliere? Which model acted as Capo? Which Soldier actually performed the work? How much context did each one need? What did the entire attempt cost, not just the successful final call? How long did it take? How many retries happened? Did the tests pass? Did the Capo reject anything? Did I actually keep the final implementation?

I’d even want to know what was happening with context at the time. Was this a fresh worker? Was Claude already several compactions into a mission? Was the main Astra session using the newer context system? Did Luna MAX get a clean 4,000-token assignment while another model had 100,000 tokens of history behind it?

After enough actual work you should start seeing patterns that are a lot more relevant than somebody posting a benchmark screenshot on X.

Maybe Sol MAX ends up being the best everyday Capo.

Maybe Fable 5.1 costs more but saves money on big refactors because it makes better plans and its Soldiers need fewer retries.

Maybe Astra MAX ends up being worth the extra spend on the genuinely ugly long-running stuff.

Maybe Luna MAX destroys straightforward implementation work.

Maybe Opus 4.8 is a little slower or more expensive but almost never comes back with something the Capo rejects.

Maybe Grok 4.6 becomes the obvious debugging Soldier.

Maybe Kimi or GLM becomes the default for an entire category because it is close enough in quality and dramatically cheaper.

All in all, that’s fine. The model pool should move as the models move.

The number I care about

The number I really care about isn’t cost per call, because that can be misleading as hell.

I care about how much it cost to get a result I actually accepted, and that means counting the failures too.

If Luna MAX costs almost nothing but takes six attempts and eventually needs Opus or Grok to fix what it did, then the cheap worker wasn’t actually that cheap.

On the other hand, if Fable spends 20 minutes exploring a problem that a Capo could have reduced into three clean jobs that cheaper models get right the first time, then using Fable for every step wasn’t exactly cheap either.

So I don’t want Blends optimizing for the cheapest model, and I don’t want it blindly using the smartest model.

I want it trying to figure out the cheapest reliable path to the quality that a particular job actually requires.

There’s a big difference between a marketing page and an auth migration. I’m not trying to save 14 cents on the part that can lock every customer out.

Where this could get stupid

The obvious danger is agent theater.

You know what I mean; some beautiful dashboard says 27 autonomous agents are collaborating, meanwhile eight of them independently read the same files, three are arguing about an abstraction nobody asked for and a frontier model just spent real money telling another model to run git status.

I have no interest in that.

The hierarchy should expand only when the problem deserves it. A tiny task might stay completely inside the main session. Another might go directly to one Soldier. A normal feature might need one Capo with two workers underneath it. A huge change touching several independent systems might actually justify multiple Capos.

There’s no right answer that says more agents equals better.

In fact I think one of the harder things Blends would have to learn is when not to delegate.

And Git doesn’t need a made guy

I also went down the rabbit hole of whether there should be a merge agent, commit agent, Git agent, whatever.

Mostly no.

A smart model may need to decide what changes belong in the final patch, because deciding whether two implementations actually fit together requires judgment.

Once that decision is made, normal software can handle the commands.

Git is already good at being Git.

Worktrees, commits, staging, queues, test execution, budgets and file locking are deterministic operations. I don’t need another language model sitting there considering whether git status is the right strategic move.

Underneath all the Sopranos terminology, the split is actually pretty simple: models make the decisions that require judgment, and the runtime handles the shit that doesn’t.

I don’t want to build another IDE

The last thing I want Blends to become is Cursor number 47.

Codex is already good. Claude Code is already good. Cursor is already good. I already work inside these things.

Blends should plug into the harness I’m already using and let that main session become the Consigliere.

If I’m in Codex and something is worth delegating, invoke Blends. Maybe the session sends one task to Luna MAX. Maybe it gives an entire mission to a Sol MAX Capo and that Capo uses Opus 4.8 and Grok 4.6 underneath it. Maybe Kimi or GLM gets used for the cheap, tightly scoped work. Maybe the problem is complicated enough to justify multiple Capos. Maybe Blends looks at it and decides doing any of that would be slower than just letting the current session continue.

I don’t want to move into another chat interface just because I wanted better routing.

Whether the integration ends up being a plugin, skill, MCP, local runtime or some combination of them is an implementation detail to me. The actual product is figuring out how to allocate the intelligence underneath the conversation I’m already having.

What I don’t know

A lot, and I think pretending otherwise would make the whole thing sound more tryhard than it needs to.

Maybe coordination overhead kills the savings for most normal work. Maybe Capos are amazing on giant codebases and add almost nothing on smaller applications. Maybe cross-model review catches real bugs, or maybe reviewers spend half their time inventing theoretical problems because we told them to find something wrong.

Maybe the routing eventually needs some sophisticated learning system, or maybe a SQLite database and boring statistics gets us 90% of the way there.

I genuinely don’t know yet.

Claude and Codex have already shown that subagents can be useful, so I’m not trying to prove that again. The thing I want to test is narrower; if we already have agent hierarchies, can mixing different levels and sources of intelligence inside those hierarchies give us a better result for the money than simply throwing the best model we have at every step?

How I’d actually prove it

Take real work I was going to do anyway and let one strong agent complete it normally, using whatever context management, tools and delegation its own harness already gives it.

Then run comparable work through Blends.

Count everything; total cost, total time, failed attempts, retries, human corrections, rejected worker output and whether the final result was actually something I wanted to keep.

Don’t remove the ugly runs because they make the graph look bad.

If one Astra MAX, Fable 5.1 or Sol MAX session consistently beats the entire hierarchy, then good, we learned something and maybe Blends shouldn’t have orchestrated that class of problem.

I don’t need the architecture to win because I like the name.

Bottom line

Subagents are already here, orchestration is already here and context management is getting dramatically better, so none of those things individually are what I’m claiming is new.

The thing I’m interested in is what happens when all of those capabilities meet a model market where the difference in cost and intelligence between available models is becoming enormous, while cheaper and open models keep getting much better.

At that point it starts to feel strange to use one intelligence level for every part of every coding job simply because that happens to be the model running the main session.

Maybe Astra MAX, Fable 5.1 or Sol MAX should spend most of its time making the decisions that actually deserve frontier intelligence, while Luna MAX, Opus 4.8, Grok 4.6, Kimi, GLM or whatever comes next handles the work underneath once the problem has been made clear enough.

Maybe that hierarchy only makes sense 20% of the time.

Maybe it makes sense 80% of the time.

Maybe some jobs shouldn’t leave the main session at all.

That’s what I want Blends to figure out.

Not how many agents we can launch, but which parts of the job actually deserve expensive intelligence, which ones don’t, and what is the cheapest reliable way to get to something I’d actually keep.