INITIALIZE · SERVE · DRAIN
Agent runtime capacity: every invocation needs an owner
Follow worker lifecycles and the invocations they own. Test readiness, shutdown deadlines and the point at which results commit.
Scroll the worker lanes horizontally. The worker inspector, sums and event trace below provide the same states as text.
Worker and invocation inspector
Committed-output fixture
Completed sums remain visible after a worker exits. This represents an external result store; browser reload does not persist it. Killed invocations have no committed output.
Recent lifecycle decisions
Your experiment
Start with one slot per worker. Compare one versus four slots while holding request duration fixed. Count completed, rejected and killed invocations separately. More slots do not remove startup delay or make graceful shutdown automatic.
Exactly what runs
Requests arrive from t = 1 s through t ≤ 40 s, at the selected interval. Each carries [request number, 1, 2]. The host assigns a free slot and models three equal-duration stages: prepare, model, tool. No AI is called. At completion, actual JavaScript addition computes and commits the sum. Each invocation owns one slot until it completes or its process is killed.
Ready-only routing picks the least-loaded ready worker, with worker ID as a deterministic tie-break. Without that guard it also considers starting and draining workers; those reject the request. There is no admission queue, retry, autoscaler or state transfer. A replacement is a single scheduled boot, not automatic recovery based on load. Startup failure affects only worker 1.
At the signal time, an enabled handler withdraws readiness and drains existing work; an ignored signal leaves the application ready until forced stop. A drained process exits immediately. At a shared timestamp, completions happen before readiness changes, termination and new admission; completion exactly at a shutdown deadline therefore wins in this model. Time is evaluated in 0.1 s steps.
Fixture gate, not a certification
PASS requires zero killed or still-running invocations and a final rejection percentage no greater than the selected allowance. It says nothing about authentication, model quality, real provider SLOs, latency percentiles or production correctness.
Offline, deliberately bounded lifecycle model. It does not execute an ADK Runner, Java process, container, operating-system signal or cloud deployment. Model/tool stages illustrate ownership and timing, not provider computation. The configurable grace period and router are teaching controls, not promises about any cloud runtime. Cloud Run’s documented termination contract and ADK’s invocation event loop must be consulted separately for real implementations. Cloud Run container contract · ADK runtime event loop.
Measure slot capacity before changing traffic
The opening uses two workers with one invocation slot each, four seconds of startup and seven-second invocations. Seek to sixty seconds: ten of twenty arrivals commit, ten are rejected and none are killed. Increase Invocation slots per worker to two while holding the other inputs fixed; inspect the new counts and the owned invocations in each lane. Raising slots models more admitted concurrency, not faster individual execution. Then increase Invocation duration and compare rejection pressure. Use Initial workers to distinguish adding a host from adding concurrency inside one host. Record all three outcomes separately: rejecting before admission is different from killing admitted work.
Trace ownership and actual output
Initial workers creates one to four workers, and Invocation slots per worker limits each worker to one to four simultaneous requests. Startup duration delays eligibility. Request interval schedules arrivals at one second and then regularly through forty seconds inclusive. Invocation duration holds each admitted slot through three illustrative stages: prepare, model and tool. At completion, JavaScript actually adds the request number, one and two. Seek to eight seconds after Common baseline settings and set startup to zero: request 1 has committed the sum four. Before completion its output is absent. These stage names do not represent real model or tool calls. There is no queue, retry, autoscaler, CPU contention or service-time slowdown as slots increase.
Withdraw readiness before draining
Route only to ready workers chooses the least-loaded ready worker, breaking ties by worker ID. Without it, starting or draining workers remain candidates and reject requests even when another worker could serve them. Fail initialization of worker 1 affects only that original worker. Signal worker 1 at chooses the termination time; Handle SIGTERM and stop admission changes that worker to draining. It accepts no new work and exits as soon as its current invocations finish. Grace period sets a forced-stop deadline. Without the handler, the worker stays eligible until that deadline and may admit requests that it cannot finish. Boot one replacement at signal time schedules one new worker with the same startup delay. It does not recover killed requests or replace every failed worker.
Account for every request
At every snapshot, arrivals equal admitted plus rejected. Admitted equals completed plus killed plus running. A killed request has no committed sum; completed sums remain in an external-store fixture after the owning worker exits. Reload does not persist that store. At equal timestamps, completion happens first, then readiness, signal and forced stop, and finally new admission. Therefore a completion exactly at the shutdown deadline wins here; real deployments need their own concurrency contract. The simulation uses tenth-second snapshots and stops at sixty seconds, after the last possible accepted request can finish. Fixture rejection allowance changes only the pass/fail threshold. Any killed or still-running invocation always fails the gate even at a one-hundred-percent rejection allowance.
Inspect time and worker state
Play runs sixty inspectable seconds at normal speed; Pause freezes time, and Play after completion replays from zero. Step 1 second advances to the next whole-second boundary and pauses. Restart preserves parameters and speed while returning to zero. Simulation time seeks directly and pauses. Speed provides quarter, half, normal and double pace; changing it settles elapsed time at the previous rate. A hidden tab pauses. Changing any model parameter rebuilds the plan and pauses at zero. Common baseline settings restores the shared model defaults, which differ from each page opening. Choose worker provides keyboard access to the same inspection as clicking its diagram lane. A replacement selected before its boot time has no state yet. Expand experiment changes the view; Exit full screen restores it.
Record evidence and understand the scope
Capture baseline saves the selected result and inputs; Replace baseline updates that comparison and Clear baseline removes it. Notes remain in this browser and Export notes downloads them. Scroll the diagram horizontally on phones, or focus its labeled region and use arrow keys. The worker inspector, committed sums and event trace provide text alternatives. The full-run preview intentionally exposes the eventual counts. This is a bounded teaching host, not an ADK Runner, Java process, operating-system signal, load balancer or cloud deployment. Grace and routing are configurable lesson assumptions, not provider guarantees. The fixture gate measures request accounting and the chosen rejection budget; it does not establish production availability, model quality, tenant isolation or real latency.