The Hidden Cost of AI Isn't Compute. It's Dependency.

Introduction

We've spent decades paying for software. Today we're starting to pay for intelligence.

For most of us, it happened so gradually that we barely noticed. Nobody sat down and announced a new pricing model for cognition. It arrived one API call at a time, inside product features that felt free because the interface hid the meter running underneath.

Somewhere in that gradual shift, the AI industry introduced a new economic unit. Not CPUs. Not GPUs. Not servers, storage, or bandwidth, the units software engineers have priced and budgeted for forty years. Tokens.

Ask a developer building an AI feature today what their biggest infrastructure question is, and the answer is rarely "how many servers do I need." It's "how many tokens will this cost per request, and what happens to my margins at ten times the usage." Millions of tokens. Billions of tokens. Token budgets, token limits, token-based rate plans. An entire vocabulary of cost has formed around a unit that didn't meaningfully exist in mainstream engineering conversation a few years ago.

This essay is not an argument that any of this is wrong. It's an argument that it's worth noticing, and worth asking whether the model we've backed into by default should become the only one available. A note on approach before we go further: what follows mixes verifiable facts, cited where the claim is empirical, with interpretation and opinion, which we've tried to flag as such rather than let blend together. FarmakoMed appears near the end, as one example of a different engineering choice, not as the argument's conclusion.

AI Invented a New Currency

It's easy to underestimate how strange this is until you say it plainly: developers building AI features today mostly don't buy GPUs. They don't provision FLOPS. They buy tokens, from a vendor's API, at a published rate, the same way a household buys electricity by the kilowatt-hour rather than by the generator.

Anthropic's own pricing documentation illustrates the shape of this clearly, every model it sells is priced per million tokens, input and output metered separately, with output typically costing several times more than input.^[1] OpenAI and Google structure their pricing the same way. This isn't one company's idiosyncrasy; it's the standard unit of the entire industry, and it has been standard long enough that an entire secondary market of pricing calculators, comparison sites, and cost-optimization consultancies now exists just to help engineering teams track it.

The consequence is that every AI request now has a measurable, itemizable price tag before it's sent. Every feature becomes, implicitly, a spreadsheet: multiply expected requests by expected tokens by the published rate, and you have a cost line that scales linearly, sometimes worse than linearly, with your product's success. A support-ticket summarizer that works beautifully for a thousand users can become a line-item risk at a million users, in a way a database query never was, because a database query didn't have a per-call invoice.

That's a genuine shift in how software gets priced and built. Compute used to be a fixed cost you amortized, buy the server, run it as hard as you want. Tokens are a variable cost that scales with usage, indefinitely, for as long as the feature exists. Engineers who grew up optimizing for CPU cycles and memory footprints are now optimizing prompts to shave tokens the way an earlier generation optimized SQL queries to shave milliseconds. It's the same discipline, aimed at a different meter.

Are We Renting Intelligence?

Software went through this transition once before. For most of computing history, you bought software outright, a box, a license key, an install disc you owned. Then subscription software arrived, and within a decade "renting" software access became the default, not the exception. Today almost nobody blinks at paying monthly for tools they'll never own a copy of.

That shift had real advantages: continuous updates, lower upfront cost, vendors who stayed invested in a product because revenue depended on renewal rather than a single sale. It also had a less-discussed cost: when the vendor changes terms, raises prices, or shuts down, the thing you were "using" simply stops being available to you, because you never possessed it in the first place.

The question worth sitting with is whether AI is repeating that pattern, one layer deeper. We didn't just start renting the software that wraps a model. Increasingly, we rent the reasoning itself, per request, priced by the token, with no cached copy left behind after the API call returns. A subscription you cancel still leaves you with your files. An AI feature built entirely on someone else's inference API leaves you with nothing portable if that API disappears or its pricing changes overnight.

None of this means renting is the wrong choice. For most products, most of the time, it's clearly the right one, building and maintaining frontier-scale infrastructure is not a rational use of most companies' engineering budget. The question this section is raising isn't "should you rent." It's whether renting should be the only option on the table, the default so total that alternatives stop being seriously evaluated at all.

The Invisible Employee

Here's one of the quieter shifts happening inside company operating budgets right now. It doesn't show up as "AI replacing jobs" in any dramatic sense, that framing is usually too blunt for what's actually happening. What's happening is narrower and, in a way, more interesting: for a specific category of repetitive cognitive task, companies are increasingly running a genuine cost comparison between a person and a metered API call.

Document summarization. Translation. First-pass categorization of support tickets. Drafting meeting notes. Sorting inbound documents. Generating boilerplate code. None of these are new tasks. They're tasks that were always done by some combination of junior staff, contractors, or nobody at all because there wasn't budget for them. What's new is that they now have a second, always-available bidder: a service priced by the token, with no onboarding time, no benefits, and a marginal cost that's a rounding error compared to a salary.

McKinsey's 2025 survey of enterprise AI adoption found that 88% of organizations now report regular AI use in at least one business function, up from 78% the year before, and that the most common uses are exactly this category: capturing, processing, and delivering information, often through a conversational interface, in support functions, marketing, and customer service.^[2] That's a fact, not a projection. What organizations choose to do with that capability, how they allocate work between people and metered inference, is where interpretation necessarily takes over, because the data doesn't yet tell a clean story either way.

The same report is worth reading for its other half, which complicates any simple "AI is replacing workers" narrative: only about a third of organizations report having scaled AI usage beyond pilots, and just 39% report any enterprise-wide profit impact at all, for most of those, under 5%.^[2] The invisible employee, in other words, is being hired experimentally far more often than it's being hired at scale. That's worth remembering before treating either the optimistic or the alarmist version of this story as settled.

Productivity Has a Hidden Dependency

The productivity story around AI is, by now, a familiar one: teams doing in hours what used to take days, individual output climbing, entire categories of drudgery automated away. Much of that is real. It's also incomplete, because the productivity gain and the dependency it's built on tend to get reported separately, if the dependency gets reported at all.

Every one of those productivity gains, when the feature is built on a hosted inference API, is running on top of a specific and growing list of things the team building it does not control.

None of that is a criticism of any specific vendor's reliability or intentions, the major providers have generally been careful stewards of exactly these concerns, publishing status pages, deprecation timelines, and pricing changes well in advance. The point is structural, not personal: a productivity gain that depends on five things outside your control is a different kind of gain than one that depends on infrastructure you own outright, even if, day to day, it feels identical. Software engineering has a long tradition of naming this pattern in every other context, vendor lock-in, single points of failure, bus factor. It's worth naming here too, rather than treating AI dependency as somehow exempt from concerns we'd flag immediately in any other architecture review.

We Forgot Where Intelligence Came From

Here's a thought worth sitting with, uncomfortably, for a moment: none of this, the models, the tokens, the pricing, the productivity gains, exists without an almost incomprehensible quantity of human effort that had nothing to do with AI at all.

Modern language models are, at their core, compressed reflections of what humanity has written down. Centuries of books. Peer-reviewed science. Medical research, published so the next physician wouldn't have to rediscover it from scratch. Open-source software, written by people who gave it away. Documentation, forum threads, Wikipedia edits, tutorials, journalism, art, teaching, an ocean of accumulated human explanation, argument, and craft, most of it produced by people who were never thinking about training data when they wrote it.

Language models did not create any of that knowledge. They learned from it, the way a student learns from a library, at a scale and speed no student ever could. We're not raising a legal or ownership claim here; that's a genuinely contested question working through courts, legislatures, and licensing negotiations around the world, and it deserves more care than a paragraph in an essay like this one can give it. The point being made here is philosophical, not legal: the intelligence flowing out of these systems has a very human origin, even when the interface makes it feel like it appeared from nowhere.

It's easy, using a chat interface for the hundredth time, to stop noticing that what's on the other end of it is, in some deep sense, a reflection of centuries of human effort, compressed, indexed, and made instantly queryable. Knowledge remains a profoundly human achievement. The tools we've built to access it faster are remarkable. They are not the thing itself.

What Kind of AI Future Do We Want?

Put the last few sections together and a genuine, open question emerges, one this essay isn't going to answer for you, because we don't think it has a single correct answer yet.

Should every intelligent interaction require a round trip to someone else's server? Should access to a capable model always be metered by the request, indefinitely, for as long as the feature exists? Is there a meaningful difference between "AI is a utility, like electricity" and "AI is a utility you can never generate your own supply of, unlike electricity, where rooftop solar is a real alternative to the grid"? If intelligence is increasingly built from collective human knowledge, does that suggest anything about how broadly the benefit of running it should be distributed, including the ability to run it without a subscription?

We don't think these questions have obvious answers, and we're suspicious of anyone who claims they do. But we do think the questions are worth asking on purpose, rather than letting the current default, cloud-hosted, metered-by-the-token, rented indefinitely, become the unexamined assumption simply because it arrived first and arrived fast.

Why FarmakoMed Explores a Different Path

This is the point where a company writing this kind of essay usually pivots to a solution. We'd rather frame it as an exploration, because that's what it honestly is: FarmakoMed is one attempt at a different engineering philosophy, not a claim to have settled the questions above.

FarmakoMed is a mobile medication-management app, and the features that would traditionally call out to a hosted AI API, recognising a medication from a photograph, summarising a scanned document, run instead on a language model executing locally on the user's phone, via Google's LiteRT-LM runtime, rather than through a cloud inference endpoint.^[3] That's a verified architectural fact about the current app, not a marketing description: the model, sized and quantized for mobile hardware, is downloaded once to the device and then performs inference there, using the phone's own CPU, GPU, or NPU rather than a remote server.

The reason this matters isn't that cloud AI is a bad idea, the sections above should make clear that we don't think that. It's that modern smartphones have quietly become capable enough to make a second option viable. Quantization and efficient model architectures now let multi-billion-parameter models run in a few gigabytes of RAM, on hardware that fits in a pocket, and the on-device AI market, smartphones as its largest segment, is projected by market analysts to keep growing sharply through the rest of the decade as this becomes more broadly practical.^[4] The compute that used to justify "it has to run in the cloud" is, for an increasing range of tasks, sitting unused in people's pockets already.

For FarmakoMed specifically, choosing on-device inference was never framed internally as only a privacy decision, even though privacy, keeping medical photographs and documents off a third-party server, is the most immediate benefit for a health app.^[5] It's also, distinctly, an economic and engineering one: because inference runs on the user's hardware, there is no per-request cloud inference cost for these features, no bill that scales with how often people use the app, and no dependency on a vendor's pricing page to keep the feature affordable next year.^[5] The Personal plan's medication scanning is free the same way a calculator is free after you own it, not free because someone else is subsidising each calculation.

None of this is presented as a complete answer to the questions this essay has raised. FarmakoMed's on-device features still depend on the phone manufacturer's hardware, on Google's LiteRT-LM runtime continuing to be maintained, on a model license that permits commercial use, dependencies of a different kind, not an escape from dependency altogether. What changes is which dependencies you're exposed to, and whether the ones you've chosen scale with your user count or stay flat regardless of how many people use the app. Ownership, resilience, and predictable long-term cost are the things being optimised for here, not the elimination of every external dependency, which isn't realistically achievable for any piece of software.

Conclusion

Cloud AI is not going anywhere, and it shouldn't. The largest models solve problems that no phone, however capable, will run locally for a long time, genuinely novel research, frontier reasoning, tasks where scale itself is the point. Nothing in this essay is an argument for abandoning that.

But somewhere in the speed of the last few years, we may have accepted one assumption faster than we examined it: that intelligence must always be rented, metered, and delivered from somewhere else. That assumption made sense when phones couldn't run anything meaningful locally. It makes less automatic sense now that they increasingly can.

Perhaps the next interesting question in this industry isn't only "how do we make the cloud bigger, faster, and cheaper per token." Perhaps it's also "how much of the intelligence people already carry in their pocket can they simply own", not instead of the cloud, but alongside it, as a genuine second option rather than a footnote.

One Last Thought

Technology should amplify human knowledge. It shouldn't make access to it something you have to keep paying for, forever, just to keep using what you've already learned to rely on. FarmakoMed is one exploration of a future where powerful AI increasingly belongs to the person using it, not because the cloud should disappear, but because a second option, genuinely available, is what makes the first one a choice rather than a default.