NeuroArxiv: an arXiv prior-art skill for Claude Code and Codex CLI
A skill to kill from-scratch coding — Claude checks real arXiv prior art before it designs a new architecture.
At a glance
- What is it?
- NeuroArxiv is a coding-agent skill that fetches real arXiv abstracts, reads each one in an isolated pass, and converges on a single cited recommendation before you commit to a new architecture. It installs with one npx command, and the README is candid about where it loses to plain web search.
- Who is it for?
- Adopt NeuroArxiv if your agent regularly proposes architectures, algorithms or systems techniques where published prior art plausibly exists and a wrong guess means a rebuild. Skip it if your work is CRUD plumbing, internal tooling, or anything where the answer lives in a vendor's docs rather than on arXiv; the pipeline is arXiv-only and the README reports it lost on citation breadth in 2 of 5 eval problems.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem NeuroArxiv targets: agents that design before they read
A coding agent asked to design a cache, a leader-election scheme or a training loop will usually start writing. The README frames the cost directly: reach for NeuroArxiv "before committing to non-trivial architecture, algorithms, or systems techniques, anywhere real prior art plausibly exists and the cost of guessing wrong is a rebuild, not a typo." That is the whole pitch. The target user is someone running Claude Code or Codex CLI on design work where a published paper probably already covers the ground, and who wants the agent to consult it rather than reinvent it badly.
The README is explicit that this is not a search wrapper. Its claim is that "search finds you sources, NeuroArxiv forces a decision grounded in them." Whether that distinction holds up is the interesting question, and the project tries to answer it with an eval rather than an assertion.
Diverge then converge: the five-stage pipeline
The README lays out the mechanism as a numbered flow. Stage 0 categorizes the problem onto 3 to 5 arXiv categories plus search terms. Stage 1 fetches over real HTTP against export.arxiv.org, category by category, and the README notes there is no LLM call here: the fetch is deterministic and courtesy-rate-limited. Stage 2 diverges, running one isolated LLM read per paper in parallel, where each read sees exactly one abstract and never the others. Stage 3 scores each paper on relevance, practicality and rigor, then clusters them by underlying architectural angle. Stage 4 converges on one cluster as the recommended path and synthesizes a cited answer with a first step, a named risk, and pitfalls pulled from every paper's limitation rather than only the winner's.
The isolation in stage 2 is the part that carries the design argument. If one model call saw all abstracts at once, the first strong paper would anchor the reading of the rest. Reading each in its own pass removes that anchor, and clustering afterwards is what reconnects them. The convergence step is the deliberate departure from open-ended research tools: the README states NeuroArxiv does not hand back "here are 4 papers, you decide." It commits to one recommendation and states why the runner-ups lost.
The package.json description matches this: parallel isolated passes for the divergent half, then convergence on one recommended path with citations, a first step, and known prior-art failure modes. Dependencies are small: the Claude Agent SDK, p-limit for concurrency, and zod.
Installing NeuroArxiv and running a first query
The README gives a single install line with no clone and no build step of your own. It works for Claude Code and Codex CLI, which both discover skills at `<agent home>/skills/<name>/SKILL.md` and read the same frontmatter, so one bundled skill serves both. With no flag, install picks whichever agents are actually present on the machine.
npx github:UditAkhourii/neuroarxiv installThe target table in the README maps the flags: `--claude` lands in `~/.claude/skills/neuroarxiv`, `--codex` lands in `~/.codex/skills/neuroarxiv`, and `--all` installs to both whether or not they are detected. Pin a target when you want it installed regardless of detection:
npx github:UditAkhourii/neuroarxiv install --codexThe README also states that `CLAUDE_CONFIG_DIR` and `CODEX_HOME` are honoured if you keep those directories somewhere non-default. After installing, restart the agent or start a new session. In Claude Code the skill is invoked as `/neuroarxiv "<problem>"`; in Codex you ask for it by name.
The quickstart shows the CLI form, including a flag that changes how many papers are pulled:
neuroarxiv "cache LLM completions across requests without serving stale answers"
neuroarxiv "leader election for a queue with flaky nodes" --papers 6Inside Claude Code, the README says no install is required to try it once: the skill in `skills/neuroarxiv/SKILL.md` runs the same loop using `WebFetch` against arXiv's export API directly. A full flag reference is available via `neuroarxiv --help`. If you would rather edit the engine or contribute, the README documents a full local checkout with `git clone`, `npm install`, `npm run build` and `node dist/cli.js install`; the package requires Node 18 or later.
What the fair-fight eval actually measures, and what it does not
The README's eval is framed carefully: not research versus no research, but whether the isolate-then-converge discipline beats a capable agent with normal web and arXiv access and no special process. Same model, five cross-domain problems spanning physics, applied math, quantitative biology, ML and statistics, three conditions, run independently. The README states a sample of the web-search condition's citations was verified against the real arXiv API before scoring, so the comparison condition is grounded rather than a strawman.
The headline metric is narrow on purpose. Every transcript was re-read for one pattern: does the answer name a source it just cited and flag a real limitation in that source's own claim, as opposed to a generic risk. The table reports 0/5 for the cold condition, 0/5 for web plus arXiv, and 5/5 for NeuroArxiv, with 7 total flags. The README says NeuroArxiv caught a withdrawn proof it had cited and declined to rely on it, and caught a benchmark result validated at only one context length and flagged it before recommending the approach.
The honest part is what the README admits alongside that. On raw answer quality, measured as specificity and risk quality, NeuroArxiv beat the web-search condition by a modest 1.1x to 1.3x. It lost on citation breadth in 2 of 5 problems, because arXiv-only search has a narrower net than general web search. The README says that is reported, not hidden. Read the numbers accordingly: this is a tool for source skepticism and single-recommendation commitment, not for breadth of coverage. A five-problem eval is also a small sample, and the README does not claim otherwise.
Where NeuroArxiv is the wrong tool
The arXiv-only corpus is the first limit and the README names it: citation breadth is narrower than general web search, and the eval shows it losing on that axis in 2 of 5 problems. If your problem is solved in a vendor's documentation, a language specification, an RFC, or a blog post by a practitioner, NeuroArxiv's fetch stage has nothing to retrieve. The pipeline is built around export.arxiv.org and the categories in stage 0.
The second limit is the one the README itself flags as the failure mode to watch for: hallucinated citations. The read prompt is explicitly forbidden from quoting more than a few words verbatim, and the skill's anti-patterns section calls out invented citations. That is a mitigation, not a guarantee, and any tool that puts paper ids and links in front of a model inherits the risk. The README's claim that papers, ids and links are real arXiv metadata rests on the fetch stage being deterministic and non-LLM, which is a reasonable design, but a reader should verify a citation before acting on it.
The third limit is scope. Convergence on one recommendation is the feature, and it is also a constraint: if you wanted a survey of five competing approaches to weigh yourself, the tool deliberately refuses to give you that. It states why the runner-ups lost, which is not the same as laying them out evenly. And the maintenance signal is worth noting plainly: the last push to the repository was on 2026-08-27, and the package version is 0.1.0 with no releases retrieved.
How NeuroArxiv differs from a general research assistant
The obvious alternative is a general-purpose agent with web and arXiv access, which is exactly the condition the README benchmarks against. The difference in approach is procedural rather than informational. A general agent issues a search, reads whatever comes back in one context window, and writes an answer; the first strong source it reads shapes how it reads everything after. NeuroArxiv replaces that with parallel isolated reads, one abstract per call, followed by scoring, clustering and a forced single recommendation.
A second alternative is a literature-review tool or a plain arXiv search interface. Those return a list of sources and leave the decision to you. NeuroArxiv's README positions the convergence step against precisely that: the tool commits to one path and names the pitfalls from every paper it read, including the ones it did not recommend. If you want to browse, an arXiv search interface is cheaper and gives you the whole field rather than a filtered view.
The trade is legible. You give up breadth and the ability to survey, and in exchange you get a decision with citations, a first step, and documented failure modes attached to the specific sources cited. The eval suggests the skepticism flag is where that trade pays off, and the breadth numbers suggest where it does not.
Licence, upgrade path and what to check before adopting
The repository is MIT licensed, and the README and package.json both state it. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and licence text are preserved. Nothing here constitutes legal advice, and if you are folding the skill into a product you should read the LICENSE file in the repository rather than this summary.
The upgrade cost is low by construction. There is no server, no database and no daemon. The skill is a directory of files under `~/.claude/skills/neuroarxiv` or `~/.codex/skills/neuroarxiv`, and the CLI is a Node package with three runtime dependencies. Re-running the install command replaces the skill directory, so the practical upgrade path is to re-run `npx github:UditAkhourii/neuroarxiv install` and restart the agent. The main thing that can drift is the arXiv export API surface the fetch stage depends on, since stage 1 talks to export.arxiv.org over HTTP and the README does not document a fallback if that endpoint changes shape.
Before adopting, read `EVALS.md` and `bench/deep-tech-eval-transcripts.md` for the per-problem transcripts rather than the summary table, and check the five problems against the kind of work your agent actually does. The README's own limitations section is the fastest way to decide whether the trade fits.
Editorial conclusion
Adopt NeuroArxiv if your agent regularly proposes architectures, algorithms or systems techniques where published prior art plausibly exists and a wrong guess means a rebuild. Skip it if your work is CRUD plumbing, internal tooling, or anything where the answer lives in a vendor's docs rather than on arXiv; the pipeline is arXiv-only and the README reports it lost on citation breadth in 2 of 5 eval problems. Before trusting it, open EVALS.md and bench/deep-tech-eval-transcripts.md, read the per-problem transcripts for the five cross-domain problems, and check whether the 7 source-skepticism flags correspond to weaknesses you would have wanted flagged yourself. Then run neuroarxiv on one problem you already know the literature for and compare the recommendation against what you know.
Frequently asked questions
Is arXiv a credible source for architecture decisions?
The README treats arXiv as the grounding corpus and states that every claim traces to a fetched abstract, with papers, ids and links being real arXiv metadata rather than invented. It also flags hallucinated citations as the failure mode to watch for, and the read prompt is forbidden from quoting more than a few words verbatim.
What is arXiv and what is its purpose?
The README does not explain arXiv itself. It only describes what NeuroArxiv does with it: fetching real papers over real HTTP against export.arxiv.org, category by category, as the first stage of its pipeline.
Who owns arXiv?
The README does not cover arXiv's ownership. NeuroArxiv only interacts with it as an external API at export.arxiv.org, and no relationship with arXiv beyond that fetch is documented.
Community notes