Cactus Needle 3: 8 MB Tool Calling, With Conditions

Cactus Compute released Needle 3 on 17 September 2026, an automation model that ships as an 8 to 29 MB binary and runs tool calls, structured extraction and text embeddings entirely on-device. The headline that carried it to 225 points on Hacker News was the comparison: 8 to 29 MB matching DeepSeek V4 Flash, a cloud model roughly four orders of magnitude larger. The code is Apache 2.0 on GitHub, installs with pip install cactus-needle, and targets iOS, Android, macOS, Linux on arm64, WebAssembly and RISC-V microcontrollers.

The parity number is real. Cactus prints the conditions attached to it directly on its own pages, and those conditions are the product. The claim is that after fine-tuning on one 200-row benchmark, a subnetwork keeping 31% of the weights passes DeepSeek V4 Flash on that benchmark. Every word in that sentence is load-bearing, and the first outside test posted publicly disagreed with the result by a factor of four.

This piece puts three things Cactus published next to each other that nobody has read together: the parity claim, the benchmark it rests on, and the company's own loss table for the depth it picked.

What Cactus actually shipped

Needle 3 is a Laddered Simple Attention Network. It replaces the feed-forward block with a Monarch Hadamard MLP, uses grouped-query attention with causal convolution taps, and adds an engram n-gram memory read by gather. Of the full 121M parameters, 70.8M sit in the engram tables across 18,432 slots. The embedding matrix is 8,192 by 768 and the attention window is 1,024 tokens. Weights are stored at 2.125 bits each in a format Cactus calls Cactus Quants, shipped as a single .cact file, and the model was trained on 360B tokens.

Speed is not the contested part. On a Raspberry Pi 5 the model decodes at 400 to 4,000 tokens per second and prefills at 1,000 to 10,000, depending on which rung of the ladder you load. Every turn returns one JSON object carrying function_calls, the model's reasoning, and a confidence score from a calibrated head.

The genuinely novel piece is the ladder itself, described in the company's intelligence ladders writeup. Needle 3 is one set of weights in which every depth from 2 to 20 layers is a trained, deployable model. Block selection follows a fixed bisection sequence (0, 19, 9, 14, 4, 6, 11, 16, 2, 7, and so on), and each depth uses the first d entries. Skipped blocks act as identity operations on the residual stream, so a skipped block reads no weights and writes no KV cache. Training samples one path per step: with probability 0.8 it is the full model, otherwise a depth is drawn uniformly, with the full model self-distilling into each subnetwork. The practical consequence Cactus highlights is real and underrated: one fine-tune is a fine-tune of all of them.

The parity claim has three conditions, and Cactus states all three

Here is the claim as printed: fine-tuning on DroidCall lifts every subnetwork by 18 to 36 points, and from 4 layers up the tuned subnetwork passes DeepSeek V4 Flash. The tuned 4-layer model lands at 56.5 exact-match accuracy.

Three conditions are stacked in that sentence. The model is fine-tuned, not used as shipped. The measurement is DroidCall specifically, not the other five benchmarks Cactus reports. And the comparison holds from 4 layers up, which is the shallow end of a 20-layer ladder.

Founder Henry Ndubuaku was straightforward about this in the Show HN thread. On the comparison: "we are merely chasing one DeepSeek v4 Flash capacity with a small model, DeepSeek models are really good." On what the number means: "You can achieve DeepSeek v4 Flash grade performance on a narrow task with just 4L, stress on 'narrow task'." And on deployment: "a real deployment would absolutely need external guardrails, more thoroughly thought out tool sets with better task-specific triggers."

That is a vendor describing its own number accurately. The gap this article is about is not between Cactus and the truth. It is between what Cactus wrote and what the headline travelled as.

What 200 rows and 24 functions actually buy you

DroidCall matters here because it is the narrowest surface in the suite. The DroidCall paper describes a dataset for LLM-powered Android intent invocation built around 24 manually predefined functions covering common Android intents. The public release splits into 10,000 training entries and a test split of 200.

Set that against the other benchmarks on the Needle 3 page. Mobile Actions runs 961 rows. BFCL v4 runs 3,641. On extraction, DSTC8 runs 1,813 turns and the two SNIPS variants run 700 rows each. DroidCall's 200-row test split is the smallest of the six, and its 24-function surface is fixed and known in advance.

DroidCall was also designed for exactly this use. Its stated purpose is fine-tuning small models to hit intent invocation accuracy that rivals much larger ones, and the paper reports Qwen2.5 and Gemma2 fine-tunes reaching or exceeding GPT-4o on it. A small model matching a large one on DroidCall after fine-tuning is the benchmark working as intended. It is evidence about DroidCall, and it is weaker evidence about your tool set.

The first outside test disagreed by a factor of four

In the Show HN thread, a commenter posting as Scaevolus ran both Needle 3 and Google's FunctionGemma against a tool-calling interface over a Runescape database, scoring 230 scenarios on two axes: whether the model picked the right tool shape, and whether the arguments were exactly right.

Two caveats belong on this immediately, and neither rescues the headline. The precisions differ: FunctionGemma ran at BF16, Needle 3 at W4A8, so some of the gap is quantisation rather than architecture. And the task is not DroidCall. A Runescape database interface is not 24 Android intents.

That second caveat is the finding, not a flaw in the test. "Narrow task" performance is not portable across narrow tasks. Scaevolus fine-tuned both models and got 20.4% from one and 85.2% from the other on the same 230 scenarios. FunctionGemma is a useful yardstick here because it is also a tiny tool-calling specialist: 270M parameters at 288 MB, about ten times Needle 3's disk footprint at full depth, reported by Google at roughly 58% out of the box and about 85% on Mobile Actions after task-specific fine-tuning.

Cactus's own loss table prices the depth it headlines

The intelligence ladders post carries a table that no coverage has put next to the parity claim. It reports, for each depth, the share of parameters kept, bits per byte, and the change in loss against the full model. The 100% row is printed at 18L. The size column below is derived from the formula Cactus publishes on the same page: roughly 2.75 MB of embeddings and heads plus about 1.3 MB per block.

The 4-layer rung is where Cactus places its parity headline. It is also the rung its own table marks at +50.3% language-modelling loss against the full model, keeping 31% of the parameters. The parity result survives that because DroidCall is 200 rows over 24 fixed functions and the model was tuned on that exact distribution, not because an 8 MB model is broadly as capable as a cloud model.

One more detail falls out of the size column. The marketed range is 8 to 29 MB, and the formula puts 8 MB at 4 layers and 29 MB at 20. The 2-layer rung, at roughly 5 MB, sits below the advertised range. The published range starts at the parity depth rather than at the bottom of the ladder.

The confidence score is the headline feature, and the first thing testers broke

Needle 3's most interesting product decision is that every response carries a confidence score from a calibrated head, with the engine applying a floor of 0.1. For on-device automation that is the right idea: a tiny model that knows when to defer is far more deployable than a slightly more accurate one that does not.

The documented failures were confident. A tester posting as viccis reported that "25 minute timer" came back as duration_seconds: 25 at full confidence, while "twelve minutes" came back as 120. Both are wrong, and the first is wrong at the top of the scale, which is the one case a confidence gate cannot catch. Other reports in the thread describe the model copying numbers rather than converting them, picking the inverse action ("take paper towels off list" triggering an add), never declining background chatter, and losing multi-turn references, where "take off the last one" deleted an entire list. Commenters also put the practical ceiling at around 10 tool definitions before selection degrades.

Ndubuaku's response was consistent with the rest of his posting: the model is task-specific, trained to be good on a narrow set of tasks, and real deployments need external guardrails. The team updated the demo presets in response to the reports during the thread.

Needle 2 made the same shape of claim six weeks ago

This is the second iteration of the same framing in six weeks. Needle 2 shipped on 9 August 2026 at 45M parameters and 14 MB, needing 28 MB of session RAM, decoding around 500 tokens per second on a Raspberry Pi 5. It scored 63.7 on Mobile Actions against LFM2.5 230M at 69.1 and FunctionGemma 270M at 64.0, meaning it lost on that benchmark as shipped. The fine-tuned configuration was what Cactus said put it ahead of DeepSeek V4 Flash.

Needle 3 repeats the structure with a bigger ladder and a better architecture. The base-model numbers are respectable rather than dominant, and the headline comes from the fine-tuned configuration on a favourable benchmark. That is a legitimate way to sell a model you expect people to fine-tune. It is not a claim about what you get on day one.

How to check this on your own tool set in an afternoon

The reason this matters is that Needle 3 might well be excellent for your narrow task. The only way to find out is to measure it on your task, which is cheap here because the model is Apache 2.0 and runs locally.

1. Install the model with pip install cactus-needle and load the full 20-layer rung first. Establish a ceiling before you start trading depth away.
2. Write 150 to 250 real scenarios from your own product, not from a benchmark. Scaevolus used 230, which is a sensible size: large enough to separate 20% from 85%, small enough to build in an afternoon.
3. Score two axes separately, as that test did. Tool shape and exact arguments fail for different reasons, and a model that picks the right tool with wrong arguments needs validation, not replacement.
4. Test numeric and unit conversion explicitly. Durations, temperatures and quantities are where the reported failures clustered, and they are easy to miss in a scenario set written from happy paths.
5. Check whether confidence separates your successes from your failures. Compute the score distribution for correct and incorrect calls. If they overlap, the confidence gate cannot be your safety net and you need external validation on the arguments.
6. Only then walk down the ladder. Because one fine-tune covers every depth, you can measure 20L, 16L, 12L, 8L and 4L from a single training run and pick the shallowest rung that still clears your bar.
7. Fine-tune before you conclude anything. Cactus reports gains of 18 to 36 points from fine-tuning, and every published parity claim is post-tuning. Judging the base model against the headline compares two different things.

Step 6 is the part that is genuinely new. On every other small model you would repeat the whole exercise per size variant. Here the ladder collapses that into one run, which is a real workflow advantage independent of whether the parity claim travels to your task.

Frequently asked questions

Does Needle 3 really match DeepSeek V4 Flash?

On DroidCall, after fine-tuning, at 4 layers and above, yes, per Cactus's own measurement of 56.5 exact-match accuracy at 4L. As a general statement about capability, no, and Cactus does not make that claim. The founder explicitly stressed "narrow task" when describing the result.

What license is Needle 3 under, and can I ship it commercially?

The code is Apache 2.0 on GitHub, which is permissive and commercial-friendly. That is a meaningfully better position than many small-model releases that carry bespoke licenses with use restrictions.

How big is it really, given the 8 to 29 MB range?

Size scales linearly with depth: about 2.75 MB of embeddings and heads plus roughly 1.3 MB per block, at 2.125 bits per weight. That is about 8 MB at 4 layers and 29 MB at 20. The 2-layer rung comes in around 5 MB, below the advertised floor.

Why did an independent test score it at 20.4% when the vendor reports 56.5?

Different task, different precision. The vendor number is DroidCall exact-match after fine-tuning on DroidCall. The 20.4% is exact-argument accuracy on 230 Runescape database scenarios at W4A8. Both can be accurate simultaneously, which is the whole point: narrow-task performance does not transfer between narrow tasks.

Is the confidence score trustworthy enough to gate actions on?

Not on its own, based on the public reports. The head is calibrated and the engine floors it at 0.1, but at least one documented failure returned a wrong unit conversion at the top of the confidence range. Measure the score distribution across your own correct and incorrect calls before you wire it to anything irreversible.

Should I use Needle 3 or FunctionGemma?

Needle 3 is roughly ten times smaller on disk and offers the depth ladder, which matters if you are targeting microcontrollers or shipping to a wide device range. FunctionGemma at 270M has the stronger public showing on an independent tool set so far. If you have the memory budget, test both, because the one public head-to-head went heavily to FunctionGemma on a task neither vendor chose.

What actually changed between Needle 2 and Needle 3?

Needle 2 was 45M parameters in a 14 MB binary. Needle 3 goes to 121M parameters across a 2 to 20 layer ladder at 8 to 29 MB, adds the Monarch Hadamard MLP and engram memory, and makes every depth independently deployable from one set of weights. The benchmark framing stayed the same across both releases.