I Was drafting my blog post, told Claude "keep it to 250 words." Got back something like 340. Asked again. Same story.
Figured there's a real reason behind this, and since I'm neck-deep in AI/ML fundamentals right now, decided to actually understand it instead of just being annoyed by it.
It generates one token at a time, no plan
LLMs don't write like we do think of the whole thing, then fill it in. They generate autoregressively: predict the next token, add it to the context, predict the next one, repeat. There's no "here's my 250-word essay, let me write it out" step happening anywhere. Every single token is picked based on what came before, nothing more.
So when you ask for 250 words, the model isn't holding a target in memory and counting down. It's pattern-matching: "text like this, following an instruction like this, tends to stop around here." That's a guess shaped by training data, not a computation.
Words ≠ tokens
Also it's not even counting words. Internally, everything is tokens: sub-word chunks. "Debugging" might be one token or three depending on the tokenizer. "250 words" as an instruction gets converted into an expectation of roughly how many tokens that maps to, and that mapping is fuzzy. There's no clean 1:1 between what you asked for and what the architecture tracks.
No counter anywhere in the architecture
This is the part that surprised me most: there's no length-tracking variable sitting in the model's forward pass. No if word_count == 250: stop. The only thing steering generation is the probability distribution over the next token, sampled step by step, until it predicts an end-of-sequence token or hits a max-length cutoff set by the system.
Compare that to something like a for loop with a counter deterministic, exact. LLM generation is closer to sampling from a learned distribution, over and over. Approximate by design, not by bug.
The workaround
Since I can't get an exact count out of a single generation, what actually works:
- Ask for a natural stopping point instead of a hard number
- Generate first, then trim or expand after, treating the count as a second pass, not the first
- For real precision, set limits in characters or use iterative regeneration with a check step, rather than trusting the first output
Why this clicked for me
This ties directly into what I've been learning attention, softmax over vocabulary, sampling strategies. Word-count control would need something structurally different: a running counter fed back into the decoding loop, or a constrained decoding step that force-stops at a token budget. Neither is how these mainstream models work by default.
Small annoyance, decent rabbit hole. Worth knowing before you set a hard word limit and assume the model's counting along with you.
Learning AI/ML from the ground up cloud engineer trying to understand the models she uses daily.
Top comments (0)