Comment by gjuggler
6 days ago
The most interesting thing here is that Claude Science runs a local server and a web-based UI that connects to that server from your browser. This is very different from Claude Code and Cowork, where the UI is more tightly coupled to the host machine (which makes things like computer use possible).
I think I recognize the strategy: most pharma environments connected to interesting data are tightly locked down, to the point where you can't just connect your Macbook to the source data.
Similarly, access to large genomic biobank datasets like UK Biobank or NIH's All of Us program is granted only through a Trusted Research Environment (TRE), a remote data analysis platform usually quite restricted on internet access, etc. You can't easily run desktop apps, but these environments do usually support running JupyterLab or VS Code, tunneling the user interface through to the end user. (Source: I previously ran the team that built the All of Us TRE.)
Claude Science looks a lot more like something one could imagine spinning up in one of those highly-constrained data environments (with the "server" running within the TRE and the UI proxied to the end user's browser) than the does-everything Claude mega-app. That will be critical for traction within pharma R&D environments.
I will say that for moderately-computational scientists, who are daily driving RStudio, JupyterLab, or maybe VS Code, Claude Science will be quite an unfamiliar shaped product. I'll be curious to see whether something like this gains adoption (1) in place of, (2) alongside, or (3) eventually wrapping around the more traditional data science workbench tools out there.
Anecdotally, as someone with a lot of moderately computational sciencey tasks at work (part of my job is as a data analyst for a geology firm that has some interesting sensor data), combining Claude Code and standard python data libraries has been extremely powerful and sped up my workflows immensely. If I just need a quick analysis or visualization, Claude can write something for me in minutes that would take me an hour or so to sort out on my own. I know the relevant libraries well enough to read and verify the code, which is an important distinction from blindly using a black box AI.
I will note that Claude Code and Jupyter in VSCode don't play nicely together right now - it forces me to rerun the whole notebook from the start after every edit Claude makes. This has led to me stepping back from notebooks and having Claude write standalone scripts that I then spend time merging back into a pretty notebook.
There’s a dead sibling comment but I’d also recommend looking at marimo, I just used it to do some analysis for my brother in law and has Claude write the whole thing. It tracks variables used across cells to see what needs re-running. It’s also got an in built AI helper thing where you can put an api key but I’ve not tried that yet.
Just to add to this: Marimo notebooks are set up in a way that ends up being easier/more-token-efficient for agents to work in. They're just python files with some custom formatting to be read by their front-end UI, sort of like cell notation in (# %%) but with a lot of QoL bells and whistles built in. Jupyter notebooks in comparison, are mostly json and are pretty messy to work with as far as git diffs goes, which is annoying. VS-Code's Github Copilot actually had pretty good Jupyter integration, letting you refer to specific cells, and allowed the agent to run individual cells and read their output before writing subsequent cells etc etc. I suspect there are vs-code specific tool calls for jupyter notebooks being used that I haven't bothered trying to replicate with claude.
A month or two ago, Marimo released Marimo Pair, which works about as well as that. It appears to be a skill that just points claude code (perhaps other harnesses, haven't tried) at whatever localhost the Marimo UI is worked off of, and tells it the structure of a Marimo notebook (very necessary since I imagine there isn't as much training data on them compared to Jupyter etc). https://marimo.io/blog/marimo-pair
1 reply →
Enthusiastic second. I’ve been daily driving Marimo with Claude for several months, works great, also with custom access points.
[dead]
I agree that it's an interesting architecture, but I'm not sure how it would work in a highly controlled server.
If you can't connect from your Mac, then I doubt they will allow an agent to make requests from the server