sebastienburel

How does hibernation decide an actor is idle? In my agent runtime actors run in XS. Messages are queued and only handled once the current handler returns, so a synchronous handler is never cut in half. But while a handler waits on an async call, an HTTP request say, other messages still get handled. So “no message being processed” isn’t the same as “nothing in flight”. Does Rivet hibernate an actor with an outstanding request, and if so, what happens when the response comes back?

To your question about how we track ours: one failure I had left no trace at all. A morning run on a resident agent just didn’t happen. The host timer runs on the uptime clock, the Mac slept through the slot, and nothing retries. As far as I can tell from the post, Signals reads traces that exist. Do you do anything for the run that should have happened and didn’t, like diffing against an expected schedule?

On a Mac the baseline I'd want is MLX, not llama.cpp. llama.cpp isn't the fast path on Apple Silicon for most models people run locally, so a speedup over llama.cpp could still be slower than mlx_lm. Do you have that number?

Second, more important for agents: decode speed is rarely what hurts. It's resending the same system prompt plus tool schemas every turn. Does self-optimizing cover prefix cache reuse across requests, or is it kernel and layout tuning only?

And is the endpoint OpenAI-compatible? My runtime already talks to llama.cpp and LM Studio through that wrapper, so drop-in is the difference between trying it tonight and not.

The channel is always whatever primitive was left in the sandbox, not the one you thought you were guarding. Block fetch and the model finds the resolver. Block the resolver and something else is still leaking bits.

In my runtime the agent has no fetch, no fs, no require, only a host.* surface. The HTTP tool refuses any host not on its allow-list, so a disallowed name never gets looked up. But the shell tool is opt-in, and the moment you turn it on you have handed over dig, and the HTTP allow-list no longer matters. The only version that holds is the one where the capability isn't there.

Thanks! Did you try it? Curious what you'd build with it

Peter Hoddie from Moddable (XS's home) wrote about KaozKit today from the engine side, including why there is nothing to sandbox: https://moddable.com/blog/kaozkit/

The hard part for an always-on company agent is what survives a restart. My runtime snapshots the whole JS heap to bytes and restores it in a fresh process, so conversation and working state come back with no serialization code — but timers don't survive, so an agent re-arms them from declarative state after restore. How do you handle that? Is a long-lived agent's state checkpointed, or rebuilt by replaying context on each wake?