Context
We're evaluating AX + Agent Substrate (self-hosted on Kubernetes, the recommended production path) as the runtime for coding agents. What drew us here is exactly the density story: we want a small fleet of machines to serve the coding-agent needs of a large number of users, and AX + Substrate's suspend/resume model looks like a great fit for that — an idle user's actor gives its worker back, so a handful of nodes can back many more users than they could concurrently host. That part is very appealing.
Our workload is mixed: both interactive (a user chatting with a coding agent, one message = one turn, and they're actively waiting on the reply) and asynchronous (scheduled tasks where nobody is watching and only the final result matters).
Everything below is a design-intent question, not a bug report — we want to understand whether the current lifecycle behavior is the intended design point before we build anything around it, so we don't fork or fight the framework.
What we observe
On the Substrate harness, each turn ends with substrateExecution.Close() unconditionally calling SuspendActor (external snapshot), and the next turn begins with ResumeActor. So every single turn closes the actor, and the next one has to resume it — even in an active session where the user sends the next message a second or two later.
For our async tasks this is exactly right, and it's the density win we came for — an actor that finishes and sits idle for minutes/hours should release its worker. The friction shows up in the interactive path: for short tasks where a person is right there waiting to drive the next turn, closing the actor after every turn and resuming it on the next makes the back-and-forth feel slow, because each reply pays a fresh resume before it can start. (We're still segmenting the exact breakdown on our side — this issue is about the design intent, not asking you to explain our numbers.)
The question
Reading the README History section, the stated rationale for suspend/resume is long idle periods:
"An agent might compute intensively for a minute, then sit idle for hours or days awaiting human approval. Keeping a stateful actor active during these long idle periods is highly inefficient and cost-prohibitive at scale."
That rationale (avoid keeping actors warm during long idle) makes complete sense to us. What we'd like to understand is the granularity:
-
Is per-turn suspension the intended design point, or is it more of a current implementation choice in the Substrate harness (Close() → SuspendActor) that happens to be the simplest correct behavior? The README motivates suspension for "hours or days" of idleness, but the implementation suspends at the seconds-scale gap between consecutive turns in an active session too.
-
Is there any intent to make suspension policy idle-aware or configurable — e.g. keep an actor warm while a session is actively producing turns, and only suspend after a configurable idle threshold (which would still aggressively suspend the long-idle / awaiting-approval case the README targets, and the async case, while avoiding churn during active back-and-forth)? We'd envision this as an opt-in knob owned by the deployer, consistent with AX being self-hosted and "not a managed service."
-
Related, is PauseActor (node-local snapshot / warm resume, as opposed to SuspendActor's external snapshot) considered part of the intended lifecycle toolkit for the "briefly idle but likely-to-continue" case, or is external suspend the only sanctioned path today?
Relationship to existing work
We see #268 (Integrate DurableDir) aimed at improving resumption performance, and the roadmap item "Improvements to resumption protocols." We read the official direction for latency as making resume cheaper rather than suspending less often — is that a fair reading? Even with a much cheaper resume, an active interactive session still pays the per-turn round-trip (new routable IP each turn, connection pools going stale — cf. the keep-alive workaround in #285, snapshot I/O). An idle-aware policy would remove that fixed cost during active sessions in a way cheaper-resume alone cannot. We'd like to understand how you see these two levers relating.
We'd really appreciate your read on whether idle-aware / configurable suspension is compatible with AX's goals, or whether per-turn suspend is a deliberate, load-bearing invariant we should design around instead. Happy to share our segmented latency measurements once we have them if that's useful input. Thanks!
Context
We're evaluating AX + Agent Substrate (self-hosted on Kubernetes, the recommended production path) as the runtime for coding agents. What drew us here is exactly the density story: we want a small fleet of machines to serve the coding-agent needs of a large number of users, and AX + Substrate's suspend/resume model looks like a great fit for that — an idle user's actor gives its worker back, so a handful of nodes can back many more users than they could concurrently host. That part is very appealing.
Our workload is mixed: both interactive (a user chatting with a coding agent, one message = one turn, and they're actively waiting on the reply) and asynchronous (scheduled tasks where nobody is watching and only the final result matters).
Everything below is a design-intent question, not a bug report — we want to understand whether the current lifecycle behavior is the intended design point before we build anything around it, so we don't fork or fight the framework.
What we observe
On the Substrate harness, each turn ends with
substrateExecution.Close()unconditionally callingSuspendActor(external snapshot), and the next turn begins withResumeActor. So every single turn closes the actor, and the next one has to resume it — even in an active session where the user sends the next message a second or two later.For our async tasks this is exactly right, and it's the density win we came for — an actor that finishes and sits idle for minutes/hours should release its worker. The friction shows up in the interactive path: for short tasks where a person is right there waiting to drive the next turn, closing the actor after every turn and resuming it on the next makes the back-and-forth feel slow, because each reply pays a fresh resume before it can start. (We're still segmenting the exact breakdown on our side — this issue is about the design intent, not asking you to explain our numbers.)
The question
Reading the README History section, the stated rationale for suspend/resume is long idle periods:
That rationale (avoid keeping actors warm during long idle) makes complete sense to us. What we'd like to understand is the granularity:
Is per-turn suspension the intended design point, or is it more of a current implementation choice in the Substrate harness (
Close()→SuspendActor) that happens to be the simplest correct behavior? The README motivates suspension for "hours or days" of idleness, but the implementation suspends at the seconds-scale gap between consecutive turns in an active session too.Is there any intent to make suspension policy idle-aware or configurable — e.g. keep an actor warm while a session is actively producing turns, and only suspend after a configurable idle threshold (which would still aggressively suspend the long-idle / awaiting-approval case the README targets, and the async case, while avoiding churn during active back-and-forth)? We'd envision this as an opt-in knob owned by the deployer, consistent with AX being self-hosted and "not a managed service."
Related, is
PauseActor(node-local snapshot / warm resume, as opposed toSuspendActor's external snapshot) considered part of the intended lifecycle toolkit for the "briefly idle but likely-to-continue" case, or is external suspend the only sanctioned path today?Relationship to existing work
We see #268 (Integrate DurableDir) aimed at improving resumption performance, and the roadmap item "Improvements to resumption protocols." We read the official direction for latency as making resume cheaper rather than suspending less often — is that a fair reading? Even with a much cheaper resume, an active interactive session still pays the per-turn round-trip (new routable IP each turn, connection pools going stale — cf. the keep-alive workaround in #285, snapshot I/O). An idle-aware policy would remove that fixed cost during active sessions in a way cheaper-resume alone cannot. We'd like to understand how you see these two levers relating.
We'd really appreciate your read on whether idle-aware / configurable suspension is compatible with AX's goals, or whether per-turn suspend is a deliberate, load-bearing invariant we should design around instead. Happy to share our segmented latency measurements once we have them if that's useful input. Thanks!