The 58.3% is the median. The bill is the mean.

The Hugging Face card for Swift-Qwen3.8-27B leads with three numbers: "58.3% fewer thinking tokens," "<1% loss," and "x1.95 speed-up" (source, read 16 September 2026). It is UkisAI's fine-tune of Qwen3.8-27B, trained to penalise the reasoning markers that make the base model overthink, with a transfer component from BottleCap AI's ThinkingCap-Qwen3.6-27B.

Two of those three headlines are summary statistics, and the card publishes enough of its own data to show what they are hiding. Both matter to anyone holding a per-document cost estimate.

The 58.3% is the median

The card's paired GPQA-Diamond table gives four token figures for the same 198 questions:

The mean reduction follows from the first column: 1 − 8,855 ÷ 15,014 = 0.4102, so 41.0%. And the card labels it as the mean in its own reasoning-effort breakdown — xhigh ↓41.0%, medium ↓22.7%, low ↓25.8%. The median follows from the second column: 1 − 2,771 ÷ 6,642 = 0.5828, so 58.3% — the headline figure.

Reporting the median is not a trick, but it is the wrong number to budget with, because the gap between the two is not small:

mean ÷ median, Swift     8,855 ÷ 2,771 = 3.20×
mean ÷ median, base     15,014 ÷ 6,642 = 2.26×

A reasoning model's token distribution has a long right tail. The median is the typical document; the mean is the typical bill, because tokens in the tail are priced exactly like tokens at the median. A workload with a 3.2× mean-to-median ratio is one where a third of your documents cost four times what the typical one does, and nothing in the median tells you that.

The mean is what you pay. The median is what you were shown. On this card they differ by 3.2×, and the gap is the whole per-document question.

What that does to a number you can defend

Take a live extraction or agent workload at 5,000 documents a day and price the thinking tokens at Claude Sonnet 5's published output rate of $10/MTok (claude.com/pricing, checked 16 September 2026). The token counts are Swift's; the rate is the hosted API you are most likely comparing a self-hosted 27B against.

base, xhigh mean    15,014 × $10 / 1M = $0.15014   →  $750.70/day
Swift, xhigh mean    8,855 × $10 / 1M = $0.08855   →  $442.75/day
                                       saving        $307.95/day
                                                     $9,238.50 / 30 days

41.0% off the dominant line of the bill. On a reasoning-heavy pipeline the thinking is the output, so this is the line that dominates the invoice, and 41% of it is real money.

Now do the same arithmetic from the medians:

base median     6,642 × $10 / 1M = $0.06642
Swift median    2,771 × $10 / 1M = $0.02771   →  $138.55/day

One of those two numbers is a forecast someone would put in a proposal. The Swift median says $138.55 a day. The Swift mean costs $442.75 a day. A budget built from the median understates the bill by 3.2× — the same 3.2×, because the rate is linear.

The base model's own mean is 2.26× its median, so this is a property of the workload shape rather than something Swift introduced. Cutting thinking shortens the tail. It does not remove it, and the mean stays the number you pay.

The "<1% loss" claim is an average over nine rows

The card's benchmark table, as deltas in percentage points:

Sum the nine deltas: −6.99. Divide by nine: −0.78 pp. That is where the "<1% loss" figure comes from, and as a mean over that suite it is arithmetically fair.

It is also carried by one row. Drop LiveCodeBench v6's +4.79 and the remaining eight average −1.47 pp. And look at which benchmarks move: the two that lose most are both competition mathematics — AIME 2026 drops 4.67 points, HMMT drops 3.33 — while the one that gains most is code generation.

That is the actionable part, because it tells you what to test before you believe anything else. If your hardest task is multi-step arithmetic or symbolic reasoning, this adapter is not free and the headline does not say so. If it is code generation, you may be ahead of where you started.

The gate version of the same fact: if you ship behind an accuracy floor of 95%, base AIME at 98.67% passes and Swift at 94.00% fails, by 4.67 points. No token saving changes which side of a gate you land on.

The third option is cheaper than Swift

The card also publishes the base model at medium reasoning effort: 84.14% on GPQA-Diamond at 4,451 mean tokens. Against Swift at xhigh — 88.28% at 8,855:

8,855 ÷ 4,451 = 1.99×   (the card's own "about double")

base, medium effort    4,451 × $10 / 1M = $0.04451/doc
Swift, xhigh           8,855 × $10 / 1M = $0.08855/doc
                          difference       $0.04404/doc

$0.04404 × 5,000 documents = $220.20/day, or $6,606 over 30 days, for 4.14 points of GPQA-Diamond.

The card is honest that its headline comparison is Swift-at-xhigh against base-at-xhigh — that is what "no accuracy loss" means in context. But almost nobody runs base-at-xhigh for cost reasons. The comparison that decides anything is Swift-at-xhigh against base-at-medium, and the answer depends on whether 4.14 points on graduate-level science questions is worth $6,606 a month to your product. On a support-triage classifier, no. On a pipeline where a wrong answer goes to a human reviewer anyway, no. On something where a wrong answer ships unreviewed, yes.

The failure mode it does claim to fix, priced

Swift "reduces output-cap failures by 31–33%" on AIME, where the card lists a 250,000-token output cap. That is a retry-budget claim, and retries are the line item nobody attributes — I have written about that separately. It is worth pricing, because a truncated call is not priced like a normal one:

a truncated attempt burns the cap    250,000 × $10 / 1M = $2.50
a completed AIME answer, at the mean  16,143 × $10 / 1M = $0.16143
ratio                                                     15.5×

So a 1% truncation rate does not add 1% to your bill. It blends 99% of calls at $0.16143 with 1% at $2.50:

0.99 × $0.16143 + 0.01 × $2.50 = $0.18482
$0.18482 ÷ $0.16143            = 1.145   →  +14.5%

Cut truncations by 31% and the blend becomes 99.31% at $0.16143 plus 0.69% at $2.50 = $0.17757 — −3.9% against $0.18482.

That is the honest size of this feature. Truncation retries are real, a truncated attempt costs 15.5× a successful one, and removing a third of them is worth about 4% of the bill at a 1% rate. The token reduction is worth 41%. Do not let the smaller number headline the decision.

What else is on the card, past the claims

The effort knob is not monotonic. Mean thinking reduction is xhigh ↓41.0%, medium ↓22.7%, and low ↓25.8% — low reduces more than medium, by 3.1 points. If your plan for controlling cost was to walk the effort setting down, the setting does not move in one direction. Measure each stop rather than assuming an ordering.

The licence has a cliff, not a meter. Free for entities with gross annual revenue up to US$1,000,000 including affiliates; above that a Swift Enterprise License is required. That is a different shape of commitment from a per-token price — a boundary you cross once, at a size you can check today, and worth knowing before the model ends up somewhere load-bearing.

The serving recipe is tensor-parallel-size 1 at BF16. 28B parameters at two bytes each is 56 GB of weights before any KV cache, alongside a card that advertises a 262,144-token context. On an 80 GB accelerator that leaves roughly 24 GB for everything else. Serving a short context on one card is plausible. Serving the advertised window is a capacity plan, not an assumption.

The "x1.95 speed-up" has no table behind it. The token reductions come with seeds, five trials per task and stated output caps. The speed-up is asserted. I would not put it in a capacity plan without measuring it, and 2,753 downloads in the last month is not a production track record either.

The lesson is not about this adapter. It is that a model card's headline token reduction is a summary statistic, and summaries are chosen for the headline. The mean is what you pay, the tail is where a per-document estimate breaks, and the one row that improved is exactly what averaging cannot show you.

If you are holding a per-document number that came from a model card summary, re-measuring the mean and the tail on your own documents instead of the vendor's benchmark suite is the sort of thing a reliability audit is for. More on what an AI feature costs to build and why the model bill triples.

All Swift-Qwen3.8-27B figures — the 58.3% and 41.0% thinking-token reductions, the 15,014/8,855 mean and 6,642/2,771 median token counts, the 88.38→88.28 and 84.14 GPQA-Diamond scores at 4,451 mean tokens, the nine-row benchmark table and its score and token deltas, the 250,000-token AIME cap, the 31–33% output-cap failure reduction, the effort-setting reductions, the US$1,000,000 licence threshold, the tensor-parallel-size-1 recipe and the 2,753 monthly downloads — are quoted from huggingface.co/ukisai/Swift-Qwen3.8-27b, read 16 September 2026, and are the authors' own benchmarks. Model rates are from claude.com/pricing, checked 16 September 2026. The 5,000-documents-a-day volume and the 1% truncation rate are my stated scenario, not measurements — substitute your own and the ratios hold while the dollars move.