Why an AI Subscription Isn’t a Cheap API#
2026-08-20
The Better You Get at Using AI, the More Cost Matters#
When I first started using AI, model quality was what mattered most. I compared which model wrote better code, read long documents more accurately, and reasoned more deeply. But once AI became part of my actual work and my usage grew, my attention shifted. Using AI well now matters as much as being able to keep using it sustainably.
I felt this most clearly after spending entire days with coding agents. Attach a frontier model to architecture and debugging, let several agents work in parallel, and productivity clearly rises. But process the same workload through an API (Application Programming Interface), and the bill rises just as quickly.
That naturally makes subscriptions attractive. If $20, $100, or $200 a month lets you use Claude Code, Codex, or Antigravity extensively, it looks far cheaper than sending the same work through an API. For an individual with consistently high usage, a subscription really can be a powerful cost optimization tool.
But that is where a tempting assumption appears.
If a subscription is cheaper than the API, couldn’t I connect the subscription account to an agent and use it like a cheap API?
The more I investigated the technically possible routes, the clearer the answer became. An AI subscription is not a discounted API product. Its economics hold only within the products and usage patterns the provider allows.
A Subscription Is Not a Prepaid Bucket of Tokens#
A $200 monthly subscription invites a simple calculation:
monthly subscription price ÷ API token price
= tokens included in the subscriptionBut the number on the right is not the number of tokens actually included. It is only a cost-equivalent baseline showing how much API usage the same money could buy.
Anthropic, OpenAI, and Google do not publish a fixed token allowance for their consumer subscriptions. Instead, limits account for the model, reasoning effort, conversation length, context size, and tool usage. A million tokens spent on short conversations with a cheaper model do not consume the same allowance as a frontier model repeatedly reading a long context.
Time adds another constraint. A product may enforce both a five-hour limit and a weekly limit. Even with weekly capacity left, a burst of intensive usage can exhaust the session limit first. Conversely, session limits may keep resetting while accumulated weekly compute eventually blocks further use.
An API is a product where you pay for what you consume. A subscription is a right to prioritized compute within a defined product. They are not the same product with different price tags.
Why a Subscription Can Be Cheaper Than the API#
How can an AI provider include usage that appears to be worth far more than the subscription price at API rates?
The three companies do not disclose the true cost structure of their subscriptions. Still, common subscription economics and the controls visible in each product suggest several explanations.
First, not every subscriber uses the full allowance. Pooling light and heavy users makes average cost more predictable. The model resembles a gym membership or an unlimited mobile plan.
Second, the provider controls the workload. Inside an official app or coding agent, it can manage concurrency, model selection, context, caching, request priority, and reset windows. When demand spikes, it can slow requests or temporarily restrict access to a model.
Third, a subscription sells more than API tokens. Search, file handling, memory, voice, images, coding tools, and storage may all be bundled into one product. An API customer, by contrast, gains the freedom to call the model from any program, automate it, and expose it to customers. That freedom — and the operational responsibility that comes with it — is part of the API price.
The low subscription price is therefore less a simple discount than the price of accepting a narrower usage boundary.
An OAuth Token Is Not a Magical Subscription API Key#
OAuth (Open Authorization) lets a user grant limited access to another program without handing over a password. It appears frequently when connecting an AI account to a third-party agent.
That creates another mistaken inference:
authenticated with the subscription account's OAuth token
→ usage is deducted from the included subscription allowanceThat inference does not hold. OAuth first proves who you are. The server still decides whether the request consumes the subscription allowance, charges separate credits, or gets rejected altogether.
To understand billing, three questions have to be separated:
- Which credential authenticated the request?
- Which product or API route received it?
- Which usage account did the server assign it to?
The same OAuth mechanism can produce opposite results. A Claude subscription token sent through an API route may not reach the base subscription allowance at all. A request sent through the dedicated Codex product route, meanwhile, may consume ChatGPT’s five-hour and weekly allowance.
Authentication alone does not determine billing.
Anthropic Keeps the Subscription Allowance Inside Claude Products#
Hermes Agent’s Claude integration makes this distinction unusually clear.
Hermes can call the Anthropic Messages API using a Claude Code OAuth token. At first glance, connecting a Claude subscription account appears to grant access to the usage included in a Max or Team plan. According to the Hermes documentation, however, this route does not consume the base Max allowance. It requires Extra Usage credits on top of a Max plan, and Hermes requests are deducted from those credits from the first token.
In simplified form:
Claude Code
→ Claude's subscription product route
→ base subscription allowance
Hermes + Claude OAuth
→ api.anthropic.com
→ Extra Usage creditsSuccessful OAuth authentication and access to the included subscription allowance are completely separate facts. Anthropic offers subscription economics inside Claude and Claude Code, but it does not pass that benefit to a third-party agent calling the API with the same identity.
This looks less like a technical limitation than a product boundary. If third-party calls also consumed the base subscription allowance, one flat-rate account could become the inference infrastructure for backend automation or a commercial service.
The behavior is documented in the Hermes Agent AI Providers documentation.
OpenAI Leaves a Door Open Through the Codex Ecosystem#
OpenAI currently appears the most permissive of the three. Hermes can authenticate through a ChatGPT account for Codex and read the consumption percentages for the five-hour and weekly windows. Those requests go to the ChatGPT Codex product backend rather than the general OpenAI API.
Within that scope, Codex usage included in ChatGPT Plus or Pro can be used through a third-party agent.
But this should not be read as permission to treat the entire subscription as a general-purpose API. Hermes has two approaches with very different characteristics.
The first has Hermes call ChatGPT’s internal Codex endpoint directly. It works technically, but the endpoint is not part of a public API contract and the implementation depends on matching client headers. OpenAI can change it at any time, and its existence is not a sound basis for a business that collects customer OAuth tokens.
The second runs the official Codex CLI (Command Line Interface) or Codex app-server and has Hermes communicate with that runtime. Authentication and requests remain the responsibility of OpenAI’s own program, while Hermes acts as the higher-level orchestrator. For an individual automating Codex in a trusted environment, this is much safer in both policy and operational terms.
There is official support for this distinction. The OpenAI Codex authentication documentation explicitly lists signing in with ChatGPT as the path for subscription access. The Codex app-server documentation recommends app-server for deep Codex integrations inside another product and the Codex SDK (Software Development Kit) for automation and continuous integration jobs.
What remains open on OpenAI’s side is therefore not a cheap general-purpose API. It is room to automate Codex through an official agent runtime.
Google Draws the Hardest Boundary#
Google’s separation is more explicit. Google AI Pro and Ultra subscriptions apply to consumer products such as the Gemini app and Antigravity. Hermes’s default gemini provider uses a Google AI Studio API key and is billed separately. Vertex AI authenticates through OAuth 2.0, but its charges belong to a Google Cloud project.
Hermes once included providers that directly reused Gemini CLI and Antigravity OAuth. Those routes could access consumer subscription allowances. Hermes later removed both because of the risk of Google account enforcement.
According to the removal notice, a third-party tool reusing Gemini CLI, Antigravity, or Code Assist OAuth could put the entire Google account at risk, potentially affecting Gmail and Drive as well. This was not merely a matter of requests failing; it could endanger the account a person relies on for everyday services.
The background is documented in the Hermes change that removed the Google OAuth providers.
Today, using Gemini as Hermes’s primary model requires either an AI Studio API key or Vertex AI. Neither route consumes a Google AI Pro or Ultra subscription allowance.
Hermes can, however, invoke Google’s official Antigravity CLI, agy, as a worker. In that setup, Hermes does not extract an OAuth token and imitate an API client. It delegates a task to the authenticated official CLI. Google officially documents this non-interactive headless mode.
Hermes
→ launches the official agy process
→ agy sends the request with its own credentials
→ Antigravity subscription allowanceThis does not make Antigravity the primary Hermes provider. Hermes still needs a separate model to run its own orchestration, and only selected tasks are delegated to Antigravity. Even so, keeping credentials inside the official runtime makes the architecture considerably safer.
The official Antigravity CLI headless-mode documentation explains how non-interactive jobs reuse previously authenticated credentials.
Running an Official Runtime Is Not the Same as Imitating an Official Client#
From the outside, both approaches appear to use a subscription model inside a third-party agent. But stability and policy risk depend on who owns authentication and request construction.
- Official CLI / SDK: The provider’s runtime handles authentication and requests. Used within its documented scope, this is relatively stable.
- Public API with an API key: The third-party application sends requests through a contract the provider explicitly supports.
- Direct internal endpoint calls with an OAuth token: The third party tracks private implementation details, making both behavior and policy unstable.
- Imitating official client headers: This carries the highest technical and policy risk.
With an official CLI, the provider’s program owns token storage, refresh, request formatting, and limit enforcement. When the provider changes behavior, the official runtime can change with it.
Calling an internal endpoint directly makes the third party responsible for chasing private implementation details. The fact that something works today does not mean it is permitted or will work tomorrow. Technical possibility and contractual permission are different things.
Personal Automation and a Third-Party Business Are Different Problems#
There is an important distinction between an individual running an agent on their own machine and a company delivering a service to customers.
When an individual runs the official Codex CLI or Antigravity CLI with their own account, it remains close to an extension of direct product use. Even if an agent launches the CLI through a terminal, the account owner, execution environment, and beneficiary are the same person.
A third-party business is different:
collect customers' subscription OAuth tokens
→ store them on the company's servers
→ process requests on customers' behalf
→ use consumer allowances as inference infrastructureIf this were broadly allowed, a business could resell consumer subscriptions while avoiding API costs. From the provider’s perspective, that is the least desirable outcome: unpredictable server workloads would run at consumer pricing while bypassing API usage controls and safeguards.
“Offering OAuth login” and “granting the right to use subscription capacity in a third-party service” are therefore entirely different statements. The first is an authentication capability. The second is a business agreement.
Combining Multiple Subscription Accounts Is Not Cost Optimization#
Once a subscription appears cheaper than the API, another strategy comes to mind: create several accounts and rotate OAuth tokens. When one account reaches its weekly limit, move to the next.
Even if it can be implemented, this is not sustainable cost optimization. The concern is not merely hypothetical. The OpenAI Terms of Use prohibit sharing account credentials and circumventing usage limits. The Anthropic Consumer Terms prohibit sharing account credentials and automated access unless it uses an API key or is otherwise explicitly permitted. The Google Terms of Service prohibit bypassing protective measures and allow Google to suspend or terminate access for violations.
Operating multiple accounts to evade limits is likely to conflict with those provisions. It also increases credential-management and account-suspension risk. A change in detection rules could stop the entire service at once.
Worse, the business’s unit economics would depend on the provider continuing to look the other way. A structure that becomes riskier as the product grows is not optimization. It is technical debt.
Subscriptions are priced around expected individual usage. Pooling several accounts into something resembling server capacity breaks that premise.
Cost Optimization Starts by Separating Workloads#
There is no need to choose only subscriptions or only APIs. Because the products serve different purposes, separating workloads is the natural strategy.
Interactive Conversation and Development#
Use subscriptions inside officially supported products such as Claude Code, Codex, and Antigravity. When usage is consistent and stays within the allowance, this is where subscription economics are strongest.
Personal Local Agents#
Prefer a CLI, SDK, or app-server for which the provider officially supports subscription authentication. Avoid extracting OAuth tokens or imitating internal endpoints. A practical design puts the official runtime underneath and lets a higher-level agent orchestrate it.
Backend Automation and Customer-Facing Services#
Treat API cost as part of the product’s unit economics from the beginning. Design caching, batch processing, low-cost model routing, per-request budgets, and usage limits. Do not make customer consumer subscriptions the foundation of the cost structure.
A Hybrid Model#
Send difficult, human-guided work to frontier models under a subscription. Route repetitive or high-volume jobs through an optimized API. Keeping subscription fees and API spend as separate budget lines also makes the true economics easier to see.
Subscription Economics Hold Only Inside the Boundary of the Usage Right#
For an individual with consistently high AI usage, subscriptions can still be much more economical than APIs. In my own work, a coding-agent subscription has processed the same compute-heavy workload for far less than direct API pricing.
But that difference is not a pool of credits available everywhere. It comes with conditions: a provider-controlled product, an official runtime, and personal use.
Anthropic separates Hermes’s Claude OAuth requests from the base subscription allowance. Hermes removed its Google providers that directly reused consumer OAuth. OpenAI maintains a relatively open route around the Codex runtime, but that still does not grant permission to resell subscription capacity or treat it as a general API.
The most accurate way to understand an AI subscription is this:
An AI subscription is not a contract to buy tokens cheaply. It is a right to use AI economically within the products and runtimes the provider allows.
Individuals can make full use of that right. A third-party business, however, has to be built on the separate economics of APIs. Recognizing that boundary is the safest form of cost optimization over the long term.
This essay is based on public documentation and the Hermes Agent implementation and documentation as of August 20, 2026. AI plans, usage limits, and OAuth policies can change at any time.