docs(limits): record that the published 1M is a rounded-down 1,048,576 - #48
Merged
Merged
Conversation
The rate-limits test carries a contract: "If any of them moves upstream, this
test has to be updated in the same change: the failure is the point." The GLM
context window is moving upstream (cloud-api 500,000 -> 1,048,576), so this is
that same change.
The published value does NOT move, and that is the point of the commit. It
already reads 1,000,000 here while cloud-api still says 500,000, so the mirror
was ahead of its source and nothing recorded why. Now it does:
* 1,000,000 is the ROUNDED-DOWN form of the backend's 1,048,576, not a stale
copy of it;
* rounding DOWN is the safe direction — a member who trusts 1M can always
send it, whereas advertising 1.049M and enforcing less could not be
honoured;
* the exact value renders as "1,049M" under es-ES, which reads as 1049
million, so publishing it would be worse than imprecise.
The test note also states the condition that ends this: if the backend ever
drops BELOW 1,000,000, rounding down stops being conservative and this has to
move with it.
`npm run build` clean; vitest 727 passed across 50 files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reworked after the QA review, which took apart the reasoning in my first
attempt and was right on both counts.
I had published a rounded-down 1,000,000 on the grounds that the exact value
renders "1,049M" in es-ES and "reads as 1049 million". It does not: in es-ES
the comma is the DECIMAL separator, as this file's own comment says two lines
above ("the card cannot read '3,000M' next to a model card that says
'3.000M'"). A Spanish reader reads 1,049M as ~1 million. My premise was wrong.
The real defect was the juxtaposition — "1,049M" beside "3.000M" on the same
page, a comma and a dot meaning opposite things in the same units — and that
belongs to the FORMATTER, not to the published number. `maximumFractionDigits:
0` renders exactly the round "1M" while publishing the true value:
1048576 es: 1M en: 1M
3000000000 es: 3.000M en: 3,000M
WHAT ROUNDING THE CONSTANT WOULD HAVE COST, which is the part that convinced
me: the site would sit permanently 4.8% below the source it declares it
mirrors, and the test contract would mutate from an EQUALITY into a floor. The
equality is the mechanism — it is what makes a backend change fail here
instead of shipping quietly, and it is exactly what caught this whole class of
bug. A floor is weaker: a future 900_000 upstream would pass it green.
So the test note goes back to the one-line mirror it was, and the assert is an
equality again.
`npm run build` clean; vitest 727 passed across 50 files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sre-helmcode
added a commit
that referenced
this pull request
Sep 11, 2026
* fix(limits): floor the token display, never round it up UX non-blocking on #48, and it closes a pair that was left half-done: the member portal guards this with `Math.floor` and the PUBLIC site did not. `maximumFractionDigits: 0` truncates nothing — it ROUNDS. Measured before and after: value before after 1048576 1M 1M 1500000 2M 1M 1900000 2M 1M Harmless at today's window, which rounds down anyway. But this page is read by people who have not paid yet, so it must never advertise MORE than the backend allows — and that is exactly the reasoning already written into cloud-ui's formatContextWindow. The guard belonged on the more public surface too, and I only put it on the private one. `roundingMode: 'floor'`, one option, no change to any published number. The other figures are unaffected: 3,000M / 3.000M and 400M render as before. `npm run build` clean; vitest 727 passed across 50 files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(limits): note that the published window is the provider's total UX follow-up, same sentence as devops#312 and enterprise-api#48. "exactly what the Novita primary serves" was the wrong frame: Novita's `context_size` covers input AND output together, so 1,048,576 is the provider's total budget, not a servable input window. A prompt at the very top leaves no room for the reply, nothing on our side filters for it (`_pre_call_checks` is off), and the caller gets the provider's error on a number this page publishes. Comment only, no published number changes. `npm run build` clean; vitest 727 passed across 50 files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(limits): assert the floor with a value that can tell it apart QA blocker, and it is the rule I have been applying all chain turned back on me: a guard that cannot fail is not a guard. `formatTokens(1_048_576)` renders "1M" whether the formatter floors or rounds, so the 727 green tests said nothing about the fix — they pass identically if `roundingMode: 'floor'` is deleted. There was no test anywhere referencing `1_500_000`, `floor` or `roundingMode`. It matters more here than in the member portal, which QA also spotted: `roundingMode` is an Intl.NumberFormat option, and a runtime that does not support it IGNORES IT SILENTLY — no error, just rounding again. So the question is not "is the word still in the source" but "does this runtime actually floor", and only an assert answers that. Verified by removing the option: `expected '2M' to be '1M'`. Restored: green. The second test pins the figures that must NOT change (1,048,576 → 1M, 3,000M / 3.000M, 400M), so a future rounding change cannot quietly move them. Also closed a seam QA found, the third of this shape in the chain: inserting the caveat paragraph left "It renders as" dangling at the end of the new block. The heuristic worth keeping — when you insert a block, read the sentence immediately before and immediately after it. `npm run build` clean; vitest 729 passed across 50 files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * style(limits): reflow the comment left ragged by the previous insert * style(limits): wrap the last over-long comment line --------- Co-authored-by: barckcode <cristian@helmcode.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
src/tests/lib/rateLimits.test.tscarries an explicit contract:The GLM context window is moving upstream in helmcode/nan-cloud-api#192 (500,000 → 1,048,576), so this is that same change. Flagged by the QA reviewer, who spotted that #192 moved the source without touching this mirror — and that because these are separate repos, CI here would have stayed green and the failure would have landed on whoever next touched this repo, blaming the wrong change.
The published value does not move, deliberately
It already read
1_000_000here while cloud-api still said500_000, so the mirror was ahead of its source and nothing recorded why. Now it does:1,000,000is the rounded-down form of the backend's1,048,576, not a stale copy.1,049Munder es-ES, which reads as 1049 million. Publishing it would be worse than imprecise.The note states the condition that ends this: if the backend ever drops below 1,000,000, rounding down stops being conservative and this has to move.
Context
The backend number is exactly what the Novita primary serves (
context_size 1048576, checked against Novita's model listing — not OpenRouter's 1.31M, which belongs to the fallback tier only).Tests
npm run buildclean.vitest run: 727 passed across 50 files.🤖 Generated with Claude Code