fix(context): count fullwidth chars in token estimates#96442
Conversation
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Codex review: needs maintainer review before merge. Reviewed June 25, 2026, 2:32 AM ET / 06:32 UTC. Summary PR surface: Source +1, Tests +7. Total +8 across 2 files. Reproducibility: yes. Source inspection of current main shows the shared regex omits the fullwidth Unicode ranges, so fullwidth forms are counted like ordinary text before downstream token division. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Next step before merge
Security Review detailsBest possible solution: Merge this focused shared-estimator update after normal maintainer review and required CI completion, keeping caller-specific budgeting logic unchanged. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection of current main shows the shared regex omits the fullwidth Unicode ranges, so fullwidth forms are counted like ordinary text before downstream token division. Is this the best way to solve the issue? Yes. Updating the shared AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 56d95b18f4bc. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +1, Tests +7. Total +8 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
188a0c4 to
cb78497
Compare
|
Merged via squash.
|
What Problem This Solves
estimateStringChars()inflates CJK/Hangul/Japanese text before downstream token estimates divide byCHARS_PER_TOKEN_ESTIMATE, but it did not include East Asian fullwidth forms. Fullwidth text such asABC123was counted like ordinary ASCII, so budget and pruning estimates undercounted that content.Why This Change Was Made
The estimator now includes the Unicode fullwidth ranges
U+FF01-U+FF60andU+FFE0-U+FFE6in the same weighted path used for other East Asian scripts. Ordinary ASCII remains unchanged.Focused tests cover fullwidth letters, numbers, and punctuation.
User Impact
Context budgeting and token estimate surfaces are less likely to undercount fullwidth CJK-style text, reducing the chance of overlarge prompts slipping past preflight estimates.
Evidence
Direct behavior probe:
Targeted test:
Formatting:
Whitespace:
AI-assisted
Prepared with Codex. I reviewed the change, understand the touched code path, and kept the PR focused on the bug described above.