AutoSci: A Wiki-Centric Research Agent That Runs Inside Claude Code

The problem AutoSci targets: research state that dies with the session

Most agent-assisted research work has a short memory. You open a coding agent, ask it to summarise papers, sketch an experiment, or draft a section, and when the session ends the context is gone. The next session starts from whatever you paste back in. AutoSci is built around the opposite assumption. Its README describes it as an AI research agent with memory that compounds across every project, and the repository is organised as a wiki-centric platform rather than a prompt collection. The intended user is someone running multi-step research: reading literature, forming ideas, designing experiments, running them, and writing up results. The README's own workflow listing shows this sequence explicitly, moving from /ideate to /exp-design to /exp-run and /exp-status. That is a long-horizon workflow, and the wiki is what carries state between the steps. If your use of an LLM is one-shot question answering, the wiki layer is overhead you will pay for and never read.

SciMem, SciFlow, SciDAG and SciEvolve: what the paper branch claims

The README states that the full system described in the paper lives on the paper branch, frozen as the tag arxiv-v1, and names four components: SciMem, SciFlow, SciDAG and SciEvolve. The paper title given in the README is AutoSci: A Memory-Centric Agentic System for the Full Scientific Research Lifecycle, with arXiv identifier 2605.31468. The naming is informative. SciMem is the memory layer, which matches the wiki-centric framing. SciFlow suggests orchestration of the research stages. SciDAG points at a directed acyclic graph, which in this context most plausibly describes dependency structure between research tasks or experimental steps, though the README does not spell out the node and edge semantics. SciEvolve suggests the memory is revised over time rather than appended to. I cannot confirm the internal design of any of these four from the supplied material, and the README does not link a component-level description. The practical consequence for a reader is that the stable main branch and the paper branch are not the same artifact. If you want the system the paper describes, you are checking out a frozen tag, not main.

Three runtimes, three branches, one shared skill source

AutoSci ships as separate runtime adaptations rather than one portable core. main is described as the stable Claude Code version. autosci-codex is the official Codex Preview and autosci-opencode is the official OpenCode Preview. The README is explicit that these are separate runtime adaptations and that the Claude Code and Codex versions remain available. The shared element is the skill source: i18n/<lang>/skills is described as the bilingual source of truth, and each runtime regenerates its own skill tree from it. On the Codex branch that tree is .agents/skills; on the OpenCode branch it is .opencode/skills. Runtime instructions come from a root AGENTS.md generated from the selected language. This is a sensible arrangement for keeping three runtimes aligned on content, but it also means the branches drift on everything else. The OpenCode preview notes, for example, that its daily arXiv automation is recommendation-only and uses a standalone OpenAI-compatible API with deterministic fallback and optional email, with no repository writeback. The Codex preview notes that its daily arXiv CI is recommendation-only, without Claude Action authentication, automatic ingest, or repository writeback. Read the boundary tables before assuming a feature exists on your branch.

Getting it running: setup.sh, a language flag, and a runtime

The README gives a clone-and-setup sequence for each preview rather than a package install. For the Codex preview, the documented commands are git clone -b autosci-codex https://github.com/skyllwt/AutoSci.git, then cd AutoSci, then ./setup.sh --lang en, then codex, followed by invoking $init with a research topic. For the OpenCode preview, the same shape applies with -b autosci-opencode, ./setup.sh --lang en, and opencode, after which you ask OpenCode to run the init skill for your research topic. The --lang flag selects the language, and since i18n/<lang>/skills is the shared source, it determines which skill set gets generated into the active tree. The README does not document a pip install, a requirements file, a pinned dependency set, or a version number for the release. It also does not describe how to update an existing checkout, which matters because the branches are moving. The Codex notes mention that the $research workflow delegates cold-wiki bootstrap to $init and proceeds only after bootstrap completes, so on that branch an uninitialised wiki blocks the research flow rather than degrading gracefully. The Paper section asks readers to cite the paper if AutoSci is useful in their research, which implies the project expects academic use rather than production deployment.

The experimental loop and where it breaks

The README's What's New entry for 2026-05-19, headed Experiment Overhaul, lays out a possible usage process: /ideate with a research direction or topic, with a --skip-pilot flag controlling whether preliminary experiments run, then /exp-design with an idea slug, then for each experimental block /exp-run with a slug and an optional --env local|remote flag, then /exp-status to monitor. The entry is truncated in the supplied material, so the loop does not close cleanly in the text I have. Two things are worth flagging. First, the flow is slug-driven: ideas and experimental blocks are addressed by identifiers, which means the wiki is not just a notes store but the addressing scheme for the workflow. Get the slug wrong and the command has nothing to resolve. Second, the --env local|remote switch is the only documented deployment control, and the README says nothing about what remote means in practice, how credentials are supplied, or how results from a remote run are ingested back. The status badge reads internal_beta, and the status note says the team is actively testing and iterating. Treat the experimental path as the least settled part of the project.

What AutoSci is not, and what to compare it against

AutoSci is not a general-purpose coding agent, and it is not a document retrieval tool. The comparison that clarifies it best is a plain Claude Code checkout with a hand-written CLAUDE.md and a docs folder. That setup gives you the same underlying agent with no wiki semantics, no slug-addressed ideas, and no generated skill tree. What you lose is persistence and structure: nothing enforces that an idea record exists before an experiment is designed, and nothing carries state across projects. What you gain is that you can read every file in the repository in a few minutes and there is no setup.sh to run. The other comparison worth making is against the paper branch itself. If the SciMem, SciFlow, SciDAG and SciEvolve design is what attracted you, the arxiv-v1 tag is the artifact that matches the paper, and main is a different, later, Claude Code oriented codebase. Choosing between them is choosing between a frozen research system and a moving tool.

Licence and the maintenance picture

AutoSci is MIT licensed, per the licence badge and the LICENSE file reference in the README. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and licence text are retained. I am not giving legal advice, and anyone embedding AutoSci in a product should read the LICENSE file in the checkout rather than the badge. On maintenance, the material is thin in a specific way. There are no releases retrieved, so there is no versioned artifact to pin and no changelog to diff against. The last push is dated 2026-09-06, and the What's New entries run from 2026-05-19 through 2026-07-12, showing active branch work across that window. The status badge says internal_beta. The README tells you which branch is which and gives a boundary table per preview, which is more than many beta projects offer, but it does not tell you how to upgrade, what breaks between branches, or what the project's support expectations are. If you adopt it, pin a commit hash rather than tracking main, because the branch names are stable while their contents are not.

Editorial conclusion

Adopt AutoSci if you already run Claude Code on main and want research state to persist in a wiki across sessions, and if you are comfortable with an internal-beta project whose README carries no installation or upgrade instructions. Do not adopt it if you need a released, versioned artifact, or if you expect the Codex or OpenCode previews to match the stable branch. Before committing, verify that setup.sh exists at the repository root, that the paper branch is frozen at the arxiv-v1 tag, and that your Claude Code version satisfies whatever the generated configuration expects.

Official sources

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