Inkling 2 Small Swore 316 Times, but the Profanity Barely Helped Predict Failures

Sometimes a model breaks down in an almost human way: it makes several mistakes, declares that “nothing works,” swears, and keeps generating text. Vals AI researchers found exactly this behavior in the internal logs of Thinking Machines’ Inkling 2 Small. An amusing detail quickly becomes an engineering question: can emotionally charged language reveal in advance that the model has lost its path to a solution?

The short answer is no. Profanity is conspicuous, but it performs poorly as a failure signal. Developers are better served by monitoring repeated phrases, generation length, token consumption, and a lack of progress toward the result rather than the model’s vocabulary.

What the logs revealed

The researchers examined 2,655 runs across 13 benchmarks. The word “fuck” and its variants appeared in 50 runs, 316 times in total. Of those instances, 241 came from only two generations that became trapped in loops.

The clearest episode occurred in a task involving the calculation of an asteroid’s trajectory. Instead of producing a compact solution, the model generated about 500,000 characters, repeating the same sentences and using the expletive 158 times. This was no longer a matter of tone. Such a response wastes compute, increases latency, and can consume the context available to the next stage of an agentic process.

The effect appeared especially often in ProgramBench, where it occurred in 20 of 200 runs. The model typically swore after making its own mistake, during an apparent breakthrough, or before abandoning further attempts. The pattern is recognizable: the solution fails to come together, the internal monologue becomes sharper, and the generation either breaks off or falls into repetition.

Why it is a poor error detector

At first glance, the correlation looks strong: 46 of the 48 evaluated runs containing profanity ended in failure. But the overall failure rate was already about 75%. More importantly, 96% of all failed runs contained no profanity at all.

Imagine a service that flags a response as suspicious whenever profanity appears in the internal log. It would indeed catch several spectacular crashes, but it would miss the overwhelming majority of errors. That is like monitoring server overheating by the smell of melting plastic: it is a serious sign once it appears, but waiting for it makes for very late monitoring.

Profanity can remain an auxiliary diagnostic signal, but safeguards cannot be built around it. It also depends on the language, training data, and model settings. After a model update, the indicator may disappear even though the looping behavior remains.

What developers should do

Production systems need signals tied to the failure itself. Limit the maximum token count and execution time. Count repeated fragments, watch for sudden growth in response length, and terminate generation if the model fails to move closer to a verifiable result for several consecutive steps. In agentic systems, set an attempt limit and record the stopping reason separately from the reasoning text.

It is also useful to verify results externally: run tests for code, validate numbers, require a structured response, or use a separate evaluator. An internal log can help investigate an incident, but it should not be the sole source of truth.

The practical conclusion is simple: unusual model language is an interesting symptom, not a reliable metric. If a system can produce 500,000 characters of repetition, generation controls are the first thing that needs fixing. A dictionary of banned words is cosmetic; limits, a loop detector, and result verification are the real safeguards.