OpenAI’s v3.6.0 release of openai-python on August 27 adds a single field to the usage object of both Responses and Chat Completions APIs: compute_units. It is one line in a changelog dominated by dependency bumps for mypy, pyright, and pandas-stubs. But that field is the quietest signal yet that the industry’s oldest pricing unit, the token, is being retired in favor of something closer to actual work performed.
The release notes, published by the openai-sdks team, list add compute_units to Responses and Chat Completions usage as the only feature in the release. The change is small in surface area. The semantic weight is large. For the first time, OpenAI’s official SDK exposes a metering unit that is not derived from token counts, but from the compute consumed to produce a response.
Token-based pricing has been the bedrock of the LLM economy since OpenAI launched the API in 2020. Every cost model, every dashboard, every fintech startup’s unit economics spreadsheet is built on the assumption that tokens are the atomic unit of AI cost. The assumption is convenient because tokens are transparent: developers can count them locally before making a request, estimate cost with a calculator, and audit bills against logs.
The problem is that tokens are a proxy, not a measure. A model that spends 20 seconds thinking through a chain-of-reasoning trace consumes far more compute than a model returning a single-word classification, even when both produce 50 tokens of output. The industry has known this for years, and the gap has widened as reasoning models like OpenAI’s o-series and DeepSeek’s R1 popularized long internal deliberation traces. Anthropic’s Claude models and Google’s Gemini have shipped their own reasoning variants. Token counts stopped tracking cost the moment models started thinking before they spoke.
compute_units is OpenAI’s answer, and it carries a specific implication: the company is moving toward billing for actual compute, not for text. The field name matters. It is not reasoning_units or thinking_tokens. It is compute, a direct reference to the underlying hardware and the time it spends active. That framing aligns with how OpenAI’s infrastructure partners, particularly Microsoft Azure, already meter GPU usage. The API layer is catching up to the hardware layer.
What makes the v3.6.0 change notable is that it lands in the usage object of both the Responses API and the legacy Chat Completions API. OpenAI is not gating the new field behind its newer endpoint. It is backfilling the old one. That suggests the company wants compute-based metering to be universal across its API surface, not a feature for early adopters. The SDK change is the plumbing; the pricing change is the policy.
There is a second signal in the release, buried in the bug fixes. The team hardened the X.509 workload identity integration. Workload identity is the mechanism that lets server-side applications authenticate to OpenAI without long-lived API keys, using short-lived certificates issued by a trusted authority. The hardening matters for enterprise deployments where secrets rotation is a compliance requirement. It is a sign that OpenAI is treating the Python SDK as an enterprise tool, not just a research convenience. The same release that introduces a new billing unit also tightens the authentication path for production workloads. Those two changes together describe a company positioning its SDK for serious, cost-aware, security-conscious deployments.
The dependency bumps in the same release are worth a glance for what they reveal about OpenAI’s internal tooling. The project moved mypy from 1.17 to 2.3.1, pyright from 1.1.399 to 1.1.413, and pandas-stubs across a major version boundary. Those are developer-experience upgrades, not user-facing features. They tell us the SDK team is investing in type safety and static analysis, which matters for a library that thousands of production systems import. A type-checked SDK is a more reliable SDK, and reliability is what enterprises pay for.
The deeper story is about the economics of AI inference. Compute-based pricing has been coming for a while. OpenAI’s own pricing page has long distinguished between input and output tokens, with output tokens priced higher because they require more compute per token. Reasoning models pushed that logic further, with output tokens priced at a premium that reflects the hidden chain-of-thought work. compute_units collapses those distinctions into a single metered quantity. It is a more honest unit, and it is a less predictable one.
For developers, the shift is double-edged. Token counts were knowable before a request. Compute units are not. A developer can estimate tokens from a prompt, but cannot know how many compute units a model will burn through before it responds. That uncertainty is a real cost for anyone building on a metered API. It makes cost forecasting harder, and it makes prompt engineering more consequential, because the compute cost of a response is now explicitly surfaced in the usage object.
The field also creates a new audit trail. With compute_units in the usage response, developers can log the compute cost of every request and compare it against the token count. That enables a new class of observability tooling, dashboards that show compute efficiency per model, per endpoint, per customer. Startups that build on OpenAI’s API will be able to measure which prompts are compute-expensive and optimize accordingly. The field is a gift to the observability layer of the AI stack.
The release is dated August 27, 2026, and the tag was pushed by the openai-sdks account on August 28. The timing matters. OpenAI has been shipping reasoning models with increasingly long internal deliberation traces. The compute cost of a single response has become a meaningful fraction of a developer’s bill. Surfacing that cost in the SDK is a recognition that the old unit of account, the token, no longer describes what developers are paying for.
There is a policy dimension here as well. Compute-based metering is a more direct measure of the resources an AI system consumes, and that makes it a more useful input for regulators trying to estimate the environmental or economic footprint of AI deployment. The EU’s AI Act, for example, focuses on compute thresholds for defining systemic-risk models. A standardized compute unit, exposed by the SDK, gives the market a common language for discussing those thresholds. Whether OpenAI intends it or not, compute_units is a contribution to the emerging governance vocabulary.
The field is new, and the pricing implications are not yet public. OpenAI has not announced a per-compute-unit price, and the release notes do not specify how the field maps to billing. That is the open question. The SDK change is the instrument panel; the price list is the policy. Developers should watch for the pricing announcement that follows, because it will tell them whether compute units are a reporting convenience or a billing reality.
What is clear is that the token’s monopoly on AI cost accounting is ending. The v3.6.0 release is a small, technical confirmation of a large economic shift. The next generation of AI cost models will be built on compute, not on text. Developers who start logging compute_units today will have the data they need when that pricing model goes live.
The release notes are unremarkable on their face, a routine patch with one feature and a stack of dependency bumps. But the single feature line is the one that will matter in retrospect. OpenAI just told the market that the unit of AI commerce is changing, and it shipped the SDK change to prove it.