omrimaya

The capability-based permission propagation is the part I'd want to stress-test first, in practice we found that the interesting failure mode isn't the agent escaping its sandbox, it's the agent calling back into the host in ways that are technically permitted but semantically wrong

The "infrastructure instead of a library" pattern is everywhere in the LLM tooling space right now. We went through the same decision point, stood up LiteLLM, ran it for a week, then ripped it out because the operational surface wasn't worth it for something that's really just a retry loop with state. The cooldown tiers make sense; the one thing I'd watch is key exhaustion behavior when all profiles are in backoff simultaneously, does it block or surface an error immediately?

The design decision I find most interesting here is ephemeral-by-default with opt-in checkpointing, that inversion of the usual "persist everything, clean up manually" model fits agent code execution well. Most sandboxing approaches I've seen treat isolation as the hard problem, but state leakage across runs is the subtler foot-gun when you're executing LLM-generated code repeatedly.

One thing I ran into building agent infrastructure: the boundary between "sandbox that runs code" and "agent that decides what code to run" wants to be a clean HTTP interface, not a library call. Makes it easier to audit what crossed the boundary. Does Shuru expose any hook for streaming stdout back to the caller during execution, or is it strictly "wait for exit, get result"?