A support tool rejects any user message longer than 2,000 words before sending it to Claude, on the assumption that this keeps every request inside the model's input budget. Live traffic shows a measured 4 per cent of accepted messages still failing on length, and the failures cluster on pasted log extracts, code snippets and German product names. The team must stop the length failures without lowering the word limit for ordinary prose. What should the guard measure instead?
- AThe number of characters in the message, since a character count is a stable proxy for the model's input budget across every kind of text.
- BThe number of lines in the message, rejecting anything past a fixed line count, because pasted logs and code are the content that produced the measured failures.
- CThe number of tokens the message occupies once tokenised, counted with a tokeniser before the request is sent, and compared against the budget the request actually has. Correct
- DThe number of words in the message, keeping the existing limit but applying it after stripping whitespace and punctuation from the text first.
Why A is wrong: Character count is tempting because it is finer grained than words, but the ratio of characters to tokens still varies by script and by content, so a fixed character ceiling either rejects valid prose or lets dense text through.
Why B is wrong: Line count is tempting because the failing content is line oriented, but a single line can carry thousands of tokens and a long prose message can carry very few lines, so the guard would miss the cause.
Why C is correct: Correct: the model's input budget is denominated in tokens, and only counting tokens before sending measures the same quantity the request is checked against.
Why D is wrong: This is tempting because it looks like a refinement of the current guard, but the unit is still words, and the failing content is exactly the text where one word becomes many tokens.