Token Harbor’s input cache silently stops hitting

DeepSeek’s biggest cost advantage is its input cache: cached input costs roughly a tenth of fresh input, which is the whole reason long agent sessions stay affordable. Token Harbor resells DeepSeek models at a low price, so the cache is exactly what I was paying for.

But while running long sessions through Token Harbor, the cache hit rate would occasionally collapse to 0% mid-conversation. So I compared Token Harbor against Command Code on the same DeepSeek model and hit both APIs directly, comparing 574 raw responses side by side.

The short version: Token Harbor’s input cache reporting stops working mid-session, and when that happens the request looks like a complete cache miss — so the entire prompt ends up looking like it was billed as fresh input.

Key Takeaways

• The problem: through Token Harbor, input cache hits stop being reported mid-session, with no error and no signal
• The evidence: cache usage vanished in 32 of 574 calls (5.6%) through Token Harbor, and in 0 of 474 through Command Code on the same model
• The impact: when it happens the whole prompt_tokens_details key disappears, so pi shows 0% and the request ends up looking like a full-price input charge
• The verdict: I would not recommend Token Harbor on this evidence. DeepSeek’s cheap cache is the main reason to use these models at all, and that is the part that fails silently

What I found comparing the two

I ran identical prompts through Token Harbor and Command Code, both serving the same DeepSeek model.

• Token Harbor returned cache usage 542 times out of 574, and returned nothing 32 times (5.6%)
• Command Code returned cache usage 474 times out of 474, and returned nothing 0 times
• On a drop, cached_tokens does not become 0 — the entire prompt_tokens_details key disappears
• Because the cache field is missing, pi counts the whole prompt as fresh input, so it ends up looking like you paid full price for it

What the raw responses actually look like

On a normal hit, Token Harbor and Command Code report cache usage in essentially the same shape.

Token Harbor:
  usage.prompt_tokens                        = 6678
  usage.prompt_tokens_details.cached_tokens  = 6656
  usage.cache_read_input_tokens              = 6656

Command Code:
  usage.prompt_tokens                        = 6678
  usage.prompt_tokens_details.cached_tokens  = 6656
  usage.cache_creation_input_tokens          = 0
  usage.cache_read_input_tokens              = 0

But every so often, Token Harbor returns this instead.

{
  "usage": {
    "prompt_tokens": 6678,
    "completion_tokens": 2,
    "total_tokens": 6680
  }
}

In short, Token Harbor sometimes just doesn’t report cached tokens. Command Code never did this in any of my runs.

That leaves pi unable to tell two cases apart: a prompt that genuinely wasn’t cached yet, and a cache hit whose accounting went missing. Both look the same, and both end up looking like the full prompt was charged as input.

Method: Token Harbor vs Command Code, raw HTTP, no SDK

To keep the isolation clean I limited the comparison to these two services and used no other provider.

It reproduces in real session history too

This was not confined to a test harness. I extracted usage.input and usage.cacheRead from pi agent’s own session logs and counted how often a call reported zero despite the previous call being a hit within five minutes.

Token Harbor is an order of magnitude worse. This was not a matter of perception.

Splitting Token Harbor’s history by prompt length shows it scales with context size.

Long sessions hit it more often, which matches the experience of a hit rate that suddenly collapses after a while — precisely when the cache is worth the most.

Summary

• DeepSeek’s cheapest feature is its input cache, which is the main reason long sessions are affordable. Through Token Harbor, cache accounting went missing in 5.57% of responses; through Command Code on the same model it went missing 0 times in 474 calls
• Cold calls produce the same shape, so pi cannot distinguish "uncached" from "misreported". That is a service-side design problem

I would not recommend Token Harbor. The failure is silent, and it hits exactly the feature you chose DeepSeek for.

What looked like a display bug turned out to be a cost-affecting behavior. The broader lesson: the same model name over a different route deserves to be measured as a different product.