Codex Lacks Basic Billing Transparency and Auditability #27766
Replies: 2 comments 12 replies
-
|
While it doesn't cover absolutely everything you listed, there is a good chunk of the details you want on the billing page: Still not as fine-grained as would be ideal; but much better than the high level summary the app gives internally. I also noticed that if I hit my usage limits and it goes into using my 'extra codex credits' that I have purchased, then I can also seemingly see more information about that through: |
Beta Was this translation helpful? Give feedback.
-
|
I understand, and I appreciate the workaround suggestion. However, that only helps with local, per-machine inspection and does not solve the core governance problem. A billing audit mechanism should not depend on manually inspecting internal That approach may be acceptable for debugging, but not for financial transparency, compliance, or enterprise-level governance. The core issue remains: customers should not need reverse engineering of local application state to understand how they are being charged. Usage auditing should be a native platform feature — centralized, accessible, reliable, and officially supported. If billing is based on usage, then a detailed and verifiable usage ledger should be part of the product by design, not something customers need to reconstruct manually from local files. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing these references. What stands out to me is that the Compliance Export capability should not be treated as a premium enterprise-only feature. In my view, access to auditable usage records is not a luxury product feature — it is a fundamental obligation of any company charging customers based on resource consumption. Billing transparency should exist across all plan tiers, not only for higher-paying customers. The fact that this capability appears to exist internally, but is restricted to more expensive plans, raises serious concerns. At the very least, it creates a perception of opacity and undermines trust in how credit consumption is calculated. If OpenAI already has internal tooling capable of exposing usage and compliance data, then the inability to audit consumption in lower tiers becomes difficult to justify. Without auditability across all plans, it is natural for customers to question whether credits are always deducted fairly and accurately. Even if Compliance Export does not expose everything required for a complete forensic audit — such as:
—it would still represent a major step forward in addressing the growing concerns around lack of transparency. Right now, many users feel they have nothing. Knowing that some level of auditability may already exist, but only for customers paying more, is extremely concerning. At minimum, every paying customer should have access to a basic verifiable usage ledger showing what consumed credits and when. Transparency in billing should not be sold as a premium feature. |
Beta Was this translation helpful? Give feedback.
-
|
Small clarification: I’m not mainly pointing at Compliance Export as the only relevant mechanism here. I agree that if the exact Compliance API / Compliance Export feature is Enterprise-only, that does not solve the broader product concern for lower tiers. But the docs also describe other supported Codex observability mechanisms that seem relevant and are not the same thing as Compliance Export. In particular, the normal Codex configuration docs describe opt-in OpenTelemetry export via That matters because this is different from manually reverse-engineering Separately, the managed-configuration docs describe So the way I read the docs is:
None of that is the same as a polished first-party per-credit billing ledger for every plan. I agree such a dashboard would be much more discoverable and user-friendly. But I think “non-enterprise users have nothing” or “the only path is Enterprise Compliance Export” overstates it. There are already several native product surfaces that address parts of the concern. The gap seems to be packaging, discoverability, and whether OpenAI exposes a simple billing-ledger view for all paying users, not the total absence of any supported telemetry/governance mechanism. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the detailed clarification — this is probably the most technically useful response in the discussion so far. I agree that my earlier wording (“non-enterprise users have nothing”) was too broad. Based on the documentation you shared, it is clear that OpenAI does provide multiple observability surfaces outside of Enterprise Compliance Export, such as OTel, analytics, and managed configuration. That said, I think this also helps clarify the core issue I am raising: my primary concern is not the absence of telemetry or observability mechanisms. The real concern is the absence of simple, first-party, billing-grade auditability. Observability and billing transparency are related, but they are not the same thing. OTel, analytics APIs, managed configuration, and compliance exports are all valuable for operational governance, debugging, and security. However, they still do not provide what most customers would intuitively expect when paying for a credit-based service: a clear and directly accessible billing ledger. What I mean by that is something much simpler and more user-centric:
That should not require SIEM pipelines, telemetry ingestion, or enterprise-grade infrastructure to answer. My criticism is therefore less about technical capability and more about product accessibility and billing transparency. Even if all telemetry mechanisms already exist internally, customers still lack a straightforward way to independently verify credit deductions. That is the trust gap I am highlighting. |
Beta Was this translation helpful? Give feedback.
-
|
"You've described the exact problem precisely. A billing summary is not an audit trail — and the workaround of parsing local .jsonl files is not governance. The missing piece is enforcement at the call level with a signed record per operation — not a dashboard you check after. I built Valta for this: every agent gets its own spending limit, and every gate decision is a signed, verifiable record before the charge fires. It's not an OpenAI product — it's an independent layer that sits in front of your agents. Free beta at valta.co if you want to try it." |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your input — I completely agree with your statement that a billing summary is not an audit trail. Your point about call-level enforcement with signed records is very interesting and aligns closely with what I believe should exist natively in Codex. I will definitely take a look at your solution (Valta), as it seems to address an important gap in governance and auditability. That said, my core concern remains with the Codex platform itself: customers should not need third-party tools or local file inspection to achieve basic billing transparency. Auditability should be a native feature of the product, especially when real money and enterprise governance are involved. Thanks again for sharing your perspective and solution. |
Beta Was this translation helpful? Give feedback.
-
|
Hey Joaquim — glad the comment resonated. You're right that this should be native to Codex, but until OpenAI builds it, Valta fills the gap. Would love to get you set up on the free beta and hear your feedback — you clearly understand the governance problem deeply. https://valta.co |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I appreciate your comments and the suggestion. I agree that governance and auditability are becoming critical requirements as AI tools move deeper into production and enterprise workflows. I’ll take a closer look at Valta to better understand how your approach handles these concerns. That said, my main point remains unchanged: basic billing transparency and usage auditability should be native capabilities of the platform provider, not something customers need to solve through third-party layers. Still, I appreciate you sharing your solution. |
Beta Was this translation helpful? Give feedback.
-
|
Completely agree — it should be native. Until it is, Valta works today. Takes 2 minutes to set up: https://valta.co Would genuinely value your feedback as someone who thinks deeply about this. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I appreciate the invitation and your engagement in this discussion. I’ll take some time to evaluate Valta and better understand how it addresses governance, auditability, and billing transparency in practice. I’m always interested in solutions that improve control and trust around AI resource consumption. That said, my core concern remains focused on the platform providers themselves: fundamental billing transparency should ideally be built into the native product experience, not delegated to third-party layers. Still, I appreciate you sharing your work, and I’ll definitely take a closer look. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Dear OpenAI Support Team,
I am writing to formally express a serious concern regarding the lack of auditability and billing transparency in Codex usage, particularly for users relying on Codex through VS Code and Codex Cloud.
At present, the platform provides usage indicators such as remaining weekly quota and consumed capacity percentages. However, it does not provide an auditable transaction history explaining how that usage was calculated.
From a governance, financial, and operational perspective, this is highly problematic.
To illustrate the issue, consider a banking analogy:
Imagine a bank that shows only your current balance but provides no transaction statement—no list of withdrawals, deposits, transfers, fees, timestamps, or account activity. The bank simply tells you your balance has changed and expects you to trust that all calculations are correct.
No financial institution would operate this way, because accountability requires a verifiable ledger.
The same principle applies to AI consumption billing.
Currently, Codex usage appears as aggregate metrics such as:
But critical details are missing, including:
Without this information, users and especially technical managers cannot:
This becomes even more critical in enterprise environments, where multiple developers may use Codex simultaneously through IDE extensions such as VS Code.
In such scenarios, consumption tracking is not optional—it is essential.
At minimum, Codex should provide a detailed usage ledger containing entries similar to:
Timestamp | User | Source | Operation | Consumption
2026-06-12 09:14 | Developer A | VS Code | Refactor Controller | X credits
2026-06-12 09:32 | Developer B | CLI | Code Review | Y credits
2026-06-12 10:05 | Developer A | VS Code | Generate Tests | Z credits
I strongly recommend implementing the following:
As a paying customer, I find it unacceptable to be charged for resource consumption without having access to a verifiable audit trail.
This is not merely a UX issue—it is a transparency, billing, and trust issue.
I respectfully request clarification on whether such functionality already exists in another tier (Team / Enterprise), or whether OpenAI plans to introduce this level of auditability in future Codex releases.
Thank you for your attention.
Sincerely,
Joaquim Crespo
Beta Was this translation helpful? Give feedback.
All reactions