if you are refreshing a cache of 120k tokens, you have to input the same 120k tokens. you can't bounce the cache with 1 byte. A proper cache hit requires your entire context that is cached. if you change 1 byte in it, everything after that byte is a cache write and no longer a cache hit
Yes, you're paying the cache read, not the cache write, which is much more expensive. You can do the math for how many 5min refreshes you can be afk for until it starts costing instead of saving
it could be either. subscription defaults to 60 min with 2x cache writes. extra usage and api defaults to 5 min with 1.25 cache writes. You can override either with settings
If you're running the subscription, by default you are paying 2x for cache writes and you're getting an hour for expiry. So refreshing based on 5 min is wasteful. You need to detect whether you are in 5 min or 1 hour mode.
The post would have been stronger and more useful focusing and expanding on the abstraction portion of his message as well as system and program design. Those elements were there but seem sidelined by the focus on DSL. For most developers on most projects, the key take away is we all have to both get good at system and program design especially around abstractions, shapes, responsilibility. Then we have to get good at inserting our selves in the AI loop to steer those decisions a lot in the beginning, regularly as the project kicks off and still more than we think as the project matures.
The counter intuitive pattern I see emerging is if you can cleanly determine intent, of the call you fix the call and prepend informative text to the tool call response indicating the mistake made and how to fix in the future then followed by the actual tool call. In this case you can validate fields and rather than throw a hard error determine if it's an extra field that isn't needed. If so you correct the call and prepend a corrective response in the tool call. This saves turns, it instructs the model in context so less likely to happen later and helps models that aren't so good at recovering from bad tool calls and staying on their longer horizon agentic task (most non openai and anthropic models)
GLM 5.2 feels like Opus 4.6 level. I actually think 4.6 and GLM work better in practice than opus 4.7 or 4.8 as I find both of those more erratic and seem to randomly have a super dumb turn. That random bad turn I see doesn't seem to be hitting the benchmark scores but they make 4.7 and 4.8 very hard to use for me. GLM is more stable like opus 4.6
It's the executive branch asserting control in this space and requiring all SOTA model providers to bend the knee. Anthropic is the least capable of playing the bend the knee game so is getting the first and worst smack down
If you don't have the capacity to have your mind changed through friction and disagreement with a SOTA LLM and feel compelled to frame those who do to through absurdly reductive statement like "insane arguing with a machine" then that says more about your limitation and lack of understanding than the OP's or Claudes.
I have the same processor and ram. The dense 30b ish Gemma/Qwen really don't break 10 TPS with or without MTP. MOE's in this range feel more usable if they are smart enough for your work. Probably would still use hosted versions of these over local unless. MOE's feel somewhere between sonnet 3.5 and 3.7 to me. Dense feels between sonnet 3.7 and 4 in basic coding or local agentic capabilities (not close to those in chat or world knowledge)
