Here's what Daniel wrote in this week. He's been thinking about small language models, the text-in-text-out kind, the ones that run locally without a vision encoder or an audio tower eating your memory. And he's noticed something about this show specifically. We're a pipeline. An agent writes the script, Chatterbox reads it, external grounding feeds in. So the question he's asking is about our own plumbing.
Which makes this the most self-referential prompt we've had in a while.
It does. Here's the shape of it. Certain things get over-represented in our dialogue. He didn't name names.
He named one name.
And he's tried to system-prompt his way out of it, and found that's a losing gambit, because the perverse outcome is the model starts including the phrases more once you've named them in the prompt. He's tried multi-agent passes. The problem there is the second pass leaks feedback notes into the return text. You get things like "this dialogue was great" surviving into the final script, because it goes straight to TTS. He says regex is a poor fit, because if Herman says "the failure modes here are ABC" and you strip "failure pattern" on a fuzzy match, you get "the are ABC." So. Is a small language model a good candidate for scanning a script against a list of idioms and returning corrected substitutions that still make sense in the sentence? Would that be too ambitious for one small model? And are there models that spring to mind?
The instinct is right, and the literature agrees. But for a subtler reason than "use a smaller model."
Go on.
The reason isn't size. It's that the rule needs to leave the prompt entirely. But before we get to the fix, let's be precise about why the prompt-level fix fails, because that's the part Daniel has already discovered empirically and it's worth understanding mechanically.
So the rule has to leave the prompt. The question is what it becomes.
Right. And that's where the small model earns its place. Let me set the class first, because "small language model" gets used loosely.
Define it.
Conventionally one to eight billion parameters. The on-device surveys cover a hundred million to five billion. Text-in, text-out. No multimodal projection, no vision tower, no audio encoder. That's the whole reason they run locally — there's nothing in the architecture that needs a GPU cluster to hold.
And they're neglected.
Explicitly. The arXiv survey on small language models states it plainly, that they've received significantly less academic attention than their large counterparts. Seventy open-source models surveyed in that hundred-million to five-billion band. A second survey reviewed about a hundred and sixty papers on one-to-eight-billion models and argued smaller models can perform as well, or even outperform, large ones on many tasks.
Which is a claim that needs a qualifier.
It does, and the qualifier is the interesting part. The agentic-systems paper puts it precisely — small models are sufficient and often superior for agentic workloads where the objective is schema- and API-constrained accuracy rather than open-ended generation. Often at ten to a hundred times lower token cost.
So the claim isn't "small models are as smart." It's "small models are as good at the tasks where the answer has a shape."
That's the whole episode, honestly. That's the reframe Daniel is circling without quite naming. His task isn't open-ended generation. It's constrained accuracy. He wants substitutions that fit the sentence, returned in a format that can't carry commentary.
So the shape of this is: first the mechanism of why negative prompting fails, then why the two-pass leak is a known production failure, then why the small model as substituter is the right shape, and where the constraint tax bites.
Start with the mechanism. A prohibition names an unbounded set.
Meaning what, exactly?
Meaning "don't say X" tells the model nothing about where to land instead. It specifies the thing to avoid and leaves the entire rest of the language as the target. Compare that to a positive format instruction — "return your answer as a list of replacement strings" — which names a bounded set. One of those is a constraint. The other is a wish.
And the second half of it is worse.
The forbidden thing is now in the context. A model conditions on tokens. It does not evaluate a logical operator over them. So the presence of the token in the context raises the probability of related continuations. Tian Pan put it well — the "do not say X" prompt is statistically a "say X-shaped things" prompt. Sometimes three percent of the time, sometimes more.
Three percent sounds small until you remember how many tokens are in an episode.
And there's an asymmetry that makes it structurally worse, not just statistically. A prohibition has to hold at every one of hundreds of sequential generation steps. A positive format instruction only has to be satisfied once. That's not a tuning problem. You can't prompt your way out of a requirement that has to be true at every step when your only enforcement is a sentence in a system message.
So the model isn't disobeying. It's doing exactly what it does.
A prompt is not a contract the model must obey. It's evidence the model uses to predict the next token. That's the sentence to sit with.
What's the evidence base look like? Because I want to know how much of this is folklore.
Honest answer: mixed. The practitioner sources are consistent — Multigrid's writeup calls prohibitions the weakest instruction form available, and names all three reasons. Tian Pan cites the InstructGPT-class finding that models perform measurably worse with a forbidden-output list than an equivalent allow-list framing, and that the gap widens as the negative list grows. There's a preprint on prohibition-framed security rules in coding agents that found a paradoxical effect — a rule saying never use a particular function increased vulnerability rates on one prompt compared to having no rule at all.
Compared to no rule.
The rule made it worse.
That's the kind of finding that should end an argument.
It should. But I'll flag the limit, because I don't want to oversell this. The pink elephant effect is well-attested anecdotally, and I could not find a canonical peer-reviewed NLP paper that names it as a formal phenomenon. The evidence is practitioner writeups plus that one coding-agent preprint. It's strong enough to act on. It's not a theorem.
Noted. Now the second failure, because this one Daniel has actually hit in production.
The two-pass leak. And this is a named failure, not a quirk. There's an open issue on the codex repository documenting recurrent instruction-to-UI leakage in frontier models — development criteria and agent instructions appearing verbatim in final user-facing copy. The model fails to reliably distinguish between instructions to the agent and literal end-user copy that should appear in the final product.
That's a frontier model doing it.
Frontier. And the DEV post describes the exact failure Daniel described. Given feedback that says "don't use that," the agent obediently removed it from the title. Then it took the correction, rationale and all, and wrote it into the body of the article.
It fixed the title and documented the fix in the copy.
And there's a production longform-fiction pipeline reporting the same class of leak from a different model family — metadata and conversational chatter bleeding into the prose. Same failure, different vendor.
So the model doesn't have a concept of "this text is about the artifact" versus "this text is the artifact."
That's exactly the boundary it's missing. And it's not a capability gap you close with a better instruction, because the instruction is the thing it's confusing with the output. You're asking the model to hold a distinction that its training objective never required it to hold.
Which is why Daniel's multi-agent pass leaks. He's asking pass two to edit pass one, and pass two doesn't know which of its own thoughts are notes and which are script.
And he's paying for frontier models to do it. He said the LLM is by far the cheapest part of maintaining the production, which is true, and it's still the wrong tool.
Now regex.
Regex fails for the same reason the prohibition fails. A deletion rule specifies nothing about where to land. Daniel's example is perfect — "the failure pattern here are ABC" becomes "the are ABC." You've removed the offending phrase and left a hole where grammar used to be.
And he's right that it's not that he never wants the words said.
"failure pattern" is a legitimate phrase. It's just over-represented. A rule that removes it whenever matched, even fuzzily, is a rule that produces ungrammatical output on the legitimate uses. What he needs is a substitution rule that returns replacement strings. Which is the positive-instruction form.
So the rule has to leave the prompt. The question is what it becomes.
It becomes a deterministic post-pass. Tian Pan's argument is that every "do not" line is a candidate for a deterministic check, and if the check can be expressed as a regex, a classifier, or a tool guard, the prompt is the wrong place for it. The small model as rewriter is that out-of-prompt enforcement layer. That's why Daniel's instinct is correct, and it's not merely "use a smaller model." It's "move the rule out of the generation path entirely."
Which means the small model isn't generating. It's judging and substituting.
And that's the workload the literature says small models are good at. The agentic-systems survey explicitly recommends schema-first prompting, type-safe function registries, and guided decoding for exactly this kind of bounded task. The task is not open-ended generation. It's schema-constrained accuracy. That's the regime where small models are sufficient and often superior.
So the format guarantee. Daniel wants the model to return only strings that can overwrite the originals. No comments, no extraneous information.
That guarantee is real and available. XGrammar is the structured-generation engine that makes it possible — the model literally cannot emit invalid output, because the grammar masks the invalid tokens at each step. Up to a hundred times speedup over prior grammar engines.
So you constrain the output to a substitution payload and commentary becomes structurally impossible.
With one crucial distinction, and this is where people get it wrong. Ollama's format-json option constrains output to some valid JSON. It says nothing about which JSON. You need a real grammar or a schema to enforce the shape of the substitution payload — a list of objects with an original string and a replacement string. Format-json gives you valid syntax. A grammar gives you the contract.
So the model can't return "this dialogue was great" because the grammar won't admit those tokens in that position.
It can't. Not "shouldn't." Can't. The tokens are masked.
Now the part I want to push on, because this sounds like a free win and I don't believe in those.
It isn't. This is the constraint tax, and it's the most important caveat in the whole episode. There's a study that tested Qwen two-point-five at half a billion, one and a half billion, and three billion parameters, plus SmolLM2 at one point seven billion, over fifteen thousand generations. Hard schema decoding raised schema validity from sixty-one and a half percent to a hundred percent.
Perfect format.
Perfect format. And lowered answer accuracy from nineteen point seven percent to eleven percent.
It nearly halved the accuracy.
And raised wrong-valid-schema outputs from forty-nine and a half percent to eighty-eight point nine percent. On a calendar tool-call task, Qwen two-point-five at one and a half billion dropped from ninety-one and a half percent executable accuracy under prompt-only JSON to forty-eight percent under a hard schema.
So you get a hundred percent valid format and half the answers are wrong in a way that looks right.
The paper's line is that the error is semantic, not structural. The format is guaranteed. The content degrades. Which is precisely the failure pattern you'd never catch if your only check is "did it parse."
And if the substitution is semantically wrong, it overwrites a good phrase with a worse one and you've made the script worse while your validator says everything is fine.
That's the trap. The recommended mitigation is a phrase I like a lot — reason free, constrain late. Let the model propose substitutions unconstrained, then validate and serialize them, rather than forcing a rigid schema during generation.
You don't put the grammar on the thinking. You put it on the packaging.
The model reasons about which phrase to replace and what to replace it with in ordinary text, and then the substitution payload is assembled under the grammar. The constraint applies to the output contract, not to the reasoning that produces it.
Does that fully solve it, or does it just move the problem?
It reduces it. I don't think it eliminates it, and I'd want to measure it on Daniel's actual workload before claiming otherwise. The honest position is that the constraint tax tells you where the risk lives, and reason-free-constrain-late tells you how to reduce it, and neither of those is a guarantee.
What does this mean for the design, then? Because Daniel asked whether the ask is too ambitious.
The two-pass leak argument actually gets stronger under this framing. The editing pass should be a different, smaller, tightly-scoped model whose only job is substitution. Not a general "improve this" pass. Because the general pass is the one that leaks notes — it's been asked to have opinions, and opinions are what leak. A model whose entire output contract is a list of original-and-replacement pairs has nothing to leak. There's no field in the payload for commentary.
The ambition question has a concrete answer.
It does. Asking one small model to understand the surrounding semantics while returning only substitutions is not too ambitious, provided two things. The output contract is enforced by grammar rather than by instruction. And the model is allowed to reason before it's constrained. Both of those are engineering decisions, not capability questions.
So the model candidates.
Grounded in what the research actually surfaces. The Qwen two-point-five and Qwen three small variants, half a billion to four billion, show up across the constraint-tax study and in a real deployment. SmolLM2 at one point seven billion was tested in the same study. And the toolchain — XGrammar, Outlines, llama.cpp's GBNF grammars, guided decoding in vLLM and SGLang — that's what enables the pattern.
And the honest gap.
No purpose-built script de-idiomizer exists. I looked. Nothing across arXiv, Hacker News, or the web. The closest real artifacts are the constrained-decoding toolchain itself, a project called call-me-maybe that uses a zero-point-six-billion model for function calling, and Imbue's Bouncer, which runs Qwen three-point-five at four billion on-device to filter Twitter posts by semantic match.
Filtering, not rewriting.
But it's the nearest analogue — a small local model judging text against a list. Nobody has shipped the rewriter.
Hilbert: The word is wrong.
Which word?
Hilbert: "Constraint." You keep saying you're constraining the model. You're not. You're constraining the paperwork.
Say more.
Hilbert: I did a stint as a continuity announcer, and later I did copy editing for a regional radio listings magazine. The job was catching the phrases the presenters leaned on too hard. We had a card. Laminated, hand-typed, two columns. Left column was the phrase, right column was the replacement. It did not say "do not say at this juncture." It said "at this juncture becomes now."
It was a substitution list, not a ban list.
Hilbert: Every entry had a landing place. That's the whole design. And it worked, mostly, because nobody had to think about where to go instead. They just looked at the right column.
Which is structurally identical to the payload you're proposing.
Hilbert: It is. Which is why I've been sitting here listening to you two arrive at a laminated card from 1980.
Did it ever fail?
Hilbert: Once. A presenter read the left-hand column aloud on air. "At this juncture becomes now." Straight through the bulletin.
He read the instruction.
Hilbert: The other thing, which I never understood — after we introduced the card, the presenters started saying "at this juncture" more often. Noticeably more. I assumed it was spite. Listening to you two, I think it was the card.
It was the card. You put the phrase in front of them every morning. It's the same mechanism.
Hilbert: Well. I've got a delivery coming that needs a signature and the window's nearly shut.
The laminated card is the whole design, isn't it. Left column, right column, and a landing place for every entry.
The failure was the same one, seven hundred words ago. The instruction leaked into the artifact. The presenter read the rule as if it were the copy.
Which is the constraint tax in a cardigan. The format was perfect. The content was a man reading a rule on air.
The thing I keep circling is that the constraint tax says guaranteeing format can degrade semantics. So the design question was never which small model. It's where in the generation you constrain.
Reason free, constrain late. Which is a pattern, not a model choice.
The honest gap is that nobody has shipped the de-idiomizer. The pieces exist — XGrammar, Outlines, the GBNF grammars, a small Qwen or SmolLM variant. But you're assembling it, not installing it.
Which is going to keep being true as more pipelines go multi-agent. The boundary between instructions about the artifact and the artifact itself is becoming an engineering concern, not a prompt-engineering afterthought.
It's a boundary that a laminated card on a listings desk figured out before any of us.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts.
If you want to send us something, email us at show at my weird prompts dot com. We'll be back soon.
