DEV Community: Kernel Pryanic

Enjoy the Bubble While It Lasts: The Secret Behind Your AI Bill

Kernel Pryanic — Tue, 28 Jul 2026 11:48:11 +0000

This is the duplicate of my original post that was unlisted for unknown reason: https://dev.to/kernelpryanic/enjoy-the-bubble-while-it-lasts-the-secret-behind-your-ai-bill-475f

Somebody else is paying for your AI subscription. Not most of it. Almost all of it.

That's the open secret of this whole era, and it's not on the pricing page. The arithmetic is inconvenient enough that nobody selling you a plan is in a hurry to walk you through it.

SemiAnalysis did the obvious experiment: buy every plan OpenAI and Anthropic sell, then spend a month actually hammering them - long agentic runs, code generation that doesn't stop. A fully maxed-out ChatGPT Pro subscription burns through $14,000 a month of tokens at API prices. Claude Max lands near $8,000. You're paying $200. Serving costs are lower than list, so the real hole is nearer $3,500 a month - which is still seventeen times what you handed over.

Plan price vs. maximum possible spend at API pricing. Source: SemiAnalysis.

The utilization math is worse than the headline. OpenAI's margin on Plus and Pro goes underwater past ~11.4% of the available limit. On the top plan, it hits zero at around 5.7%. Everything above that is loss. The business model, right now, is that most subscribers barely use what they bought - and the few of us who do are the cost center.

We are the cost center, and that's the good news

If you're a software engineer using AI seriously, you are exactly the user these plans lose money on. Agentic coding tasks consume roughly 1,000x the tokens of a standard chat query, with frontier models burning over 100,000 output tokens on a single task. Every time you point an agent at a repo and let it run, you're spending someone's capital.

That someone is a pension fund, a sovereign wealth fund, a hyperscaler's balance sheet, a chip vendor financing its own customers. Which is to say: ultimately a fairly small number of very rich people and the institutions that move their money. Enormous piles of capital betting that habits formed today convert into pricing power tomorrow. The bet may be correct. It may be not. Either way, the capital has already been spent, and the receipts are landing in your terminal.

This is not a scam and it's not new. It's the same playbook that gave us $5 cross-town rides and two-day free shipping and cloud compute below cost. The difference is the multiple. Uber subsidized maybe 50% of a ride. This is 40-70x.

The part of the bill that is yours

Except we're not getting away completely clean, and this half doesn't make it into the launch keynote.

Go price a RAM kit. A 32GB DDR5 kit that ran $60-80 in early 2025 now asks $180-250. That's not a supply hiccup - Samsung, SK Hynix and Micron make over 95% of the world's DRAM, and they're pointing their wafers at high-margin HBM for AI accelerators. Datacenters are on track to absorb something like 70% of high-end memory output this year, up from 20-30% a few years ago, and the squeeze runs through at least 2027.

So there is a tax, just not on the invoice with our name on it. The giants underwrite our inference, and we underwrite their memory supply chain by paying triple for a component we've bought without thinking for twenty years. A few hundred dollars every few years against thousands a month of frontier compute is still an excellent deal - for us.

Worth noting who else is in that "us", though. The markup is on the memory, not on the AI plan, so it lands on anyone buying a laptop, a phone, a console, a prebuilt. Most of them will never open an agent. The subsidy flows to people who use AI, but the memory tax is spread across everyone who buys a computer.

But it's a tell. When memory - the one input you'd need to run models yourself - is what's being priced out of reach, the cheap path and the independent path are quietly diverging.

Bubble, but which kind

"We're in a bubble" is now the safest opinion in tech, which usually means it's about to stop being useful. The interesting question isn't whether - it's what happens next, and there are roughly three shapes:

It bursts. Capital dries up, the loss-leader plans die, and inference gets priced at what it costs. Uncomfortable, but not the end - the models don't unlearn anything.

It deflates. Prices creep up, limits tighten quietly, the generous tiers get renamed and repriced. Most likely, honestly. Nobody announces the end of a subsidy; they just adjust the quota.

The margins catch up. Per-token cost is falling somewhere between 9x and 900x per year depending on the benchmark, with a median around 50x, and API gross margins are already moving in the right direction. It's genuinely possible efficiency outruns the burn before the money runs out.

I don't know which one. Neither does anyone tweeting confidently about it. But all three end the same way: the gap between what you pay and what it costs closes. Only the third one closes it in your favour.

What to do with a subsidy

Burning tokens for sport is the obvious way to waste this. Probably the better move is to treat it as a window with a closing date you don't control.

Learn the workflows now, while experimenting is nearly free. The muscle memory of working alongside an agent - knowing what to delegate, what to verify, where it reliably lies to you - is the part that survives any pricing change. Skills are not repriced. Quotas are.

Build the things that only work at today's prices. Some ideas need so many tokens that they would never pay for themselves at the real cost of inference. Right now you can still run them - so run them, and find out what they are worth while the finding out is cheap.

And keep an exit. This is the argument I made about small models from a different angle: the same task that costs $14,000/month at frontier scale often costs approximately nothing on a 4B model running on your own hardware. Not for everything - for the long tail of focused, repetitive work that makes up most of what we actually automate. Knowing which of your workflows would survive a 10x price increase is cheap insurance, and you can find out in an afternoon. Buy the RAM before it gets worse, if you were going to anyway.

The honest position

We're living through a strange, brief moment where the most expensive computation ever built is available to individual developers at a rounding error of its cost, because a lot of very rich people are making a very large bet.

The secret was never that any single one of these numbers was hidden. It's that they're never put next to each other: what your plan costs to serve, what fraction of it you'd have to use before you turned unprofitable, and what happened to the price of memory. Each one is public, and each one got covered on its own - the compute economics as an AI story, the memory squeeze as a hardware story. Put them in the same paragraph and they describe a deal nobody is going to walk you through, because the labs have no reason to hand you the ruler.

Enjoy it. Use it hard. Learn everything you can from it. Just don't build your entire practice on the assumption that a subsidy is a permanent feature of the universe - and don't mistake the current price for the actual value of what you're using.

The bill is real. It's just not yours yet - most of it, anyway.

Enjoy the Bubble While It Lasts: The Secret Behind Your AI Bill

Kernel Pryanic — Mon, 27 Jul 2026 19:56:45 +0000

Somebody else is paying for your AI subscription. Not most of it. Almost all of it.

That's the open secret of this whole era, and it's not on the pricing page. The arithmetic is inconvenient enough that nobody selling you a plan is in a hurry to walk you through it.

Plan price vs. maximum possible spend at API pricing. Source: SemiAnalysis.

We are the cost center, and that's the good news

The part of the bill that is yours

Except we're not getting away completely clean, and this half doesn't make it into the launch keynote.

But it's a tell. When memory - the one input you'd need to run models yourself - is what's being priced out of reach, the cheap path and the independent path are quietly diverging.

Bubble, but which kind

It bursts. Capital dries up, the loss-leader plans die, and inference gets priced at what it costs. Uncomfortable, but not the end - the models don't unlearn anything.

It deflates. Prices creep up, limits tighten quietly, the generous tiers get renamed and repriced. Most likely, honestly. Nobody announces the end of a subsidy; they just adjust the quota.

What to do with a subsidy

Burning tokens for sport is the obvious way to waste this. Probably the better move is to treat it as a window with a closing date you don't control.

The honest position

The bill is real. It's just not yours yet - most of it, anyway.

Are We Using AI at the Wrong Scale?

Kernel Pryanic — Tue, 28 Apr 2026 11:07:28 +0000

We open our IDE and let a model running somewhere in the cloud read our entire codebase to add a null check - and track our behaviour along the way. We open Google Docs and ask Gemini to fix a typo. We fire up GPT-class models to refine a Slack message, restructure a comment, generate a thumbnail. We're going to shove AI into every single hole that has data for it to be trained on.

I'm not saying we shouldn't - that's the nature of expected technological progress, and there isn't much choice in the matter. But somewhere along the way we stopped asking whether the scale of the model matches the scale of the task. And the answer, more often than we'd like to admit, is no.

This isn't a doom take. We're not being replaced. We're just still in the early adoption phase, when most people don't fully grasp what AI is not and where its limits are, wishful-thinking about it a bit too much. Which means we can still shape it - like we shaped radio, then the internet, then open source. We just need to find a more natural path for this technology, before the current default ossifies into the only option.

The numbers don't support the defaults

Take Qwen3-Coder-Next: 80B total parameters but only 3B active - performing on par with models that have 10-20x more active compute, runnable on high-end consumer hardware (think a 64GB+ Apple Silicon Mac, or a beefy workstation card) instead of a datacenter rack. Go smaller still and it gets more interesting. A Qwen3-4B fine-tuned for a specific task matches a 120B+ model on that task, deployable on consumer hardware. Or take Chandra - a 5B OCR model purpose-built for PDF and image conversion that outperforms both Gemini 2.5 Flash and GPT-5 Mini on multilingual document benchmarks. Not because it's smarter. Because it's focused.

And every major model release is announced like an earth-shattering event, destined to shadow everything before it and boost everything tenfold. Then we actually start using the thing, and we find a modest improvement - mostly specific, mostly a derivative of what the model was trained on. Take the mysterious announcement of Anthropic's Mythos, supposedly "too dangerous to release" - we don't even know yet if it justifies the hype. Meanwhile this experimental article from Aisle already suggests small models can match or outperform it in vulnerability scans - one early experiment, but telling.

This isn't new, either. Chinchilla challenged the "bigger is always better" orthodoxy back in 2022, and since then the evidence has only stacked up - small models trained on high-quality data for a dedicated task can match or beat their much larger cousins. We just kept defaulting to the biggest available thing anyway, partly out of habit, partly because the cloud paradigm is being pushed hard by everyone with a stake in keeping us there. The headline outpaces the reality, and the reality is that for most tasks, we're already past the point of useful returns from going bigger.

A different path

There's another path, and it doesn't look like Cyberpunk 2037. It doesn't require massive H200 clusters just to prettify your CV. It leads to more equal AI distribution, and it doesn't try to substitute anybody.

That path consists of small, dedicated models trained to do one or a few specific things at most. Models that are just smart enough to fulfill their purpose, and small enough to avoid creating the false impression that they're replacing anyone. This is the mass AI of the future - a true symbiosis. Or to be more precise, it's proper tool use.

Because AI is not a being. It's a simulation of one: a very cleverly engineered statistical model that's good at approximation in a way that looks like adaptability. Treating it as a being is what gets us reaching for the largest possible model every time, as if we were asking a person for help. Treating it as a tool is what lets us match the model to the task - the way you don't use a chainsaw to slice bread.

What this looks like in practice is software built AI-native from the ground up, not bolted onto with MCPs and API calls to remote giants. A document editor with small models embedded or pluggable for grammar checks, restructuring, summarization, all running locally. An OCR pipeline that just does OCR, well - paired with a small RAG model that lets you actually search and query a shelf of scanned papers or PDFs locally. A video editor with a small model that clips and tags footage on your machine. An in-game AI that runs on the player's hardware. None of these require breakthroughs - the models already exist, or could be trained without a billion-dollar cluster if there's enough data available.

What's missing is the software paradigm to host them properly - and the orchestration layer to chain them together. If general AI adoption is in its early phase, small-model orchestration is in its infancy: tooling, conventions, ecosystems, all still forming. ComfyUI already lets people chain specialized image and video models into local pipelines - the closest thing we have to a working blueprint, though it's fragile and leans heavily on Python venvs. LM Studio and Ollama make running local models trivial and stable, but they're runtimes more than orchestrators. These are embryos - but they prove the paradigm works. And it's the part worth building out further.

Where the big ones still belong

Large models aren't a dead end. They're the right tool for genuinely hard, open-ended problems - complex coding across unfamiliar codebases, in-depth analysis, anything that genuinely requires reasoning across a wide context. The argument isn't "small models for everything." It's "stop using a trillion-parameter model to fix a typo."

The honest version of the AI future is mixed: large models where their capabilities are actually needed, and small specialized models for the long tail of focused tasks - which is most of them. Treating those two cases the same way is what's wasteful. Not the technology itself.

Why this matters

Using large models for everything is the dead end. Not because it doesn't work, but because of what it costs and where it leads. Every "fix this typo" routed through a frontier model is a small vote for the centralization of compute, the centralization of data, and the centralization of who gets to decide what AI does next. Multiply that by a billion daily prompts and you get the bubble we're currently inflating - one where the only viable AI is the kind that requires a hyperscaler to run.

The small-model path isn't just more efficient. It's more honest about what most AI tasks actually need, and it leaves room for AI to be something other than a service we rent from a handful of hyperscalers.

We can still take that path. Many of the models are already there, others are still to be explored and trained. The hardware is there. What's missing is the will to stop assuming bigger is always better - and the software to make small the new default.

Should Hand-Written Code Be Considered Art Now?

Kernel Pryanic — Sat, 18 Apr 2026 13:25:51 +0000

A few years ago, "writing code" meant sitting down and writing code with your own hands, kicking in a concentrated thinking process, being in a "flow". Today, more and more of it is generated, scaffolded, auto-completed, or delegated wholesale to AI. The act of typing out a function by hand has shifted pretty drastically from the default way of building software to delegating most of the code writing to AI.

And that shift makes me wonder: if coding by hand is no longer the norm, does it start to look less like labor and actually more like craft?

The car manufacturing analogy

Consider the automotive industry. Most mass-market cars roll off highly automated production lines. Robots handle welding, painting, and assembly with precision and speed that no human can match. Humans are still in the loop, but mostly as reviewers, inspectors, and exception-handlers - finding defects and making judgment calls the machines can't.

Then there's the other end of the spectrum. Bugatti, Pagani, Morgan, Rolls-Royce - manufacturers where people still shape body panels by hand, stitch leather in-house, and assemble engines one at a time. These cars cost a fortune, take months to build, and are objectively less "efficient" than their mass-produced counterparts.

Nobody buys them for efficiency. They're bought because they're considered art.

But here's the nuance worth keeping in mind: even these manufacturers don't do everything by hand. Machine-stamped steel, off-the-shelf electronics, supplier-made fasteners - all of it shows up in a Bugatti too. The craft is concentrated where it matters: the engine, the interior, the body lines.

The interesting thing is that hand manufacturing didn't become art because the craft itself changed. It became art because the context around it changed. Once automation became the default, building by hand took on a different meaning.

Software is going through the same shift

For decades, all code was hand-written - so we never thought of it as artisanal. It was just how the job got done. But as AI-assisted development becomes the norm, the way code gets produced is splitting in two:

Generated code - fast, cheap, good enough for MVPs, but without proper supervision it tends to turn into slop - plausible-looking code that quietly rots a codebase over time.
Hand-written code - slower, more expensive in human hours, but shaped by intent, taste, and experience at every line.

Real codebases won't be purely one or the other. Most will be a mix - boilerplate, glue, CRUD endpoints, and test scaffolding generated by AI, while the parts that really matter - the core domain logic, the critical algorithms, the architectural seams - stay hand-written. Same as the Bugatti. The craft gets concentrated where it counts.

And if the analogy holds, those hand-written parts might eventually carry the same kind of prestige a hand-built engine does.

What would make code "art"?

Art in craft isn't just about doing things the hard way. A handmade engine isn't art because it's slow to build - it's art because every decision was made deliberately by someone who understood the whole. The same could be true for code:

Intentionality - every abstraction, every name, every structural choice made for a reason.
Coherence - the handcrafted parts read like they were written by one mind, with a consistent aesthetic.
Restraint - knowing what not to add, which is something unsupervised AI-generated code famously struggles with.
Taste - the hard-to-articulate sense of what makes a solution elegant rather than merely correct.

And here's where it gets interesting. There's growing evidence that heavy AI use doesn't just change what we produce - it changes how we think. A recent paper from USC researchers argues that when people's writing and reasoning are mediated by the same handful of LLMs, their distinct linguistic styles, perspectives, and reasoning strategies get homogenized into standardized expressions and thoughts. An MIT Media Lab study observed the same effect at the neural level: participants who wrote essays with ChatGPT showed measurably lower brain activity, and their outputs converged stylistically.

If most code starts flowing through the same few models, codebases will start to look alike - same patterns, same abstractions, same "safe" choices. Which means the qualities above - intentionality, coherence, restraint, taste - were always valued, but they weren't distinguishing. When everyone writes code by hand, having taste is an advantage. When most code is generated, and generated code trends toward the average, the hand-crafted parts are what give a codebase its character.

The counter-argument

It's worth noting the other side. Software's value has always been measured by what it does, not by how it was made. A throwaway script that saves a team ten hours a week is more valuable than an elegantly crafted library nobody uses. If AI can produce working code faster and cheaper, the "art" framing risks romanticizing a slower, more expensive process for its own sake.

So, is it art?

I don't think all hand-written code is art, just as not every handmade object is. But I do think the category is emerging. Sometimes it'll show up as entire codebases built from scratch by human hands - small libraries, focused tools, passion projects where every line was deliberate. More often, though, it'll show up as the deliberate pieces inside otherwise ordinary projects: the core engine, the key abstractions, the parts someone cared enough to shape themselves.

Ten years from now, I suspect we'll talk about those pieces the way we talk about a Bugatti engine or a Patek Philippe movement: not because they're the most efficient way to solve the problem, but because someone chose to solve it with care, line by line, on purpose.

And maybe that's enough to call it art.

What do you think?