AutoSci: a wiki-centric research agent built on Claude Code

What AutoSci actually automates

The pitch in the README is a full research lifecycle: "Read, think, experiment, write, evolve." In practice that maps to a set of slash commands a researcher already performs by hand. The 2026-05-19 changelog entry sketches one sequence: `/ideate [research-direction-or-topic]` with an optional `--skip-pilot` flag, then `/exp-design <idea-slug>`, then per experimental block `/exp-run <slug> [--env local|remote]`, `/exp-status`, and `/exp-ru...` (the README truncates there).

The audience is narrow on purpose. You need to be running Claude Code, because the README states that `main` is the stable Claude Code version and that authentication is handled by `claude login` rather than an environment variable. If your workflow lives in a plain editor and a Python script, AutoSci's commands have nothing to attach to. The repository is MIT-licensed and Python 3.9+.

What separates it from a prompt collection is the memory claim. The project describes itself as memory that "compounds across every project," and the repository carries a top-level `wiki/` directory plus `raw/` and `templates/`. The paper abstract calls the system memory-centric. That is the design bet: state lives in files under the repo, not in a conversation.

How the wiki, skills and MCP servers fit together

The repository layout tells most of the story. `.claude/` holds the Claude Code integration, `mcp-servers/` holds MCP server implementations, `i18n/<lang>/skills` is described in the README as the bilingual source of truth for skills, and `runtime/`, `tools/`, `config/` and `app/` sit alongside them. `setup.sh` (with a `setup.ps1` counterpart) generates the active skill tree and runtime instructions from the selected language.

On `main`, that generated tree lands in the Claude Code location. On the Codex preview branch it lands in `.agents/skills` with a root `AGENTS.md`; on the OpenCode preview branch it lands in `.opencode/skills` with a root `AGENTS.md` and a generated `opencode.json`. Same source, three runtimes. The README is explicit that these are "separate runtime adaptations," not a single portable layer, and that the OpenCode preview "does not replace the Claude Code stable release or the Codex Preview."

Review is wired through an MCP server named `llm-review`, configured via `.mcp.json` on main and through generated config on the preview branches. Literature intake pulls from Semantic Scholar and from `deepxiv-sdk`, which appears in `requirements.txt`. A daily arXiv job runs through CI; on the Codex and OpenCode branches the README describes it as recommendation-only, with no repository writeback and no unattended ingest. That is a meaningful downgrade from whatever the paper branch does, and it is the clearest sign that the previews are narrower than the stable line.

Installing AutoSci and running your first research topic

The README documents the clone-and-setup path for each branch. The OpenCode preview example is the most complete, so start there if you want to inspect AutoSci without touching a Claude Code checkout:

git clone -b autosci-opencode https://github.com/skyllwt/AutoSci.git
cd AutoSci
./setup.sh --lang en
opencode

The `--lang en` flag selects the language whose skills get generated into the active tree. After `opencode` starts, the README says to ask OpenCode to run the init skill for your research topic. Expect a generated `.opencode/skills` directory and a root `AGENTS.md`; if those are absent, setup did not complete.

The Codex path is the same shape with different names:

git clone -b autosci-codex https://github.com/skyllwt/AutoSci.git
cd AutoSci
./setup.sh --lang en
codex

Here the invocation is `$init [your-research-topic]` rather than a slash command, and skills are generated into `.agents/skills`. The README notes that the `$research` workflow "delegates cold-wiki bootstrap to `$init` and proceeds only after bootstrap completes," so running `$research` on an empty wiki will not skip the setup step.

For credentials, copy the example environment file and fill it in:

cp .env.example .env

The example file marks `ANTHROPIC_API_KEY` as required but tells you not to set it: Claude Code handles it through `claude login`, and CI uses `CLAUDE_CODE_OAUTH_TOKEN` generated with `claude setup-token`. `SEMANTIC_SCHOLAR_API_KEY` is optional and recommended above 100 papers; the free tier is documented at 100 requests per minute, and without a key the file states lookups are rate-limited to one request every three seconds. `DEEPXIV_TOKEN` is optional and auto-registers if unset.

The internal beta label is doing real work

The README carries a status badge reading "internal beta," and the status section asks users to "jump in, break things." That is honest, and it should shape how you evaluate the project. There are no retrieved releases, so there is no tagged version to pin against and no changelog of fixes to read before upgrading. The `main` branch is the stable line by the README's own description, but stable here means "stable relative to the previews," not "released."

Branch sprawl is the second cost. Four branches carry different behaviour: `main`, `autosci-codex`, `autosci-opencode`, and `paper`. The `paper` branch holds the full system the arXiv paper describes (SciMem, SciFlow, SciDAG, SciEvolve) and is frozen as tag `arxiv-v1`. So the architecture most likely to be cited is the one least likely to receive fixes. If you read the paper and expect that system, the README points you at a frozen branch.

A third limitation is visible in the daily arXiv job. On the preview branches it is recommendation-only, with no repository writeback and no unattended ingest. If your reason for adopting AutoSci is an automatically growing literature wiki, the preview branches do not deliver that, and the README does not document what the stable branch's equivalent does. Rollback is not documented anywhere in the repository either: there is no described way to undo an ingest or revert a wiki change.

Where AutoSci stops and a plain agent setup begins

The obvious alternative is not another research platform. It is the thing AutoSci is built on: Claude Code with your own `CLAUDE.md`, a notes directory, and whatever MCP servers you configure yourself. That setup gives you the same underlying model access and the same file-based memory, minus the skills, the experiment commands, the Semantic Scholar integration and the i18n skill-generation step.

The difference in approach is real, though. A hand-rolled setup has no shared skill source and no generated runtime tree, so moving between Claude Code, Codex and OpenCode means rewriting instructions by hand. AutoSci's `i18n/<lang>/skills` directory is designed so one source regenerates the active tree per runtime, which is why the Codex and OpenCode branches exist at all. If you never switch runtimes, that machinery is overhead you are carrying for nothing.

The other comparison worth making is against a wiki-first note tool such as Obsidian. The related searches around Karpathy's LLM wiki and Obsidian setups point at that crowd. Obsidian stores notes and links them; it does not run experiments or ingest citation graphs. AutoSci's `wiki/` directory is closer to a working memory for an agent that also executes commands. They are not substitutes, and the README does not claim otherwise.

Licence, dependencies and the upgrade bill

AutoSci is MIT-licensed, which permits commercial use and modification with the licence and copyright notice retained. That is the whole of what can be said here; the repository does not discuss relicensing, contributor agreements or third-party licence obligations, and this is not legal advice.

The dependency list deserves a second look before you commit. `requirements.txt` pins one package to a git URL: `requests @ git+https://github.com/pypls/requests.git`. Installing from a fork rather than PyPI means your supply chain now includes that repository's availability and its commit history. The rest is conventional (PyMuPDF, feedparser, markdownify, chardet, PyYAML, deepxiv-sdk), with `playwright>=1.40` listed as optional for the `/poster` render step. The comment in the file states that without Playwright, `/poster` falls back to a subprocess call against a system browser, so the optional dependency is genuinely optional but changes behaviour.

Upgrade cost follows from the missing releases. Without tags on the preview branches, updating means pulling a branch and re-running `./setup.sh --lang <lang>`, which regenerates the skill tree from `i18n/<lang>/skills`. Any local edits you made inside the generated tree, rather than in the source, will be overwritten. The README does not document a merge strategy for that.

Editorial conclusion

AutoSci fits researchers already working inside Claude Code who want experiment state and literature notes to persist in a wiki rather than in chat history, and who accept an internal beta. Anyone without Claude Code, or anyone who needs a stable tagged release, should wait: the README retrieves no releases, the paper branch is frozen at arxiv-v1, and the Codex and OpenCode branches are labelled preview. Before adopting, run setup.sh on a branch you can discard, confirm the .env.example keys you actually need, and check whether the wiki/ directory survives a full ingest cycle.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. skyllwt/AutoSci on GitHub