I Asked 2 LLMs to Count the Cherries - Only One Did a Good Job!

I'd just finished off a bowl of cherries and what was left behind looked like a small archaeological site. Pits, stems, and the creeping suspicion that I'd eaten more than I'd meant to.

So I photographed the evidence and asked two AI models to count it for me. Then I counted the pits myself, by hand, in the bowl. Twenty-six.

Hold on to that number because having a ‘right’ answer is what's going to make verification possible later.

The Experiment

I took one photo - straight down into a white bowl while I was sitting on my couch. iPhone 17, 24 megapixels.

The pits were mostly laid flat but touching each other, and the stems were still in there, tangled across the top of the pile like someone had dropped a handful of green string over it. It is, I realised later, a genuinely challenging test (for an AI with no fingers).

I uploaded it to the iPhone apps and used Gemini 3.1 Pro and Claude Opus 5, with the below simplistic and natural sounding (by design) prompt:

“Count the cherries I ate”

Five runs each. Same photo, same prompt, fresh chat every time.

The Results

Stats:

Actual Count = 26

Gemini's Mean = 25.2

Claude's Mean = 30.2

Gemini's mean error : −0.8 and Claude's was +4.2

Overlap: The two ranges don't overlap anywhere. 

Observations

The Analysis

When you look deeper into the reasons for this behaviour, there are two key aspects that come into play and therefore I will split the analysis into 2 sections to properly cover each.

Strategic Analysis

Before we get to the mechanics, there's a commercial reason this result isn't a fluke. Both companies have invested heavily in image processing, but each has bet on a different set of applications.

Google's documentation says its models are multimodal from the ground up, and that they get additional training for object detection and segmentation specifically, which means drawing a box and a contour around each individual thing in a scene. So this isn't a vague ‘our model understands images’ claim. It's a named capability, trained for separately. And it's not for nothing!

Google has a whole robotics programme riding on it. Gemini is built by Google DeepMind, and DeepMind also builds Gemini Robotics, which is a model family constructed on top of Gemini itself and extended into the physical world with better spatial understanding. Their published material lists pointing, precision object detection and, explicitly, counting among the capabilities they benchmark and improve with every generation. Which makes complete sense the moment you picture a robot arm. A machine that can't work out where one object ends and the next one begins is not going to be able to pick up either of them. So object separation isn't a nice-to-have for Google, it's load-bearing for an entire product line, and my bowl of pits is just a small, low-stakes version of that same problem.

Now look at how Anthropic justifies its own high-resolution image support. The documentation names the use cases directly: computer use, screenshot understanding, and dense documents. Screens and paper, in other words. That's vision aimed at a laptop. Anthropic also openly states that its counting is approximate, and says the same thing about pinpointing where objects sit in an image. 

So this is actually a story of two companies making different bets, and one specific task turning out to suit one model's strengths more than the other's. 

Note that the robotics models are a separate family from the Gemini 3.1 Pro I actually tested, but they're built on the same foundation, which tells you something about where the focus is.

Technical Analysis

TL;DR: counting isn't really a seeing problem, it's a separating problem, and Gemini has that step built in while Claude had to assemble one on the fly.

Before you can count anything at all, you have to commit to a boundary and decide that this pit is a different object from that one. If you get those boundaries right, the counting itself is trivial arithmetic. If you get them wrong, nothing you do afterwards will save you. That one step, which people call individuation, is basically the entire task.

It's also the step Google trains for. Its API documentation has a whole mode for this: ask the model to detect objects and it returns structured data rather than prose, one entry per thing, each with coordinates and a label, and from 2.5 onwards a contour mask tracing the object's actual outline. I should be clear that I never used that mode and never saw any of it. I typed a sentence into a phone app and got a sentence back. But the existence of that output format tells you something about what the model was trained to do, because a model trained to produce one entry per object has been trained, thousands and thousands of times over, to decide exactly where one thing stops and the next one starts, including when they're touching or overlapping or sitting half-hidden behind something else.

Once you can do that, counting almost comes for free: draw the outlines, count the entries. It wasn't doing less work than Claude was. It was doing that work somewhere we cannot see, because the work is baked into the model rather than assembled at the moment I asked.

Claude doesn't have that step trained in, so it built itself a substitute out of code, isolating everything pit-coloured and then running an algorithm designed to slice fused blobs apart. Which is a perfectly legitimate approach, and in principle very similar. But because it came up with the working on the fly the execution was a lot less rigorous than what Gemini probably did behind the scenes before baking the capability into the model.

In our case, the stems do some real work in exposing the boundary problem. Claude counted the stems too, kinda like a second opinion, and reported 16, then 16, then 22, then 18–19. I never counted the stems myself, since they're tangled and much harder to count than the pits, and I'm not going to pretend otherwise. But I don't actually need the true number, because the wobble is the finding. That's four different answers spanning six, from a photograph that never changed. Its pit counts stayed within three of each other; its stem counts didn't. The more tangled the objects, the harder the boundaries get and the less stable the count becomes.

Sources

Everything I've claimed about how these models work comes from the companies' own published material rather than my own inference, so here's where to check it. All of it is first-party and was accessed in August 2026. Two caveats worth stating plainly, though. The robotics models are a different family from the Gemini 3.1 Pro I actually tested, so they tell you where Google is investing rather than what was running on my photo. And everything technical below documents API behaviour, whereas I ran this in the consumer apps. I did go looking for the consumer equivalents and they do exist, but they only cover what you're allowed to upload rather than what happens to it afterwards, so my image sat comfortably inside both sets of limits and beyond that I can't tell you what either app did with it.

Which is its own small finding, really. The developer documentation tells you how the machine sees; the consumer documentation tells you how big your file can be. If you're a normal person using the app on your phone, the information you'd need to sanity-check a wrong answer isn't written down for you anywhere.

The Human Moat

From everything we analysed above we know that Gemini completed a counting task better than Claude and that it’s not by fluke but instead that there are both technical and strategic reasons for it. But that’s not the most important learning. The more important learning here is that AI models have markedly different capabilities and perform very differently depending on the task. And to arrive at the best outcome someone has to choose who to employ for the task.

So the lasting skill worth developing is informed delegation. And by that I mean knowing which model gets which job, and being the person who makes that call.

And this experiment showed me why that job is harder than it looks. I'd have been quite happy with ‘the confident-sounding one was bluffing’ because that's a comfortable lesson we've learnt before. But that isn't what happened. Claude ran a real pipeline with real libraries, generated its own visualisations, cross-checked itself against a second method and gave me honest-looking error bars. Every signal we normally use to judge whether someone knows what they're doing was firing, and not one of them was faked. It still came out four pits off with the right answer sitting outside its own stated range, in all five runs.

So baseline knowledge and methods are cheap now. A machine will deploy real effort on your behalf, and if that method carries a bias nobody has checked, the effort makes the answer worse and more convincing at the same time.

Your human moat doesn't stop at spotting the bluff. It's knowing that trying and nailing something are two different things, and building the skills needed to tell them apart.

Practically speaking:

Delegate freely when:

Exercise caution and dig deeper on whom to delegate to when:

The cherries, for the record, were excellent. Worth all twenty-six of them.

The Transcript

Gemini 3.1 Pro

Run 1:

Cherry Count — Based on the contents of the bowl in image.png, we can determine the number by counting the leftover pits. I can spot approximately 24 cherry pits clustered in the bowl. Assuming each pit accounts for one cherry, it looks like you ate 24 cherries.

Run 2:

Based on the provided file "image.png", I count 25 cherry pits in the bowl.

Run 3:

Based on the pits visible in image.png, it looks like you ate 27 cherries!

Run 4:

Based on the cherry pits visible in image.png, it looks like you ate 24 cherries. I counted them by tracking each distinct pit (seed) left in the bowl.

Run 5 (its only exact hit):

Cherry Count — Based on a careful count of the pits visible in "image.png", it appears you ate 26 cherries. (Note: This count relies on each individual pit representing one eaten cherry, as there are roughly an equal number of stems mixed in.)

Claude Opus 5

Run 1:

About 32 cherries.

I counted the pits rather than the stems, since every cherry leaves exactly one pit but stems sometimes stay on the branch or come off in pairs. I ran the photo through a color segmentation (pits are reddish-brown against a white bowl) and split the touching ones with a watershed pass — it consistently landed on 30–32 distinct pits across different sensitivity settings, which matches my eyeball count.

Two caveats worth flagging: the pile is stacked two or three deep in the middle, so a pit fully hidden underneath wouldn't show up, and a couple of the very dark, glossy ones at the right edge blend into the shadows. So 32 is a solid floor — the true number could be a pit or two higher.

Counting a pile like this is a bit like counting pebbles in a stream bed from the bank: the ones on top are obvious, but the overlap means you're always slightly undercounting what's beneath.

Were you tracking this for a reason — a serving-size experiment, or just curiosity about how many you actually put away?

Run 2:

About 29 cherries — I'd put the honest range at 27–31.

I zoomed into the pile and counted grid-square by grid-square. The tricky part is that the pits aren't laid out in a single layer; several are half-tucked under neighbors or shadowed by stems, so a few are showing only a sliver of shoulder. It's a bit like counting stones in a shallow creek bed — the ones on top are easy, the ones wedged underneath you're inferring from an edge.

Two things worth noting:

If you want a firmer number, spreading them into a single layer with a bit of space between would get us to an exact count. Was this one sitting?

Run 3:

About 30 cherries — my count of the pits lands at 30, with real uncertainty of roughly ±3.

Here's why it's not exact: the pits are piled two deep in places and half-buried under stems, so counting them from a single overhead photo is like counting coins tossed in a heap — the ones underneath never show their faces. I zoomed into quadrants and worked through them systematically, and the pits I can clearly resolve number about 30.

The stems are a useful cross-check but a worse one: I can trace roughly 16 free stem tips, well short of 30. Some are tangled under the pile, and cherries often come off the branch stemless or in pairs, so stems almost always undercount.

If you want a precise number, spreading the pits into a single layer with a bit of space between them would make a re-count trivial. Was this one sitting, or spread over a while?

Run 4:

About 30 cherries — I count 30 pits, with a realistic range of 28–32.

The uncertainty comes from the pile itself: the pits are heaped rather than spread out, so several are partly tucked under their neighbors. It's a bit like counting coins poured into a dish instead of stacked in a row — the ones on the bottom layer only show an edge, and two overlapping pits can read as one.

As a cross-check I counted stems, since each cherry brings exactly one. I can make out about 22 free stem tips, but a good handful disappear under the pit cluster, which is consistent with a total in the high twenties to low thirties.

If you want an exact number, spreading them into a single layer on the plate and reshooting would get it to a hard count. Out of curiosity — were these from a bag or picked fresh? The stems still look green and springy, which usually means they were picked recently.

Run 5:

About 30 cherries — I count roughly 28–32 pits in the bowl, with 30 as my best single number.

Two things make exact counting hard: the pits are piled and overlapping, so a few in the middle are partly buried, and the stems don't help as a cross-check — I can only make out around 18–19 of them. That gap is normal, since stems often stay on the bunch or break off before the cherry gets eaten. Counting pits is like tallying seats after a concert instead of tickets: one pit per cherry, no exceptions, whereas stems go missing.

If you want a precise number, spreading the pits into a single layer and re-shooting would get it exact — the pile is doing most of the damage to the count.

Claude's executed steps, run 1 (from the app's summary panel)

Check image dimensions · Crop and enlarge pit region · Split into quadrants · Top-left quadrant · Add grid overlay · Gridded pit region · Create horizontal bands · Band 0 · Band 1 · Enhanced sub-regions · Left upper region · Right upper region · Bottom region · Segment pit-colored pixels · Check for scipy/skimage · Visualize mask · Mask overlay · Connected component analysis · Watershed split of pit mask · Visualize watershed centers · Watershed centers overlay

Photo

Specifications: iPhone 17, 4284 × 5712, 24 MP.