My agentic engineering series started in late May 2026, and I promised myself not to turn this blog into a weekly model-news ticker. But this space moves so fast that after one summer, some of my recommendations have quietly changed – and I'd rather tell you in one short post than let the old ones age in silence. So this is a quick end-of-summer status update 📋 – the first in what I plan to make a quarterly series – across the three layers of the stack: the models, the harness, and the apps – plus what all of that costs. If you're new here, the apps and harnesses post and the harness setup post explain how I slice those layers. This is a subjective field report from my daily work.
TL;DR: What Changed This Summer
If you only have thirty seconds: my preferred models are now Fable 5, GPT-5.6 Sol, and – as the budget pick – GLM-5.3 Flash. On the harness layer, nothing important changed – the setup recommendations hold up. On the app layer, however, there is real news: the open-source T3 Code is now my preferred app, with the Codex app as my alternative for computer use. Every layer but the apps gets the latest DeepSWE numbers – official for models and costs, via Artificial Analysis for harnesses – and each one gets a small podium with my three personal favorites. And the one thing to take home is my current workflow: Fable 5 as the orchestrating agent, GPT-5.6 Sol as the sub-agent – the best way I know to stretch the precious Fable budget. Plus my two cents on loop engineering, the buzzword of the summer.
Models: My New Trio
In the LLM post from late May, my ranking was Opus 4.7 for Angular, GPT-5.5 as the all-rounder, and Composer 2.5 as the newcomer. One summer later, all three have been pushed aside: Opus 4.7 by its maker's next generation, GPT-5.5 by its own successor, and Composer 2.5 by a model I hadn't even heard of in May – not because they got worse, but because the next round arrived. Interestingly, Cursor – by now part of SpaceX, since the SpaceXAI deal from the apps post closed on August 14 – didn't produce a podium model at all. In the apps post I expected them to enter the frontier stage, and so far that call was wrong.
1: Fable 5 by Anthropic
No surprise if you read my Fable 5 post: this model is a new generation, and it is still the best model I have ever pointed at an Angular codebase – or at anything else, by the way. It is very intelligent and – I keep coming back to this word – expansive: give it a vague goal and it explores the problem space, tests its own ideas, and comes back with validated results instead of a guess. And the best part: it usually just understands what I meant. After the June shutdown drama, access came back on July 2 and has stayed ever since – and Fable 5 has settled in as my go-to for everything hard: architecture, design, reviews, and long-horizon refactorings. The catches from that post – price, speed, usage limits – are all still real, which is exactly why the sub-agent workflow at the bottom of this post exists.
2: GPT-5.6 Sol by OpenAI
In the Fable post, I predicted OpenAI would answer with GPT-6. They answered with GPT-5.6 instead – and honestly, the name is the least interesting part. The big variant, GPT-5.6 Sol, is very intelligent, clearly a step up from GPT-5.5, and it comes at a fair price: the included usage in the OpenAI subscriptions remains generous, so I can let it work all day without watching a meter. And on August 21, OpenAI cut the Sol price again – 20% on input tokens, a third on output tokens, valid through November 21 – the third price cut in the GPT-5.6 family within a month; the subscriptions stay as they are, but Codex credits and API calls get cheaper too. It has taken over the role GPT-5.5 had in my setup – the reliable senior engineer for focused implementation work – and, as you'll see below, it is my sub-agent of choice.
3: GLM-5.3 Flash by Zhipu (Z.ai)
The third step of my podium was empty for most of the summer. In May, this was the newcomer slot, held by Composer 2.5 – which, next to what came after it, simply isn't capable enough anymore. Then I gave Grok 4.5 a real shot at it – cheap, and for mechanical refactorings and test generation it held up fine – but when it mattered, I kept reaching for the two models above.
What finally filled the slot came from a lab I wasn't even tracking in May: GLM-5.3 Flash, the small sibling of Zhipu's GLM-5.3. It is not frontier intelligence – 63% on DeepSWE, ten points behind Sol – but it is absurdly fast, it gets there for about €0.25 per task, and in my Angular work it is simply more capable than the obvious alternative, GPT-5.6 Luna, which I already pay for through the OpenAI subscription. The leaderboard doesn't back that up outright – Luna at max scores 67% – but at the effort I actually run Luna, high, it drops to 44%, while the Flash gets its 63% flat out at max, and at that price, effort levels stop mattering. That makes it the cheapest model whose output I'd actually merge. For the mechanical share of my work – the well-specified legwork I would never hand to Fable anyway – that is often enough, and next to two expensive models, a dirt-cheap third one is exactly what my setup was missing. More on that in the costs section, where it climbs to the top of the podium.
The shortlist behind it is longer than ever, and I'll keep re-evaluating it every quarter:
- Kimi K3 by Moonshot and the big GLM-5.3 – both at 69% on DeepSWE for around €4 per task: stronger than the Flash, but not cheap enough to be the budget pick, and not strong enough to replace Sol.
- Grok 4.6 by xAI – the successor to the model that didn't stick, now at 67%.
- Muse Spark 1.2 by Meta AI – the outsider at 55%; I haven't spent enough time with it to say more, but it stays on the list.
- DeepSeek V4 – the Pro variant scores 63% for under €2 per task, the Flash 53% for about €0.45 – the closest competitor to my new #3.
- And yes, even Opus 5 by Anthropic – the DeepSWE winner at 74%, and, as always with the Claude line, the model with the most taste in this list. It does everything that made Opus 4.7 my #1 for Angular back in May, just a notch better. But that's the point: a notch, not a new tier. In my daily Angular work it is simply not as good as Fable 5 and GPT-5.6 Sol – and as an always-on third model for the legwork, it is far too expensive.
What DeepSWE Says
As in every post of this series, I put my gut feeling next to the one benchmark I trust the most: DeepSWE, because it measures a large share of my implementation work – a short behavioral prompt, a real codebase, and an agent that has to find the right place and implement the change cleanly. Here is the official v1.1 leaderboard, updated on August 26, 2026:
DeepSWE v1.1 pass@1 – snapshot from August 29, 2026, my selection of eight out of 26 models; click the chart for the live leaderboard. All models run through the same minimal harness (mini-swe-agent), so this really is a comparison of models, not of products.
And here it gets interesting, because the benchmark and I don't agree on the order. DeepSWE puts Opus 5 on top at 74%, GPT-5.6 Sol right behind at 73%, and Fable 5 third at 70% – all at max effort, and with the ±3 to ±4 points the leaderboard prints on them, all within one error bar of each other. Below the top three, the picture has changed a lot since May – and this is where my shortlist lives: GLM-5.3 and Kimi K3 sit at 69%, the small GPT-5.6 Luna, GPT-5.5, and Grok 4.6 at 67%, my new #3 GLM-5.3 Flash at 63%, and Opus 4.8 – my architecture and review model of early summer – sits at 59% (GPT-5.5, Opus 4.8, and Sonnet 5 are not in my eight-model selection above – click through for the full board). Sonnet 5 lands at 54% – and is, weirdly, the most expensive model per task in the whole table – which confirms what I wrote in the verdict post: there is no reason to go down to the Sonnet models.
So why is Fable 5 still my #1 when it comes third on my favorite benchmark? Because DeepSWE measures one well-defined task at a time – and that is exactly the kind of work I don't give to Fable anymore (see the budget section below). The things that make Fable a new generation to me – staying with a vague, long-horizon problem, validating its own ideas, the taste of the result – simply don't show up in a pass@1 number. Same story as in the first post: benchmarks are useful signals, not final answers. For the well-specified single task, the benchmark is right: GPT-5.6 Sol – and Opus 5 – are just as good, and cheaper. That's exactly the split my workflow below is built on.
My Podium: Models
- 🥇 Fable 5 – my best friend for architecture, design, reviews, and long-horizon refactorings. Expensive, slow, rationed – and still the best model I know for an Angular codebase.
- 🥈 GPT-5.6 Sol – the reliable senior engineer for focused implementation work, fairly priced, second on DeepSWE, and my sub-agent of choice.
- 🥉 GLM-5.3 Flash – not as intelligent as the two above, but absurdly fast and cheap: the model for the mechanical legwork.
As always: judge these models in your own codebase, with your own tasks and your own review standards.
Harnesses: Nothing to Report (Which Is Good News)
On the harness layer, not much has changed over the summer – and I mean that as a compliment. Everything from the harness setup post holds up: the style guide is still the single highest-leverage file, AGENTS.md is still the operating contract, and the feedback loops from ng lint to Playwright are still what turn a capable model into a careful teammate. The ng-agentic repo keeps evolving in small steps, but the recommendations stand. If you set up your harness in June, you don't have to rebuild it now.
One caveat, though: a harness is never finished. Whenever something goes wrong, I fix the setup right away – a rule in AGENTS.md, a line in the style guide, a missing check in the feedback loop – instead of re-prompting around it. And every new model deserves a pass over AGENTS.md and the other instruction files: some rules only exist because an older model kept making one specific mistake, and the new one may not need them anymore.
What DeepSWE Says About Harnesses
The official DeepSWE leaderboard deliberately runs every model through the same minimal harness, so it can't tell us anything about harnesses. Artificial Analysis can: they run DeepSWE through the real coding agents – Claude Code, Codex, Cursor CLI, opencode, and a few more – and in their harness comparison they even hold the model constant and swap only the harness. It's the same chart I used in the harness setup post – Artificial Analysis still pins the model at Opus 4.7, so the harness spread itself hasn't moved; what's new are the model-plus-harness pairs further down their page:
Artificial Analysis Coding Agent Index by harness for the same Opus 4.7 model at medium effort – snapshot from August 28, 2026; click the chart for the live comparison.
Two things stand out. First, with the model held constant at Opus 4.7 (medium), opencode scores 51 on their composite index, Cursor CLI 47, and Claude Code only 42 – and on the DeepSWE tab of the same chart the spread is even wider: about 40%, 32%, and 27%. Nothing changed but the wrapper – and the spread is bigger than between most models on the leaderboard. Second, and more relevant for my two favorite models: with current models, the agent pairs land at Codex with GPT-5.6 Sol at about 69%, Claude Code with Fable 5 at about 66% (including the sessions Anthropic's safeguards route to Opus), and Claude Code with Opus 5 at about 63%, each at its top effort level. So in harness form, the Codex-plus-Sol pair is the fastest and cheapest of the three frontier pairs – which at least suggests that Codex is a very efficient harness for its own model.
Does that mean I should run Opus through opencode instead of Claude Code? On paper, maybe – and bonus tip 2 shows the one setup where I actually do. On my Claude subscriptions, though, no: the Opus 4.7 chart is the only one where Artificial Analysis currently holds the model fixed across three harnesses, it's a spring model at medium effort, and the Claude Code harness keeps moving – sub-agents, hooks, /loop, everything my orchestrator workflow grew up in. What the chart proves is the point of the harness setup post, not a reason to switch: the wrapper changes the result, and the part of the wrapper you control – style guide, AGENTS.md, feedback loops – is where your points come from.
My Podium: Harnesses
- 🥇 opencode – the most flexible harness of the bunch: open source, model-agnostic, and it runs every model I care about on the subscriptions and keys I already have – Fable 5 and Opus 5, GPT-5.6 Sol, and GLM-5.3 Flash via OpenRouter. And it is a good harness in its own right – the one chart that holds the model fixed puts it ahead of both alternatives. It's one of the five harnesses T3 Code can drive – next to Claude Code, Codex, Grok Build, and Cursor – and the one GLM-5.3 Flash runs on via OpenRouter, and the one the whole Copilot setup from bonus tip 2 lives on – more on that in the app, costs, and workflow sections.
- 🥈 Claude Code – the harness I run Fable 5 and Opus 5 through – and it is fantastic at orchestrating sub-agents, even with GPT-5.6 Sol in the sub-agent seat. Sub-agents in
.claude/agents/are the reason my orchestrator workflow exists – hooks and/loopare the extras opencode can't match yet. - 🥉 Cursor CLI – it still runs most of the models that matter, it hand-tunes its tools and prompts for every new one, it is very well integrated with the IDE, and it lands second on that same harness chart, ahead of Claude Code. Two catches, though. The price is the price: it meters usage at API prices, so the included budget drains far faster than a Claude or OpenAI subscription – not where my daily volume goes. And since Cursor became part of SpaceX, OpenAI has announced that it plans to wind down its contract supplying models to Cursor, with November 12, 2026, as the proposed shutoff date – so the "most models" part now has an uncertain expiry date.
Codex CLI just misses the podium: it's the harness my GPT-5.6 sub-agent runs on every day – GPT-5.6 Sol and GPT-5.6 Luna on my OpenAI subscription, other providers' models via API key – and, as the Artificial Analysis numbers above show, the Codex-plus-Sol pair is the most efficient of the frontier pairs. But it is built for OpenAI's models first, and – unlike Claude Code with its sub-agents and hooks – it adds nothing my orchestrator workflow needs. That is what keeps it off my podium. If you live in the terminal, opencode is still my recommendation – and Pi for the tinkerers who want to reshape their harness themselves.
Apps: T3 Code Takes the Lead
Here is the actual news of this post. In the apps and harnesses post, I mentioned T3 Code in one throwaway paragraph as an open-source GUI on top of the agents you already pay for. Since then, the open-source T3 Code has quietly become my preferred app. The Codex app is now my alternative, demoted from daily driver to solid second choice.
Why the switch? Three reasons – plus one big bonus:
1. Remote control, without the lock-in. Like the Codex app, T3 Code lets me control my agents from my phone while the desktop machine does the actual work – start a task from the couch, check the diff on the train. With T3 Code, this is easily set up through a Tailscale connection: my phone talks to my own machine, no cloud runner in between. That also keeps the data and privacy story refreshingly simple – the code still goes to whichever model I picked, but nothing else sits in between.
2. Open source and free. No subscription for the app itself, and the source is public, so I can read every line of it. After the Claude Code source-map episode from the harness setup post, I have come to appreciate being able to inspect the layer that wraps my code.
3. Any model, any provider. T3 Code doesn't care which vendor I'm loyal to this week. All three of my current favorites – Fable 5, GPT-5.6 Sol, and GLM-5.3 Flash – work perfectly in it, on the subscriptions and keys I already have – and two of them, Fable 5 and GPT-5.6 Sol, via opencode even on a company GitHub Copilot plan (see bonus tip 2 at the end of the workflow section). Remember the "don't get too attached to one vendor workflow" advice from the apps post? This is the answer.
My favorites in T3 Code's model picker, each one keyboard shortcut away: Fable 5 through Claude Code and – via opencode – through GitHub Copilot, GPT-5.6 Sol through Codex or Copilot, and GLM-5.3 Flash through opencode and OpenRouter.
4. The new sidebar. A (big) bonus rather than a reason to switch, but the recently released sidebar is genuinely cool to use – it keeps everything that matters in view while an agent is working, without the tab-juggling I got used to in the other super apps. Think of it as an inbox: one entry per thread with project, branch, and status, and when you're done with one, you settle it and it slides to the bottom.
The T3 Code sidebar as an inbox: the active threads on top, the settled ones at the bottom – client names pixelated, and this very post in the middle.
To be fair to Codex: if you live entirely in the OpenAI world, it remains a great choice. In my setup, it has moved from first pick to a specialist: T3 Code gets most of my day, and I open the Codex app mainly for computer use – the browser-driving, screenshot-checking kind of task where it is still the best tool I have.
And the terminal? Honestly, I hardly open one for agentic work anymore – the super apps have simply become too convenient. If you still prefer it: opencode for most people, Pi for the tinkerers – see the harness section above.
My Podium: Apps
No benchmark here – nobody measures how nice a sidebar is – so this one is pure taste:
- 🥇 T3 Code – open source, any model, remote control via Tailscale, and that sidebar. The app I open first every morning right now.
- 🥈 Codex app – still the most polished closed app, still just works, and my go-to for computer use. Also the one I'd hand a colleague who never leaves the OpenAI world.
- 🥉 Cursor – the super app with the strongest IDE integration, running most of the models that matter under its own harness – but Cursor-provided access to OpenAI's models is planned to end, with November 12 as the proposed date (see the harness section).
The Claude Desktop app lands just off the podium: still the natural home of the Claude Code harness, but T3 Code now does that job for me – with more models.
Costs: Fable 5 Is the Expensive One
Model podium, harness podium, app podium – now the boring part that decides whether any of it is sustainable: money. The costs post from June still holds in every important point: the subsidized subscriptions remain by far the best deal, and the number that matters is still the cost per accepted, reviewed, merged change, not the price per token. What has changed is the spread between the models at the top – and DeepSWE gives me the closest proxy I have for it, because it tracks the average API cost per task right next to the score:
DeepSWE v1.1 cost view – average API cost per task against the score, snapshot from August 29, 2026, my selection of 34 out of 63 configs – all effort levels for the frontier models and most of my shortlist, so you can see the curves; click the chart for the live leaderboard. Note the inverted cost axis – cheaper is further right – so up and to the right is where you want to be.
DeepSWE reports in US dollars; I converted to euros and rounded. For the frontier models, the chart shows all effort levels, because high is what I run most of the time and the leaderboard's default view only shows the best score per model – usually the max-effort one. At high effort, one DeepSWE task costs roughly €8.50 with Fable 5 (69%), €5.50 with Opus 5 (73%), and €2.50 with GPT-5.6 Sol (69%). At max effort, the same three score 70%, 74%, and 73% for about €20, €11, and €6. Read that again: max effort roughly doubles the bill for one extra point on both Claude models – Sol is the only one where it buys something real, four points.
The score order shuffles with effort, but the cost gap doesn't: at every level, Fable 5 costs about three times as much per task as GPT-5.6 Sol. Two reasons: Fable burns about twice the output tokens per task that Sol does (119k at max versus 60k), and its per-token price is well above Sol's on top of that. Token efficiency is where OpenAI is currently winning, and that matters even on a subscription, because tokens are exactly what your usage limits are made of.
The bargain corner is where it gets interesting, and it's where my #3 lives. GLM-5.3 Flash solves 63% of the tasks for about €0.25 – a tenth of what Sol costs at high effort, and a tiny fraction of Fable at any effort. It is clearly a class below the frontier models, but for the mechanical share of my work it's often enough, and it's fast – which is why it tops my cost podium below. The competition in that corner is real, though: GPT-5.6 Luna, the small sibling of Sol, is the line of dots hugging the right edge of the chart – 44% for about €0.15 at high effort, 67% for about €0.60 at max – with DeepSeek V4 Flash not far away and the DeepSeek V4 Pro a bit further up. The bigger open-weight pair from my shortlist, GLM-5.3 and Kimi K3, sits higher up at 69% – the highest score among the open-weight models, though Sol matches it for less, and the Flash beats both on cost per task.
Artificial Analysis tells the same story in harness form and adds the clock: a Codex run with GPT-5.6 Sol costs about €4.50 per task and finishes in roughly ten minutes, while Claude Code sits at about €7.50 with Opus 5 (at xhigh) and about €11 with Fable 5 – and both Claude runs take close to 24 minutes. That Fable is slow is nothing new; that the gap is now measurable is.
What does that mean for my wallet? Less than you'd think, because almost everything still runs on subscriptions, not per token: two €200 Claude subscriptions since July (as confessed in the Fable post), one OpenAI subscription that GPT-5.6 has never come close to exhausting – and, for GLM-5.3 Flash, an OpenRouter key I use through opencode inside T3 Code – plus a GitHub Copilot plan for the setup in bonus tip 2. OpenRouter adds a small fee on top of the model's own price, but at €0.25 per task that is noise, and in return I can try out any new model on the leaderboard the same afternoon. All of it together, at my hourly rate, is still paid for by lunchtime on the first working day of the month. But the per-task numbers above translate directly into how fast a subscription's limits drain – and that is why the next section exists.
My Podium: Cost per Accepted Change
Not price per token – cost per change I actually merge. DeepSWE's cost per task is only a proxy for that, so the rest is my judgment:
- 🥇 GLM-5.3 Flash – not as smart as the frontier models, but quick and close to free – which is fine, because I don't hand it the hard stuff. For mechanical work, it's the best cost per accepted change I have found.
- 🥈 GPT-5.6 Sol – the middle ground: top-three quality at a fraction of the Claude cost per task, the fewest tokens per task, plus the most generous included usage. The best deal among the frontier models, full stop.
- 🥉 Fable 5 – the best model and the most expensive one in my trio. The worst deal on paper, and the best deal for the problems that would otherwise cost me a day: worth every cent for hard, long-horizon work, overkill for everything else.
Notice what just happened: this is the models podium turned upside down. And that is exactly the tension the next section is about – I want to use the best model as much as possible, and I can't afford to.
How I Save My Fable Budget
Fable 5 is the one model I actively ration, and after a summer of doing that, these are the habits that survived – the biggest one last, because it gets its own section:
- GPT-5.6 Sol is the default, Fable 5 is the exception. The question I ask before every task: would GPT-5.6 Sol – or even GLM-5.3 Flash – get this right too? For normal implementation work, the answer is yes, the benchmark agrees, and it doesn't touch the Claude limits at all. If I want to stay inside the Claude world, Opus 5 does the same job at roughly two thirds of Fable's cost per task at high effort, and about half at max. Fable gets the vague goals, the architecture, the reviews, and the brownfield refactorings that span half the codebase.
- Medium to high effort, not max. The effort numbers from the costs section make the case better than I could: one extra point for double the bill – and even at medium, Fable still gets 65% for about €5.50. So I run Fable at medium or high and reserve max for the rare task where a wrong answer costs more than the tokens.
- Plan first, then let it run. A few minutes of spec and plan before the long autonomous run save a lot of expensive laps. Fable is at its best when the outcome is clear but the route is not – a long-horizon problem it can explore without first having to guess what success means – and at its most wasteful when it has to discover the goal by trial and error, at Fable prices.
- Keep the context lean. Fresh thread per task, short
AGENTS.md, no sprawling terminal output – the team rules from the costs post, just applied more strictly. A bloated context is re-read on every turn, and those are the tokens that drain your 5-hour window. - Hand the legwork to a sub-agent. This is the big one: Fable 5 thinks, a cheaper model types. It's the tip from the July 4th update of the Fable post, and by now it's my standard workflow – so it gets its own section right below.
And if all of that still isn't enough? Then you're in my situation – see the two Claude subscriptions above.
My Current Workflow: Fable 5 Orchestrates, GPT-5.6 Sol Does the Legwork
So here is tip number five in detail – the habit that saves me the most usage, because it addresses the Fable 5 catch that hurts the most: the usage limits.
The idea is simple: Fable 5 should think, not type. I run Fable 5 as the orchestrating agent – it does the planning, the architecture decisions, and the final review – and I hand the well-specified implementation legwork to GPT-5.6 Sol as a sub-agent. Fable 5 writes a self-contained task description, the sub-agent executes it through the Codex CLI on my OpenAI subscription, and Fable 5 reviews the result. The expensive model spends its tokens on judgment; the fairly priced model spends its tokens on volume.
In Claude Code (and therefore in any app driving that harness), this is one Markdown file in .claude/agents/:
---
name: gpt-implementer
description: Delegates well-specified implementation tasks to GPT-5.6 Sol via the Codex CLI. Use for mechanical, clearly spec'd legwork – not for architecture or design decisions.
tools: Bash, Read, Grep, Glob
---
You are a thin wrapper around the Codex CLI. Take the task you were given, write it into a single self-contained prompt (all relevant file paths, constraints, and acceptance criteria included – Codex starts with zero conversation context), then run:
codex exec -m gpt-5.6-sol "<your prompt>"
Return Codex's output as your result. Do not implement anything yourself.That's it. The orchestrating Fable 5 session now delegates on its own whenever a task is mechanical enough, and my Fable limits last noticeably longer – I run Fable 5 itself at medium to high effort and let the sub-agent burn the implementation tokens. The same division of labor works with Opus 5 in the sub-agent seat if you'd rather stay entirely in the Claude world – cheaper than Fable, same harness, no Codex detour. And of course, the harness setup does its quiet work here too: the sub-agent reads the same AGENTS.md and style guide as everyone else, so the code comes back looking like mine no matter which model typed it.
Bonus Tip 1: A 1M-Token Context Window for GPT-5.6 Sol in Codex
One related tip for the Codex side of this setup, because it comes up so often: by default, Codex runs GPT-5.6 with a deliberately smaller context window than the model supports – tuned for performance and cost. Earlier this month (on August 16, 2026), OpenAI's Tibo Sottiaux documented how to raise it to a 1M-token working window for GPT-5.6 Sol. Open ~/.codex/config.toml and add these three lines at the top level, before any [section] header:
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000The first line selects the model, the second gives Codex a one-million-token context budget, and the third starts automatic compaction of older history at around 900k tokens, leaving some headroom. Restart Codex and start a new session. If you'd rather try it once without touching your defaults:
codex -m gpt-5.6-sol \
-c model_context_window=1000000 \
-c model_auto_compact_token_limit=900000For the sub-agent workflow above, this matters less than you might think – every codex exec starts fresh with a self-contained prompt anyway. Where it pays off is in the long-running Codex sessions you drive directly, in the app or the CLI: more code, tool output, and conversation history stay in view before Codex has to summarize older material. My take: OpenAI tuned the default carefully, and I'm not switching it on everywhere – but for the occasional big brownfield task, it's good to know the knob exists.
Bonus Tip 2: "Hey Alex, I'm Only Allowed to Use Copilot"
I hear this sentence in almost every workshop, and my answer used to be short: in the costs post I wrote that I wouldn't build a 2026 setup around Copilot, and the harness setup post steers you away from plain VS Code plus Copilot. Both still stand – for the Copilot harness. The Copilot subscription is a different story. Since Fable 5 and GPT-5.6 Sol landed in Copilot's model picker (on the Pro+, Max, Business, and Enterprise plans), the subscription your company already pays for gets you the two frontier models from my podium – all you need is a better harness around it. And, funnily enough, that is a setup I run myself right now, side by side with the Claude Code plus Codex one above: T3 Code on top of opencode on top of GitHub Copilot. Same orchestrator workflow as above – Fable 5 thinks, GPT-5.6 Sol types – just without the Codex detour, and without a Claude or OpenAI subscription of your own.
Step 1: connect opencode to Copilot. Install opencode, run opencode auth login (or /connect inside a running session), pick GitHub Copilot, and confirm the device code on GitHub. Afterwards, opencode models lists everything your plan unlocks as github-copilot/<model>. Two caveats: the opencode docs note that some models need a Pro+ plan or higher, and on the Business and Enterprise plans your admin has to switch the frontier models on in the Copilot policies first – that is the one conversation you can't automate.
Step 2: global defaults. In ~/.config/opencode/opencode.json, Fable 5 becomes the session model, and Luna takes care of opencode's small internal jobs – titles, summaries – without touching the expensive budget:
{
"$schema": "https://opencode.ai/config.json",
"model": "github-copilot/claude-fable-5",
"small_model": "github-copilot/gpt-5.6-luna"
}My real file also holds the OpenRouter provider entry for GLM-5.3 Flash from the costs section, but that is optional.
Step 3: the sub-agents. This is the opencode version of the .claude/agents/ file from above, except that it lives in the project's opencode.json – and it is even simpler, because GPT-5.6 Sol is a native opencode model here, so no CLI wrapper is needed. Sub-agents are defined under the agent key; the built-in general, explore, and scout agents get a model too, so that every sub-agent's model is explicit:
{
"$schema": "https://opencode.ai/config.json",
"instructions": [".opencode/OPENCODE.md"],
"agent": {
"general": { "model": "github-copilot/claude-fable-5" },
"explore": { "model": "github-copilot/gpt-5.6-sol" },
"scout": { "model": "github-copilot/gpt-5.6-sol" },
"implement-sol": {
"mode": "subagent",
"model": "github-copilot/gpt-5.6-sol",
"description": "Implementer on GPT-5.6 Sol. Give it a self-contained brief (files, exact behavior, constraints, verification commands); it implements exactly that and reports back. All implementation goes here – never implement in the session.",
"prompt": "You are the implementer on GPT-5.6 Sol. The session model (Claude Fable 5) has already made the design decisions and hands you a brief. Implement exactly that brief – no scope changes, no redesign, no opportunistic refactors. Follow AGENTS.md and the style guide. Run the verification commands the brief names – at least the linter for every touched project. Never stage, commit, push, or switch branches. If the brief is ambiguous or conflicts with the code you find, stop and report instead of guessing. Final message, short: files changed, verification results, open questions.",
"permission": {
"edit": "allow",
"bash": {
"*": "allow",
"*git add*": "deny",
"*git commit*": "deny",
"*git push*": "deny",
"*git checkout*": "deny"
},
"task": "deny"
}
}
}
}The permissions are the guardrails: the implementer may edit and run commands, but the git commands that would stage, commit, push, or switch branches are denied, and "task": "deny" keeps it from spawning agents of its own. opencode's Task tool has no model parameter – a sub-agent's model comes only from its definition – which is exactly what we want. general stays on Fable because the rare open-ended delegation is exactly the judgment call I want the expensive model to make; everything mechanical goes to implement-sol. My three reviewers (review-fable, review-opus, review-sol) follow the same pattern with "edit": "deny", and the routing rules live in the .opencode/OPENCODE.md referenced under instructions: Fable never implements; it writes the brief, launches implement-sol, runs the three reviewers in parallel on the same diff, and briefs implement-sol again until the review is clean. Bulk codebase fact-finding goes to explore, and external research to scout; both are pinned to Sol. And you can always address the sub-agents yourself with @implement-sol or @review-sol in the prompt.
Step 4: T3 Code on top. Install T3 Code, pick opencode as the harness for your project, and the model picker shows the Copilot models next to whatever else you have connected – see the screenshot in the app section. From here on, it's the workflow from above.
What you give up: Claude Code's hooks and /loop, the Codex CLI's 1M-token knob from bonus tip 1, and, since Copilot moved to usage-based billing, every Fable turn shows up as AI credits on your admin's dashboard – one more reason to let Sol do the typing. What you get: the frontier models on the subscription you already have, inside a harness that is actually built for agents. And if your admin still says no, the revolution I recommended in the costs post remains an option 😉.
Loop Engineering: The Buzzword of the Summer
One more thing, because you will run into this term anyway: loop engineering. Google's Addy Osmani gave the term its big write-up earlier this summer (in June 2026), and it comes with two very quotable one-liners. Boris Cherny, head of Claude Code at Anthropic, said on stage in June – as quoted by Osmani: "I don't prompt Claude anymore. I have loops running that prompt Claude." And Peter Steinberger, the creator of OpenClaw, was even more direct on X: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
The idea in one sentence: after prompt engineering and context engineering, the next skill is not writing a better prompt – it's not typing the prompt yourself. Instead, you design the system that prompts the agent: a schedule that wakes it up every morning, a hook that fires when CI turns red, a goal it iterates on until the checks pass – and only then stops. The tooling is already there: Claude Code ships /loop, hooks, and scheduled agents, and the Codex app has its scheduled tasks.
My personal take? The name is new, the substance mostly isn't. Strip away the branding and loop engineering is what the harness setup post has been arguing all along: an agent is a model running in a loop, and that loop is only as good as the feedback flowing through it. If your ng lint, tests, and Playwright runs give the agent a reliable signal, you can let the loop run longer without you – if they don't, a self-prompting agent just produces slop on a schedule. Even Osmani warns about exactly that: unattended mistakes and the comprehension debt of code nobody read. So my rule doesn't change – whatever ran while I was away, I still own the final judgment on every diff. I'm using loops in small doses so far, and I'll dig into where they genuinely pay off – and where they're just a fancy cron job – in an upcoming post of this series.
Until then, read Manfred Steyer's Loop Engineering with Super Mario and Twelve AI Coding Agents: he handed twelve coding agents the same two tickets – a Koopa Troopa for an Angular-based Super Mario clone – and let one automated loop run all of them. All twelve delivered, at a 160x spread in cost and a 19x spread in speed, and his key finding is my harness mantra in one sentence: every systematic failure traced back to something the tickets didn't say. Loops don't fix a vague spec – they execute it, literally.
Agentic Engineering Workshop
Model trio, app of the summer, orchestrator workflow – if this post shows anything, it's that the pieces keep changing while the system underneath stays the same. Learning that system, instead of chasing each piece, is exactly what our Agentic Engineering Workshop is about, available in English and German: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring for advanced Angular developers.
- 🤖 Agentic Engineering Workshop – 2 days, remote
Conclusion
Three months into this series, the pattern is becoming clear: the models rotate fastest (Fable 5, GPT-5.6 Sol, and GLM-5.3 Flash today – ask me again in November), the apps every few months (open-source T3 Code now, Codex as the alternative), and the harness setup barely at all. The cost picture is just as stable: the subscription is still the deal, and Fable 5 is still the one model worth rationing. Which is exactly why I keep repeating that the harness is where your investment compounds – everything else you should hold loosely.
If you take one practical thing from this update, make it the orchestrator workflow: let Fable 5 think, let GPT-5.6 Sol type, and let your guardrails make sure you can't tell the difference in the diff. And since a quarter is about how long these recommendations survive, the next edition of this update is planned for November 2026 – see you then.
You won't have to wait that long for the series itself, though: next week, it continues with the post I promised at the end of the harness setup post – Agent Skills for Angular Development. Where the harness gives your agent a clean workspace and an operating contract, skills give it repeatable procedures: a complete catalogue of Angular skills in a new companion repo, how to use third-party skills, how to write your own, and how to adapt them to your project. A good prompt helps once – a good skill helps every time.
Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️