There is a growing narrative that artificial intelligence is becoming cheaper, more capable, and more widely available.

On the surface, that is true.

For around $20 a month, an ordinary person can access models that can write, research, reason, generate images, analyze documents, and produce software. Capabilities that would have looked impossible only a few years ago are now sitting inside a browser.

That sounds like democratization.

But I am beginning to think we are measuring the wrong thing.

The real question is no longer whether ordinary people can access artificial intelligence.

The question is whether ordinary people can afford enough reliable AI capacity to complete meaningful work.

Those are not the same thing.

The lockout

I was recently working across two software projects.

The first was Laminar, a business systems platform I have been building around project delivery, operating workflows, client collaboration, and business process management.

The second was NeverØwe, a financial application designed to help sole proprietors and gig workers understand their tax obligations, cash flow, expenses, and financial position before they get blindsided.

I was trying to get NeverØwe fully released into the app stores as a subscription product.

That matters because I am not building these products from a comfortable position inside a well-funded company. I am unemployed and trying to create something that can generate income.

I was using Codex to assist with development across both projects.

Then the usage limit hit.

Not for a few hours.

Not until the next morning.

Five days.

Both development streams stopped at once.

There had been no meaningful warning that I was approaching the limit. No visible percentage showing how much capacity remained. No clear way to estimate the cost of the next task. No practical way to reserve enough capacity to finish one project before switching to the other.

The system simply reached the boundary and told me to come back later.

The immediate alternative placed in front of me was an upgrade from the roughly $20 tier to a $100 tier.

The higher-priced plan advertised five times more usage for five times more money.

That is not a productivity solution. It is linear rationing.

And if I had $100 to spend on a coding agent, I would spend it on Claude Code, because in my experience it was the better coding agent.

The cheaper compromise

I previously used Claude Code, but I allowed that subscription to lapse.

I could not afford to maintain two AI subscriptions, and Claude cost more.

So I kept ChatGPT and attempted to make Codex work.

That required adjustment.

Codex was not my preferred coding agent, but I invested the effort required to build a working process around it. I became far more cautious about allowing it to make changes. I started demanding code audits, implementation plans, impact analysis, reuse analysis, rollback considerations, and a clear explanation of what it intended to change before it touched the codebase.

That caution was not theoretical.

A misunderstanding by an AI coding agent can become destructive very quickly.

A model can make one incorrect assumption about the architecture, then confidently propagate that misunderstanding through database schemas, interfaces, services, tests, migrations, and user workflows.

By the time the mistake becomes visible, the damage may be spread across dozens of files.

So I now require the agent to explain:

  • what it believes the task is;
  • which parts of the codebase are affected;
  • what existing code will be reused;
  • what will be changed or replaced;
  • why those decisions are necessary;
  • what risks exist;
  • and how the work can be reversed.

That protects the codebase.

It also slows development substantially.

The AI is supposed to reduce my workload, but I increasingly have to supervise it like a fast, confident, and occasionally reckless junior developer.

I pay for its mistakes twice.

First, I lose usage while it misunderstands the task, retries failed approaches, or creates work that must later be undone.

Then I lose my own time auditing, correcting, and repairing the result.

When the usage limit finally arrives, none of that distinction matters.

Productive work and wasted work are counted the same.

The compute was consumed, so the allowance is gone.

Access is not capacity

This is where the claim that AI is being democratized becomes more complicated.

Technically, I have access to advanced AI.

I can open the application. I can select from several models. I can give it complex instructions. I can ask it to inspect software, produce plans, write code, run tests, and make changes.

That is nominal access.

But effective access is something else.

Effective access means having enough capacity to:

  • maintain context across a substantial codebase;
  • understand the existing architecture;
  • work through long implementation cycles;
  • run tools repeatedly;
  • verify results;
  • recover from mistakes;
  • preserve continuity between sessions;
  • and finish the task before the system stops.

A user may have access to the model without having access to enough of the model to produce a reliable outcome.

That distinction matters.

For casual tasks, the lower-cost subscription can be extraordinary.

It can summarize text, draft emails, explain concepts, help with research, produce marketing copy, and answer questions.

But serious software development is not a sequence of isolated prompts.

It is stateful work.

The agent must understand what already exists. It must preserve architectural decisions. It must remember what was approved. It must know what should remain untouched. It must run tests, inspect failures, trace dependencies, and verify that the final result still works.

The more complex the work becomes, the less useful a model is if it cannot maintain continuity.

I do not need the smartest model all day

One of the strangest parts of the current AI market is the assumption that greater model intelligence is always the most valuable upgrade.

It is not.

Most software development tasks do not require the most powerful model available.

They require a competent model that:

  • understands the repository;
  • follows existing patterns;
  • remembers the approved plan;
  • works carefully;
  • and has enough time and usage to finish.

I would gladly use a slower, less powerful model for most development tasks if it came with better codebase comprehension, stronger context retention, and substantially more usable capacity.

Routine development involves tracing behaviour, modifying business logic, extending existing components, writing tests, updating interfaces, and preserving compatibility.

That work often depends more on consistency than brilliance.

A moderately capable model with excellent context can outperform a frontier model that repeatedly forgets the architecture or consumes the entire allowance halfway through implementation.

Yet the pricing model is often built around access to the most capable model rather than around the capacity required to complete real work.

The user is sold intelligence when what they often need is continuity.

The emerging divide

The AI divide may not develop in the way people expect.

It may not be that wealthy users receive intelligent AI while everyone else receives unintelligent AI.

It may be that everyone receives impressive AI, but only well-funded users receive enough uninterrupted AI labour to use it reliably.

That is a more subtle divide, but it may be just as consequential.

A large company can absorb failed agent runs.

It can purchase multiple subscriptions, pay API charges, run agents in parallel, assign humans to review the output, and move another engineer onto the work if one tool reaches a limit.

An independent developer cannot.

When my coding agent stops, there is no second engineer.

There is no separate quality team, release manager, architect, or product owner.

I am all of them.

When the tool is unavailable, the entire production line stops.

A five-day lockout does not merely delay a few prompts. It destroys momentum across the entire project.

When access returns, the work must be reconstructed. The codebase must be reloaded into context. The unfinished plan must be reviewed. The branch state must be understood. The agent must often be reminded of decisions it no longer remembers.

Ironically, the interruption itself creates more future usage.

The people who need leverage most

This is the part that concerns me most.

The people who benefit most from AI leverage are often the least able to absorb unpredictable limits or expensive upgrades.

A well-funded company may use AI to reduce labour costs or accelerate an existing product roadmap.

An unemployed person may use AI because there is no budget to hire anyone.

A small business owner may use it because there is no marketing department, software team, analyst, designer, or operations consultant.

A solo founder may be trying to turn one viable product into enough income to survive.

For those users, AI is not a novelty or convenience.

It is borrowed capacity.

It is the closest thing they have to a team.

But borrowed capacity is only useful if it remains available long enough to complete the work.

A $20 subscription may appear affordable. But if serious use requires an upgrade to $100, multiple subscriptions, API spending, or repeated interruptions, then the true cost is not $20.

The true cost includes lost time, rework, delays, abandoned momentum, and unfinished products.

That is the $20 illusion.

The subscription gives access to the system.

It does not necessarily provide enough AI labour to produce an economic result.

A strangely appropriate ending

There is an irony in writing this article.

I normally use an agent connected to my blog to help assemble, format, and publish my posts.

Because I have now exhausted my available coding-agent capacity, I may have to publish this one manually.

There is something almost too perfect about that.

An article about the limits of affordable AI may itself require more human labour because the AI allowance ran out.

That does not mean AI has failed.

These tools are still astonishingly capable, and I have built things with them that would otherwise have taken far longer or may not have been possible at all.

But capability alone is not democratization.

Real democratization requires affordable, predictable, sustained access.

It requires enough context, enough continuity, enough verification, and enough usage to reach the finish line.

The meaningful metric is not how many people can open an AI application.

It is not how many models are listed in a dropdown.

It is not the cost per token or the benchmark score.

The real metric is simpler:

Can an ordinary person use the system long enough, reliably enough, and affordably enough to complete something that materially changes their life?

Until that answer is consistently yes, access to AI should not be confused with access to AI labour.