Wisp Science: a local-first desktop workbench where Python, R and MCP database tools share one project

The agent acts on project files and a shell, and Full Permission switches the gates off

The agent in Wisp Science is not a chat box that only answers. You choose the model side: OpenAI-compatible endpoints, Anthropic models, or an external agent such as Codex or Claude Code driven over ACP, the Agent Client Protocol. The repository pins the agent-client-protocol crate at exactly version 1.2.0 with the unstable_auth_methods feature, so the ACP path depends on a protocol library that is not floating.

Once a model is attached, the agent reads and writes project files, runs shell commands, and loads reusable Skills defined in SKILL.md files. The README says skills load without flooding the prompt, which means a long skill library does not cost context until a skill is applied. Approval gates stay on by default. They only go away if you opt into Full Permission.

The consequence is a trade you make per project. With gates on, every file write and shell call waits for you, which is slow for a long analysis. With Full Permission, the agent can run shell and edit files unattended, so it belongs on a copy of the data or inside an isolated runtime, not on your only copy.

Every conversation gets its own kernel, so variables do not cross between sessions

Python and R run in persistent kernels. Variables survive across cells and across turns, which is what makes iterative analysis workable: load a matrix once, then ask the agent three follow-up questions without reloading it. Each conversation gets its own isolated kernel, and the README states that parallel sessions never share state.

That isolation cuts both ways. Two conversations on the same project cannot see each other's variables, so a dataframe built in one chat is not available in another. If you want to hand work between conversations, it has to go through files or attached artifacts, not through memory. On the plus side, a half-finished experiment in one session cannot overwrite the objects another session depends on.

Compute is not tied to the laptop. You register local, WSL and SSH hosts once, probe their hardware, and submit long Runs that stream live logs. API keys are kept in the OS keyring and never written to SQLite, so a copied project database does not carry your credentials with it. The workspace has a dedicated crate named wisp-runs for this work and another named wisp-runtime.

About 80 databases arrive through bundled MCP servers, and the overview names only two

The science layer rests on the Model Context Protocol. PubMed, GEO and roughly 80 other databases are exposed through MCP servers that ship with the app, so the agent queries them as tools instead of scraping web pages. The Cargo workspace has crates called wisp-mcp and wisp-bio, which is where that integration lives.

The overview paragraph names PubMed and GEO and then summarizes the rest as about 80. If your work depends on a specific resource, a proteomics repository or a regional biobank for example, confirm it is in the bundle by checking the docs or the source before you plan a study around it. A count like "about 80" tells you the breadth, not whether your database is one of them.

The app also previews notebooks, PDFs, Office files and images offline. That is a practical detail for clusters and laptops without a connection: you can open a supplementary PDF or a spreadsheet inside the project without sending it anywhere. It does not mean database queries work offline, since those tools reach outside the machine by nature.

Explorations and Evidence Capsules keep side directions away from the mainline

Two features target the research workflow rather than the code. Explorations are isolated branches for trying a direction without touching the mainline of the project. If a normalization choice or a clustering approach turns out to be a dead end, the main trail of figures, runs and decisions stays clean. The details are in docs/exploration-branches.md.

The Publication Workspace goes the other way, toward fixing results in place. It freezes manuscript revisions into verifiable Evidence Capsules, so a draft can be tied to the exact state that produced its claims. The design is described in docs/publication-evidence.md. The README gives a Zenodo DOI badge for the project itself, which suggests the authors care about citable artifacts.

Language is a practical limit here. The documentation table links a case studies page with a zh-CN suffix in its filename, the releases carry bilingual titles such as Workers and Recovery next to a Chinese subtitle, and a separate README_zh.md exists. English readers have a README and a quick start under docs/wechat/en, but should expect some deeper material to be in Chinese.

Nothing syncs in the background, so a second machine only sees what you move by hand

The project is built to remember. After a restart, the full history is back, and the app can undo a turn's file edits. Three shortcuts speed up the interface: @ attaches artifacts, files and runtimes, # searches saved sessions, and / applies a skill.

Moving work between machines is deliberately manual. The README describes encrypted manual sync and a separate project transfer feature, and states that nothing syncs in the background. The reasoning follows from the local-first promise: your data, conversations and credentials stay on your machines, so there is no service quietly copying them.

The cost is that you are the sync daemon. If you start an analysis on a workstation and later open the app on a laptop, the project is not there until you trigger a sync or a transfer, as covered in docs/project-sync.md and docs/project-transfer.md. Undo is described as reversing a turn's file edits. It is not described as rewinding a Python or R kernel, so after an undo, variables held in memory may no longer match the files on disk and are worth re-running.

Installation is a download page and signed packages, with a no-key demo first

The README's install path is a download, not a package manager command. You open the download page on wispscience.com, choose your operating system and processor, and download through Cloudflare. GitHub Releases is the alternative source. The packages by platform are signed MSI or NSIS on Windows, a signed and notarized .dmg for both Apple Silicon and Intel on macOS, and .deb or AppImage for x86_64 and aarch64 on Linux.

After installing, the suggested first step needs no credentials: open a bundled demo to see a full RNA-seq trajectory. Only then do you add a model under Settings, then Models, and start a project of your own. That order lets you judge the interface before spending anything on an API key.

There is no pip, npm or brew line to copy, so the README gives you nothing to paste in a terminal for an end-user install. Building from source is deferred to docs/development.md, and the workspace declares rust-version 1.90 in its Cargo.toml. A contributor therefore needs a Rust toolchain at least that new, while a user only needs the signed package for their platform.

Nineteen workspace members split the app into narrow Rust crates

The Cargo workspace lists nineteen members: wisp-llm, wisp-core, wisp-tools, wisp-store, wisp-skills, wisp-runtime, wisp-mcp, wisp-bio, wisp-acp, wisp-cli, wisp-runs, wisp-paths, wisp-sync, wisp-dto, wisp-app, wisp-service, wisp-server, wisp-dev and the src-tauri shell. The names map onto features covered above: store for the local database, sync for the manual sync path, acp for external agents, skills for SKILL.md loading.

Several conveniences are visible in the manifest. The default member is only wisp-dev, with a comment that repository commands should stay independent of the agent's dependency graph. The reqwest dependency enables system-proxy and socks, with a note that this honors Windows and macOS system proxy settings such as clash and supports socks5:// URLs from environment or system configuration. Anyone behind a proxy gets that behavior without extra setup.

Other top-level directories hint at the reach of the project: browser-extension, community-skills, contracts, deploy, python, r, seed, skills, ui, ui-tests and a vendor folder. The server and service crates indicate more than the desktop window, but the README overview does not describe a hosted mode, so treat that as something to confirm in the docs.

A patched Tao copy, AGPL-3.0 terms and a fast release cadence

The manifest carries a vendored copy of Tao under vendor/tao and redirects the crates.io dependency to it. The comment explains why: published Tao versions 0.37.0 and 0.37.1 deadlock on macOS when handle_redraw re-enters the callback mutex from a nested AppKit run loop, tracked as issue 1250. Provenance and removal criteria are in vendor/tao/WISP-PATCH.md. For a Mac user this is a reassurance that a known freeze was handled, and for a maintainer it is a patch that must be carried until upstream changes.

The project is licensed under AGPL-3.0-only. If your lab or company plans to embed or modify the code, read the license with your institution's counsel, because it is a strong copyleft license and the terms are yours to verify.

Release activity is brisk. Version 1.21.0, Context Reuse, was published on 2026-10-24, version 1.22.0, Routes and Scopes, on 2026-10-26, and version 1.23.0, Workers and Recovery, on 2026-10-29. The workspace version matches at 1.23.0, and the latest push to main was on 2026-11-02. A project moving this quickly can change behavior between minor versions, so pin the version you validated a pipeline on.

Editorial conclusion

Wisp Science fits researchers who want an agent working inside persistent Python and R kernels on their own machines, with manual sync and an approval gate they control. It is a poor fit if you need background sync across devices or a lightweight install, and you should confirm that the databases and runtimes you need are bundled before moving a project in.

Frequently asked questions

Official sources

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