GPT-6 Astra appears to consume Pro weekly allowance at 1.4× the published credit-equivalent rate #45940

What version of the Codex App are you using (From “About Codex” dialog)?

26.905.11957

What subscription do you have?

ChatGPT Pro

What platform is your computer?

win11 x64

What issue are you seeing?

I built an auditing system that reconciles Codex's locally recorded token usage telemetry against the ChatGPT Pro weekly allowance meter.

When using GPT-5.6 Sol, the observed weekly allowance consumption reconciles very closely with the published credit rates:

• Uncached input: 100 credits / 1M tokens
• Cached input: 10 credits / 1M tokens
• Output: 500 credits / 1M tokens

Based on this, a full weekly allowance on my account appears to correspond to approximately 12,500 Sol-rate-equivalent credits.

However, when GPT-6 Astra usage is included, the same reconciliation does not work with the published Astra rates:

• Uncached input: 250 credits / 1M tokens
• Cached input: 25 credits / 1M tokens
• Output: 1,250 credits / 1M tokens

The observed weekly allowance depletion only reconciles when Astra is instead assigned approximately:

• Uncached input: 350 credits / 1M tokens
• Cached input: 35 credits / 1M tokens
• Output: 1,750 credits / 1M tokens

These values are exactly 1.4× the published Astra credit rates.

In other words, Astra appears to consume the included weekly allowance at approximately 3.5× the Sol rate, rather than the 2.5× ratio implied by the published credit rates.

I am reporting this as an observed allowance-accounting discrepancy. I understand that subscription allowance accounting may differ from purchased-credit pricing, so I would like to confirm whether this additional 1.4× weighting is intentional or whether it indicates an accounting issue.

What steps can reproduce the bug?

1. Start from a known weekly allowance state and record the current weekly allowance meter reading.

2. Use GPT-5.6 Sol in Codex and record the locally generated token usage telemetry for each session, including:

   • uncached input tokens
   • cached input tokens
   • output tokens

3. Record the change in the weekly allowance meter after the Sol usage.

4. Calculate the expected usage using the published Sol credit rates:

   Sol usage =
   uncached_input × 100 / 1,000,000

   • cached_input × 10 / 1,000,000
   • output × 500 / 1,000,000

5. Repeat this across enough Sol usage to estimate the full weekly allowance. In my measurements, the result converges very closely to approximately 12,500 Sol-rate-equivalent credits.

6. In the same account, repeat the measurement using GPT-6 Astra.

7. Calculate Astra usage using the published Astra rates:

   Published Astra usage =
   uncached_input × 250 / 1,000,000

   • cached_input × 25 / 1,000,000
   • output × 1,250 / 1,000,000

8. Compare the calculated Astra usage with the actual change in the weekly allowance meter.

In my measurements, the published Astra rates systematically underestimate the observed allowance depletion.

The observed depletion reconciles closely when applying a uniform 1.4× multiplier:

Observed Astra-equivalent usage =
uncached_input × 350 / 1,000,000

• cached_input × 35 / 1,000,000
• output × 1,750 / 1,000,000

This same 1.4× factor appears across all three token categories.

What is the expected behavior?

I would expect the weekly allowance accounting to be internally consistent and clearly documented.

If Astra's included Pro allowance is intentionally weighted at 1.4× its published credit-equivalent rate, I would expect that weighting to be documented so that the weekly usage meter can be understood and audited.

If no such additional weighting is intended, then the weekly allowance depletion should reconcile with the documented accounting rules.

Please verify from the server-side usage ledger whether the discrepancy is caused by:

• an intentional Astra-specific allowance multiplier;
• additional metered Astra activity that is not represented in the local Codex token telemetry, such as retries, background activity, subagents, or reviews; or
• an unintended error in weekly allowance accounting.

Additional information

No response