Is every rare token a glitch token?

No. Rarity can be relevant, but the label requires evidence of anomalous behavior or the specific definition used in a study.

Can a token work in one model and fail in another?

Yes. Models can have different training exposure and learned representations even when their tokenizers are related.

Does splitting a string always fix the problem?

No. Alternative segmentation may help in some cases, but it changes the input representation and needs validation for the intended task.

AI Glossary / Generative AI and language / Intermediate

Glitch token

Definition

A Glitch token is a token associated with unusually unreliable or anomalous behavior in a language model, such as difficulty reproducing its text or responding coherently when it appears. A major studied cause is a mismatch between tokenizer vocabulary and model training: a token exists in the vocabulary but receives little or no relevant training exposure. The label is behavioral and model-dependent; not every unusual string or rare token is necessarily a glitch token.

What it means

A tokenizer converts text into token identifiers, and the model learns how to process those identifiers. Being present in the tokenizer's vocabulary does not guarantee that an identifier acquired a useful representation during model training. If tokenizer development and model training use different data, some vocabulary items can be poorly represented. This helps explain why a model that handles ordinary text well may behave unexpectedly on a small class of inputs. The problem is not evidence of hidden meaning in the string.

How it works

Researchers investigate suspected tokens using tokenizer properties, model-weight indicators, and controlled behavioral tests. A useful investigation checks the exact tokenization, the model and tokenizer versions, and whether an anomaly repeats across several neutral tasks. Comparisons with matched ordinary tokens help separate token-specific problems from general task difficulty. Weight-based indicators can prioritize candidates, but behavior and training evidence must be interpreted carefully. A failure on one prompt is not enough to prove that a token was absent from training or that every model sharing a tokenizer will fail similarly.

Three practical examples

Identifier handling: test whether a document assistant preserves unusual catalog identifiers when copying them into a structured report.
Model quality assurance: include rare and atypical vocabulary cases in a controlled regression suite alongside ordinary-language cases.
Tokenizer maintenance: check newly added vocabulary items and tokenizer-model compatibility when adapting a system, instead of assuming vocabulary inclusion alone provides reliable handling.

Think of it this way

Think of a keyboard with a key that is physically present but poorly connected to the software interpreting it. Pressing it produces an unexpected result even though the key exists. The analogy explains the gap between representation and learned behavior, but a glitch token is not necessarily a literal software wiring defect, and its effects can depend on context and model parameters.

Worked example

A fictional quality team tests whether a model can copy reference strings exactly. It uses 20 prompts containing one suspected token and 20 matched control prompts containing ordinary tokens of similar length. The model copies the control strings correctly in 19 cases but the suspected string in only six. The observed exact-copy rates are 95% and 30%, a difference of 65 percentage points.
That result justifies investigation, but it does not prove a specific training history. The team checks whether the suspected text really maps to the same token identifier in every prompt; leading spaces or surrounding punctuation can alter tokenization. It also repeats the test under recorded generation settings and inspects whether errors are simple formatting changes or unrelated substitutions. Suppose a revised tokenizer splits the same visible text into three familiar tokens and the copy rate improves. That is evidence that tokenization may matter in this setup, but it is not a universal repair result: changing segmentation can affect other behavior and must be evaluated separately. The counts are invented for instruction and are not findings from a published model study.

Illustrative case study

A fictional catalog-processing service notices inconsistent transcription of a few unusual product codes. Developers first rule out source-file corruption and extraction errors. They then record the tokenizer output and reproduce the problem in a controlled test. Because the codes are exact identifiers, the service passes verified identifiers through a deterministic field rather than relying on the model to rewrite them. The team keeps the anomalous cases in its regression set and documents the affected model configuration without claiming every unusual code is problematic.

Common misconceptions and mistakes

Glitch tokens are not simply spelling mistakes or words the model does not know. Visible strings can map to different token sequences across tokenizers and contexts. Sharing a tokenizer does not imply identical learned representations or identical failures. A strange response can have other causes, including prompt ambiguity, truncation, or decoding behavior. Blocking a short list of known strings is not a complete reliability strategy. Nor should a successful test on ordinary words be treated as proof that all vocabulary entries behave equally well.

Business use

The practical concern is reliability on the actual data a service receives. Preserve exact identifiers and critical source text using appropriate deterministic handling where possible. Test unusual inputs alongside representative everyday cases and record both the model and tokenizer version. Evaluate a proposed mitigation for unintended changes to normal behavior. When reporting an issue, provide reproducible benign examples and distinguish observed symptoms from hypotheses about their cause. Avoid turning isolated anomalies into broad claims about a model's overall competence.

Check your understanding

A strange string causes one incorrect answer. Can we conclude it is an untrained token?

Answer: No. First verify tokenization, repeat controlled tests, and consider alternative causes. Behavioral failure alone does not establish that the token had zero occurrences during training.

Related terms

Token
Tokenizer
Vocabulary
Robustness
token embedding
under-trained token
rare token
tokenization mismatch
exact-copy evaluation
regression testing

Learn next

Compare how a tokenizer represents ordinary words and unusual identifiers, including changes caused by surrounding spaces. Build benign copying and identification tests with matched controls. Study the distinction between tokenizer vocabulary and model training next, then read token-quality research with attention to each paper's definition and evidence for under-training.

Sources

Land and Bartolo, Fishing for Magikarp: Automatically Detecting Under-trained Tokens in Large Language Models: https://arxiv.org/abs/2405.05417 Li and colleagues, Glitch Tokens in Large Language Models: Categorization Taxonomy and Effective Detection: https://arxiv.org/abs/2404.09894

Previous: GLIE Next: Global calibration