Five service layers making three retries each can turn an ordinary 429 into 243 times the original load. An impressive capacity number quickly becomes irrelevant when failure behavior is ignored.
Recovery capacity matters during failure
Exponential backoff needs jitter so clients do not retry in lockstep. But jitter only changes timing. It does not eliminate the requested work.
A resilient system also needs limits on in-flight requests, respect for Retry-After, and a retry budget.
In one metastable database failure example, the database normally handled nearly 300 queries per second. Retry-driven load reached 560 queries per second. Recovery began only after load fell below 150.
That gap is the important one. Clearing the original trigger may not end the outage because synchronized work, queues, and crash loops can sustain the overload. Normal serving capacity was nearly 300 queries per second, but recovery capacity was below 150.
A benchmark answers only the workload it measures
HTTP Arena’s leading entry exceeds 3 million requests per second on one 64-core machine using a small cached response with no parsing or lookup.
As the workload becomes more realistic, throughput changes:
- With JSON serialization: 1.09 million requests per second
- With TLS: 850,000
- With one asynchronous Postgres query: 275,000
- On the four-CPU mixed profile: between 32,000 and 68,000
The peak remains useful for exposing runtime overhead and showing what a narrowly optimized system can do. It cannot answer a production question until the benchmark resembles the production workload.
Zalando’s result is more operationally specific. Moving routing from a shared proxy into callers reduced its proxy fleet from more than 50 pods to eight. Its daily bill fell from about $450 to about $110.
A specialized tool can be a sensible choice when its assumptions match the hot path. The benchmark does not need to reproduce the entire production system, but the claimed gain must be evaluated where it will actually be used.
Cheap work is not the same as cheap completion
Z.ai’s GLM coding plan starts at $18 per month and works inside Claude Code and Codex. Comparisons cite $200 plans for Codex Pro and Claude’s top Max plan, but these are not equivalent offerings. GLM has smaller limits and lower stated problem-solving ability.
The lower price may still suit bounded worker tasks. Consequential work needs explicit checks, durable handoff files, and review by a stronger trusted model.
Subscription price is only one part of task cost. Repeated context, retries, validation, review, and lost state can offset apparent savings. A cheap attempt is not necessarily a cheap completed task.
Optimization depends on the baseline and deployment shape
In a reported single-GPU comparison, Unsloth reduced one Alpaca run from 23 hours and 15 minutes with Hugging Face to 2 hours and 34 minutes. Cut cross entropy reportedly reduced loss-computation memory from 24 GB to about 1 megabyte without changing the gradient.
These gains came from narrow transformer-specific optimization, fused Triton kernels, and avoiding large intermediate values.
The baseline changes the interpretation. One claimed 12 times gain for mixture-of-experts kernels used Transformers version 4 as its baseline. Against Transformers version 5, the advantage became about two times. The improvement remained, but the engineering conclusion changed.
Unsloth’s multi-GPU documentation was also inconsistent. When configurable parallelism or multi-node training was required, Axolotl or LlamaFactory were clearer choices. The fastest single-GPU path and the clearest distributed-training path were not necessarily the same tool.
Trust a number only after it survives your workload, baseline, failure path, recovery test, and the full cost of completing the work.
Peak capacity describes ideal conditions. Recovery capacity determines whether the system can escape failure. The number worth using is the one that survives both.