median · 0 grant-SLO breaches
Measurements before claims.
Live-provider efficacy, local restoration semantics, and distributed-control behavior answer different questions. This page keeps their runtimes, trade-offs, and limitations attached to the numbers.
Every claim keeps its benchmark boundary.
moflux-bench v0.35.0 is public under Apache-2.0. The reviewed eight-seed OpenAI sweep carries the live-provider protected-concurrency claim. The latest local-contention result tests a different question: lending, restoration, and the gap between a returned grant and capacity that is actually usable again. The August 26 synthetic ladder remains separate evidence for token pressure and coordinator-distance behavior.
The grant came back in 258ms. Usable capacity did not.
All 5/5 seeds passed the current H1–H4 proof, including H4a capacity-transfer safety and H4b no-new-borrowing after protected demand returned. Median grant restoration was 258ms with zero grant-SLO breaches. But already-admitted borrowers still had to drain: median occupancy restoration was 31.6s, with 5 breaches of the 15s occupancy objective.
This is admission-layer evidence from CPU-only Ollama 0.12.3 / qwen3:0.6b. It does not claim GPU preemption, KV-cache reclamation, or upstream execution reclamation. This generated result has not yet been promoted into the reviewed public results corpus.
median · 5 occupancy-SLO breaches
new-borrow growth violations after demand return
median batch borrow-window completions vs static
795/800 interactive requests completed through Tyr under live OpenAI overload.
575/800 completed with the same 36-request global concurrency ceiling and no workload protection.
Median MoFlux advantage across eight matched seeds; every seed was positive (17–58 points).
Both static and MoFlux kept provider 429s at zero; direct OpenAI produced 280 under the same offered workload.
pooled interactive success versus the static cap
counterbalanced seeds favored MoFlux on interactive success
median paired batch-success delta versus static
same global concurrency ceiling; Tyr protected 8 interactive / 4 batch
Four approaches under controlled overload.
The synthetic ladder is still useful for token pressure, Redis coordination distance, and adaptive fleet behavior. It is no longer the primary proof that protected concurrency changes interactive outcomes under a real provider.
| Metric | No control | Static cap | Redis | MoFlux |
|---|---|---|---|---|
| Interactive successCompleted interactive logical requests | 81.1% · 75.8%–85.3% | 93.7% · 87.3%–98.7% | 92.7% · 88.3%–95.7% | 97.4% · 90.8%–100.0% |
| Interactive goodputSuccessful interactive requests per second | 4.79 · 4.38–5.13 | 5.52 · 5.07–5.91 | 5.50 · 4.89–6.04 | 5.73 · 5.13–6.24 |
| Interactive p50End-to-end latency among successful requests | 7.39s · 6.53s–8.51s | 5.77s · 5.07s–7.09s | 4.22s · 2.89s–5.64s | 5.25s · 3.08s–7.21s |
| Interactive p95End-to-end latency among successful requests | 14.87s · 12.70s–17.67s | 13.23s · 11.75s–15.14s | 10.30s · 7.67s–12.89s | 11.54s · 9.43s–13.12s |
| TTFT p50Time to first streamed output among successful requests | 2.96s · 1.27s–3.95s | 1.93s · 1.11s–2.53s | 0.79s · 0.56s–1.13s | 1.04s · 0.53s–1.84s |
| TTFT p95Time to first streamed output among successful requests | 7.23s · 6.44s–7.79s | 5.77s · 4.84s–5.98s | 2.92s · 2.14s–3.44s | 5.46s · 1.46s–7.27s |
| Retry amplificationAttempts per logical interactive request | 1.828 | 1.457 | 1.478 | 1.339 |
| Batch successCompleted batch requests; the adaptive policy guarantees liveness, not maximum batch throughput | 55.1% · 50.0%–69.8% | 23.0% · 17.2%–30.2% | 17.4% · 11.4%–23.3% | 9.2% · 8.6%–14.0% |
| Local rejectsAttempt-level work shed before provider execution | 0 | 295 · 196–443 | 306.5 · 231–420 | 264 · 160–401 |
| Token-budget rejectsRequest size was a binding admission constraint | 0 | 0 | 86 · 13–123 | 40.5 · 2–63 |
| Upstream 429sProvider-side rejection after capacity was spent | 375 · 241–471 | 0 | 0 | 0 |
| Peak provider occupancyActive requests against the 32-slot envelope | 32/32 | 32/32 | 32/32 · 30/32–32/32 | 32/32 |
Token pressure changed real admission decisions on every 0ms MoFlux seed.
Interactive request sizes varied by roughly 24.9×–32.0×. A median 50.6% of MoFlux capacity-bound rejects were token-bound, with 40.5 median token-budget rejects. No control and the static cap do not make request-size-aware token admission decisions. MoFlux and Redis exercised token-aware admission on all eight 0ms seeds.
The current result supports a differentiated product, not a universal winner.
Static caps and Redis both work. The benchmark is useful precisely because it shows where MoFlux adds value and where another control is currently better.
MoFlux completed more protected interactive work than Redis
At the 0ms rung, MoFlux improved paired interactive completion by +4.0 pts and goodput by +4.2%. Across all four rungs, its median interactive-success advantage stayed between 3.42 and 4.72 percentage points.
MoFlux shed fewer attempts and retried less
At 0ms, median local rejects were 264 for MoFlux versus 306.5 for Redis — about 13.9% fewer attempt-level local rejects. Retry amplification was 1.339× versus 1.478×. Local rejects are attempt-level, so completion remains the stronger reliability outcome.
Redis still delivered faster successful-request latency
At the 0ms rung, Redis median TTFT p95 was 2.92s versus 5.46s for MoFlux, and Redis median end-to-end p95 was 10.30s versus 11.54s. These percentiles include successful logical requests only, so they should be read together with completion rate.
Redis also served more batch work in this policy
At 0ms, Redis median batch success was 17.4% versus 9.2% for MoFlux. MoFlux restored and served the protected batch floor on every seed, but this adaptive policy prioritizes interactive reliability over maximizing batch throughput.
Per-request coordination pays for distance on the request path.
The published ladder injects 0, 5, 20, and 50ms into the Redis coordinator path. Redis admitted-decision time rose 1.0141ms for each 1ms of injected distance, with all 8 seeds degrading. Tyr's admitted-decision slope was -0.0001ms/ms with a 95% interval from -0.0005 to +0.0002. The benchmark directly measures Tyr synchronous decisionDuration separately from queue wait. The near-zero MoFlux decision slope supports coordinator-distance independence for that measured local decision path; it does not mean end-to-end TTFT is zero-cost or invariant.
1.014 ms/ms
Median paired slope across eight seeds; 95% interval 1.0092–1.0183.
-0.0001 ms/ms
Measured Tyr decisionDuration excluding queue wait; 95% interval -0.0005 to +0.0002.
+3.42 to +4.72 pts
MoFlux median interactive-success advantage over Redis across the four tested coordinator-distance rungs.
32/32 rung-seeds
Every rung recorded 8/8 passing seeds for the configured interactive target, batch-liveness floor, zero-upstream-429 requirement, and handoff safety checks.
The current stack proves the handoff, not just the lending event.
All eight 0ms seeds observed and committed the reclaim handoff, restored the protected batch guarantee in controller and data-plane evidence, proved commit-before-admission with exact Tyr admission provenance, and recorded no applied over-allocation. Interactive traffic actually consumed borrowed slots on six of eight seeds. Controller-level lending was observed on all eight, so some seeds made capacity available without needing to occupy it above the protected floor. The median first batch admission window was 0.36–0.68s after commit. The roughly 14.28s commit-to-response-headers interval includes downstream simulated service for the large batch prompt and should not be read as capacity-control recovery latency.
8/8 seeds
Every seed committed in safe event order, before batch admission and fallback lease expiry, with no applied over-allocation.
0.81s median
Where demand timing was available, drain began immediately; acknowledgment dominated the handoff, while acknowledgment-to-commit was 0.01s at the median.
6/8 seeds
Interactive traffic actually consumed borrowed capacity on 6 of 8 seeds, reaching as many as 4 extra concurrency slots.
0.36s–0.68s
Median lower/upper bound for first batch admission after commit. The roughly 14.28s commit-to-response-headers interval includes downstream simulated service for the large batch prompt—queue/prefill/TTFT-equivalent work—not capacity-control recovery.
Conservative reservation does not have to stay stranded until completion.
MoFlux recovered a median 60.6% of reserved tokens net of overruns, and 83.4% of refunded tokens returned while streams were still active. Median overrun was 133.5 tokens. This is earlier reuse of existing headroom, not newly created capacity.
60.6%
Median across eight matched 0ms seeds.
83.4%
Share of refunded tokens returned mid-stream.
The isolation mechanism has direct proof, but not yet on the newest runtime.
This earlier run used Tyr 0.22.0 and Latchflo 0.8.0. Across five matched seeds, the protected policy was exercised successfully, both classes continued to receive service under contention, and every arm recorded zero upstream 429s. Against class ceilings alone, premium median success moved from 72.5% to 75.4% and contended goodput from 2.76 to 2.88 requests/s. Premium TTFT was effectively unchanged versus ceilings-only.
5/5 seeds passed
Same trace, both classes observed and served under contention, protected policy exercised, minimum noisy-class progress met, and zero upstream 429s in every arm.
+2.93 pts · +4.3% goodput
Protected floors improved premium success and goodput in four of five seeds, but the effect is incremental rather than dramatic.
1.003× · +0.3%
Median protected/ceilings premium p95 TTFT ratio and change. Protected TTFT was better in only 2/5 seeds, so the benchmark does not establish a TTFT advantage over ceilings-only.
+0.67 pts success · 16 vs 18 completions
Noisy median success edged up from 37.5% to 38.2%, but median contended completions fell. The floor guarantees progress; this run does not show a noisy-class throughput win.
The shared arm is an important counterweight: it reached 98.8% median premium completion and 4.52 premium contended goodput, both well above protected. Protected instead cut premium contended p95 TTFT to 0.535× shared at the median — about 46.5% lower — while reserving capacity for the noisy class. That is an isolation trade-off, not a universal performance win.
The interesting part is the boundary of the claim.
The newest evidence strengthens the safety claim substantially: across the published four-rung ladder, all 32 rung-seed combinations passed the recorded adaptive proof, and the 0ms evidence includes exact Tyr admission provenance for safe reclaim. Current Tyr/Latchflo releases also support opt-in demand-aware class-floor lending, but the class-performance numbers below are still from the earlier static protected-floor proof and should not be relabeled as current-stack performance evidence.
This is a workload-specific benchmark, not a universal ranking
The provider is simulated and the policy intentionally prioritizes interactive traffic. The result supports claims about this tested overload regime, not a blanket statement that MoFlux is faster or more reliable in every workload.
Static caps remain a credible low-complexity control
At 0ms, static caps reached 93.7% median interactive success with zero upstream 429s. MoFlux reached 97.4% and adds token-aware admission, adaptive lending, fleet authority, provenance, and coordinator-independent local decisions — at the cost of more system complexity.
Redis wins responsiveness in this comparison
Redis had substantially lower median successful-request TTFT at 0ms and lower median end-to-end latency. MoFlux's value in this run is higher interactive completion, lower retry amplification, fewer attempt-level local rejects, and a request path that does not inherit coordinator RTT.
Batch fairness is bounded, not maximized
All 32 rung-seed combinations met the configured batch-liveness floor, but at 0ms MoFlux median batch success was 9.2% versus 17.4% for Redis. The site therefore describes the batch guarantee as non-starvation/liveness, not superior batch throughput.
Queue wait is measured separately from local decision time
The published Tyr 0.27.0 ladder exports synchronous admission decision time separately from queue wait. The coordinator-distance claim uses decisionDuration excluding queue wait; end-to-end TTFT still includes retry/backoff, queueing when exercised, provider prefill, and first-token service.
Protected-class proof is from the previous stack
Protected class floors remain shipped, but the five-seed class proof cited here was generated with Tyr 0.22.0 and Latchflo 0.8.0. It is prior isolation evidence, not a current-runtime performance rerun.
Reservation recovery is reuse, not new capacity
MoFlux returned a median 60.6% of reserved tokens net of overruns, with 83.4% of refunded tokens released while streams were still active.
The harness is public. Licensed product evidence is clearly labeled.
The benchmark harness is at v0.35.0. The August 26 adaptive coordinator ladder cited here is published under video-seed-sweep in the public results tree. Reproducing the MoFlux arms still requires licensed Tyr and Latchflo images. The older protected-class performance proof remains separately disclosed because it predates the current runtime.
What you can check
- publicmoflux-bench v0.35.0 source and verification suite
- publicReviewed counterbalanced live OpenAI overload sweep
- publicDynamic fleet-membership benchmark driver
- runnableProvider simulator plus no-control, static-cap, and Redis arms
- publicReviewed August 26 overload ladder at results/video-seed-sweep.json
- licensed images requiredTyr + Latchflo benchmark arms
- not committedProtected-class proof cited on this page (older stack)
Inspect the published reviewed result or clone mofluxhq/moflux-bench and run npm run verify. The current ladder driver is npm run demo:coordinator:adaptive; the protected-class driver is npm run demo:classes. Licensed Tyr and Latchflo images are required to reproduce the MoFlux arm.
The live overload result is real-provider evidence
The openai-live-overload-sweep artifact sends real requests to OpenAI under deliberate request-rate overload. Arm order is counterbalanced across eight seeds and each arm starts behind the same rate-limit headroom gate. The older August 26 Universal Scalability Law ladder remains separate synthetic evidence for coordinator distance, token pressure, and adaptive fleet behavior.
The live OpenAI claim is deliberately narrow
MoFlux completed 795/800 protected interactive requests versus 575/800 under the static cap, with a positive paired advantage in every seed. It shed more batch work to do so, and Single-node Tyr protected concurrency only. This sweep does not exercise Tyr in-flight token-budget admission or Latchflo fleet coordination.
Dynamic membership proof stops at topology convergence
5/5 membership runs passed with no revision churn, duplicates, stale members after convergence, or revision regressions. This benchmark validates Latchflo membership and routing-topology convergence. It does not yet prove uninterrupted routed request traffic while peers churn.
The current ladder is reviewed public evidence
The August 26 ladder 20260826T204430Z was promoted under video-seed-sweep. The site links directly to the reviewed evidence in the public moflux-bench results tree rather than relying on an unpublished local corpus.
Runtime provenance is current-stack evidence
The published ladder is associated with moflux-bench 0.27.0, Tyr 0.27.0, Latchflo 0.12.4, async-bulkhead-llm 3.16.0, and async-bulkhead-ts 1.0.1.
Coordinator distance has direct admission timing
Redis admitted decisions rose 1.0141ms per 1ms of injected coordinator distance. Tyr admitted decisions had a median slope of -0.0001ms/ms with a 95% interval of -0.0005 to +0.0002. This measures local decisionDuration excluding queue wait, not end-to-end response latency.
Admission timing is separated from response timing
At 0ms, the safe handoff took a median 0.81s. First batch admission was bounded to 0.36s–0.68s after commit at the median, while response headers arrived 14.28s after commit because the large batch request still had downstream simulated service to do.
Protected-class evidence is older than the ladder
The reviewed npm run demo:classes run used Tyr 0.22.0 and Latchflo 0.8.0. It remains useful correctness/isolation evidence, but it is not presented as a current-stack performance measurement.
Peer-routing causality is not isolated here
Peer routing ships in the current Tyr release. The published ladder measures the full MoFlux arm with routing enabled, but it does not isolate routing as a standalone causal effect.