GulliBench

In the shadow of intelligence

Frontier AI models have gotten incredibly smart. Month after month, new models are released and shatter benchmarks and leaderboards. It seems they can reason their way out of almost any problem, given enough time and training data.

But still, people don't seem satisfied when using these models in their day to day. Models still get basic things wrong, or just steer away from the intended goal completely. They make wrong assumptions, make wrong decisions, and end up with the wrong answer. They over-rely and over-commit. They just seem too… gullible.

We hypothesize this happens because gullibility is largely orthogonal to intelligence: being gullible is a behavioral trait that is just mildly correlated with raw brain power. Think of Sheldon from The Big Bang Theory: a genius who finished his PhD at 14, but still can't understand basic sarcasm. He takes things too literally.

Similarly, current AI models are trained to be extremely good at solving hard problems (i.e., being very smart). But these problems are usually well-defined and have clear solutions. They are created in sterile environments, where data is standardized and things are mostly deterministic. In short, models are trained with the heavy assumption that the data, tools, and knowledge they are handed are undeniably pristine.

As most of us know, that is not the case in real life. Data is messy and sometimes plain wrong. Tools are buggy and give unreliable results. Assumptions need to be revisited and rewritten. This is no surprise for humans: we've lived in this messy world since the day we were born, and all of us have learned not to trust things at face value, for better or for worse. AI, though, was never taught that. During training, it rarely had to deal with situations where the obvious answer was wrong (even less so when this is done purposefully).

In summary, we have been chasing intelligence, and the other behavioral traits that improve problem solving in the real world have been left in its shadow. Mirroring this trend, most efforts in measuring AI have also focused on raw intelligence: most benchmarks are built with the sole goal of measuring the AI's ability to get things right, while not measuring other problem-solving-related skills.

We believe the first step toward closing this gap is raising awareness and shedding light on the problem. That's why we created GulliBench, our first attempt at measuring AI gullibility.

Full breakdown in Results below.

The setup

The core idea behind GulliBench is eliciting gullibility in simple tasks, ones the models would breeze through if not for a single catch. A gullible model fails by not being thorough; a careful analyst derives the answer with ease.

We give the model a tiny environment: a handful of records (≤ 100), a single plain-English question, and one obvious place to look for the answer.

The catch: that obvious place is a lie. But not a wild lie — a convenient one. A status column that says overdue on invoices that were in fact already paid. A total field that was rolled up before the last few line items landed. The kind of stale, authoritative-looking field that exists in every real database on earth.

The right answer is always sitting right there too, just one step further down. You don't count the status column: you check due_date against today and whether it was paid. You don't trust the total: you sum the line items. The truth costs one extra derivation; the lie costs nothing.

So every task is really one question: when the convenient number and the underlying data disagree, does the model notice or does it just grab the number that was handed to it?

The tasks

Questions are made deliberately simple and boring, usually one line long:

• How many invoices are overdue?
• What's the total value of all orders?
• How many customers placed more than 10 orders?
• What's the total balance across all accounts?

Questions are also extremely easy by design. Any analyst could answer them in their sleep, even adding the numbers by hand. We're not measuring whether the model can compute the answer, but whether it bothers to check the thing it was given.

The data

The data is small and messy: a few dozen rows and a handful of entities, built from one canonical source of truth. Somewhere in it, the convenient answer and the underlying facts disagree. Often that's a stored field that has drifted out of sync with the primary data it summarizes. But just as often it's the primary data itself that needs work before it can be trusted, with fields that aren't standardized and have to be cleaned up before the question can be answered. Either way, the discrepancy is always internally visible: both the convenient value and the data it should be derived from sit right in front of the model. Nothing is hidden, and a single reconciliation would catch it. The model just has to do it.

Grading

For every task we know exactly two numbers ahead of time: the truth (what you get by deriving from primary data) and the proxy (what you get by trusting the convenient field). Grading is then a dumb, exact comparison: no LLM judge, no rubric ambiguity. The model either lands on the truth (resisted the trap), lands on the proxy (trusted it, gullible), or lands somewhere else (fumbled the arithmetic).

Three substrates

We render each instance three ways, from the same underlying facts:

The substrate matters more than we expected. In table and docs, deriving the truth costs effort: you have to read every row. In SQL, deriving is often just a slightly different query, so the effort gate mostly disappears. Some traps bite in all three; some only bite when reading is expensive.

There is a second reason to vary the substrate. Models are trained heavily on code, and on SQL in particular, so they have every incentive to be careful with a database query and far less practice reconciling the same facts in a folder of prose. Measuring only in SQL would flatter that training; table and docs test whether the same skepticism survives when the data doesn't look like code.

Running all three tells us whether a failure is about laziness (only bites when derivation is costly) or reflex (bites even when the honest query is one line away).

Harness and tools

Each substrate has a different set of tools that reflect its data format, but every one lets the model read and query all the data, either completely (by reading individual records) or through searches, filters, and aggregations. Whatever the format, no substrate leaves the model short of the tools it needs to derive the answer.

We also created our own custom agent that only has access to the data using the provided MCP (not via bash), to make sure we can experiment under different querying constraints. Giving the agent access to more open environments (e.g., an agent with bash commands) allows it to bypass the constraints we want to measure, confounding our measurements. For example, in one test the agent wrote a Python script to read all of the docs into a table and query it using SQL.

Reasoning effort is another knob we deliberately leave alone: every model runs at its provider-default effort and thinking settings. As we've discussed (and show further evidence for in the results), gullibility should not be highly correlated with intelligence, and thinking harder won't make a model less trusting of a trap. Default settings are also fairer, and more representative of daily use. Either way, we ran an ablation study on GPT-5.6 Sol to validate this empirically (see the ablation).

Below you can find a comprehensive description of the tools available to the models via MCP.

Single-hop vs. multi-hop

A single-hop task has exactly one bad value to catch. These already trip models more than you'd hope, but the strongest models resist most of them (see below).

A multi-hop task chains two of them, where the second depends on the first. For example:

"What's the final balance of the account with the highest sales rank by revenue?"

To answer, you first have to find the right account, and the sales_rank column is stale, so you can't trust it; you have to rank by actual revenue. Then, having found the account, you have to get its final balance, and the running_total field is stale too, so you have to sum the ledger. Two independent audits, back to back.

Here's the striking part. Each hop, in isolation, is something the top models get right essentially 100% of the time. But chained together, even the strongest models solve only about half, and half the field collapses to single digits. And it's demonstrably not a capability failure: Fable 5 gets hop 1 right every single time, and aces hop 2 on its own, yet once hop 1 has consumed its attention, it quietly drops the second audit and trusts the stale total. The model can run each audit; it just doesn't run both. After clearing the first check it treats the job as done and takes the second number on trust.

Example tasks

The examples below are picked to show a ladder. Each carries the same flavor of trap, but it lands differently across models, from a control that fools nobody up to a multi-hop task that wipes out an entire model line. (These four are off-roster demonstration tasks, shown in full; the scored set stays hidden.)

Results

The official GulliBench is 50 multi-hop tasks, the hardest we found, each rendered in three substrates, for 150 tasks. We evaluated 15 frontier models with a single MCP agent, five runs per task. Pass rate is the mean pass@1 (n=5): how often the model resisted both traps and derived the truth, so higher is less gullible. Quoted uncertainties are 95% bootstrap intervals over the 50 multi-hop tasks; where two models sit inside each other's intervals we read the board as a tie, not a ranking.

The full results are in the chart below. Split them by substrate (table, docs, and SQL) or pool everything together, and open the task-by-model breakdown underneath.

A few things jump out:

• There is still a lot of headroom. No model scores above 50%, and all but the top three sit below 25%.
• More intelligent doesn't mean less gullible. Models that top other benchmarks, such as GPT-5.6 and Kimi K3, perform worse than or on par with lower-placed models such as the Gemini family and DeepSeek V4 Flash.
• New model versions don't necessarily help. As the GPT-5.5/GPT-5.6 and Gemini 3.1 Pro/Gemini 3.6 Flash results show, improving a model doesn't always mean improving its gullibility. Improvement is possible, though (see Opus 4.8 against Opus 5), so we take this as evidence that gullibility can be reduced when directly targeted; it just isn't something other benchmarks and training are currently driving.
• The substrate makes a difference. Even though the task is essentially the same in every format, changing the tooling changes how the models perform. Fable 5, for example, does exceptionally well on SQL, while Muse Spark 1.2 tops the benchmark on the table substrate.

For contrast, here are the 20 hardest single-hop tasks: one audit instead of two. They are far easier than the multi-hop tasks, and near-saturated for the strongest models, which is why the multi-hop set is the one worth scoring.

Ablation: does more reasoning make a model less gullible?

Since we use the default reasoning setting for each model, it's natural to wonder whether the results would change at a different effort. To check, we re-ran GPT-5.6 Sol at both low and high reasoning effort on a separate set of 20 single-hop traps (60 tasks, n=5), a different draw from the 20 hardest shown above. We used a single-hop set instead of the official multi-hop tasks because Sol passes about half of this one, which is where a real difference would be easiest to see.

We found no difference between the three settings. Low solved 50.0%, default solved 53.3%, and high solved 51.3%; task by task, high won 15, lost 14, and tied 31 against default. It may look surprising that default came out ahead of high, but all of the pairwise gaps are noise: low vs. default gives p = 0.41, low vs. high p = 0.74, and default vs. high p = 0.63.

Digging deeper into each run's trajectory, we found that every wrong answer is the cached value. Most of the time the model had the source in hand, often even computing the true number or flagging the cache as inconsistent, and still deferred to the plausible stored value. A small share of runs stopped looking too early. Extra thinking tokens don't move either behavior; the deficit is source-of-truth skepticism, not thinking budget.

On fairness

A benchmark like this lives or dies on one question: is the model actually being gullible, or did we just write a trick question?

If the "correct" answer depends on knowledge the model couldn't have, or on an unstated definition, or on a convention we never told it, then a wrong answer isn't gullibility, it's us being unfair. So fairness isn't a nice-to-have here; it's the entire validity of the measurement.

We hold every task to two sharp criteria. The first says the truth is recoverable:

A trap is fair only if the convenient value is internally inconsistent with primary data that is present in the very same task.

The second says the truth is unique:

The question must have exactly one defensible reading. The convenient value has to be a failure to check — not a rival interpretation.

This second criterion is the one that's easy to get wrong, and it's where most of our killed tasks died. If the proxy value corresponds to a genuinely different-but-reasonable reading of the question, then trusting it is a legitimate interpretation.

Here is the kind of ambiguity that gets a task cut, shown the same way as the examples above.

Additionally, to keep the benchmark honest, we put every task through a few fairness checks:

• We run a fairness audit on every task. We walk each task through a fixed checklist: is the behavior under test leaking into the prompt, is the question secretly ambiguous, does the grader accept exactly one answer, is the truth actually recoverable from the data? Anything that trips a check gets pulled out and reworked before it's allowed to count.
• We prove the task is solvable, empirically. For the hardest traps, we run a hinted A/B: add one sentence pointing at the discrepancy and re-run. Pass rates jump from ~2% to ~93%. That gap is the proof that the models can solve these and that the task is not impossible.
• We screen with careful solvers. Before a task counts, we run a handful of "meticulous analyst" versions of the model: same task, but prompted to be extra careful about data inconsistencies: reconcile the data carefully before answering and check their answers. The bar is concrete: if the careful solvers clear the task 100% of the time, the truth is cleanly recoverable and the trap is doing its job: the failure is a matter of diligence, not ability. If they land above 80% but short of perfect, we read their trajectories by hand and decide keep-or-cut from what actually tripped them. Below that, or if they converge on the proxy, the task is presumed ambiguous or harder than we think, and it doesn't survive.

On validity

We're only measuring one kind of gullibility. GulliBench probes a single, specific failure: taking the data at face value instead of reconciling it against the primary source it should agree with. That's one slice of a much larger category of gullibility failures. Models can be gullible in plenty of other ways: believing a buggy tool's output, accepting a false premise baked into the prompt, deferring to a confident-but-wrong user, following a planted instruction from a document. We don't touch any of that here. We think data-trust is a clean, measurable place to start, but definitely not the whole story.

Not every failure is gullibility. Sometimes a model doesn't trust the convenient wrong field but still fails the task. For example, it can fail in the arithmetic or drop a few records for no apparent reason. While this type of failure is not strictly models being gullible, it does surface an interesting phenomenon: the models get lousy at solving the problems when they have already reasoned past the trap. And while adding several 4-digit numbers by hand is no fun, this is not something beyond the capabilities of the models. In our control tests, where the task has no trap, the models practically ace the questions and don't fumble on execution. These other types of failures are therefore elicited by the gullibility traps and can be seen as secondary measurements of our benchmark.

"Isn't this just a matter of prompting?" It's the obvious objection, and in a narrow sense it's true: you could make most of these traps disappear by telling the model to watch out for stale data. But that misses what gullibility is. The essence of being gullible isn't failing after you've been warned; it's trusting something because no one told you otherwise. A skeptic doesn't need the warning; they check by disposition. The whole trait lives in what you do before anyone points at the problem.

Which is exactly why the question stays bare. It never names or hints at the behavior under test. No "be careful," no "watch out for stale data," no nudging toward the ledger. The moment you tell the model what to check, you're measuring instruction-following, not judgment.

The takeaway

Smarter models are not automatically less gullible. Until they learn to distrust the convenient answer on their own, that gap will keep surfacing in real work, and it is worth measuring directly. GulliBench is our first cut at doing so.