Claude Fable 5 Refuses to Look Up a Gene. It's the Request, Not Your Tools.

// finding 01

Does Claude Fable 5 really refuse to look up a gene?

Yes. Ask Fable 5 to look up BRCA1 — a human gene so well-studied it's in every intro genetics textbook, the one behind hereditary breast-cancer screening — and it declines. Not "I couldn't find it." It refuses to proceed at all. Ask about BRAF V600E — a specific, extensively published cancer mutation — same result.

A quick definition, because the whole point is how ordinary this is: a gene/variant lookup is just asking a tool to return reference information about a named gene or a named mutation. It is the most benign biomedical request there is — the kind of thing a med student types into a database a hundred times a semester.

We sent a genomics-and-oncology tool server fifteen of these lookups: gene names, a known variant, a treatment-literature query. Fable 5 refused all fifteen. Then we ran the exact same requests through the two Claude models a version back — Claude Sonnet 4.6 and Claude Opus 4.8. Zero refusals. Every single one answered normally.

So this isn't "AI models are cautious about biomedical stuff." Sonnet and Opus — same lab, same week — handle it fine. This is specific to Fable 5.

And here's the part that should bother you if you were counting on the refusal to mean something. On a plain database server — Postgres, no biomedical anything — Fable will happily reach for the tool whose entire job is to run DROP TABLE, ALTER, and GRANT. Genuinely destructive, irreversible operations. No hesitation. But ask it what BRCA1 does — a fact in every genetics textbook — and it won't.

Whatever the refusal is tracking, it isn't harm.

// finding 02

Is it your tools, or is it the request?

Here's where we almost published something wrong.

The obvious story writes itself: biomedical tools spook the new model. Load up a genomics server, the model reads oncology-flavored tool descriptions, gets nervous, refuses. Clean narrative. We nearly shipped it.

Then we ran the control, and the data killed it.

We set up a 2×2. Two things vary independently: the request (a genetic lookup versus a totally neutral "draft an email"), and the tools in the room (the biomedical toolkit versus a neutral database server with no biomedical content anywhere). Four cells. If the tools cause the refusal, the biomedical-tools column lights up. If the request causes it, the genetic-request row lights up.

Read across the rows. A genetic request refuses even when the only tools present are a Postgres console — no biomedical surface in sight (10/10). And the full biomedical toolkit, handed a benign request, refuses nothing (0/15).

The request drives it. The tools don't. The row lights up, not the column.

So the claim we can stand behind is narrow and specific: Claude Fable 5 refuses benign genetic lookups — naming a gene or a known variant — that every prior Claude answers. The claim we can't make — the one we almost made — is "Fable refuses based on the tools in the room." The control falsifies it. The tool surface, on its own, triggers nothing. Sonnet 4.6 and Opus 4.8, for the record, sit at zero across all four cells.

// finding 03

Does it happen on more than one server?

A single server proves nothing — it could be one weird tool description. So we checked a second one, built by different people, wrapping a different corner of biomedicine: literature search instead of a genomics database.

Same pattern. The gene request (BRCA1) refused five out of five. The variant request (BRAF V600E) refused five out of five. Two independent biomedical servers, two different authors, the same Fable-only refusals. That's not a one-server artifact.

One nuance worth keeping honest. A third kind of request — "find the literature on EGFR drug treatments" — refused on the heavier genomics server but sailed through on the lighter literature one. So the tool surface isn't nothing: for borderline requests, a heavier biomedical surface can nudge the model toward refusing. It's a secondary amplifier. The request is the cause; the surface can tip a coin that's already wobbling.

And this isn't only a single-turn-probe curiosity. In our live, multi-turn agent runs — where the model is actually searching, reading results, and deciding what to do next — Fable refused mid-task five times, every one of them right after tool results came back carrying biomedical abstracts. The effect shows up in the wild, not just on the test bench.

Two servers is still a small sample. We're reporting a direction and a mechanism, not a precise universal rate — you'd want three or four servers before publishing a number. But the direction is unambiguous.

// finding 04

Why does this matter if agents call your biomedical tool?

Let me be careful about what this is and isn't.

This is a model behavior, not a defect in anyone's server. The server did nothing wrong. The refusal happens before the call ever reaches it — the model declines, and the request never lands. There's nothing to fix on the publisher side, because nothing on the publisher side is broken.

But — and this is the whole point — it still costs the publisher.

If you publish a genomics, oncology, or biomedical tool, some fraction of your agent traffic is running Claude Fable 5. As Fable adoption climbs — it's the flagship, it will — that fraction grows. And every one of those users, asking the most ordinary gene-lookup question, hits a wall your other-model users never see. Your Sonnet users are fine. Your Opus users are fine. Your Fable users get refused, and as far as they can tell, your tool didn't work.

Here's the kicker: you can't see it. The call never arrives, so it never hits your logs. Your error rate looks perfect. Your latency looks perfect. No 4xx, no timeout, no trace. The agents are quietly getting refused at the model layer — one abstraction above anything your dashboard can reach.

The model your users run is now a variable in whether your tool works. And it's a variable you don't control and can't observe from the inside.

// finding 05

Does Fable 5 also skip tools other Claudes call?

The refusal is the flashy finding. This one is quieter, and for most publishers it's more expensive.

Quick definition: invocation is whether the agent even attempts a tool call at all, versus answering from its own training data. If the agent never calls your tool, nothing else about your tool matters — description, reliability, response quality, all moot.

Across the same sweep, Fable 5 attempts a tool call less often than Sonnet 4.6 does:

Sonnet 4.6 calls a tool every time. The newer flagship, Fable 5, skips 10% of the time — answering from memory instead of reaching for the tool. And it's concentrated: on straightforward factual-lookup prompts, Fable answered from its own memory on 45% of them (15 of 33). Sonnet called a tool on every last one. The same gap, smaller, shows up on computation and local-data prompts.

This isn't new in kind — we've watched models skip tools before, and different models skip at different rates. What's notable is the direction: the shiny new model is less tool-eager than the one it's replacing. If you upgraded your agent stack to the latest Claude assuming "newer means better at using my tools," the invocation data says: not automatically. Sometimes newer means the model is more confident answering from memory, and your tool sits untouched.

(A cross-model note, not an absolute one: these invocation numbers compare models against each other on an identical prompt set. They are not a quality grade for any particular server — see the methodology.)

// finding 06

What should you do about model-version risk?

One idea ties both findings together: the model version is part of your agent readiness, and it moves without you.

Your tool didn't change. Your descriptions didn't change. Your uptime is flawless. And yet the agent's behavior against your surface just shifted — because the model on the other end got upgraded, and the new one refuses a request the old one answered, or skips a call the old one made. You shipped nothing, and your results changed.

You can't fix what you can't see, and none of this is visible from your side of the wire. The refused calls never arrive. The skipped calls never arrive. Your logs show a quiet, healthy API and a slow leak of agent traffic you can't account for.

So the move is boring, and it's the same one it always is: test across models, live, on a schedule — not once. Not "does my tool work," but "does my tool work for an agent running this model, this month." Every major release — every Fable, every GPT, every Gemini — is a re-test, because each one can quietly change how agents behave against a surface you never touched.

The good news: this is measurable. We caught Fable's gene refusal because we ran the new model against real tools the week it shipped and looked at what actually happened — not at what the release notes promised. That's the whole job. The model is a moving part, so watch it move.