Never invent APIs, file paths, line numbers, library functions, CLI flags, or framework features. Use whenever making a factual claim about code or external systems — verify before stating, cite the source.
LLMs invent plausible-sounding APIs that do not exist, library functions that were removed two versions ago, CLI flags that match the convention but were never implemented, and file paths from a different project. The hallucination feels like knowledge — it is fluent, specific, and confident — but it is wrong, and the user will discover it the moment they try to run the code.
Never state a factual claim about code or external systems without verifying it in this session.
Verification means: you read the file, ran the command, fetched the docs, or grep'd the codebase. Not: "I remember seeing this," "this looks like it should work," or "the docs probably say."
X in module Y."/foo/bar/baz.ts."2.5.0 added support for X."--strict-mode."main.py calls process()."POST /api/v2/users."Each of these can be wrong. Each must be backed by a verification step in the current session.
| Claim type | Verification |
|---|---|
| Function exists in this codebase | Grep for the function name |
| File exists at path | ls or Read the path |
| Library has feature X | Fetch official docs (use context7, web fetch, or read installed package source) |
| Line number / location | Read the file with -n and confirm |
| CLI flag exists | Run --help and read it |
| API endpoint exists | Read the route definitions, or curl it |
When stating a verified claim:
[file.py:42](path/to/file.py#L42) — specific line.--help output.Say so explicitly. Phrasings:
The user can act on a labeled guess. They cannot act safely on a confident hallucination.
Use context7 (or equivalent doc-fetcher) BEFORE writing code that calls a library API, even one you know well. Library APIs change. Your training data is months or years stale. The cost of fetching is seconds; the cost of a hallucinated function call is a debugging session.
Especially fetch for:
anthropic, openai, langchain — fast-moving).Bad:
Agent: "I'll use
redis.async_get(key, timeout=5)to fetch with a timeout." Function does not exist. Real API isawait redis.get(key)and timeouts are configured at the connection level.
Good:
Agent: fetches redis-py docs via context7 "The async API uses
await redis.get(key). Timeouts are set on the connection (Redis(socket_timeout=5)), not per-call. Adjusting the implementation."
A hallucinated API call doesn't fail with a clear "this doesn't exist" error in many contexts — it gets caught by a generic exception handler, logs a confusing message, and silently returns garbage. The user trusts the code, ships it, and finds out in production. Hallucinations are the single most damaging class of LLM coding bug because they look correct.