Cause one: the model size was never suited to that job

Sub-1B models are not small versions of large ones. They are good at a specific, bounded class of work, and the class matters more than the parameter count.

What a 0.6B-1B model does reliably:

* drafting tokens for a larger model to verify * captioning an image * locating a UI element on screen for a click target * classifying into a small fixed set

What it does not do reliably:

* hold a multi-step plan across turns * decide when a task is finished * keep a tool-call schema stable under long context

The pattern is that the first list is bounded and checkable, there is a right answer and something can verify it. The second is open-ended. A model asked for open-ended work outside its range still answers, fluently, and has no way to return 'I am the wrong size for this'.

Serving systems encode this as capability tiers rather than raw size: a model declares a minimum tier and is refused below it. A refused load looks identical to an agent doing nothing, unless the refusal is surfaced.

Why speculative decoding shows the shape of the fix

Speculative decoding is worth understanding even if you never configure it, because it is the clearest example of a small model used safely.

A small draft model proposes tokens. A larger model verifies them. Wrong proposals are discarded before anyone sees them. The result is a fast reply that is still the large model's answer, commonly around 40% faster, with the small model's errors filtered out by construction, not by luck.

Run that same small model unsupervised on the same task and nothing filters anything. Same weights, same prompt. The difference between reliable and silently wrong is entirely whether something checks the output.

That generalises: any step in an agent loop with no verifier produces invisible failures, whatever size produced them. The useful question is not 'is this model big enough' but 'what checks this step, and would it notice'.

Cause two: the prompt left a decision unmade

The other half is not the model at all.

When a prompt leaves something ambiguous, a model resolves it. It does not flag it, and it usually resolves it the same way every time, which is why prompt-caused failures are so easy to mistake for model limitations. They look deterministic, because they are.

The distinguishing test is cheap. Run the same task several times:

* fails identically each run -> the prompt made the decision * degrades as the task gets longer -> size, context or attention * fails only past some step count -> the loop, not the model

Swapping in a larger model is the usual first move and it is the wrong one for the first case. A bigger model resolves the same ambiguity, more fluently, and the failure survives the upgrade, now with better prose around it.

Why 'silently' is the operative word

Every mechanism above shares a property: the failure produces a plausible output rather than an error.

A crash is cheap. It stops, it names a line, someone fixes it. A silent failure produces something shaped correctly, passes downstream, and only shows up as a number that looks slightly off, long after the run.

Three that recur, all cheap to prevent:

* A check that cannot fail. A validator tested only against bad input will pass even if it rejects everything. Test that it ACCEPTS known-good input. That is the test that can catch a reject-everything bug. * A swallowed exception. `except: continue` in a selection loop turns 'every candidate errored' into 'no candidates found', the same outcome as an empty list, and a completely different cause. * A detection fallback with no signal. When capability detection fails and quietly falls back, behaviour degrades correctly and reports nothing. The fallback is right. The silence is the bug.

None of these need better models. They need the failure to be loud.

What this page does not claim

There are no failure rates here by parameter count, because that would need a benchmark this page has not run. 'A 1B model fails N% of agentic tasks' is the kind of figure that gets quoted for years after being invented once, and one invented number discredits every measured one beside it.

What is asserted is structural: which classes of work are bounded and checkable, why capability tiers gate loading, and why a verified draft is safe where an unverified one is not. Those are design rationales, not empirical accuracy claims.

The prompt-versus-size diagnostic is a heuristic, offered as one. It is worth running because it is cheap and it separates two problems that get treated as one, not because it is proven.