I paid $200 for $5,961 of API-priced AI usage. Now I'm building apps around a bargain that may disappear
By Max Tymoshyn6 min read
In the first 19 days of August, Codex recorded 8.183 billion tokens while I was using it through a $200 ChatGPT Pro subscription. At OpenAI's published API rates, the same mix of fresh input, cached input, and output would have cost $5,961.08.
That is not just a discount. It is an incentive to build software differently. At a 29.81× price difference, the rational short-term choice is to build apps that depend on a personal subscription, a CLI, and my laptop staying in the loop, instead of putting the model behind an API in the cloud.
I think that is bad, even while I keep doing it. The gap is too large to ignore, but I have to treat it as temporary. Subscription limits, supported tools, and prices can change, and none of those decisions is under my control. If the bargain disappears after an app depends on it, I will not just get a larger bill. I may have to move, redesign, or rebuild the workflow.
Claude showed the same pattern. My reproducible July record would have cost $4,785.23 at Anthropic's API rates against the $200 Claude Max fee. I audited both local CLI histories to measure how strong this incentive really is. The numbers explain why I am using it now. They also explain why every app built on it needs an exit plan.
The clean setup costs more than the awkward one
Anthropic bills Claude plans and API access separately. OpenAI does the same with ChatGPT.
A subscription pays for use inside the company's apps and supported tools. The API has its own bill, based on the model and how much text goes in and comes out. That text is counted in small pieces called tokens.
Heavy personal use makes the choice less tidy. The gap in my own usage is big enough that I keep redesigning the workflow around it. Work I can do under a flat monthly plan can feel painfully expensive once every call has a meter attached.

I said 20× and 30× in my original note. I have done the like-for-like calculation now.
I scanned the local token records on my Mac, removed copied history created by resumed and spawned sessions, kept each model and cache category separate, and applied Anthropic's published API rates and OpenAI's published model rates.
The results:
| CLI / subscription / period | Recorded tokens | API-equivalent price | vs. $200 plan |
|---|---|---|---|
| Claude Code / Claude Max · Jul 1–31 | 4.117 billion | $4,785.23 | 23.93× |
| Codex / ChatGPT Pro · Jul 27–31 (5 days) | 3.968 billion | $2,973.70 | 14.87× |
| Codex / ChatGPT Pro · Aug 1–19 (month to date) | 8.183 billion | $5,961.08 | 29.81× |
The 30× number is real for my August Codex workload. It is not a universal promise about either subscription.
Long-running CLI sessions reuse a lot of context. Cached input accounts for $3,916 of the August Codex total. I ran a deliberately unfair test against my own conclusion and priced every cached token at zero. Fresh input and output alone would still cost $2,044.76 — 10.22× the subscription.
This is an API list-price comparison, not an API invoice or a claim that OpenAI lost $5,761 on my account. ChatGPT Pro and API access are separate products. They have different limits, controls, and terms. The calculation only answers one question: what would the same recorded tokens cost at the published API rates?
The older Claude report behind my first note said $5,605 and 28×. I cannot reproduce that exact number because the detailed aggregate is gone and the surviving raw transcript store is smaller now. I am using the lower result I can reproduce today: $4,785 and 23.9×.
That is still large enough to change the software decision. A $200 plan can carry thousands of dollars of API-priced personal CLI work. Once the same work has to run in a shared cloud product, the meter changes the economics.



The cheaper version runs on my laptop
Take a CRM workflow. The clean version keeps the data and AI work in the cloud. It updates records on a schedule with no laptop in the middle.
The cheaper version keeps the data in the cloud but runs the AI through a local helper tied to my subscription. I can test more ideas and use far more AI without watching an API meter.
It works. It is absolutely stupid from a usability point of view, but it works.
Now my laptop has to be on, logged in, and working. If it sleeps, loses its login, or sits with a dead battery, the workflow can stop. Sharing is harder. A failed run and its logs belong to one person's machine.

The gap changes what I build and buy. I would use more AI inside Notion or ClickUp if the price matched Claude or ChatGPT. The add-ons aren't the point. I already have cheap access in the model app, so a local helper looks like the better deal.
This is a great deal and a risky system
It basically feels like a hotfix.
The hotfix is useful. It lets me build things I might skip under an open API meter. A temporary money decision starts shaping software I may use for years.
Plan limits, login methods, and usage rules can change. I don't know that this route will disappear, and I'm not predicting it. A workflow built around one laptop and one personal plan may need a rebuild if the route stops fitting the work.
It's impossible not to use this advantage, but it's increasing the risk.
A model company sells cheap access to a person and metered access to a software company. That company adds its product and margin. A heavy user has a reason to stay in the model app or build a local helper.
I can't prove that vendors planned this. I can see it in my own decisions. The cheap plan pulls useful software back to the person and the machine in front of them.
Which route fits the job?
The right starting point changes with the job:
- One person working at a laptop: Subscription app or local helper — cheap, interactive, and the person is already present.
- Work that must run without you: API plus a cloud service that runs the job — it runs on a schedule without relying on your laptop.
- Shared team or customer workflow: A product connected through an API — access, logs, ownership, and billing belong to the system.
- Prototype that may grow: Local now, with one replaceable AI connection — keep cheap testing now and make a later move smaller.
Price is one question. I ask three more:
- Does it need to run when nobody is there?
- Does anyone else depend on it?
- Can one person's laptop own the failure?
One yes may be enough to pick the API, even when the bill looks worse. A shared or customer-facing tool should run in company-controlled cloud software, not on one person's laptop.

Use the saving without betting the whole workflow on it
I still want the cheap route for work that fits it. I just don't want the AI login spread through every part of the system.
The CRM data should live outside the laptop. The code should have one clear place where it calls the AI.
Today, that place can point at a local tool. Later, it can point at an API. The switch won't be free, but it won't touch every piece of the workflow.

I want the move point written down before the hotfix grows: a second person needs access, the job must run overnight, one missed run matters, customers touch it, or the plan's rules change. Cheap now, with a known reason to rebuild later.
The cheap route needs an exit plan
I'm not going to stop using subscriptions for this work. The saving is too useful. It lets me build and test things I would skip if every action had an API meter attached.
I don't want a cheap plan to quietly own the business. If a workflow lives on my laptop, I want its data elsewhere, its AI connection easy to swap, and the move point written down.
The awkward answer is to take the saving and prepare for the rebuild. Pick one workflow. Write down the event that would force it off your laptop. That is the real price of the cheaper route.
