Your weekly limit is not the problem. Your model mix is

The precision you pay for may not matter

OpenRouter analyzed 1,455 provider endpoints across 470 models to determine what quantization does to quality and price, testing on October 20, 2026. The headline result is reassuring: testing on Qwen3.8 27B revealed no statistically significant accuracy differences between fp8, fp4, and fp16 across 240 tasks, with all six endpoints scoring between 98.3% and 99.2% accuracy. Lower precision stores model weights in fewer bits to reduce memory and hardware requirements, and for this model at least, the cheaper representation did not cost accuracy. m:…5515

The pricing result is messier. Lower precision is generally cheaper — 8-bit was cheaper than 16-bit for 14 of 24 models served at both precisions, and 4-bit was cheaper than 8-bit for 26 of 33 — but pricing varies significantly by provider, and some 8-bit endpoints cost more than 16-bit alternatives. OpenRouter's conclusion is blunt: the provider affects the price more than the precision does. Only 54 of 163 models with a labeled endpoint even have a 16-bit option. The practical advice is to test specific workloads before committing, and to pin precision using provider settings so the endpoint you get is the one you priced. m:…5515

The model mix is the budget

Claude Code users have reported hitting weekly usage limits significantly faster following the release of Fable 5.2 on November 9, 2026. Kilo Code, a coding agent vendor, argues the problem is not the limit but the model mix: users default to the most expensive model for every task. Fable 5.2 is priced at $8 per million input tokens and $40 per million output tokens — twice the price of Opus 5.5 and four times the price of Sonnet 5.5 — and its usage is capped at 50% of a user's total weekly limit, meaning exclusive use of Fable effectively halves the available capacity. m:…6265

The fix Kilo proposes is routing by task. Planning tasks typically consume 20% of a feature's tokens, while implementation consumes 80%, so using Fable for planning and Opus 5.5 for implementation reduces session costs by approximately 40% compared to using Fable for both — and planning on Fable with Sonnet 5.5 for implementation reduces costs by approximately 60%. The same logic shows up in OpenRouter's traffic: open-weight models handle 64% of tokens on its platform while accounting for only 28% of total spending. The expensive model earns its keep on the hard 20%. Everything else is overpayment. m:…6265

The plumbing matters as much as the price

The third piece is reliability, and it is the least glamorous of the three. OpenRouter reports that default SDK retry settings often fail to handle rate limits: in a test batch, default settings in the OpenAI Python SDK left 23 of 60 requests failing. Implementing a retry mechanism that waits for Retry-After or X-RateLimit-Reset headers ensured all requests in a batch completed successfully, and using model fallbacks allowed a batch of 60 requests to complete in 13 seconds without waiting for rate limit resets. Provider routing automatically retries requests at alternative providers when one returns a 429 error. The lesson is that a 429 is not a capacity problem, it is a retry-logic problem. m:…5514

The same applies to structured output. OpenRouter tested three methods across nine models and found 209 of 216 replies matched a strict schema, while prompting for JSON without a strict schema resulted in 18 failures due to code fences. Forcing a single tool call can yield structured output from models without native support, and forced tool calls were cheaper on 6 of 9 models tested. Decision models like Jev, which return probabilities rather than text, are presented as more cost-effective for classification. The theme across all four stories is the same: the model is the least interesting part of the bill. Routing, precision, retries, and output format decide what you pay — and most teams have never tuned any of them. m:…5830