Bug report request] Bedrock GPT-5.6 Sol usage is substantially underreported by Codex telemetry

[arieleiz]

Issue creation is currently restricted in this repository, so I am posting this as a discussion and asking a maintainer to triage it as a bug report.

Environment

• Codex CLI: 0.149.1
• Model: OpenAI GPT-5.6 Sol through Amazon Bedrock
• AWS region: eu-central-1
• Date range: 2026-08-26 through 2026-08-28 UTC
• ccusage: 20.0.20

Observed AWS billing

For the same three-day period, AWS Cost Explorer reports approximately:

• 424.18M long-context input tokens: $4,241.83
• 148.20M standard input tokens: $740.99
• 420.96M long-context cache-read tokens: $420.96
• Other associated meters: approximately $185.48
• Total actual AWS spend: $5,589.26

Observed local telemetry

Codex JSONL session telemetry and ccusage produce a much lower estimate.
The dominant Codex session alone reports approximately:

• 15.06M non-cached input tokens
• 1,096.79M cached input tokens
• 1.52M output tokens
• Estimated local cost: approximately $669

Across the matching date range, the local estimate is approximately $697,
versus $5,589.26 billed by AWS.

The discrepancy is not explained solely by the documented 2x long-context
input multiplier. AWS classifies hundreds of millions of tokens as billable
long-context input that the local Codex telemetry appears to classify as
cached input.

Questions

1. Is cached_input_tokens returned by the provider, or calculated by Codex?
2. Does Codex 0.149.1 omit or combine cache-write/input-token categories?
3. Can Codex expose whether a request crossed the 272K-token long-context
   pricing threshold?
4. Could this be a regression or incomplete fix related to GPT-5.6 cache_write_tokens are dropped from TokenUsage and rollout JSONL #32479?
5. Can Bedrock billing-compatible usage fields be recorded in the session log?

[razdgann]

This is a really good example of why cost observability probably needs to happen at the request boundary rather than only at the client/session level.

One thing I'd want to capture per request is:

provider + model
input / cached input / output tokens
context size
request duration
retry count
service tier
provider-reported usage
estimated cost at request time

Then reconcile that against the provider invoice separately.

The interesting part here isn't just that the numbers are wrong. An 8x discrepancy can stay invisible for days if the telemetry layer itself is the thing being trusted for cost reporting.

We're working on this problem in ModelGate from the proxy/gateway side, so this case is especially interesting. The long-context threshold and cache-write distinction look like exactly the kind of metadata that needs to survive all the way through the request trace.