The issue is that all input (including context) counts towards that limit. So 10 requests with 50k of context will blow through the limit, even if little to no output was generated, which is incredibly easy to do with agentic workloads.
This is pretty terrible advice when there are dozens of AI inference providers out there serving great models with significantly more cost effectiveness than you'd get from buying your own hardware.
Most providers do what's called "prefix caching", where each turn in a session is cached such that sending new messages with the exact same "prefix" (set of previous messages) gives you the cache read price on that input instead of the full price. As long as you're not changing your system prompt, available tools, etc mid-session, you automatically benefit from this.
But presumably everyone in your company/team is using Jira, so it's not an "ad" because it's a product already used internally. Claude is appending these links to all commits by default, whether or not others on the team use Claude. Those are very different things.
They're not "docking points", they're calculating it in the most straightforward way. If I start a session and the majority of requests are sent to Provider A, and my last request gets routed to Provider B, I have a 0% cache hit rate with Provider B. I'm very curious how else you expect this to be calculated? Do you think they're completely omitting requests that switch providers mid-session?
FWIW, I get significantly higher than listed cache hit rates when I pin my session to a specific provider, which is further evidence of the above.
This is very much NOT my experience in practice, even though it's how I would expect it to work. OpenRouter will happily bounce you between several providers (none of which have downtime) even within the same session. Requesting specific providers is the only way I've been able to hit a cache rate above 90%.
The simulator doesn't have a camera. The android emulator allows to configure the camera and use a picture, it's very handy to test your qr/barcode reader without needing to use a physical device. Maybe this also allows to use an image as camera?
It’s been years but I ran into a problem with a notification extension years ago. Worked fine on simulator, not on device. Turned out it was because I was using a HEIF image and (I think) the on-device extension was trying to use hardware decoding and didn’t have access to it. Meanwhile the simulator had no such sandboxing restrictions.
The difference doesn’t matter until it does, and then it’s infuriating to work out what’s going on.
It would also make testing far easier. I got bit with something that failed on real life iPhones with language set to es_US that worked fine on the simulator.
reply