# Stop Claude making things up

A hallucination is a confident answer with no support behind it. You cut hallucinations by changing what you ask for: give Claude permission to say "I don't know", make it quote the source for every claim, restrict it to text you provide, and verify the output instead of trusting it. None of this needs special tooling. It is mostly prompting, plus the search tools already built into the Claude Code CLI.

The reason a model invents an answer is that the default request rewards confidence. You ask "what does the auth config do?" and the model produces fluent prose whether or not it has the facts. The fix is to change the reward: make the honest answer ("I cannot find that") the easy path, and make every factual claim carry a receipt.

## Why does Claude make things up?

A language model predicts plausible text. Plausible and true are not the same thing. When the relevant fact is not in the context window, the model still produces the most likely continuation, and a fabricated function name or a made-up date is often more likely than the words "I don't know".

So the failure has two ingredients: the fact is missing, and the prompt does not reward admitting that. You address both. [Put the real material in the context](/guides/feed-claude-the-right-context), and write the prompt so honesty wins.

The four techniques below each close one of these gaps. Use them together.

## Technique 1: allow "I don't know"

The single highest-impact change is to tell Claude, in the prompt, that admitting uncertainty is an acceptable answer. By default a model treats "produce an answer" as the goal. When you state that "I don't have enough information" is a valid response, the fabricated answer stops being the path of least resistance.

This is the first strategy Anthropic lists in its own guidance on reducing hallucinations. It is one sentence and it works on its own.

```text
Review this report and assess the integration risks for the merger.

If the report does not contain enough information to assess a risk, say "I don't have enough information to assess this" rather than guessing.
```

Put the escape clause near the instruction, not buried at the end. Be explicit about the exact phrase you want when there is no answer, so a confident-sounding non-answer is easy to spot in the output.

This pairs with [effort levels](/guides/claude-code-effort-levels): a quick reply is more likely to paper over a gap, while a higher-effort pass has room to notice the gap and report it. When accuracy matters more than speed, ask for the careful pass and grant the permission to decline.

## Technique 2: ask for sources

A claim with a citation is checkable. A claim without one is a guess you have to trust. Make every factual statement carry the quote or file reference it came from, and you turn an opaque answer into one you can audit in seconds.

For a document or codebase, ask Claude to extract the exact supporting text before it draws a conclusion. This is "use direct quotes for factual grounding" in Anthropic's terms: for long inputs, having the model pull word-for-word quotes first anchors the answer in real text instead of a paraphrase that has drifted.

```text
Read docs/checkout-flow.md and answer: when does the cart lock for payment?

For each claim in your answer, quote the exact line from the file that supports it. If you cannot find a supporting line, write "no source found" and do not make the claim.
```

In the Claude Code CLI this is natural, because Claude reads real files with its `Read` and `Grep` tools and can quote them line by line. The quote earns its place: compare "the cart locks after the address step" and "the cart locks after the address step (`checkout-flow.md` line 84: 'lock cart once shipping is confirmed')". The second one you can verify without re-reading the whole file.Asking for a quote does not guarantee the quote is real. A model can invent a plausible line and a plausible file path together, so a confident citation that you never open is a fancier hallucination. Open at least one cited line yourself, or have Claude `Grep` for the exact quoted string and show the match, before you trust any of them.

### How do I get sources from the web?

When the question is about [current facts rather than your own files](/guides/give-claude-web-search), Claude Code has two built-in tools. WebSearch runs a query and returns result titles and URLs. WebFetch retrieves a specific page so Claude can read and quote it.

These tools require permission. You can grant them up front in `.claude/settings.json` so Claude does not have to ask each turn:

```json
{
  "permissions": {
    "allow": ["WebSearch", "WebFetch(domain:docs.example.com)"]
  }
}
```

`WebSearch` takes no specifier, so you allow or deny the whole tool. `WebFetch` scopes by domain, so the rule above lets Claude fetch pages on `docs.example.com` without a prompt while still asking before it touches anywhere else. One detail worth knowing: WebFetch runs your extraction prompt against the page with a small model and returns that answer, not the raw HTML, so a "not mentioned" result can mean the prompt did not ask the right question. Ask again with a sharper prompt, or have Claude `curl` the page when you need the unprocessed text.

```text
Search the web for the current rate limit on the Acme payments API, then fetch the official docs page and quote the exact limit. Give me the source URL. If the docs do not state a number, say so.
```

## Technique 3: ground it in provided text

The strongest defence is to remove the model's freedom to draw on anything outside the material you give it. Anthropic calls this "external knowledge restriction": instruct Claude to use only the provided documents and not its general knowledge. When the answer must come from the text in front of it, an unsupported claim has nowhere to come from.

This is the right move whenever the truth lives in your data: a policy document, a config file, an API contract, a support transcript. The model's training data is stale and generic. Your file is current and specific. Tell Claude which one to trust.

```text
Using only the contents of src/auth/session.ts, answer how long a session token stays valid.

Do not use your general knowledge of auth libraries. If the file does not define the duration, say "not defined in this file" and stop.
```

Grounding and citations reinforce each other. Restricting Claude to the provided text removes the source of invention; asking it to quote that text proves it stayed inside the boundary. Used together they are close to airtight for questions about your own material.

| Question is about | Ground it in | Tool that supplies it |
|---|---|---|
| Your code | The actual files | `Read`, `Grep` |
| Your docs or policy | The document text | `Read` |
| A live external fact | The fetched page | `WebSearch`, `WebFetch` |
| A connected system | The system's own data | An MCP server |

For questions that need data from a live system rather than a file, connect it through an MCP server so Claude queries the source directly instead of recalling it. See [MCP fundamentals](/guides/mcp-fundamentals) for how that connection works, and [useful MCP servers](/guides/useful-mcp-servers) for ready-made ones.

## Technique 4: verify before you trust

Even with the first three techniques in place, treat the output as a draft until it is checked. Verification is a second pass that hunts for the unsupported claim the first pass slipped through.

### How do I make Claude check its own answer?

After Claude produces an answer, ask it to audit its own claims against the source and retract any it cannot back up. Anthropic describes this directly: have the model find a supporting quote for each claim after it answers, and if it cannot, it removes the claim.

```text
Review your previous answer. For each claim, find a direct quote from the provided files that supports it. If a claim has no supporting quote, delete it and mark the spot with [removed: unsupported].
```

### Run it twice and compare

Ask the same question in two fresh sessions and compare. Anthropic calls this best-of-N: where the two answers agree, the facts are stable; where they diverge, one of them is invented and the disagreement flags it for you.Agreement proves the answer is stable, not that it is true. Two runs can land on the same plausible-but-wrong fact when the model has a consistent bias toward it, so use this to catch divergence, not as a green light. For facts that matter, still check one against the source. Use `/clear` between runs so the second answer is not anchored to the first.

```bash
# First pass, then clear, then ask again in a clean window
/clear
```

### Verify with code, not prose

The most reliable check is one that does not rely on the model at all. For anything you can test, have Claude run the test and report the real result rather than predict it.

```text
You said the build passes after this change. Run the test suite with the project's test command and paste the actual output. Do not summarise, show the real result.
```

A passing test is a fact. A model's assurance that a test would pass is a prediction. In the Claude Code CLI you can demand the fact, because Claude runs the command with its `Bash` tool and the output is real.

Pick the verification that fits the claim. A factual claim about your docs wants the self-check. A subjective or open-ended answer wants the run-twice comparison. A claim about behaviour wants the real test output.

## Put it in CLAUDE.md

The four techniques are habits, and habits stick when they are written down. Add a short section to your project's `CLAUDE.md` so every session starts with the rules already loaded, and you do not have to repeat them by hand.

```markdown
## Accuracy rules

- If you cannot find a fact in the provided files, say so. Never guess.
- Quote the exact line or source for every factual claim about this codebase.
- Answer questions about our code only from the files, not from general knowledge.
- Before claiming a change works, run the test and show the real output.
```

This is durable context that applies on every turn. For why that placement matters and how to keep it lean, see [context engineering](/guides/context-engineering). A rule in `CLAUDE.md` costs tokens on every request, so keep this block to a few precise lines rather than a wall of caveats.

## A worked example

You want to know whether a rate-limit change shipped. Here is the careful version, using all four techniques in one prompt.

```text
Question: did we lower the API rate limit in the last release?

Rules:
- Answer only from the files in this repo, not general knowledge.
- Quote the exact line that sets the limit, with the file path.
- If the limit is set in more than one place, list every match.
- If you cannot find where the limit is defined, say "not found" and stop.
- Then run git log on that file and quote the commit that last changed the value.
```

This grounds the answer in the repo, demands a quoted source, allows an honest "not found", and verifies with a real `git log` command rather than the model's memory of what shipped. Every part of the answer is now checkable in seconds.

## What if hallucinations still slip through?

These techniques reduce hallucinations sharply. They do not delete them. Watch for the cases where the model can still drift:

- **The source itself is wrong.** Grounding makes the answer match the document. If the document is out of date, the answer is faithfully wrong. Verify the source, not just the match.
- **A "not mentioned" that means "not asked".** A WebFetch result that says a page lacks something can mean the extraction prompt missed it. Re-fetch with a sharper question before you conclude the fact is absent.
- **Confident hedging.** "Based on the file, the timeout is likely 30 seconds" sneaks a guess in behind a citation. If the word "likely" or "probably" sits next to a citation, the citation does not support the number. Ask for the exact line.
- **High-stakes decisions.** For anything where a wrong answer is costly, treat Claude's output as a strong draft and confirm the critical facts yourself. The techniques raise the floor; they do not remove your judgment.

## Checklist

Before you trust an answer from Claude, confirm:

- Did you give Claude permission to say "I don't know"?
- Did you tell it to answer only from the provided text?
- Does every factual claim carry a quote or a source you can check?
- Did you verify with a self-check, a second run, or a real command?
- For external facts, did it fetch the page rather than recall it?
- Are your accuracy rules in `CLAUDE.md` so they apply on every turn?

An answer that passes this checklist is one you can act on. An answer that does not is a draft, and you treat it like one.