Field notes from real builds, not vendor marketing · August 2026
Where this one started
There is a conversation running on X right now that I keep getting pulled back into, and I think it is one of the more important ones happening this year. It is not loud. It is not a launch. It is a handful of people quietly noticing that the ground has shifted under our feet.
It started for me with a post from Ahmad saying that with the newest open weight models, the permanent underclass semi-joke is now cancelled. A couple of GPUs and some agency, he said, and that is all you need. I replied with a genuine question, not a cynical one:
Does this actually mean that with a couple of GPUs and the right setup you get frontier tier intelligence running locally now? Or is it closer on the benchmarks that get posted and still a step behind on the harder, less measurable stuff, the judgment calls, the edge cases, the things that only show up after months of real use?
I still do not have a clean answer to that. Anyone who tells you they do is selling something. But the question kept nagging, and a day later the same thread turned into something bigger: agent to agent orchestration across different labs’ models. Mixing models you run on your own hardware with models you reach through a subscription, inside one workflow.
That is when it clicked for me, and I wrote what I actually believe:
The cost savings are real, but they are not the point. The point is that intelligence stops being something you can only rent. Some of it lives on your machine, under your control, no matter what any lab decides tomorrow.
This article is the long version of that thought. What we are all doing today, what is about to change, what actually works right now (I went and checked, and the answer surprised me), who this is for, and the one thing that will break your whole setup if you ignore it.
What most of us are actually doing right now
Let us be honest about the current state, because the timeline makes it sound far more advanced than it is.
For heavy users, there are really two workloads that dominate everything else: coding with AI agents, and research. That is it. Those are the two places where people are getting genuine, measurable, daily value. Everything else is either downstream of those two or still mostly a demo.
And in both cases, the default posture is the same. You pick one model and you trust it. You open your coding agent, you pick Opus or GPT or whatever your subscription gives you, and you work. One brain, one session, one relationship. Everything you build is filtered through one set of judgments and one set of blind spots.
That works fine until it does not.
The first real orchestration move: hire an external auditor
The first time I broke out of the single model habit, it was not because of some grand architecture. It was because I got burned.
An agent wrote a piece of code, reviewed its own work, told me it was solid, and it was not. Which, if you think about it, is exactly what you would expect. Asking the thing that wrote the code to audit the code is like asking someone to proofread their own essay ten minutes after writing it. They read what they meant to write, not what is on the page.
So I started doing something very simple. I would use the latest Opus to write a specific piece of code, a defined segment, and then I would hand that segment to the latest GPT and ask it to audit. Different model, different training, different blind spots. It is exactly like bringing in an external auditor. They will find things the internal team will never find, not because they are smarter, but because they are not invested in the story of how it was built.
An agent auditing its own code reads what it meant to write. A different model reads what is actually there.
From there it grew. On production work I did a lot of this inside Augment Code’s Intent, where you can genuinely assign roles: this worker uses this model, that worker uses that model. Audit goes to GPT. Simpler mechanical tasks go to Sonnet. Complex reasoning goes to Opus. You are not picking a model, you are staffing a team. I wrote about that experience in detail in From Writing Code to Directing Intelligence, and it was genuinely the moment orchestration replaced coding for me.
The catch, and it is a real one, is cost. Intent is API based. And once you have lived with a subscription, going back to raw API pricing is painful. On a big Anthropic plan you are effectively getting many times more usage than the same money would buy you through the API. That gap is not marginal. For a solo builder or a small team it is the difference between shipping and not shipping.
What my daily setup actually looks like
So here is where I have landed for daily work, and it is deliberately unglamorous.
My daily driver is Claude Code Desktop, orchestrating agents from within the Anthropic model library. I use the latest Opus as the orchestrator and I tell it plainly what its job is. You are my CTO. You are the orchestrator and the auditor. You do not write the code yourself. You deploy worker agents for the simpler tasks. Use Sonnet for the mechanical work, use Opus for the complex reasoning, and report back.
When I want to raise the ceiling, I make Fable the orchestrator and let it delegate down to Opus and Sonnet. Same pattern, higher grade of judgment at the top.
This works. It works well. But it has one obvious wall, and I hit it every single week.
I can only orchestrate inside one house
Everything I just described happens inside the Anthropic estate. The orchestrator is Anthropic. The workers are Anthropic. The auditor is Anthropic.
What I actually want is this. I want my orchestrator running on my subscription, and I want it to be able to delegate out. To a model running locally on my own machine for the repetitive, mechanical, high-volume work. To a GPT subscription for the audit pass, because GPT is genuinely excellent at that. And back to a frontier model for the hard reasoning.
Or the mirror image. Use the Codex harness as the front end and orchestrate agents that sit on my Anthropic subscription and on my local hardware.
One conductor. Different orchestras. Some of them in my building, some of them rented by the hour.
That is the mixed fleet. And a year ago it would have been a silly thing to want, because the local option was not good enough to bother with. That is the part that changed.
Why now: the hardware and the open weights finally met in the middle
We cannot pretend anymore that the open-weight models are a hobby tier. The gap has closed enough that the conversation is different.
Qwen3.8-27B landed on 14 August 2026 under an Apache 2.0 licence. Roughly 27 billion parameters, dense, with a 262K native context window that can be stretched further. The practical number that matters: at four-bit quantisation, the community consensus is that this is a 24GB VRAM job, not a 16GB one. That is one high-end consumer GPU. Not a rack. Not a data centre. One card.
DeepSeek V4 Flash went to public beta on 31 July 2026 with MIT-licensed open weights. It is text-only; it wants 32GB and up to run locally, and through an API it is priced at a level that makes the frontier labs look like a luxury good.
Now, the honest caveat, because this is where most write-ups get lazy. Almost every benchmark number circulating for these models is vendor-published. In at least one case, the prompting was asymmetric, meaning the model got one fixed prompt while its comparators got the better of two attempts. That is not fraud; it is normal marketing, but it means you should treat the headline scores as a direction of travel rather than a verdict. Which brings us right back to my original question on X. Closer on the measurable things, almost certainly. Equal on the judgment calls that only surface after three months in production? Nobody knows yet. I do not.
Open weight does not mean local. A model with published weights and 600 billion parameters is still not running on your laptop. The interesting releases are the ones that are both good and small enough to actually host.
This matters more to me than benchmark bragging rights, and I have written about why at length in The Fight for Intelligence. We in Europe got a very direct lesson in this when Fable arrived; we had it briefly, and then access was cut. For hobby work, that is annoying. For serious production development, it is a genuine problem, because you built a process around something that can be taken away by a policy decision made on another continent.
A quick detour: what a harness actually is
If you are newer to this, the word harness is about to appear a lot, so let us define it once.
A harness is the software wrapped around a brain that turns it into an agent. The model is the intelligence. The harness is everything else: the loop that keeps it working, the tools that let it touch your files and run your commands, the memory that stops it from starting from zero every session, the permission system that decides what it is allowed to do.
Claude Code is a harness. Codex is a harness. OpenCode is a harness. DeepSeek now ships one too. The models inside them are swappable, at least in principle, and that swappability is the whole basis of what we are talking about. I wrote the full breakdown of all twelve components in Blueprint of a Frontier Coding Agent. If any of this article feels like it is skipping a step, that is the one to read first.
So can you actually do this today? I went and checked
I had not tested any of this before writing, and I did not want to publish a wish list dressed up as a guide. So I went through the documentation properly. Here is what I found, and some of it is not what I expected.
Ollama has quietly become the connective tissue here. It now ships one-line launchers for a whole set of harnesses: ollama launch claude, ollama launch opencode, ollama launch dsh for the DeepSeek harness, and ollama launch codex-app. It also exposes both an OpenAI-compatible and an Anthropic-compatible endpoint, which is the trick that makes all of it work.
The finding that matters
For Claude Code, the Ollama integration is substitution, not addition.
What it actually does is point Claude Code’s API base URL at your local Ollama instance instead of at Anthropic. Three environment variables, and now Claude Code is running on a local model. That is genuinely useful, and if you want a fully offline coding agent with a UX you already know, it is excellent. But it replaces Claude. It does not let Claude call out to a local model as one of its workers.
The setting is session-wide. There is an open feature request on the Claude Code repository asking for exactly what I described earlier: per-agent provider routing so an Opus orchestrator can delegate mechanical subagent work to a local model. As of writing, the model field in an agent definition only accepts Opus, Sonnet or Haiku, and they all point at the same endpoint. So the thing I want is a known want, and it is not built yet.
On the Claude Desktop app specifically: it is not in Ollama’s integration list at all. The Claude entry is the CLI. Codex App, on the other hand, is supported as a desktop GUI from Ollama v0.24.0 onward, and it will even back up and restore your original profile when you switch. So your instinct there was right on both counts.
The one that actually does what we want
OpenCode.
OpenCode treats the model as configuration rather than destiny. You define providers in a config file; you can have Anthropic, OpenAI, Google and a local Ollama endpoint all registered at once, and then you assign models per agent. A reviewer agent on one model, an explore agent on a local model doing the file reading and string matching that local models are genuinely good at, a build agent on the strongest thing you are willing to pay for.
That is the mixed fleet, working today, in one session. Not a roadmap item. Add the Oh My Opencode plugin on top and you get a full multi-agent system with category-based routing, and there are published configurations where the main agent is a paid cloud model and the subagents are local.
There is also a middle path for people committed to Claude Code: a community proxy that sits between the harness and the providers and routes by request type. Background tasks and diff summaries to a local model, planning to a reasoning model, long context to something with a big window. It is widely used, and it works, but be clear-eyed: routing is by request category rather than by agent role, and some Claude native behaviour degrades when the request is not actually going to Claude.
Here is the summary, in the order I would recommend investigating it.
The part nobody puts in the tutorials
There is a catch here, and I would rather you hear it from me than discover it later.
The obvious dream setup is: keep your Claude subscription, plug it into OpenCode, add your local models, and orchestrate everything from one place at subscription prices. And technically, community plugins to do that exist.
Anthropic’s position is that subscription logins for Free, Pro and Max plans are for native use of their own products, and that third-party tools must use API key billing through the console. In March 2026, the OpenCode project removed its Anthropic OAuth integration following a legal request, and the documentation now carries a note that using a Claude subscription in OpenCode is not officially supported.
So the honest position today is this: the mixed fleet works, but if Anthropic models are in it, you are paying API rates for that slice. There is no supported way to have both the subscription economics and the cross-provider orchestration.
I do not love it, but I would rather tell you the real shape of the constraint than let you build a workflow on something that could be switched off. And I would expect this to move. The demand is obvious, the feature request is public, and every harness vendor can see the same thing we can.
Who this is for, and who it really is not
Now the part I actually care most about, because I teach this and I watch people hurt themselves with it.
If you are new to this, if you are somewhere on the vibe coding rollercoaster and enjoying yourself: do not orchestrate. Not yet. Genuinely, do not.
Pick one harness. Get good. All of the current options are excellent, and you will not go wrong with any of them. Claude Code is now available inside the Claude Desktop app, which means you do not need to know a thing about terminals; you download an app, get a subscription and start building. I actually prefer it to the CLI, the UX is better for how I think. Codex is a fantastic harness. The DeepSeek harness is new and promising. OpenCode is open source, and it is what I use for teaching and for my own experiments, partly because you can see how it works.
Use one. Ship something. Break it. Fix it. That is the curriculum.
Orchestration is for when you are running work that a single agent can no longer hold. And here is the honest framing: orchestration is not a technical skill, it is a management skill. You are hiring, briefing, delegating, reviewing and firing. If you have ever run a team, you already know 80 per cent of this. If you have never run a team, orchestration will teach you why management is hard, at speed, with receipts.
What you get for the trouble is real: work happens in parallel, quality goes up because you have independent audits, bugs surface earlier. But the biggest prize is not any of those.
The bottleneck was never the model. It is context.
This is the thing I keep coming back to in almost everything I write, because it is the thing that decides whether you ship or stall.
Take any frontier model in any decent harness today. You are working with a very large context window. Sounds like plenty. It is not. You can build a simple app inside one window, comfortably. But real work does not fit.
Building Lumina Gen 2 took me hundreds of sessions with hundreds of agents. My working rule is that I start planning the handover at around 80 percent of the window, because past that the quality degrades before you notice it degrading. That is the part that catches people out. The agent does not announce that it has lost the thread. It just quietly gets worse, more confident, and more wrong.
Your agents do not fail loudly. They fail confidently. By the time you notice, you have three commits built on a misunderstanding.
So the skill is not prompting. It is not even picking the right model. It is maintaining continuity across sessions and across agents, so that agent number 47 starts with the same understanding of the project as agent number 3 finished with. I have written about this repeatedly, most completely in Context is the Code, and it is the single highest leverage thing you can learn in this whole field.
What I actually maintain, in practice
People ask me for the system, so here it is, stripped down. There is nothing clever in it. That is rather the point.
• A synced documentation library. Technical documentation and user-facing documentation, maintained through the project and beyond it. Not big. Deliberately not big. Consolidated and current, because a bloated knowledge base is worse than a small one. This is the grounding.
• A live spec file. You could argue this belongs in CLAUDE.md or AGENTS.md, and partly it does. But I keep a separate one that I call the spec, and it works like a running log of the project: the roadmap, the latest developments, the problems, the decisions and why we made them. Every agent has a global command to update the spec.
• A handoff file. This is the one that does the heavy lifting. At the end of every session, my orchestrator writes a handoff. What happened. Which agent did what. Links into the documentation. What is still open. And crucially, it also carries the role instruction forward: you are the orchestrator, you do not write code yourself, you delegate, you audit.
• The operational reality. Deployment, infrastructure, gating, permissions. In Lumina, I have GitHub Actions set up with a full suite of tests and CI. Everything that gets pushed runs the pipeline. When everything is green, the deployment agent can go to production. That knowledge travels in the handoff, so a fresh agent knows the rules of the house before it touches anything.
I also manually remind the agents, every single session, that all documentation must be in sync before we close. Yes, manually. Yes, every time. It is a small discipline and it is the reason the whole thing holds together.
Start a new session, open the handoff, and the new orchestrator knows exactly where it is standing. That is onboarding. It is the same job you would do for a human joining on a Monday, and it is the reason orchestration feels like management rather than engineering.
Now imagine the fleet
Put the two halves together and you can see where this goes.
I have the context discipline. The docs, the spec, the handoffs, the roles. That machinery does not care where the brains come from. And soon, with the right hardware, some of those brains will be sitting on a machine in my own office. DeepSeek, Qwen and Kimi running locally, always on, taking the mechanical work. GPT doing the audit pass, because it is genuinely good at that. A frontier model at the top holding the architecture in its head.
Different brains for different roles. Some rented, some owned. The workflow is the same either way.
Cost is the headline. Sovereignty is the story. When part of your intelligence lives on your own hardware, a policy decision in another country becomes an inconvenience rather than an outage.
That is why I think this conversation matters more than the benchmark posts it usually gets buried under. We spent a couple of years in a world where capability was a subscription. That is not a criticism, the subscriptions are extraordinary value and I pay for them happily. But being able to choose is a different thing from having to depend. Anyone who lived through the Web3 self-custody argument will recognise the shape of this exactly.
What I would actually do this week
Concretely, if you want to get somewhere with this rather than just nod at it:
• If you are still learning: ignore all of the above. Pick one harness, build one real thing end to end, and come back to this in three months.
• If you are already orchestrating inside one provider: install Ollama, pull one small capable model, and run it through a harness just to feel the latency and the quality. No project attached. Just get the reflex.
• If you want the actual mixed fleet: OpenCode is where to start, because the per agent model assignment is a first-class feature rather than a workaround. Budget for API billing on the frontier slice.
• Before any of it: get your documentation, spec and handoff discipline in place. Orchestration multiplies whatever you already have. If what you have is chaos, you now have parallel chaos.
• And keep watching the hardware. The interesting threshold is not the trillion parameter flagship. It is the 27 billion parameter model that is genuinely good and fits on one card.
Where I land
I do not think the underclass joke is cancelled yet. I think it is being renegotiated, and that is more interesting.
The frontier models are still ahead where it is hardest to measure: the judgment calls, the edge cases, the strange situations that only appear after months in production. That is exactly the part no benchmark captures, and it is exactly the part I care about, because I ship things that people pay for.
But the direction is not ambiguous. A capable model now fits on one consumer GPU. Harnesses are learning to route across providers. The orchestration patterns we built inside single vendor estates transfer over cleanly, because they were never really about the vendor. They were about roles, context and handoffs.
So the skill to build is not knowing which model is best this month. It never was. The skill is being able to run a team of them, keep the thread through hundreds of sessions, and stay unbothered when one of your team members gets taken away from you.
That is the whole thing. Everything else is a model release.
Sources & Further Reading
From this series
• Blueprint of a Frontier Coding Agent — the twelve components of a production agent harness. Read this first if the word harness is new to you.
• Context is the Code: The Complete Guide — the full treatment of the context problem, the spec file, and session continuity.
• From Writing Code to Directing Intelligence — five days inside Augment Code’s Intent, and the moment orchestration replaced coding for me.
• The Fight for Intelligence — why open-weight and local-first models are infrastructure, not a hobby.
• From 0 to Dev in One Day: What a Real Coding Harness Does — the practical on-ramp for anyone starting from zero.
The X conversation this came from
• On agent to agent orchestration across labs, and why cost is not the point
• The genuine question about local frontier tier intelligence
• On maintenance automation and Lumina Gen 2 infrastructure monitoring
• Boris Cherny on letting Claude take over day to day app maintenance
Ollama harness integrations (all verified against the official docs, August 2026)
• Ollama integrations overview
• Claude Code + Ollama — note the manual setup section: it replaces the Anthropic base URL.
• OpenCode + Ollama — provider config, which is what makes the mixed fleet possible.
• DeepSeek Harness + Ollama — currently a developer preview.
• Codex App + Ollama — desktop GUI support, Ollama v0.24.0 and newer.
Background and verification
• OpenCode agents documentation — per-agent model assignment using provider/model.
• OpenCode providers documentation — the full provider list, including local endpoints.
• Claude Code feature request #38698: per-agent model provider routing — the exact capability discussed in this article, still open.
• Qwen3.8-27B technical analysis — architecture, benchmarks and deployment requirements.
• Qwen3.8-27B specs and hardware reality check — including the benchmark prompting caveats I mention above.
• Qwen 3.8 Max vs DeepSeek V4 Flash — licensing, pricing and capability shape.
• Claude Code Router — the community proxy approach to request-type routing.
A note on the numbers: model specifications, prices and benchmark scores in this space change weekly. Everything here was checked against at least two sources in August 2026. If you are reading this later, re-verify before you make a purchase decision on the strength of it.
About the Author
Dr. Tali Režun is a serial entrepreneur, business developer and academic working at the frontier of AI and Web3. As Vice Dean of Frontier Technologies at COTRUGLI Business School, he leads AI innovation initiatives and shapes MBA curricula for the next generation of technology leaders. Over more than 30 years he has founded and scaled ventures including Lumina Agents, Moj AI, Block Labs, 4thTech, Immu3, PollinationX and Online Guerrilla.
He is a non-technical founder who ships production software using AI coding agents rather than writing code himself, and he uses himself as the proof of concept for the Centaur model: domain expertise plus AI fluency equals output that neither could produce alone.
From Lab to Life publishes weekly at talirezun.substack.com. Field notes from real builds, not vendor marketing.
Disclaimer
Research and educational purpose. This article documents personal working practice and independent research. It is not professional technical advice, and every setup described here should be tested in your own environment before you rely on it for production work.
No commercial relationships. I have no commercial relationship with Ollama, OpenCode, Anthropic, OpenAI, DeepSeek, Alibaba or any of the other tools and vendors named. I pay for the subscriptions I use, at retail. Where I recommend something it is because I use it.
Evolving landscape. This field moves faster than publishing does. Model capabilities, pricing, licensing terms and platform policies change constantly, and the terms of service positions described here in particular are subject to revision. Verify current documentation before making decisions based on anything written here.