Token Harbor’s cache drop: is it fixed yet?

Token Harbor’s pricing page now estimates 4.9k+ requests for DeepSeek V4.1 Flash, up from 2.3k+. I re-ran the input cache test I published last month, using this provider alone. Across 1,890 raw API calls, the cache field dropped 2 times (0.11%).

Key Takeaways

• The drop rate fell: 2 of 1,890 calls lost the cache field (0.11%), versus 11 of 490 (2.24%) before
• Both drops clustered: they hit 7 and 21 minutes after the run started, and the next 1,667 calls had none
• The page estimate doubled, but so did its assumption: 8K of the 10K input is now counted at the cache rate
• Cold requests still hide the gap: the API omits the field entirely rather than returning cached_tokens: 0

The drop rate is now 0.11%

The main numbers first.

• 2 of 1,890 calls lost the cache field (0.11%)
• The same condition last month was 11/490 = 2.24%, and the confidence intervals do not overlap
• Both drops landed early in the run, with 0 of the next 1,667 calls dropping
• Cold requests still omit the field, so a drop looks identical to a cold miss

The pricing page number is not a plain 2x

The pricing page’s “estimated requests” now lists 4.9k+ for DeepSeek V4.1 Flash, up from 2.3k+. The assumption behind it changed at the same time. It now counts 8K of the 10K input at the cache rate, so this is not a doubling of usable volume.

The previous test

Last month I compared two providers and found that only one of them dropped the cache field.

Token Harbor's input cache silently stops hitting

DeepSeek's cheapest feature is its input cache, and Token Harbor seems to lose it mid-session. In 32 of 574 raw API calls the cache usage vanished, so the whole prompt looked like a full-price input charge.

ccie-go.com

2026.10.24

What changed this time is the scope. I dropped the comparison and measured tokenharbor-p alone.

Conditions

The 6.7k-token prefix kept the total bill at about $0.13 despite 12.64M input tokens. I did not retest with a large prefix.

Results: 2 drops out of 1,890 calls

• Drop rate 0.11% (95% CI 0.03%–0.39%)
• Previous same-prefix run was 11/490 = 2.24% (95% CI 1.26%–3.97%)
• The intervals do not overlap, so the rate is lower

Whenever the field was present, cached_tokens came back as 6,656 almost every time. The prefix was identical, so a working cache yields the same count.

Both drops clustered in 20 minutes

Neither prompt_tokens_details nor cache_read_input_tokens was present. The field is removed entirely rather than returned as cached_tokens: 0.

Both drops fell inside the first 20 minutes of the run. The 1,667 calls after the second one had no drops, so this is not constant.

Cold requests still behave the same

Five calls with a unique prefix each returned no cache field at all.

An explicit cached_tokens: 0 appeared zero times again. A cold miss and a dropped field are still indistinguishable from the JSON alone.

pi reads a missing field as cacheRead = 0, so a drop shows the whole input at full price. That display problem is still unfixed on the provider side.

The response headers offer no hint

As of 2026-11-08 the headers carried a routing decision.

x-th-route-decision  {"model":"deepseek-v4.1-flash","tier":"low","cache_hit":false}

cache_hit was false on both hits and cold calls. It cannot be used to detect a drop.

Summary

• The pricing page lists 2.3k+ → 4.9k+ estimated requests for DeepSeek V4.1 Flash
• The assumption changed too (8K counted at the cache rate), so it is not a plain 2x
• Across 1,890 calls against tokenharbor-p alone, the cache field dropped 2 times (0.11%)
• The rate is below the previous 2.24%, with non-overlapping confidence intervals
• The drops are not zero, and cold requests still cannot be told apart