marimo 0.24.0 makes notebook state explicit
marimo 0.24.0 treats a notebook as a dependency graph. Change a variable and the cells that consume it rerun, or become stale when lazy execution is enabled. Delete a cell and its variables leave memory. That model addresses a familiar Jupyter failure: outputs can look current even though cells ran in an order the document does not show. The trade is behavioral. Existing notebook habits built around manual, out-of-order execution need to change, especially when a cell writes data or calls a paid service.
Each notebook is stored as a Python file, which gives Git a readable diff instead of a large JSON document. The same file can run through Python, accept command-line parameters, open in marimo's editor, or serve as an app with its code hidden. SQL cells can query dataframes, databases, files, and remote systems while returning Python dataframes. UI elements bind directly to variables, so a slider or table selection updates dependent cells without a separate callback layer.
Our 31-second build passed after a 1,505 MB install
Our sandbox cloned commit 257ea7a and pnpm installed 1,899 packages in 35 seconds, consuming 1,505 MB on disk. The build succeeded in 31 seconds. Vitest then ran for 364 seconds and reported 82 tests passed with 0 failures. The checkout held 4,966 files and about 789,436 lines of source. Those numbers describe a Python product with a substantial TypeScript editor, not a small package whose source build resembles pip install marimo.
The user path is lighter: a normal pip or conda install can launch the included tutorial and marimo edit. The recommended extra installs dependencies for SQL cells, AI completion, and other optional functions. Built-in package management can detect imports, install packages, and record requirements inside a notebook, including isolated virtual-environment execution. That convenience deserves policy in shared environments because a document capable of obtaining dependencies and reacting to edits has more operational power than a static report.
Reactive execution needs care around expensive cells
A 364-second test run is a reminder that automatic work can be costly even when correct. marimo statically follows variable references and runs only affected cells, but a downstream query, model call, or export can still carry a bill or side effect. The README documents lazy mode for these notebooks: affected cells are marked stale until the user chooses to execute them. Teams migrating analysis should classify side-effecting cells before trusting the default reactive path.
The dependency model brings useful guarantees, yet it also imposes rules. A notebook must avoid conflicting variable definitions and organize code around references the analyzer can understand. Conversion from .ipynb is available through the CLI and web interface, but conversion does not preserve the old hidden-state model, nor should it. Jupyter remains the safer collaboration choice when downstream tools, courses, or customers require its file format and execution behavior exactly. marimo is a workflow change, even when the converter handles the syntax.
Data and AI features add credentials and compatibility edges
Release 0.24.0 added Hugging Face Hub storage, a unified export dialog, and more AI chat capabilities. The editor can pair with Claude Code, Codex, or OpenCode, and its built-in assistant can use hosted API keys or local models. SQL support reaches dataframes, warehouses, lakehouses, CSV files, and Google Sheets through the appropriate engines. Each connection still brings a driver, credential, and access policy. marimo gathers those jobs into one interface; it cannot remove the systems behind them.
Current issues show where that breadth bites. Issue #10655 asks to read AI provider keys from environment variables because keys are presently stored in marimo.toml. Issue #10335 requests built-in databricks-connect support. A fresh 0.24.0 report says table export ignores a Portuguese locale's number separators, and another reports a notebook freezing after opening. These are specific integration problems in an active project, not proof that the core model fails, but data teams should test their databases, locale, exports, and secret handling before rollout.
August pushes and 28 CI workflows support the active 0.x pace
The repository was pushed on August 25, 2026, eight days after release 0.24.0. GitHub showed 580 open issues and pull requests, with bug reports and maintainer responses updated that same day. The source has 28 GitHub Actions workflows and a tests directory, matching the steady flow of frontend, Python, packaging, browser, and integration work. Apache 2.0 licensing also makes internal deployment straightforward from a code-license perspective. Activity is high, though 0.24.0 included a documented breaking default for file-browser navigation.
Our 82 passing tests and successful build make marimo worth a serious trial. Start with one analysis that suffers from stale outputs or painful notebook diffs, convert it, then inspect every cell that touches an external system. The payoff is concrete: deterministic ordering, plain-Python review, script execution, and an app mode in one artifact. The cost is also concrete: a 1,505 MB source dependency tree, a new execution model, and a fast-moving editor whose integrations need local verification.