"The seat license isn't what hurts, it's the tokens."
not X, but Y... so this is very likely Opus 5 text, given timing and how it reads. has all the marks of it, one being very weird wording which makes it so hard to read the text.
Try it on a flaky connection. Every menu (maybe any action of any kind?) makes a roundtrip to the server before displaying, with a very slow timeout.
It's crazy how bad it is.
Maybe it is different for you, but for me the web app is flakey at best. A bug which has been a pet peeve of mine for the last 6 months: if you leave the page open for half an hour with nothing playing, sometimes all the play buttons just stop working and you have to reload the whole page before you can play anything again.
I've gone back to the high seas and bandcamp myself. Spotify stopped having humans curate their playlists back in like 2016 or 2018 and the subsequent ML algorithms always recommend the same sounding stuff, nothing ever new or interesting. I'm back to getting recommendations in real life and literally talking to bands after their sets on who they listen too.
Do you pay for Spotify? If so, I hope you never have to experience the dumpster fire that is their free version. Half the time you select a song to play it'll just start playing related tracks.
No mention of correctness or task success rate. This only works if the subagent model is much cheaper than the one running your session, which means it will probably be mistaken a lot more often [1] about what the code does. Routing purely on size tells you nothing about code complexity.
On top of that, saving 90% of input tokens != saving 90% "of tokens", output is wildly more expensive.
[1] especially if it's a really old model like Gemini 2.5!
> I've never had an issue with Codex or Claude reading massive files
Reading files isn't a problem they want to solve. The idea seems to be using a cheaper model to "scout" for the intended code, instead of an expensive one that reads all the things (and spends more tokens / thinks about them).
I think this might be useful because Opus 5 especially tends to over-read. So this looks like an "LLM Bloom filter", telling "hey this is the code you might want to read".
I have a stage-gated workflow that prioritizes “premium” token efficiency (Fable.) and getting the most out of my subscription services. (Which boils down to Fable running carefully prompted deepseek-flash agent teams that defer back to the managing agent for any design decisions in most work.) As part of that workflow the manager uses cheap reconnaissance agents to burn their tokens in order to build relevant repo context, instead of the managing model’s. I’ve been doing this since they released Opus and it occurred to me that most of my pre-implementation phase token use was going right into the garbage bin with file reads that have to be done to find the relevant code, but are very wasteful.
There’s an added benefit that the manager’s focus on strategy and task decomposition before actually handling the user’s prompted task directly seems to be a very good way to interact with Claude’s Fable safeguards, and I haven’t had any refusals doing this.
And while I haven’t ran any numbers, I can get orders of magnitude more out of my claude subscription doing this, especially with deepseek-v4-flash being as good as it is for as cheap as it is.
The creator (Eric Provencher) worked for Unity before that and he is exploring game development tooling etc (with an open token budget) its fun to see where things are heading in the on-demand future of handsfree blender output and animation
Im now fascinated by how exactly Bcherny generated that message using claude. Like is the entire issue resolution automated, or still guided in someway?
> So this is just delegating certain work to dumber models? I certainly wouldn't use Gemini 2.5 Flash (!!?) for code writing as suggested.
Why not, though? I started using OpenCode + GitHub Copilot, but I burned through my Claude Sonnet quota in just three days. I switched to GPT-5.4-mini, which uses far fewer tokens, and it’s often just as good as Sonnet. I think optimizing token usage is a good exercise. We often assume a model will be terrible, when it really isn’t.
This is true, but with the newer generation of models you don't want to do this yourself, they're really good at orchestrating and triage. Run Fable or Astra on low/medium, and tell them to come up with a plan then direct subagents using a weaker model (I like GPT 5.6 terra medium) to implement and verify, and review their work.
> and it’s often just as good as Sonnet. I think optimizing token usage is a good exercise. We often assume a model will be terrible, when it really isn’t.
“Often” doesn’t sound great. If the smaller model fails then I just wasted a lot of time and tokens.
On desktop, it's basically forced heavy smoothscrolling, with an attempt to replicate real motion by gradually slowing to a stop. Horribly laggy for those of us sensitive to such things.
The question is, are we doing this page for the sake of art or are we doing this for the sake of spreading and sharing information? These are two different domains with different requirements as to how the page works.
There is nothing wrong with art. It is a great thing, I hope to see more art in the world. However, if the goal is sharing information, which is supposedly the goal of a fairly large number of websites, art needs to be secondary to sharing that information. And then those things that add motion, whatever: you're adding art and harming the real purpose.
Allow me to put it more bluntly: if you are feeling like an artist, don't meddle with UX.
The comment above shows this type of people don't understand it. Yet they are the ones getting hired due to formal qualification. Those who do are at the intersection of design, engineering and computer science. The latter give you enough experience to understand the culture to recreate familiar _look and feel_.
Does anyone even review these blog posts before they get published? If nobody in the company can be bothered to review it, I don't know why they expect anyone to persevere with the AIphorisms
It cuts token usage because they are using a different service with a different token budget for the reader/code writer tasks.
You can also just delegate this to subagents with Claude Code (though you have a more limited choice of models unless you swap the cheaper models via OpenRouter).
I'm OK using a dumb model as a smart grep, but the whole point of using the frontier models is using their intelligence for the hard stuff like coding.
I’m currently on codex can it also this? I find it hard to make accurate benchmarks in token use for these kind of changes because I don’t keep repeating the same tasks.
Basically I run in luna high or extra high continuously with a terra subworker dedicated to planning and difficult research questions. Then I end with a final review in Terra or Sol depending how big the feature is.
yes, and you can do it entirely in developer instructions (AGENTS.md/SKILLS.md). No hooks or other executables needed. Check out `codex-subagent-router` for an example. Its overly complicated, and has a few things wrong, but it mostly works. In short:
- Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
- Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
- in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
- Explain they can use "default" or specify their own custom model settings if needed.
- Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.
Details to know:
- IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
- You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest.
Anyways, write you skill & subagent profiles and it basically "just works".
The downside of reading posts about the practical application of AI is that the practioner often uses AI to write it. I don't know why AI prose is so hard to read in the browser. I don't have any problem when reading off my TUI
Try it yourself, use a big model like Opus or Sol to implement everything by first making a plan using plan mode.
Then try distributing the task to a cheaper models like Luna Max or Gemini Flash 3.8.
During planning, the big model already reads the relevant files in context, while giving a smaller model a slice of work itself requires the big model to reason about the task distribution, review, etc.
When I've tried it using API-rate billing I've saved on $$ on the tasks where I split planning+execution into Sol+Terra or Terra+Luna even. I wasn't paying attention to the token count, I was paying attention to the spend.
There are a bunch of approaches that do this kind of thing to reduce token usage ("semble" came to mind, technically different but functionally similar) but their performance is usually mixed because the models haven't been RL tuned to use them as they have the default tool suite. Combine that with the incentive by Anthropic et al. to make you actually burn through as many tokens as possible and I don't see these kind of things becoming mainstream yet. Maybe once we reach a point where consumers actually care about cost (because LLMs have become commoditized) these cost-reduction approaches become relevant enough to actually finetune the model with them.
Read tokens are the cheap place to optimize — input is ~¼ the price of output. The money's in write-side re-reads/retries, and nobody put a dollar number on that.
So it's giving summaries to the main agent instead of source code? Is that it?
> If Claude needs to make edits based on the analysis, it still has to read the specific section directly.
Yeah iirc the sysprompt tells it that it must always (re-)read a file before editing it. I noticed this because I customized Claude Code to just read all source at startup (if the project was only a few thousand lines of code). And it would still read the stuff it had already read! Because the system prompt explicitly told it to...
>Tested against a Java monorepo across four scenarios, measuring tokens Claude would consume reading files directly vs. consuming the bulk-reader's summary or writing code via the code-writer. Mean bulk-read savings were around a whopping 90%.
>The code-write scenario is harder to measure in tokens because without shunt, Claude both reads the reference files and generates the output as expensive output tokens. With shunt, the code goes straight to disk, Claude never sees it.
So nothing about accuracy or actual performance? At least run against DeepSWE bench or something.
> The worker model found surface-level patterns but missed a subtle thread-safety bug in my testing. Claude spotted it in seconds once given the right context.
So the actual performance was bad.
It might be an acceptable trade off tho. If token costs become prohibitive, then using a meat engineer to actually debug could be cheaper.
Isn't this a somewhat standard multi-model setup? there's nothing ground breaking here, just delegate claude to plan -> smaller model for implementation.
Very standard in all coding harnesses/models I've worked with, with the bonus that everything listed in the "What doesn't work in Portal by Spotify" section still works. I've been watching Opus spin off work to Fable and Sonnet as appropriate all day.
Do you have specific instructions that cause this or did it come out of the box? Is it also when using normal prompting or only when you set a goal?
In codex I don’t see this behaviour despite having added the instructions to do so to my agents file. I also let that agents file be reviewed by Sol to come up with the right phrasing but no luck so far.
Here is another technique to save tokens: allow the model to read a skeleton of the source code before reading the code, to give it an index into the code so it can read targeted chunks.
There is a tool that uses ripgrep and treesitter that does this [1], adapted from the maki coding agent.
I want a local model that I talk to, and that delegates work to whatever model it deems adequate, simplifying and perhaps even anonymizing the prompts/data as it goes.
I sometimes get jumpscaped at the thought of older or less proven models used in enterprise settings. I understand the devex ergonomics argument; I'm not a fan of profiles concepts typically if trodding into delegation.
If you want an expensive model to reason on your files, you need to give them your files.
If you think a cheap model is smart enough to filter information to give to your expensive model, you can save some money. If you think your cheap model is smart enough to format your expensive output, you can save some money.
In practice, this didn't work well until Qwen 3.8.
Qwen 3.6 and (abliterated) Gemma 4 were almost there but still making mistakes.
I could only read one sentence, then skipped to another paragraph. Sure enough the scroll bar revealed a suspiciously long article. No human would ever write this much bland bullshit.
Why do people write like LLMs? Maybe they delegate all the work to a LLM and don't have the time or the will to edit the copy. How about telling another LLMs to replace at least the most common LLM patterns with something human looking?
I don't feel like this was a piece by someone who has used LLMs too much.
I'm fairly confident this is just LLM writing the majority, possibly tweaked by a human.
Opening line is a form of, "It's not X, it's Y": ".. isn't thinking. It's I/O".
Then the start of the second paragraph is that weird breathless kind of writing:
> Reading five files to answer a question about one method. Generating a test file that follows the exact same pattern as the twenty test files next to it.
More "It's not X, it's Y": The seat license isn't what hurts, it's the tokens.
The softly pressed insistence that AI is worth it, really: "The tooling pays for itself but only if..."
in my experience doing something like this is either the results are trash or the main agent is like: "this does not sound right let me look into the file myself" and then spending more tokens working on bypassing the limitation
> By 2028, AI coding costs are expected to blow past the average developer's salary. A quarter of engineering leaders already burn $200–$500 per developer per month on tokens.
Wasn't the AI promise to save costs? So it was a lie.
Smooth as butter with Firefox on Android. As for why scrolljacking is "allowed", web devs will always find new ways to do annoying things and work around browser constraints.
The Bloom filter framing is right. What made it work for me: the cheap model is only allowed to point, never to decide. Once it stopped judging anything and just returned file paths and line ranges, the quality complaints disappeared. The expensive model still does all the reading that matters, just on 10% of the bytes.
Unlike an actual Bloom filter (which does not return false negatives), the cheaper model is still trusted to correctly recognize synonyms, equivalent functional constructions etc.
One is strictly a performance optimization, the other is a speed/quality tradeoff. It might well be a very good one, but it’s a tradeoff nevertheless. The framing is misleading.
reply