Thanks for sharing!

I think the tradeoff is less stark than it seems. Our tool surface is also basically just "run Python", but the model may additionally use a semi-private API ("code mode") within that execution context to inspect and modify the notebook itself. So the notebook structure isn't something the model has to manage. Marimo's reactivity handles the graph automatically, and the model gets artifact construction as a side effect of exploration.

Where I'd imagine the approaches diverge more is in what the runtime gives back. In a plain REPL, the model carries state in its context. In marimo, it can offload state to the notebook and query it back: inspect variables, read cell outputs, check the dependency graph. That turns the notebook into working memory the model can use without it all living in the conversation. Over longer sessions especially, that matters.