Cool! Dumb question, but do prepaid credits ever expire? Feels like the interest only matters if they don't.
48 karma · joined November 6, 2018
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.
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.
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!
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.
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.