> So my question is: what is the actual reason Anthropic lobotomizes the model when the new one is about to be dropped?

You can only fit one version of a model in VRAM at a time. When you have a fixed compute capacity for staging and production, you can put all of that towards production most of the time. When you need to deploy to staging to run all the benchmarks and make sure everything works before deploying to prod, you have to take some machines off the prod stack and onto the staging stack, but since you haven't yet deployed the new model to prod, all your users are now flooding that smaller prod stack.

So what everyone assumes is that they keep the same throughput with less compute by aggressively quantizing or other optimizations. When that isn't enough, you start getting first longer delays, then sporadic 500 errors, and then downtime.

▲

gck1 3 hours ago | parent [-]

So if I understand it right, in order to free up VRAM space for a new one, model string in the api like `opus-4.6-YYYYMMDD` is not actually an identifier of the exact weight that is served, but more like ID of group of weights from heavily quantized to the real deal, but all cost the same to me?

How is this even legal?

	▲	jubilanti 2 hours ago \| parent [-]
		> How is this even legal? Because "opus-4.6-YYYYMMDD" is a marketing product name for a given price level. You consented to this in the terms and conditions. Nothing in the contract you signed promises anything about weights, quantization, capability, or performance. Wait until you hear about my ISPs that throttle my "unlimited" "gigabit" connection whenever they want, or my mobile provider that auto-compresses HD video on all platforms, or my local restaurant that just shrinkflationed how much food you get for the same price, or my gym where 'small group' personal trainer sessions went from 5 to 25 people per session, or this fruit basket company that went from 25% honeydew to 75% honeydew, or the literal origin of "your mileage may vary". Vote with your wallet.