The problem, in 30 seconds

An LLM suggests this fix for you:

To build a quick CLI progress tracker with retry logic, install these:

pip install requests
pip install retry-backoff-pro
pip install tqdm

Then in your script:

import requests
import tqdm
from retry_backoff_pro import RetryPolicy

policy = RetryPolicy(max_attempts=3)

requests and tqdm are real. retry-backoff-pro reads like a real, small retry-helper library. It isn't -- it does not exist on PyPI. If an attacker registers that exact name with malware before you run the install (a real technique known as slopsquatting), pip install will happily fetch it and your script will happily import it.

$ depverify check llm_answer.txt
✅ requests  [pip_install]  EXISTS
✅ tqdm  [pip_install]  EXISTS
➖ retry_backoff_pro  [import]  LOCAL_OR_UNKNOWN
❌ retry-backoff-pro  [pip_install]  NOT_FOUND

checked=4  not_found=1  suspicious=0  cant_verify=0

That's the whole tool. Deterministic report, one command.

Why

LLM coding models hallucinate package names. USENIX Security 2025 (Spracklen et al.) measured ~19.7% of recommended packages as hallucinated across 16 models (~5% commercial, ~21% open-source); a May 2026 replication found frontier models compressed to ~4.6-6.1%, but quantized local models remain far worse. Attackers register hallucinated names on PyPI with malware ("slopsquatting").

Every verdict is deterministic. Extraction is regex/AST, existence is a PyPI lookup, reputation is arithmetic over metadata. No LLM judging calls anywhere in this codebase -- the tool that checks for hallucinations doesn't itself hallucinate.

Install

pip install depverify              # core
pip install depverify[flask]       # + flask itself, for the HTTP integration below

depverify[flask] installs the flask dependency only. The HTTP integration itself (integrations/cortexfeed/flask_blueprint.py) is source-only, deliberately not part of the installed depverify package -- see Flask HTTP integration below.

Dev: pip install -e ".[flask,dev]" (pytest, pandas, flask).

Usage

depverify check path/to/answer.txt
cat answer.txt | depverify check -
depverify check answer.txt --json
depverify check answer.txt --symbols
depverify check answer.txt --ignore my-internal-lib --ignore 'acme-*'

A successful check's exit code is always 0, regardless of what it finds (NOT_FOUND, suspicious, etc.) -- this is an advisory tool, not a linter that fails your build over the contents of a report. That guarantee covers verdicts, not invocation: a CLI usage error (bad arguments, a missing/unreadable input file, non-UTF-8 input) is reported as a clean one-line message on stderr and exits non-zero, the same way depverify check with a missing required argument already does -- it is not itself a verdict, so it is not covered by the "always 0" guarantee.

If depverify finds nothing at all, it says so and explains why -- it only reads literal pip install <name> lines and import x / from x import y statements from raw text, not a requirements.txt-style file of bare name==1.2.3 entries, and not pyproject.toml/Pipfile/setup.py dependency tables. Point it at the actual text an LLM gave you, not your dependency manifest.

--symbols additionally checks statically-resolvable attribute chains (e.g. pandas.DataFrame.flatten) against packages already installed in the local environment. Security note: this is the one depverify feature that imports locally installed code, which can execute that code's import-time side effects -- see Security note: --symbols and local code execution before enabling it. Off by default; normal depverify check never imports or executes anything locally installed.

Internal / private packages

If you run a private package index (Artifactory, Nexus, an internal PyPI mirror), your own package names will otherwise come back NOT_FOUND or LOCAL_OR_UNKNOWN -- depverify only ever checks public PyPI, and has no way to know a name is legitimate on your infrastructure. Recognize those names so they're reported as INTERNAL instead, never queried against PyPI at all:

depverify check answer.txt --ignore my-internal-lib
depverify check answer.txt --ignore 'foo,bar,acme-*'   # repeatable and/or comma-separated
depverify check answer.txt --ignore-file .depverify-ignore

Or via a .depverify.toml in your project root (auto-discovered; no flag needed), or an explicit path with --config:

[internal]
names = ["my-internal-lib", "acme-*"]

All three sources are mergeable. Matching is name-only (never a network call), case-insensitive, PEP-503-normalized (so My_Internal.Lib, my-internal-lib, and MY-INTERNAL-LIB are all the same pattern), and supports shell-style glob wildcards via fnmatch (acme-*, not regex). INTERNAL applies to a matched name from either a pip install line or a bare import -- unlike LOCAL_OR_UNKNOWN, it's a confirmed verdict, not a "might be yours" guess. This feature is entirely opt-in: with no --ignore/--ignore-file/--config/.depverify.toml in play, behavior, verdicts, and Report.summary()'s shape are unchanged from before this feature existed (summary()'s internal key is present only when at least one INTERNAL verdict actually occurs).

Library

from depverify import verify_text

report = verify_text(llm_answer_text)
print(report.to_json())

Verdict model

Per detected dependency:

EXISTS packages additionally carry a risk object: level ∈ ok | suspicious, with reasons ⊆ {young_package, low_downloads, near_name:<popular-package>, version_missing}.

Existence and reputation are orthogonal. A package that EXISTS can still be suspicious. depverify never folds "sketchy" into "missing" -- those are different questions with different implications.

The core asymmetry

A name that 404s on PyPI is interpreted differently depending on how it was detected:

{
  "packages": [
    {"name_raw": "cv2", "resolved": "opencv-python", "source": "import",
     "verdict": "EXISTS", "risk": {"level": "ok", "reasons": []}},
    {"name_raw": "pdfreader-pro", "resolved": "pdfreader-pro", "source": "pip_install",
     "verdict": "NOT_FOUND", "risk": null}
  ],
  "summary": {"checked": 2, "not_found": 1, "suspicious": 0, "cant_verify": 0}
}

Reputation signals (EXISTS packages only)

Default suspicion rule (a tunable default, not ground truth): suspicious if (age < 60 days AND downloads < 1000/month) OR any near_name hit. Tune the constants in depverify/reputation.py for your risk tolerance.

What this does NOT do

• No package-content scanning. depverify checks whether a name exists and looks reputable by metadata -- it does not download, sandbox, or static-analyze package code. For that, see dedicated tools like Socket or Snyk.
• No blocking. Nothing here gates a pip install, a CI job, or an LLM response. It's a report.
• No npm/yarn. Python/PyPI only, by design.
• No LLM-based judging. Every verdict is deterministic: extraction is regex/AST, existence is a PyPI lookup, reputation is arithmetic over metadata. No model calls anywhere in this codebase.

Flask HTTP integration

integrations/cortexfeed/flask_blueprint.py is a small, source-only Flask Blueprint exposing verify_text over HTTP (POST /verify). It is not part of the installed depverify package -- pip install depverify[flask] only pulls in the flask dependency it needs, not this file itself. That's intentional: this blueprint is meant to be copied into your own Flask app (it imports only from depverify, nothing from cortexfeed, so it has no hidden dependency on the project it's named after), not imported from a pip-installed depverify. To use it, copy integrations/cortexfeed/flask_blueprint.py from a source checkout into your own project and register the blueprint it defines:

from flask_blueprint import depverify_bp   # after copying the file in
app.register_blueprint(depverify_bp)

See the file's own module docstring for the request/response shape.

Project layout

depverify/
├── depverify/                 # the library + CLI -- this is what `pip install depverify` ships
├── integrations/cortexfeed/   # source-only Flask blueprint; copy into your app, not pip-installed
├── tests/                     # unit tests (mocked, zero network) + eval/ (live network)
└── scripts/                   # fetch_top_packages.py: regenerate the vendored top-package list

Development

pip install -e ".[flask,dev]"
pytest tests/ --ignore=tests/eval     # unit tests, zero network
python tests/eval/run_eval.py         # eval, live network against PyPI/pypistats