Fast mode is excluded from subscription plans, so Max capacity can't cover the one feature I'd spend it on

What I'd like

A fast mode allowance included in subscription plans — even a small, capped one — so that Max subscribers can use the feature without a separate usage-credits balance.

Why

Fast mode on Opus 5 is roughly 2.5x faster in interactive work and it's the feature I'd most like to keep using. What blocks me is purely how it's billed.

The docs are explicit that for subscription plans fast mode is "available via usage credits only and not included in the subscription rate limits", and that it draws from credits "even if you have remaining usage on your plan".

In practice, on Max 20x, my plan sits at ~12% weekly utilisation while fast mode is unavailable to me. The capacity I already pay for cannot cover the one feature I'd most want to spend it on, so the plan and the feature never meet. The result isn't "I evaluated fast mode and chose standard speed" — it's "I tried it once, hit an unrelated balance of zero, and turned the setting off."

Why now

Fast mode is documented as a research preview whose "availability and pricing are subject to change". Feedback during the preview seemed more useful than quietly not using the feature.

Concrete shape this could take

Any of these would convert it from "tried it, can't justify it" into daily use:

• A monthly fast-mode token budget included in Max (capped is fine — even a small one makes it usable for short interactive bursts).
• Or: let plan usage cover fast mode at a higher token-equivalent rate, so heavy fast-mode use draws down the plan faster rather than requiring a separate balance.

The second is arguably cleaner: it keeps one bucket instead of two, and it prices speed honestly without making the feature all-or-nothing for subscribers.

Environment

• Plan: Claude Max 20x
• Claude Code: 2.1.220, native install, Linux
• Model: Opus 5 (1M context)