A solo founder’s honest day with Opus 4.8 — four things it changed, four it didn’t, and the one review that cost 2.4M tokens.
Claude Opus 4.8 shipped on May 28, 2026. I build and run four SaaS products by myself — StandupFlow, QuietLog, DocDecay, and OriginBrief — so I spent that whole day running it through my actual work instead of reading benchmark charts. I wanted to see what changed in my own code, not on a leaderboard.
Every time a smarter model comes out, it’s tempting to say it changes everything. After a day with this one, my honest take is more boring than that. Some things genuinely got better. A surprising number didn’t move at all. The interesting part is the gap between those two lists, so I’ll go through both. The model helps, and it helps a lot. It just doesn’t help with the parts I keep hoping it will.
What changed
1. More headroom for the same price.
Standard pricing is still $5 per million input tokens and $25 per million output, same as 4.7. The model got better and the price didn’t move. There’s also a fast mode ($10 / $50) that runs about 2.5x quicker. For a solo developer with no revenue yet, that flat price matters more to me than the benchmark gains. If every new model came with a price bump, people like me would just fall off the frontier. More capability without paying more is about the best news I can get right now.
There’s a catch, though, and it shows up in #3.
2. It misses about a quarter as many code mistakes.
Anthropic says it’s roughly four times less likely to let a code defect through, so the miss rate is down to about a quarter of what it was. Day to day, that feels like fewer rounds of “generate, read it, point out what’s missing, regenerate.” That loop used to run several times per change. Now it’s noticeably shorter.
With four products to watch alone, fewer misses just turns into time. Trim the review loop a little on each one and you get an evening back. But a quarter isn’t zero, and I’ll come back to that.
3. It runs in parallel now (dynamic workflows), and it burns through tokens.
There’s a research preview in Claude Code that lets you fan a single session out into a lot of subagents working at the same time. Instead of one agent grinding through a list, you hand the work to many agents with different jobs and collect what they find. The headline use case is big migrations, driven from kickoff to merge with the test suite as the pass/fail gate. Working solo, it’s the closest I’ve gotten to having more than one pair of hands on the keyboard.
I tried it on a real change before shipping it to production. I had different agents review the diff from different angles, plus a few whose only job was to try to prove the others wrong — all in one command. I won’t oversell it, but it did the job, and the output was genuinely good. It caught a design flaw a normal self-review of mine had walked right past, the kind that would have broken production quietly.
Here’s the catch I mentioned back in #1.
That one review spun up around 30 agents and used about 2.4 million tokens. For one review.
The reason isn’t a mystery, and it isn’t my pet theory — Anthropic has written about it. In a multi-agent setup, every subagent gets its own context window. Put ten agents on the same code and that code gets read ten times and billed ten times. Anthropic’s own number is that multi-agent systems use roughly 15x the tokens of a normal chat, and they’ve said token usage by itself accounts for about 80% of how much better these systems perform. So the spending isn’t a side effect. It’s most of the reason the thing works at all.
Which means the strength and the cost are the same fact. The agents catch what a single pass misses precisely because they’re independent — and being independent is exactly why each one has to carry the full context again, and why you pay for it again. It’s not wasted. You’re paying for the coverage. It’s just a lot more than you’d guess.
So even at $5 per million, what a single command costs is a different order of magnitude. The per-token price stayed cheap. My monthly usage did not.
A couple of practical notes. On a subscription, running this interactively doesn’t cost extra, but it eats your usage limits fast and you’ll hit rate limits sooner. Run it headless or through the API and, starting June 15, 2026, it draws on a separate metered budget at API rates. Either way, “just parallelize everything” is rough on both your quota and your bill.
Anthropic’s own guidance is that this is for high-value work and overkill for simple tasks, and that’s exactly what I saw. Parallel isn’t a default. It’s for the moments that earn it: a serious pre-ship review, a wide audit, a big migration. A cheaper model doesn’t change that math. A powerful feature used carelessly can blow up your invoice in a single command, and that part is on me, not the model.
Remember me for faster sign in
4. I can leave it alone for longer.
Its reliability as an agent went up — 84% on the Online-Mind2Web benchmark. The number matters less to me than the loop it unlocks: hand off a task, walk away, check it when it’s done. Before, I felt like I had to keep one eye on it even after delegating. Lowering that babysitting cost takes real weight off cycling between four products all day.
But leaving it alone isn’t the same as forgetting about it. Whatever comes back, I still have to check it. Which is the other list.
What didn’t change (this is the actual point)
1. The model doesn’t know my business.
OriginBrief monitors only the sources a user picks. That’s a deliberate line, and no amount of model intelligence moves it — the product won’t start suggesting sources on its own. Deciding what to watch, and what to leave out, is a human call, and I made it on purpose.
This holds across all four products. The model speeds up how I build. It doesn’t decide what to build, what to skip, or why. When my own “what” and “why” are fuzzy, a smarter model just gets to the wrong place faster and more convincingly. Intelligence doesn’t come with a direction attached.
2. The architecture is still on me.
Here’s a small one. A job that runs every day had been failing for two weeks. Nothing dramatic: I’d stuffed an unbounded list into a field with a length limit and missed the edge case. A smarter model doesn’t catch a design mistake like that until I trip over it myself. It answers the instruction in front of it well; it doesn’t ask “how big does this list get a year from now, and does this still hold then.” That question was mine. The fix was boring too — break the list into fixed-size chunks, and don’t let one bad piece kill the whole run. Not clever. But it was my call to make, not the model’s.
3. Checking the work is still the whole job.
A quarter as many misses isn’t zero. Someone still has to confirm the thing is actually right at the end, and that someone is me.
If anything it gets harder as the model gets faster. Generation might be 10x quicker; my ability to verify it is not. So my real bottleneck now isn’t writing code — it’s keeping up with checking it. That’s exactly why I reached for the parallel review above: to push some of that checking off my own eyes and onto a structured crowd of agents. But setting it up, and making the final call on what they flagged, came back to me anyway. Tools make verification faster. They don’t make it go away.
4. The real bottleneck is still getting it in front of people.
I’ve written code for 25 years. Marketing is new. I’ve put more than a dozen articles out there “naked” — no distribution, no audience waiting for them. I publish one and it sinks. I write another and it sinks too.
The model makes the code faster. Structure makes the checking a bit faster. But getting what I built in front of the people who’d actually want it hasn’t moved at all. If anything, the faster everything else gets, the louder the silence around “okay, but who actually uses this” gets. That’s the part the model can’t help with, and the part I’m still worst at.
What I’m taking away
- A new model is a tailwind, not a turning point — it speeds up the work you already do; it doesn’t take over the calls only you can make.
- “Cheap per token” isn’t “cheap per month.” Save parallel / multi-agent runs (dynamic workflows) for high-stakes moments — a critical review, an audit, a migration — not routine tasks.
- The faster generation gets, the more verification becomes the bottleneck. Build structure to check the output; don’t let the model’s speed outrun your ability to catch its mistakes.
- The model can’t decide what to build, who it’s for, or how to get it in front of them. Direction and distribution are still entirely yours.
In closing
A new model is a tailwind, not a new destination. Designing the thing, checking it, getting it to people — that’s all still my job. Opus 4.8 makes the job faster; it doesn’t do it for me. And features like parallel ask for something back in return for the speed: knowing when to reach for them and what they’ll cost. The more the model can do, the more of these calls land on me.
So I’ll take the tailwind and keep rowing. It makes the rowing faster. Where to row is still up to me.