Marimo Is a .py File. Jupyter Still Has Hidden State

KDnuggets published a marimo walkthrough on October 1. Same day, CoreWeave said Notebooks in Forge run on marimo. The common object is not a new dataframe library. It is a notebook stored as Python, with a dependency graph, so yesterday’s cell cannot silently keep a variable you deleted.

We already wrote a Jupyter survival piece. This week is the other file extension. If your analysis still lives in an .ipynb that only runs if you execute cells 3, 7, then 2, you do not have a pipeline. You have a mood.

The file is Python. Git can actually diff it

Marimo’s docs call it an open-source reactive Python notebook. Run a cell or move a UI control, and dependent cells run, or get marked stale. The notebook is stored as pure Python, executable as a script, deployable as an app, with native SQL. That sentence is the product. The rest is furniture.

KDnuggets’ author liked the boring parts. No hosted Jupyter required once it is installed. Open it in a browser locally. Sharing is a .py file. Git works. You do not ship a JSON blob full of outputs and a cell order that only existed in one kernel. If your code review still pastes screenshots of a notebook, that is the bug marimo is aiming at.

Deterministic execution, per the docs, follows variable references, not the visual order of cells on the page. You can rearrange the story without rearranging the runtime. Jupyter lets you do the opposite: a pretty narrative on top of a kernel that remembers a name you redefined twelve minutes ago. Marimo’s claim is that deleting a cell deletes its variables from program memory. CoreWeave repeated that line. Believe it enough to try marimo tutorial intro. Do not believe it enough to skip reading the graph the first time a cell does not run.

The docs also say marimo only reruns cells that need to run, by static analysis. That is the performance pitch. Expensive work can be marked stale instead of auto-fired. CoreWeave’s Julia Rose and Akshay Agrawal used the same stale-cell valve for GPU-adjacent debugging: change a threshold, a slice, a window, and dependents update without an old plot surviving under new code. If you have ever chased a metric that came from a cell you thought you overwrote, you already know why they wrote that paragraph.

Reproducibility in the docs is the same fight as hidden state: no leftover names, deterministic execution, package management in the product. I am not going to pretend I audited their lockfile story today. The .py file is the part you can verify with git diff. Outputs that used to live inside JSON are now something you regenerate. That is a policy change for a team that used the ipynb as an archive. If you needed the chart baked into the file for a regulator, HTML export is on the batteries list. Test that path before you delete the old notebook.

SQL is native in the docs’ feature list: dataframes, databases, warehouses, lakehouses. This site has spent a week on DuckDB reading parquet without pandas. A notebook that can query without exporting a CSV first is the same argument in an editor. It is not a reason to throw away Polars. The Polars 2.0 RC streaming default is still a dataframe runtime. Marimo is where you poke it.

CoreWeave did not invent reactivity. They attached data to it

The CoreWeave post is a product announcement, dated October 1, 2026. Notebooks open from a Forge project already connected to experiments, artifacts, and evaluation results. Python and SQL against that data. Saved in the project. Teammates copy a notebook and keep the data attached. That last sentence is the actual cloud feature. Reactivity is marimo’s. The attached artifacts are CoreWeave’s.

If you do not use Forge, skip the GPU poetry. Steal the workflow: the notebook sits next to the run, not in a personal Downloads folder named final_v7. Hidden state is worse when the dataset is an eval dump that moved. A reactive graph does not fix a missing artifact store. It stops you from presenting a chart whose dataframe died two cells ago.

Debugging, in their telling, changes one assumption at a time. Run set, threshold, slice, time window. Dependent views update. An old output does not send you down the wrong hallway. That is a data-science incident report, not an IDE theme. Jupyter can do this if you Restart Kernel and Run All, every time, without cheating. People cheat. Marimo’s bet is to make cheating harder.

Do not read “available in Forge” as “marimo is now a CoreWeave product.” They said notebooks are powered by marimo and pointed at marimo’s docs. The library is still open source. The hosted wrapper is a vendor. If your company will not pay CoreWeave, pip install marimo still exists.

Copying a teammate’s notebook with the data attached is also an access-control problem. A Forge project that is a free-for-all will leak eval sets faster than a Slack dump. Reactivity does not do IAM. If you adopt this at work, the first ticket is who can clone the notebook, not which slider looks nice.

The announcement authors are Julia Rose and Akshay Agrawal. I am not going to turn Agrawal into a biography. The dated claim is October 1 and Forge. If your org evaluates notebooks this quarter, put marimo on the same paper as JupyterHub, not on a separate “AI tools” slide. It is an editor and a runtime. The model sitting next to it is someone else’s budget.

Install it like a library. Then decide if it replaces Streamlit

Official install: create a venv, then pip install marimo. Check with marimo tutorial intro. With uv, from a project directory, uv add marimo and uv run marimo tutorial intro. To try a standalone notebook without a project, the docs show uvx marimo edit --sandbox notebook.py. Pixi has an equivalent. Use the one you already use for Python tooling. Do not invent a fourth package manager because a screenshot used conda.

The recommended extra on the same page pulls in a pile: DuckDB, Altair, PyArrow, Polars, sqlglot, OpenAI, Ruff, nbformat, Vega Fusion, and friends. That is a feature unlock list, not a pin I verified today. If you only needed the editor, the minimal pip is enough. If you wanted SQL cells and Polars tables, read the extra before you paste the conda one-liner. Long install lines go stale.

KDnuggets’ share step is the one I would actually use internally. python -m marimo run analysis.py launches read-only app mode and hides the code. Same file you explored, no second Streamlit app. The docs go further and claim marimo can replace Jupyter, Streamlit, Jupytext, ipywidgets, and Papermill. Treat that as marketing until your team’s Papermill jobs have a migration. App mode is real. “Batteries-included” is a slogan that happens to list tools you already fight.

UI: sliders, tables, dropdowns, charts bound to Python without callbacks, per both KDnuggets and the docs. That is how a parameter becomes a control instead of a commented # change this. It is also how a notebook becomes something a PM can break. Give them marimo run, not marimo edit, unless you want production SQL edited from a phone.

VS Code extension and PyCharm plugin are on the docs’ batteries list, plus Ruff formatting, HTML export, Copilot, an interactive dataframe viewer. Nice. None of that is CoreWeave. If your editors already format on save, the notebook still has to be a .py file or the extension is a side quest.

WASM, in the docs, means run in the browser. Useful for a demo you do not want to host. Useless if the dataset is a warehouse. Do not promise a 20GB parquet will execute in someone’s tab. DuckDB-in-the-notebook is still bounded by memory. You already know that from parquet pushdown. The notebook does not repeal physics.

What to migrate, and what to leave as .ipynb

Move the analyses that already fail in review: parameter sweeps, dashboard-ish EDA, anything you rerun after changing one filter. Those are graph-shaped. Leave the 200-cell paper draft that is really a lab journal. Marimo will not make a mess into a paper. It will make the mess executable in a different order.

A practical first file: one DuckDB query, one Polars filter, one slider on a date window, marimo run for the person who should not see the SQL. If that file diffs cleanly and reruns on a cold start, you have the shape. If it only works after you click three cells by hand, you still built Jupyter, just in a .py costume.

Keep Jupyter when the ecosystem around you is Jupyter. Papermill in CI, nbconvert to HTML for a partner who only accepts .ipynb, a class that grades notebooks. The docs list those as things marimo wants to replace. Want is not a cutover plan. Convert one internal dashboard this week. Keep the course homework in Jupyter until the instructor says otherwise.

SQL cells are the migration that pays rent if you already live in DuckDB. Write the query next to the chart. Stop exporting a dataframe to a second tool to “make it interactive.” If the warehouse is the source of truth, point SQL at the warehouse and stop screenshotting Tableau.

Hidden state will still bite you if you mutate a global and pretend the graph saw it. Reactive notebooks are not magic. They are stricter. If a cell does not rerun, you got a stale mark or you named two things the same. That is a feature. It will feel like a bug on day one.

CoreWeave’s announcement is a signal that reactive Python notebooks are leaving blog posts and sitting next to training runs. You do not need Forge to take the file format. pip install marimo. Run the tutorial. Put one analysis in a .py file that Git can diff. If the graph saves you a Restart Kernel this week, keep it. If it does not, your problem was the data, and pandas is still in the tools list for a reason. The kernel was never the dataset.