Dev Breakfast · 2026-10-07

SemiAnalysis re-measures the cost of every subscription every day, and finds that at the same price point, the API-equivalent value Anthropic's plans convert to can exceed OpenAI's by more than 5x — but only when you're running the right model and token type. So don't ask which plan is worth it; first ask whether what you burn every day is input or output.

The same $200 Claude plan: what it's worth depends on which model you run

SemiAnalysis ran the numbers on subscription plans: at the same price point, the API-equivalent value of an Anthropic subscription can reach more than 5x that of OpenAI. But the conclusion comes with a caveat — that multiplier isn't fixed; it changes with the three-way combination of "plan + model + workload."

The essence of subscription pricing is this: you pay a set amount each month in exchange for a quota of "credits," and each (model, token type) combination consumes credits at a different rate. The key point is that the credit-consumption ratio doesn't line up with the API pricing ratio, so the value of the same plan swings wildly depending on which model you run and whether you lean toward input or output. The source puts it bluntly: saying "this plan is worth X dollars" in isolation is meaningless — you need the full (plan, model, workload) combination. And that combination keeps shifting: vendors can quietly retune limits by adjusting credit costs at any time, and promotions and new model launches adjust things publicly. SemiAnalysis's approach is to re-measure the cost of every (plan, model, token type) every day, exposing changes in real time.

How did they measure it? They isolate one token type at a time and run repeated calls to see how far the vendor's usage meter moves. Input, cache write, and cache read share the same prompt template, built from excerpts of War and Peace — because stuffing large blocks of garbage text makes some models refuse outright. For input tests, a random tag is appended on each call to guarantee a cache miss; for cache read tests, a fixed tag makes the first call a cache write and every call after a read. For output, a technical article is used to force long completions, because mechanical prompts like "repeat SemiAnalysis a hundred thousand times" get refused. Two things are recorded per call: the vendor-billed token counts by category, and the usage-meter reading. Since a single request often doesn't budge the meter, they measure in "steps" — the token count accumulated between two meter movements is the cost of moving the meter one notch, and the incomplete first and last steps are dropped entirely.

For people who write code, this means two things. First, when choosing a subscription, don't just look at the price and relative claims like "5x more usage than Plus" — OpenAI once priced plans with "Expanded Codex usage," "5x more usage than Plus," and "20x more usage," then cut usage on the $200 plan in half and pulled relative-usage claims off the pricing page; relative multipliers are inherently unstable. Second, your own bill depends on your workload: agent loops dominated by cache read and long-form generation dominated by output eat through quota on completely different scales. The source also gives the weight subscriptions carry in a vendor's finances — subscriptions make up only about 10% of Anthropic's total revenue yet can consume over 40% of its inference compute, dragging blended revenue per megawatt down by roughly $36 million. That also explains why limits keep getting re-adjusted: what's at stake isn't chump change.

💡 Chef's take: The most useful thing here is that it breaks "how much is this plan worth" into a reproducible triple — you can totally build a small script yourself, run it locked to a single token type, and see how many tokens it takes to move the meter one notch. That's more accurate than any comparison chart.

Sources:

• Anthropic Subscriptions Offer 5x+ More Value Than OpenAI

Vibe coding isn't as fun as hand-writing code: a viral HN post spells out 'frontloading the fun'

An essay on vibe coding climbed to the top of HN, and its title states the conclusion outright: vibe coding isn't as fun as writing code by hand. The author doesn't deny that AI let him build things he never could before — a bookmarklet for "has this link already been on HN," a small prediction-market simulation game, a wildfire early-warning system built on Pyronear (running on Lumo's free plan, working in two afternoons, able to pick out the first frame of smoke in an ignition scene), and a database migration assistant for a Kobo e-reader. He wouldn't have hand-written most of these, because it isn't worth spending weeks on. But he breaks "fun" down into six sources: the excitement of an idea, the excitement of making that idea real, the sense of accomplishment after a hard fight, the satisfaction of doing a job well, the excitement of learning itself, and the satisfaction of solving your own real problem. Vibe coding reliably gives you the first, second, and sixth; the third, fourth, and fifth are not its natural byproducts.

That decomposition carries more information than taking sides on whether "AI is any good." He calls vibe coding's core mechanism "frontloading the fun": the moment an idea surfaces, you have a runnable prototype minutes later, and the dopamine hits immediately. The cost comes later — refactoring code vibe-coded into existence is anything but thrilling. He also offers an analogy: it's like a string of first dates. You haven't built a relationship with the project, so you never get that sticky sense of belonging. Another line cuts deeper: vibe coding inserts a layer between you and reality. You're like an executive at a big company — everything looks like it's taking shape, but you're always suspecting that someone underneath is slacking off or sabotaging things, and aside from keep throwing money in and shouting louder, there's nothing you can do. He even quotes "dangerously-skip-permissions" to describe the auto-approval hook he set up — people who write code will crack a smile at that phrase, then wince a little.

For someone who writes code every day, the value of this piece isn't in "should I use AI" — it hands you a coordinate system for self-checking. The last time a piece of code made you happy, was it because it ran, or because you finally understood why it runs? The former has a very short half-life; after a few repetitions it goes dull. The latter compounds. The author doesn't draw a hard line either — he admits hand-written code is often unpleasant: your first time writing Go, your first twenty-odd lines wrestling with the Rust compiler — these are certified-unhappy moments. But that's "type two fun," the kind that hands you achievement and a "I figured it out" afterwards, and makes the next time easier. So if you're going to use AI, it's worth picking the things you wouldn't have done and don't intend to learn, and pouring the saved time into the part you genuinely want to understand. As for this essay itself — by his own account, the outline was written by candlelight in blue ink, and AI wasn't even allowed to fix a typo.

Sources:

• Vibecoding isn't as fun as writing code by hand

Mistral Large 4 opens preview: 1T params, 49B active, weights not out until month-end

We covered the Mistral Large 4 launch in earlier issues, where the takeaway was Europe's flagship model reaching its fourth generation. Today's item isn't a new release — it's the model opening to public preview. For people who write code, that moves from "knowing a model like this exists" to "I can call its API today." The codename "Le Chonk" was also disclosed here — the official line being "informally it's ML4, officially it's le Chonk." Naming a 1T-parameter model a fat cat: Europe's naming chill is genuinely in a league of its own.

Let's get the specs right first: 1T total parameters, 49B active, natively multimodal, trained on 3,800 NVIDIA Grace Blackwell GPUs in Mistral's own European data centers. You can try the preview API on Mistral Studio right now, but the weights won't ship until month-end — the official line is that this window is for red-teaming in real environments, and what partners receive is the same version with "reduced moderation, extended networking capabilities." A few numbers that line up: DeepSWE v1.1 at 61.7%, SWE-Atlas-QnA at 59.4%, Terminal-Bench 4 at only 28.3%, an overall 49.8% on the Coding Agent Index — ahead of DeepSeek V4 Pro 0813 and Qwen3.8 Max; in Surge AI's blind test it ranks second (3.74), behind Claude Opus 5 at 4.22. The loudest claim in the marketing copy is "the best open-weights model in the US or Europe" — note the qualifier is "in the US or Europe," which carves the Chinese open-source models out of the comparison. When reading rankings like that — where the track gets drawn by the runner — keep that in mind. On visual grounding, Dense 200's 42% edges out GPT-6-Astra's 41%; a one-percentage-point "victory" that wins within the margin of error.

The most practical item for us is the weights. The API is live today, but self-deployment waits until month-end — if you want to slot it into your own pipeline or run it for offline code completion, all you can do for now is wire up the API and get a feel for it; don't rush to rework your architecture. The other item official comms leaned on is the cybersecurity scenario: they claim Claude Opus 5.5 and GPT-6 Astra score near zero on tests like "reproduce a vulnerability and then patch it" — refused outright, out of safety guardrails — while ML4 scores 82%, solving 93% of Cybench's 40 questions. There's a fair point here: closed-source safety filters genuinely do get in the way of legitimate vulnerability research. But be clear-eyed about this too: this capability ships alongside a reduced-moderation version. Once you deploy it yourself, where you draw the boundaries is your problem, not its.

Sources:

• hackernews · j-bu
• hackernews · apt-get

Claude Code's suggested-message feature: the real customer might be the model, not you

In earlier issues we covered Claude Code leaving engineers feeling drained, with the sentiment leaning negative. Today's item is the same product from a new angle: on that "suggested messages" feature, the author argues the real customer is the model, not the human. The earlier take looked at human engineers' experience; this one asks who the product design actually serves — the two perspectives don't conflict, they explain each other. If this item flips your evaluation of Claude Code, this is the hinge: the feature isn't there to save you trouble, it's there to let the model run smoother. My inclination is to ask one question first: on what data was this feature validated as effective?

Sources:

• hackernews · zed_labs_dev

Pressing enter for 12 hours: Claude Code accused of draining engineers

An engineer posted anonymously on X saying that at their company, everything from product specs and tests to tickets and reports is generated by Claude Code; people work 12 to 13 hours a day, and their main action is pressing enter. He described the job as "soul-sucking," and said engineers from L1 to L7 are all doing the same thing: talking to Claude. He's not against using AI — he's against having no time to review the code that gets generated, and nobody actually fixing bugs. In the post, management's metrics are sprint cycles, PR count, and number of features shipped — stack those numbers together, and who's still willing to spend two hours reading a diff? I've sat on the judge's bench: what we're looking at is whether you can explain clearly what you changed and why you changed it that way — you can't press enter your way into that.

Sources:

• hackernews · hefner1456

---

The pile of work in front of you — are you going to keep computing credit costs model by model, or just switch to paying by actual API spend? See you at 8 tomorrow morning.

This issue selects 5 items out of 61 collected over the past 24h across X / Hacker News / GitHub Trending (written up hour by hour, fact-checked, then curated for the morning). Content is LLM-assisted and generated; every item links back to its original source, and important decisions should be cross-verified.