fix: annthropic cache rate for fast mode (#5063)#5087
Merged
Conversation
Fixes a cost calculation bug where Anthropic prompt-cache tokens (both cache read and cache creation) were billed at standard rates even when the request used fast mode. Per Anthropic's pricing model, cache multipliers stack on top of the fast base input rate, meaning cache token costs should scale by the fast/standard input ratio rather than remaining at the standard cache rate. - Introduced `fastCacheRate`, a helper that scales a standard cache rate to the fast-mode equivalent by multiplying it by the fast/standard input price ratio. - Applied `fastCacheRate` as an early-return guard in `tieredCacheReadInputTokenRate`, `tieredCacheCreationInputTokenRate`, and `tieredCacheCreationInputAbove1hrTokenRate` so fast-mode requests use the correctly scaled cache rates. - Updated the existing fast-mode cache test (`TestComputeTextCost_FastMode_CacheStacksOnFastBase`) to reflect the correct expected values (cache tokens now scale 2× when the fast input rate is 2× the standard rate). - Added a regression test (`TestComputeTextCost_FastMode_Opus48CacheRegression`) pinning the real-world miscalculation observed with Anthropic Opus 4.8 fast mode + `cache_control`, where 44,667 5-minute cache-creation tokens were billed at the standard $6.25/MTok instead of the fast-scaled $12.50/MTok. - [x] Bug fix - [x] Core (Go) ```sh go test ./framework/modelcatalog/datasheet/... ``` The new regression test `TestComputeTextCost_FastMode_Opus48CacheRegression` will fail on the unfixed code and pass after this change. The updated `TestComputeTextCost_FastMode_CacheStacksOnFastBase` validates the general scaling behaviour. - [x] No None. - [ ] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
|
|
Collaborator
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Jul 10, 2026
Contributor
Confidence Score: 4/5The fast-mode streaming billing path has a contained issue in the final completed response.
core/providers/anthropic/responses.go Important Files Changed
Reviews (1): Last reviewed commit: "fix: annthropic cache rate for fast mode..." | Re-trigger Greptile |
Contributor
Merge activity
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Anthropic's fast mode (
speed:"fast") was billing cache tokens at standard rates instead of fast rates. This PR introduces dedicated fast-mode cache pricing columns (cache_creation_input_token_cost_fast,cache_creation_input_token_cost_above_1hr_fast,cache_read_input_token_cost_fast) and fixes the streaming path to forward thespeedfield onto the response so thattier.isFastis correctly set for streamed requests.Changes
ToBifrostResponsesStreamnow copieschunk.Usage.Speedonto the response when emitting usage frommessage_deltaevents. Previously, streamed fast-mode requests hadtier.isFast = false, causing all cache and input/output tokens to bill at standard rates.cache_creation_input_token_cost_fast,cache_creation_input_token_cost_above_1hr_fast,cache_read_input_token_cost_fast) are added toTableModelPricing. When set,tieredCacheReadInputTokenRate,tieredCacheCreationInputTokenRate, andtieredCacheCreationInputAbove1hrTokenRatereturn the fast rate instead of the standard or tiered rate.migrationAddFastModeCachePricingColumnsadds the three columns with rollback support.pricingSyncUpdateColumnsso they are written during catalog syncs.Options,Entryconversion helpers, andpatchPricingare updated to carry the new fields through the override and catalog pipeline.PricingOverridePatchTypeScript type is updated to match.TestComputeTextCost_FastMode_CacheBillsAtStandardRatestest is replaced withTestComputeTextCost_FastMode_UsesFastCacheRatesand two new tests — one verifying fallback to standard rates when fast columns are unset, and a regression test pinning the real-world Opus 4.8 miscalculation. A streaming test (TestFastMode_StreamingForwardsSpeed) verifies themessage_deltapath forwardsspeed=fastand preserves cache-creation token counts.Type of change
Affected areas
How to test
cache_creation_input_token_cost_fastandcache_read_input_token_cost_fastset.cache_controlblocks andspeed:"fast".Breaking changes
Security considerations
None. Changes are limited to pricing calculation logic, database schema, and UI display fields.
Checklist