Show HN: Cactus Hybrid: We taught Gemma 4 to know when it's wrong
https://github.com/cactus-compute/cactus-hybrid
Hey HN, Henry & Roman here from Cactus.A small, on-device model is fast and private, but sometimes wrong, but frontier models are getting expensive pretty fast. So, we post-trained Gemma 4 E2B post-trained to know when it's wrong. Every response comes with a confidence score between 0 and 1. Developers can accept the on-device when it's high, hand off to a bigger cloud model when it's low. By routing only 15-35% of queries to Gemini 3.1 Flash-Lite, Gemma-4-E2B matches Gemini 3.1 Flash-Lite on most benchmarks.
- ChartQA: 15-20%
- LibriSpeech: 25-30%
- MMBench, GigaSpeech, MMAU: 30-35%
- MMLU-Pro: 45-55%
We were always frustrated by the routing signals hybrid apps rely on: asking the model to rate itself in text (unreliable, and you're parsing prose), or token entropy heuristics (barely better than a coin flip in our tests). So we did mechanistic studies on small models, Gemma 4 particularly, and found the hidden state for different layers carry meaningful self-awareness signal for various situations.
SO we extended the model with a 68k params probe layer (LayerNorm, low-rank projection, attention pooling, small MLP head) reads one intermediate layer during decoding and predicts p(wrong); confidence = 1 - p(wrong), returned as structured data, never parsed out of the answer text.
Across 12 hold-out benchmarks spanning text, vision and audio, the probe averages 0.814 AUROC vs 0.549 for token entropy. The result that convinced us this is real: the probe was trained on zero audio data, yet scores 0.79-0.88 AUROC on four audio benchmarks where entropy is near-random or worse (0.32-0.52). It's reading a modality-independent correctness signal from the hidden state, not memorizing patterns from its training data.
We published all weights on HuggingFace and provide copy-pase codes to run it on Transformers, MLX, Llama.cpp or Cactus. With Ollama, vLLM, SGLang etc in the works. For llama.cpp we ship a patch series you compile in once (upstreaming is planned). The code is MIT licensed; Gemma model use remains subject to the Gemma terms.
GitHub: https://github.com/cactus-compute/cactus-hybrid
Weights: https://huggingface.co/collections/Cactus-Compute/cactus-hyb...
Some caveats:
- The probe scores single-sequence decoding only, up to the first 1024 generated tokens.
- Handoff works best when routing per task in a multi-step process, not per step.
- Hierarchical routing is still in the works: try on-device, then DeepSeek v4 Flash, before Fable/GPT5.5/Gemini/Muse/Grok.
- The technique is boutique for each model, we will share each weights as they roll out.
These issues are currently being tackled at Cactus and updated weights will be shipped directly into the HuggingFace collection and GitHub repository straight up. Please let us know your thoughts, it helps us find ways to improve the design progressively.
Thanks a million!
Neat! Just to make sure I understand - you trained your probe layer to take this hidden state and predict p(wrong)?
Curious to learn more. Any more info on your approach (esp the mechanistic study)?
And thanks, huge pasta fan :)
Or using it for sub-tasks, where a framework with a larger primary model dispatches simpler jobs ("summarize ...", etc.) to it?
Is it plausible to wonder if some developer judgement feels, like maybe "the code I just wrote is clean/crufty", or "things came together smoothly/janky", might have extractable signals in some models?
If so, might one create a shopping list of desired signals to check for in a model, as with activation steering concepts, where one checks whether and how hard each concept can usefully be nudged?
Is it also post-trained to know when it's wrong about when it's wrong?
> "Every response comes with a confidence score between 0 and 1"
How confident is it in its confidence?
Please, I'm sure that what you're doing is very neat and useful, but use other language to describe it. I beg you. You can't know when you're wrong. You can only know when you're unsure or inconsistent. You can be absolutely certain and still wrong and uncertain and still correct.
Complex assertions and their compounded forms can be filtered by these classes fairly easily. I rarely see this referenced in general comments.
"I like green" is a statement of fact about what you like. "Green is good" would be an opinion. It's funny to me how often people mix the two.
> forms can be filtered by these classes fairly easily
Obviously not so easily. :)
Opinion is a ghost in the machine—fleeting, unanchored, and vanishing upon inspection. It leaves no footprint for another mind to verify, no independent trail of evidence to confirm or deny its existence. To rely on such solitary perception is to drift in a void where facts do not exist; it is not merely uncertainty, but an absence of reality itself—a whisper that the universe refuses to echo back. --AI Carl Sagan
> "Verifying an opinion X at time T does not entail X at time T+1."
"My cat weighs 9.5 lbs" is only true within a context of a particular moment.
"1+1=2" is only true within a context of what "1" and "2" and "+" and "=" mean.
I think you could do without the invective.
My view is specifically thus:
> "Opinions can only be seen as facts when modelled as time series data."
Opinions can never be seen as facts, timestamps or otherwise. Only facts about opinions can be seen as facts, not the opinions themselves.
"Green is good" is never a fact regardless of whether you timestamp it. "Green is good right now" is not a fact. "Green was good yesterday" is not a fact. "BugsJustFindMe thinks green is good" is a (false) fact, "BugsJustFindMe said green is good" is a (true) fact, and neither one is an opinion at any time.
> "Verifying an opinion X at time T does not entail X at time T+1."
A constraint binding timeliness specifically to opinions is misplaced and also not extremely relevant in the context of whether something is a statement of opinion or fact.
[1] a view, judgment, or appraisal formed in the mind about a particular matter, https://www.merriam-webster.com/dictionary/opinion
Confirmation also is somewhat orthogonal: there can be true facts that we can't confirm.
Conventionally, "I like green" is considered a factual claim about the speaker's preferences. Even if you refuse to acknowledge it as a fact because of the restrictions you've given, that doesn't make it an opinion. It's subjective, but it's not an opinion.
Would you say that if someone is experiencing a headache, and they say "I have a headache", that that's also merely an opinion?
Complex assertions and compounding arguments, can still result in circular reasoning - the petitio principii, or worse.
Most LLMs are guided by strong statements like it must do this or that. Which assumes that it won't apply the fallacy of accident, even though people regularly do. (Don't agree? Argue a definition with a BA for a day and come back to me.)
Now there might be even better ways of getting feedback, I saw some interesting trials using "J-spaces" (from Anthropic's latest research in this area). Turns out you can kinda see when the model uses deep seeded concepts in early layers, or it's "riffing on an idea" with shallow signals in those same layers. And youc an get some signal out of it, and have it re-do a step.
It's also worth mentioning that LMs are wrong in different ways from humans. It's not impossible that we'll eventually find ways of better understanding this (through mechanistic interpretation or something else) and have easy "classifiers" for "this comes from the training data" vs. "this comes from early context" (i.e. supplied materials from prompts/discovery) vs. "this comes from later tokens, likely the model doom-looped itself".
Or the opposite https://arxiv.org/abs/2606.06574v1
> "It's also worth mentioning that LMs are wrong in different ways from humans."
This to me only shows a poor and incomplete knowledge of humans and of wrongness and its causes. If you look at all of the humans and all of the times, you find exhibitions of all the same ways of being wrong. At best you can say that some (<all) LMs are wrong in different ways than some (<all) humans at some (<all) times, but that's as good as saying that different humans are wrong in different ways than different other humans at different times.
https://plato.stanford.edu/entries/knowledge-analysis/
This is why LLMs are more successful in programming than other disciplines: it's easier to assess correctness of results, through proofs, typechecking, and testing. Similarly for maths and applied maths. Much harder in the humanities.
It seems successful specifically in "computer science", for "programming" which encompasses a much wider field, "successful" is still up for debate. Also, we haven't even figured out yet what "success" even means in a software development process, for some it's that the program does everything the users want, in the way they expect, for other's, it's about correctness, reliability, performance, composability, maintainability and/or a whole host of other "measures".
1. Consider using conformal prediction to calibrate the cutoff. Conformal prediction provides a distribution-free guarantee under exchangeability. This would let you turn your raw probe score into a threshold with a guaranteed bound on the rate of wrongly-kept on-device answers. Source: https://en.wikipedia.org/wiki/Conformal_prediction
2. The best indicators of confidence in ML come from multiple independent methods. What was the result if you combine the token entropy and verbal confidence reporting methods? Does this improve the result?
3. I noticed you didn't mention the assessment method of rerunning the model and judging whether outputs are consistent. How does that method compare in terms of AUROC?
2. We combine both on Cactus; rolling entropy method helps with per-token signal for early exit, while the probe runs on complete output.
3. Users hate this in production, drains battery on edge devices, but ultimately primarily works ok-ish on 7B+ models, we will share the results too.