Hacker News Reader

Comment by Lalabadie | Hacker News Reader

In my experience, that's the OpenRouter tax. Even a session that does everything right to remain sticky ends up getting moved between providers on a few requests, which bills you the full context as input every time the switch happens.

I assume it's done as load balancing/latency mitigation, but it's put me off of OpenRouter for my use cases (limited use, limited need for changing models).

View on HN

This has not been my experience. Generally I do pin to 1 provider, or 1 provider with a couple fallbacks (especially with deepseek - most providers are 10x the cached token price compared to deepseek themselves), but even when I don't I still usually see 99%+ cache hit percentage. Specifically using pi with various ad-hoc customisations (that I was careful not to break prompt caching with).

then what is the point of using operouter for this model? Just use the deepseek API and save the 5% fee on top of the better caching rate.

Because they don’t want to sign up for 10 different providers and subscriptions/etc, especially if some models are just going to receive light, or rare usage?

Why not pin to specific openrouter provider and disable fallback?

There is only one provider for this model, so shouldn't be running into that.

Seems like pro 0813 is exclusively served by Deepseek themselves at the moment so I wouldn't say that's the case?

It is a pain from openRouter if you don't define your providers correctly, but for DeepSeek, surely not- the weights aren't released yet and there's only one provider, DeepSeek.

With Deepseek as the provider, there's no issue of course, but that means you don't filter providers for data retention, and you could also choose direct API use with them at that point.

Fallback are still very useful and won't poison much your cache hits too much if the provider is down anyway.

That’s a very heavy tax tbh.

You can set it up to always use the official provider.

Reply on news.ycombinator.com