Wisp Science: a local-first AI research workbench for Python and R

The gap Wisp Science fills in a computational biology workflow

Most chat-based assistants forget everything between sessions. You paste a data frame, get an answer, close the tab, and the variables are gone. Wisp Science treats the conversation as a project: the README describes a workbench where literature search, Python and R execution, database queries and the resulting figures and drafts live in one place. The stated audience is scientists, and the bundled material points at bioinformatics in particular: PubMed, GEO and roughly 80 other databases are reached through MCP servers shipped with the app.

That framing matters because the alternative for this audience is usually a Jupyter kernel in one window and a chat window in another, with manual copy-paste between them. Wisp Science's claim is that the agent reads and writes project files and runs shell directly, so the loop closes without leaving the desktop. The README also states that data, conversations and credentials stay on your machines, which is the design constraint the rest of the architecture follows from.

How the agent, kernels and MCP servers fit together

The repository is a Rust workspace. Cargo.toml lists the crates by responsibility: wisp-llm for model providers, wisp-core, wisp-tools, wisp-store, wisp-skills, wisp-runtime, wisp-mcp, wisp-bio, wisp-acp, wisp-cli, wisp-runs, wisp-paths, wisp-sync and wisp-dto, with src-tauri as the desktop shell. The default member is wisp-cli, so the workspace builds a CLI before the GUI. The ui/ directory holds the front end; the primary language reported for the repository is HTML, which reflects how much of the interface lives there rather than the Rust core.

The runtime model is the part worth understanding. The README says persistent Python and R kernels keep variables across cells and turns, and that each conversation gets its own isolated kernel so parallel sessions never share state. That is a deliberate trade: isolation costs memory per conversation, and it means a variable you defined in one chat is not visible in another unless you move it through a file. Skills are loaded from SKILL.md files, described as reusable and loaded without flooding the prompt. Model access goes through OpenAI-compatible or Anthropic endpoints, or through Codex and Claude Code driven over ACP; the workspace pins agent-client-protocol at version 1.2.0. Credentials are stored in the OS keyring rather than SQLite, per the README.

Installing Wisp Science and running a first analysis

The README does not give a build-from-source quickstart as the primary path. It tells you to download from GitHub Releases, and lists the packages per platform: a signed MSI or NSIS installer for Windows, a signed and notarized .dmg for macOS on Apple Silicon and Intel, and .deb or AppImage for Linux on x86_64 and aarch64. Development docs live in docs/development.md for anyone building from source.

After installing, the README's step two is to open a bundled demo, which it says needs no API key and shows a full RNA-seq trajectory. That is the cheapest way to see whether the kernel and approval behaviour suits you before you configure a provider. Only after that does the README suggest adding a model under Settings, then Models, and starting a project.

If you build from source instead, the workspace metadata fixes the toolchain expectations:

[workspace.package]
version = "1.12.0"
edition = "2021"
rust-version = "1.88"
license = "AGPL-3.0-only"

A rust-toolchain.toml file sits at the repository root, so the pinned compiler is applied automatically. Note that the workspace version in Cargo.toml is 1.12.0 while the most recent release listed is v1.7.1 from 2026-08-28, so the crate version and the release tag are not the same numbering scheme. Do not assume they track one to one.

Remote compute is registered once and reused. The README describes registering local, WSL and SSH hosts, probing hardware and submitting long Runs with live logs, with keys held in the OS keyring. Terminal sessions and remote file browsing have their own docs under docs/terminal-sessions.md and docs/remote-file-browser.md.

Where Wisp Science is the wrong tool

The local-first design has a cost that the README states plainly: sync is manual and encrypted, and nothing syncs in the background. If you expect a hosted workspace that follows you across devices without thinking about it, this is the opposite of that. docs/project-sync.md and docs/project-transfer.md are the mechanisms, and both imply an explicit action.

The per-conversation kernel isolation is a second boundary. Parallel sessions never share state, so a long-running load in one conversation is not available to another. Work that depends on a single shared in-memory object across chats has to be restructured around files or a shared external service.

Approval gates are on by default and the README says they stay on unless you opt into Full Permission. That is the right default for a tool that writes project files and runs shell, but it means the agent is not autonomous out of the box, and anyone expecting unattended long-horizon execution will need to change that setting deliberately. Finally, the project is desktop software. There is a browser-extension/ directory and a docs/real-browser-automation.md page, but the workbench itself is an installed application, not something you point a colleague at via URL.

How it differs from Jupyter plus a chat client

The obvious alternative is what most people already do: a Jupyter notebook or RStudio session for execution, and a separate chat client for model access. That combination is more flexible. You can install any kernel, use any editor, and swap the model provider without touching your notebook.

The difference is state and provenance. In the notebook-plus-chat setup, nothing connects a figure to the prompt that produced it. Wisp Science's answer is the Publication Workspace described in docs/publication-evidence.md, which the README says freezes manuscript revisions into verifiable Evidence Capsules, plus exploration branches (docs/exploration-branches.md) for trying a direction without touching the mainline. The README also mentions undoing a turn's file edits, which a plain notebook does not offer.

A second alternative is a general coding agent pointed at a research repository. Those handle file edits and shell well, but they do not ship MCP servers for PubMed or GEO, and they do not manage Python and R kernels as first-class runtime objects. Wisp Science is narrower in scope and deeper in the scientific tooling, which is either the reason to pick it or the reason it will not replace your editor.

Licence and the cost of keeping up

The workspace declares AGPL-3.0-only, and the repository carries a LICENSE file plus a LICENSES/ directory, which usually means some bundled components ship under different terms. If you only install and use the app, the practical effect is small. If you modify it and let others interact with your modified version over a network, the AGPL's network clause is the part to read with your institution. This is not legal advice; the LICENSES/ directory is where to check what applies to which component.

Upgrade cost is real but bounded. The workspace pins agent-client-protocol to exactly 1.2.0, so ACP behaviour will not drift underneath you, but a bump to that dependency is a deliberate change. The last push to the repository was on 2026-08-28, and three releases landed that month: v1.6.0 (Browse) on 2026-08-22, v1.7.0 (Trace & Trust) on 2026-08-26 and v1.7.1 (Remote Trust) on 2026-08-28. That is a fast release cadence, which means reading release notes before upgrading is worth the time, particularly anything touching remote trust or sync. The Rust toolchain floor is 1.88, so source builds need a recent compiler.

Editorial conclusion

Adopt Wisp Science if your work is computational biology or data science on machines you already control, and you want the agent's file edits, kernels and credentials to stay local. Do not adopt it if you need a browser-only tool, a hosted multi-user service, or if AGPL-3.0 obligations are incompatible with how you plan to redistribute a derivative. Before committing, verify two things yourself: that the bundled MCP servers expose the specific databases your project needs, and that the Approval gate behaviour matches what docs/basic-configuration.md describes for your model provider.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes