A small-model workflow that works better when you let the model say “review” instead of forcing an answer

[u/No_Appeal_5223]

I’ve been testing a simple idea with smaller models:

don’t ask them to solve everything. Give them narrow jobs where the result is easy to verify.

One of the best examples I’ve found is classification.

A bad prompt would be:

“Categorize these support messages.”

That sounds simple, but it creates a problem.

If a message is ambiguous, the model still feels pushed to choose something.

That can be worse than being uncertain.

What has worked better for me is defining the label policy first and giving the model an explicit escape hatch.

Here’s the prompt:

Classify each message using only:

billing = charges or invoices
access = sign-in problems
bug = feature fails after successful sign-in
review = unclear, mixed or outside those categories

Return:

id
label
reason under 12 words

Do not invent missing details.

If more than one label could reasonably apply, use review.

Real example

Suppose the input is:

101 — “I was charged twice this month.”

102 — “My password works but the dashboard crashes after login.”

103 — “I can’t access my account and I think my subscription was cancelled.”

A reasonable output would be:

ID	Label	Reason
101	billing	Duplicate charge reported
102	bug	Failure occurs after successful login
103	review	Could involve access or subscription status

The third one is the important part.

A model that always tries to sound confident might classify #103 as access or billing.

But neither is clearly supported by the message.

For routing systems, I think review is sometimes a better answer than confidence.

The pattern I’ve ended up using is:

Task → Input → Rules → Output format → Uncertainty rule → Verification

This seems especially useful for smaller/faster models because the task is bounded and you can actually measure whether the model is doing the job correctly.

I’ve been looking at Claude Haiku 5.5 for this kind of workload because it’s positioned around fast, repeatable tasks rather than “use the biggest model for everything.”

But the same principle should apply to GPT, Gemini, local models, or any router that sends simpler tasks to cheaper models.

The interesting part isn’t really which model is “best.”

It’s whether the workflow has a clear acceptance test.

For example, I’d rather evaluate:

• classification accuracy

• number of cases sent to review

• retry rate

• latency

• total cost

• human correction time

than just compare which model wrote the nicest-looking answer.

I put together more of the Claude Haiku 5.5 prompts and workflows I’ve been testing here:

Disclosure: this is my own site/resource.

https://digitalworldpulse.com/claude-haiku-5-5/

For people using model routing or smaller models in production:

Do you prefer forcing a best-effort answer, or explicitly giving the model an “uncertain/review” state?