A kind of comical thing happened yesterday while I was burning a third of a month's AI credits in 3 hours. I had Anthropic's most powerful reasoning model (sans cyber capabilities), Fable5, doing the initial design refinement, SMCC artifact creation and implementation of SMCC. Yesterday's post.

Using Fable5 for this initial bring-up was a good use of tokens, circumstances notwithstanding. We were designing something that will hopefully endure for years and power a lot of efficient and high-value programming. After the design refinement and finalization process, Fable created a number of SMCC artifacts and then proceeded to "turn the crank" and implement the semantic checker, compiler and staleness detector. Which was pretty likely a big overuse of its capabilities. In fact, I'm wondering if Qwen 27B (running locally on my solar-powered inference server anuenue) could have done the coding, with an Opus 4.8 or Opus 5 code review before PR. The attractiveness of this is apparent. Once the design is formalized into the SMCC state and context structure, the rest should hopefully be SMOP (simple matter of programming). The expensive reasoning has already been captured in the project state.

When I was doing the data deconstruction of a website in preparation for rewriting it in a CMS system (Webflow), I was at the very beginning of my “pay for every token” era of programming. As a result, I used Sonnet 4.5 to do some of the initial analysis and data cataloging. The work was performed in three phases. When I got to phase 3, I discovered Sonnet had done some bad analysis that severely impacted the feasibility of that last phase. I used Opus 4.5 to go back and fix the mistakes. My conclusion at the time was: “don’t ever use Sonnet for anything, use Opus.”

I am now realizing that heterogeneity in "work assignments" can bring big benefits. You'll probably laugh at me and say, "Duh." Of course it is best to spend the highest intellectual capacity on the design; mistakes there are extremely costly. This is software engineering 101. It took me a long time to arrive at my current "mixture of experts" agentic coding workflow but it ended up being "single agent" focused for implementation, and it was natural to use the coding agent to reason through design refinements, consulting with me and the architecture agent. I also got seduced (there is no better word for this) into long-running, large context sessions (Opus 4.5 1Million). It wasn't until near the end of my "endless tokens paid for by my employer" era that I realized that this is not only wasteful, but also demonstrably harmful to efficiency and quality of output.

With SMCC, I am going to experiment with a new workflow process that is heterogeneous across agents, utilizing both cloud and local. We will call this pattern capability routing (which is less awkward than "reasoning-tier routing"). For most projects, design will involve my normal 3-way collaboration with high-reasoning models and agents. A high-reasoning coding agent (typically Opus) will perform both design refinement and creation of the initial SMCC artifacts. After review by the architecture agent, the project is ready for implementation. At this point, tasks can be handed to a local model on the anuenue inference server for implementation. Code reviews by a high-reasoning model can be done just before or during the PR process.

What happens if the smaller model "fails", meaning it cannot reason its way through the task? This is where SMCC becomes especially useful. The failure does not have to disappear into a chat transcript. The local coding agent has the exact task description and relevant context items, so it can record what blocked it, add unresolved questions or proposed state changes, and move the task to blocked. The high-reasoning cloud agent and architecture agent can then reason over that bounded problem, update the SMCC state, and return the task to the local coding agent. Failure itself becomes structured state rather than a lost conversation.

Highly complex and foundation-critical tasks can still be farmed out to the high-reasoning cloud agents. But there is an awful lot of "turning the crank" (SMOP) that happens in even complex software projects.

Regular readers will recall that the GitHub Copilot (GHCP) chat interface had a difficult time with small to medium context for the local anuenue-hosted models. So, there is still work to be done in refining the agentic implementation structure for these small models on the local inference server. Earlier Post - Experiments

SMCC lets us spend expensive reasoning once, preserve its consequences as durable state, and then route implementation work to the cheapest model capable of completing each bounded task.

Perhaps the most expensive reasoning model on the planet doesn't need to turn every crank.