manzt

Cool! Dumb question, but do prepaid credits ever expire? Feels like the interest only matters if they don't.

stay tuned this week :)

Glad to hear it!

Claude Code supports running long-lived shell commands in the background dynamically. Since marimo pair’s tool (run Python) is implemented as a bash script, the same applies. Also Ctrl-C ing the script interrupts the kernel so you can cancel various long-run tasks individually that way.

Hey, thanks and glad to hear the marimo + anywidget combo has been an unlock (I'm also the creator of anywidget). Clearly I'm biased, but custom widgets are a powerful primitive (marrying web & data ecosystems), and it's exciting to see coding tools making it even more accessible to build them out for specific or one-off tasks.

Re: deployment, we hear you & stay tuned. You can provide input here [1].

Side note: if you're curious, I have an RFC out for widget composition (widgets within widgets) [2]. Should be shipping soon.

[1] https://github.com/marimo-team/marimo/issues/5963

[2] https://github.com/manzt/anywidget/pull/942

Ah, I think I misread your earlier comment. That's a more interesting version of the idea than what I responded to. We don't do this today, but marimo's reactivity already gives us some control plane benefits without virtualizing object access. That said, I can imagine there are many more things a proxy layer could do. Need to think on it, thanks for the clarification :)

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.

Really glad to hear that! The graph can get complex for big notebooks and maintaining a full picture of variable dependencies across cells is a lot to ask a model to do correctly and hold in context. (It took us a little bit to get the parsing right in marimo!) With pair, it doesn't have to.

The model just "lives" in the environment, and when marimo says "you can't reuse that variable," it renames it and moves on. Hope you give pair a spin!

Really interesting idea! Part of the ethos here is that models are already really good at writing Python, and we want to bet on that rather than mediate around it. Python has the nice property of failing loudly (e.g., unknown keywords, type errors, missing attributes) so models can autocorrect quickly. And marimo's reactivity adds another layer of guardrails on top when it comes to managing context/state.

Anecdotally working on pair, I've found it really hard to anticipate what a model might find useful to accomplish a task, and being too prescriptive can break them out of loops where they'd otherwise self-correct. We ran into this with our original MCP approach, which framed access to marimo state as discrete tools (list_cells, read_cell, etc.). But there was a long tail of more tools we kept needing, and behind the scenes they were all just Python functions exposing marimo's state. That was the insight: just let the model write Python directly.

So generally my hesitation with a proxy layer is that it risks boxing the agent in. A mediated interface that helps today might become a constraint tomorrow as models get more capable.

One of the authors here, happy to answer questions.

Building pair has been a different kind of engineering for me. Code mode is not a versioned API. Its consumer is a model, not a program. The contract is between a runtime and something that reads docs and reasons about what it finds.

We've changed the surface several times without migrating the skill. The model picks up new instructions and discovers its capabilities within a session, and figures out the rest.

Thank you! We're excited about it. LSP opens the door for us to gradually provide marimo features in whatever form makes sense for a particular env, allowing more folks collaborate on notebooks.