@prohost/cli 0.4.2 → 0.6.0

package/CHANGELOG.md

@@ -4,6 +4,105 @@ Versions follow [semver](https://semver.org/). Publishing is automated: merging
 a version bump to `main` triggers `.github/workflows/npm-publish-cli.yml`, which
 builds via `prepack`, runs the suite, publishes, and tags `cli-v<version>`.
 
+## 0.6.0
+
+ProhostAI can now show which runtime, model and machine a paired AI employee
+runs on, and how much of the operator's Claude or Codex subscription is left.
+
+- **A `runtime_status` frame.** When — and only when — the server lists
+  `runtime_status` in `auth_ok.features`, `agent run` reports its runtime
+  (`claude_code`, `codex`, `goose` or `custom`), the agent CLI's version, the
+  model, the plan (`Claude Max`, `ChatGPT Pro`, …) and the 5-hour and weekly
+  capacity windows as percentages with reset times. It is sent on connect,
+  every five minutes, and promptly when the model or plan changes or capacity
+  crosses 75% / 100% — never more than once per 31 s. An older server gets
+  nothing new.
+- **Your login never leaves this machine, and the CLI never reads it.** The
+  numbers come from the agent CLI answering with its own credentials: Claude
+  Code's own `stream-json` output (`system/init`, `rate_limit_event`) and, when
+  idle, its `get_usage` control request (no model turn, no quota spent); Codex's
+  per-thread rollout file under `$CODEX_HOME/sessions` and, when idle,
+  `codex app-server`'s `account/rateLimits/read`. The Claude Code keychain item
+  and `~/.codex/auth.json` are never opened, and account ids, emails and org
+  names are never forwarded. Anything unknown is omitted, never sent as zero.
+- **The model on completion.** `POST /v1/agent-runs/{id}/complete` now carries
+  `model` when the harness knows it (Claude Code's `system/init.model`, Codex's
+  rollout `turn_context.model`), so a reply can say which model wrote it. A
+  plain `--exec` command's completion body is unchanged.
+
+## 0.5.0
+
+A paired agent can no longer sit on a dead socket believing it is connected.
+
+- **The failure.** One daemon (`agent run` under launchd) was "connected" for
+  three weeks and received nothing. The server had closed the socket on
+  2026-08-11 — the laptop was almost certainly asleep, the FIN never arrived —
+  and the client kernel kept the TCP connection in `ESTABLISHED`. The CLI only
+  ever reacted to `close` and `error`, answered pings with pongs, and had no
+  deadline of its own, so from where it stood the connection was open, quiet,
+  and fine. The server pings every 30 s and reaps after 60 s without a pong;
+  that contract only helps when the close actually reaches the client, and on
+  a half-open socket it never does. Nothing on either side had a reason to
+  say anything.
+- **Client-side liveness watchdog.** Every frame the server sends — pings
+  included — is proof of life. Ninety seconds without one (three missed pings,
+  comfortably past the server's own reaper) means the connection is dead
+  whatever the kernel thinks: the CLI logs
+  `… no server ping for 90s — reconnecting`, tears the socket down with
+  `terminate()` (not `close()`, whose handshake would wait on a peer that is
+  not there), and the ordinary backoff-and-reconnect path runs. `listen` has
+  the same deadline; it has no reconnect loop, so it ends the session with
+  `… no server ping for 90s — connection lost` rather than a counter that
+  quietly stopped moving. The timer dies with the socket, so a reconnect never
+  inherits the previous socket's silence.
+- **TCP keepalive.** Switched on for the connection under the websocket, with
+  a 30 s idle delay, as a kernel-level probe underneath the application-level
+  one. Guarded: a `ws` build that hides its socket, or none at all, simply
+  gets no keepalive rather than a crash on `open`.
+- **A heartbeat in the log.** Every five minutes while connected, `agent run`
+  writes `● connected — last server ping Ns ago`. A stalled daemon now looks
+  different in `agent.log` from a healthy quiet one.
+- **The build reports itself.** The websocket auth frame carries
+  `client_version` (this build's version) alongside `api_key` / `machine` /
+  `subscription_id`, and the upgrade request sends `User-Agent:
+  prohost-cli/<version>` like every HTTP call already did. The failing daemon
+  was two minor versions behind npm the whole time and nobody could tell.
+- **An upgrade notice.** At `agent run` startup the CLI asks the npm registry
+  for the latest version, with a 3 s budget, and prints
+  `⬆ @prohost/cli <latest> is available (running <current>) — npm i -g @prohost/cli`
+  when there is one. It is not awaited and cannot fail startup: a slow, down,
+  or nonsensical registry prints nothing.
+- **A stalled handshake is bounded too.** The deadline only starts at `open`,
+  and `ws` has no handshake timeout by default, so `agent run` now gives the
+  handshake 30 s — the same asleep-laptop failure, one step earlier.
+
+A slow reply is no longer reported as a failed run.
+
+- **The second failure, seen the moment the daemon reconnected.** The reply
+  `POST /v1/conversations/{id}/messages` took the server **51,216 ms** and
+  returned 202 — the message was saved — but the CLI had abandoned the request
+  at its 30 s deadline, logged `✗ run … reply rejected (HTTP 0) This operation
+  was aborted`, and completed the run as failed. The server then posted a
+  "picked this up but its run failed — posting the reply failed with HTTP 0"
+  note directly under an answer that had in fact landed. Two consecutive runs.
+  The slow send path is being fixed server-side; this release stops the client
+  turning a slow success into a reported failure.
+- **120 s for the reply and the completion.** Cheap calls (heartbeats) keep
+  30 s. Four times the observed latency is the margin.
+- **No answer is not a failure — replay with the same key.** The reply POST
+  was already keyed on the run id (`Idempotency-Key: prohost-cli-run-<run_id>`),
+  which is exactly what makes asking again safe. On a timeout or a network
+  error the CLI now logs `… reply POST timed out after 120s — replaying with
+  the same idempotency key` and sends the byte-identical request once more.
+  The server answers with the cached response of the attempt that landed
+  (`✓ reply confirmed on replay`), or with `409 idempotency_key_in_flight` if
+  the first attempt is still being processed — in which case the CLI waits
+  5 s and replays once more. Only a definitive answer, or a second transport
+  failure, reports the run as failed, and it does so exactly once.
+- **`HTTP 0` is gone from the log.** A request with no response now says why:
+  `timed out after 120s` or `network error: <cause>`, in the log line and in
+  the failure reason the server shows in the thread.
+
 ## 0.4.2
 
 Isolated Codex runs no longer receive the operator's **apps (connectors)**.

package/README.md

@@ -428,6 +428,20 @@ your agent a second time. That matters because your agent holds a credential:
 a second execution could file the same task or send the same email again, which
 no amount of message deduplication would undo.
 
+### What ProhostAI sees about your runtime
+
+When the server supports it, `agent run` reports which runtime it drives
+(Claude Code, Codex, goose or a custom command), that CLI's version, the model,
+your plan's name, and how much of your 5-hour and weekly capacity is used, as
+percentages with reset times. ProhostAI shows this next to the AI employee.
+
+Your Claude or Codex login never leaves your machine, and `prohost` never reads
+it: the numbers come from the agent CLI's own output (Claude Code's
+`stream-json` events, Codex's session rollout files) or from asking the
+unmodified CLI through its own protocol (`get_usage`,
+`codex app-server`), which answers with its own login. Account ids, emails and
+org names are never sent.
+
 ### The trust model — read this once
 
 `agent run` is a standing instruction to execute a command on your machine when
@@ -525,6 +539,16 @@ On macOS this writes a launchd agent to
 `$PROHOST_HOME/agent.log` — the first place to look when the agent is quiet.
 Re-running it with a different `--exec` replaces the old daemon.
 
+**It notices when the connection dies, even when the network doesn't say so.**
+The server pings every 30 seconds. If no frame of any kind arrives for 90
+seconds — a laptop that slept through the server closing the socket looks
+exactly like this — the CLI logs `… no server ping for 90s — reconnecting`,
+drops the socket and reconnects with backoff. While connected it writes
+`● connected — last server ping Ns ago` every five minutes, so a healthy quiet
+daemon and a stalled one read differently in `agent.log`. At startup it also
+checks npm and prints one line if a newer `@prohost/cli` exists; the check
+never delays or fails the connection.
+
 The daemon is scoped to `$PROHOST_HOME`, because that's where the one credential
 lives: installing twice from the same home replaces the daemon rather than
 adding a second one. To run two agents on one machine, give each its own

package/dist/agent/api.d.ts

@@ -13,13 +13,23 @@ export interface ApiOptions {
     baseUrl: string;
     apiKey: string;
     fetchImpl?: typeof fetch;
-    /** Per-request timeout. Defaults to 30 seconds. */
+    /**
+     * Per-request timeout override, applied to every call. Unset, each call
+     * uses its own default — {@link DEFAULT_TIMEOUT_MS} for the cheap ones,
+     * {@link SEND_TIMEOUT_MS} for the reply and the completion.
+     */
     timeoutMs?: number;
 }
 export interface ApiResult {
     ok: boolean;
+    /** HTTP status, or ``0`` when no response arrived at all — see ``failure``. */
     status: number;
     error?: string;
+    /**
+     * Why ``status`` is ``0``: the request was abandoned at its deadline, or the
+     * network failed before any status came back. Absent on every real response.
+     */
+    failure?: 'timeout' | 'network';
     /**
      * The response body, when the caller asked for it.
      *
@@ -28,6 +38,35 @@ export interface ApiResult {
      */
     body?: string;
 }
+/** Deadline for the cheap calls — a heartbeat answers in milliseconds. */
+export declare const DEFAULT_TIMEOUT_MS = 30000;
+/**
+ * Deadline for the reply POST and the completion.
+ *
+ * Thirty seconds was not enough. On 2026-09-01 the server took 51,216 ms to
+ * accept a reply (``POST /v1/conversations/{id}/messages`` → 202): the
+ * message was saved, but the CLI had already abandoned the request at 30 s,
+ * logged the reply as rejected, and completed the run as failed — so the
+ * server posted a "run failed" note under an answer that had in fact landed.
+ * Twice in a row. The slow send path is being fixed server-side; the client's
+ * job is to not turn a slow success into a reported failure, and four times
+ * the observed latency is the margin for that.
+ */
+export declare const SEND_TIMEOUT_MS = 120000;
+/**
+ * One line a person can act on for a failed result: ``HTTP 503``, ``timed
+ * out after 120s``, ``network error: ECONNRESET``. ``HTTP 0`` told nobody
+ * anything, and it was the only thing the log said for the whole of the
+ * 30-second-timeout incident.
+ */
+export declare function describeFailure(result: ApiResult): string;
+/**
+ * The server's "same key, same body, the first attempt is still being
+ * processed" answer (``api_public/middleware/idempotency.py``). A replay that
+ * gets this should wait and replay again — the original will finish and be
+ * cached, and the next replay receives its response.
+ */
+export declare function isIdempotencyInFlight(result: ApiResult): boolean;
 /**
  * Post the agent's reply into the conversation that triggered the run.
  *
@@ -69,6 +108,7 @@ export type HeartbeatOutcome =
     kind: 'error';
     status: number;
     detail?: string;
+    failure?: ApiResult['failure'];
 };
 /**
  * Tell the server a run is still being worked on, and ask whether it should be.
@@ -89,10 +129,13 @@ export declare function heartbeatRun(options: ApiOptions, path: string, progress
  * A ``409`` is reported as success: it means the run already reached a terminal
  * state (a redelivery we raced, or the 2h stale-run sweeper got there first).
  * Treating that as a failure would only produce noise about work that is done.
+ *
+ * ``model`` is the model id the run used, when the harness knows it. Omitted
+ * otherwise, so a plain ``--exec`` command's completion body is unchanged.
  */
 export declare function completeRun(options: ApiOptions, path: string, outcome: {
     ok: true;
 } | {
     ok: false;
     error: string;
-}): Promise<ApiResult>;
+}, model?: string): Promise<ApiResult>;

package/dist/agent/api.js

@@ -10,14 +10,53 @@
  * `completion.path`), which is why these take a path rather than building one.
  */
 import { USER_AGENT } from '../version.js';
-import { MAX_ERROR_CHARS, MAX_PROGRESS_CHARS, RUN_STATUS_FAILED, RUN_STATUS_SUCCEEDED, } from './contract.js';
-const DEFAULT_TIMEOUT_MS = 30_000;
+import { MAX_ERROR_CHARS, MAX_MODEL_CHARS, MAX_PROGRESS_CHARS, RUN_STATUS_FAILED, RUN_STATUS_SUCCEEDED, } from './contract.js';
+/** Deadline for the cheap calls — a heartbeat answers in milliseconds. */
+export const DEFAULT_TIMEOUT_MS = 30_000;
+/**
+ * Deadline for the reply POST and the completion.
+ *
+ * Thirty seconds was not enough. On 2026-09-01 the server took 51,216 ms to
+ * accept a reply (``POST /v1/conversations/{id}/messages`` → 202): the
+ * message was saved, but the CLI had already abandoned the request at 30 s,
+ * logged the reply as rejected, and completed the run as failed — so the
+ * server posted a "run failed" note under an answer that had in fact landed.
+ * Twice in a row. The slow send path is being fixed server-side; the client's
+ * job is to not turn a slow success into a reported failure, and four times
+ * the observed latency is the margin for that.
+ */
+export const SEND_TIMEOUT_MS = 120_000;
 /** Cap on a captured response body. Every one we parse is a small object. */
 const MAX_BODY_CHARS = 2_000;
-async function post(options, path, body, idempotencyKey, captureBody = false) {
+/**
+ * One line a person can act on for a failed result: ``HTTP 503``, ``timed
+ * out after 120s``, ``network error: ECONNRESET``. ``HTTP 0`` told nobody
+ * anything, and it was the only thing the log said for the whole of the
+ * 30-second-timeout incident.
+ */
+export function describeFailure(result) {
+    if (result.failure === 'timeout')
+        return result.error ?? 'timed out';
+    if (result.failure === 'network')
+        return `network error: ${result.error ?? 'unknown'}`;
+    if (result.status === 0)
+        return `network error: ${result.error ?? 'unknown'}`;
+    return `HTTP ${result.status}`;
+}
+/**
+ * The server's "same key, same body, the first attempt is still being
+ * processed" answer (``api_public/middleware/idempotency.py``). A replay that
+ * gets this should wait and replay again — the original will finish and be
+ * cached, and the next replay receives its response.
+ */
+export function isIdempotencyInFlight(result) {
+    return result.status === 409 && (result.error ?? '').includes('idempotency_key_in_flight');
+}
+async function post(options, path, body, idempotencyKey, captureBody = false, timeoutMs = DEFAULT_TIMEOUT_MS) {
     const fetchImpl = options.fetchImpl ?? fetch;
     const controller = new AbortController();
-    const timer = setTimeout(() => controller.abort(), options.timeoutMs ?? DEFAULT_TIMEOUT_MS);
+    const deadlineMs = options.timeoutMs ?? timeoutMs;
+    const timer = setTimeout(() => controller.abort(), deadlineMs);
     try {
         const response = await fetchImpl(`${options.baseUrl.replace(/\/+$/, '')}${path}`, {
             method: 'POST',
@@ -46,9 +85,22 @@ async function post(options, path, body, idempotencyKey, captureBody = false) {
         return { ok, status: response.status, error, body: captureBody ? text : undefined };
     }
     catch (err) {
+        // Our own deadline fired: `fetch` rejects with an AbortError, whose
+        // message ("This operation was aborted") names neither the cause nor the
+        // duration. Say both.
+        const abortError = err instanceof Error && err.name === 'AbortError';
+        if (controller.signal.aborted || abortError) {
+            return {
+                ok: false,
+                status: 0,
+                failure: 'timeout',
+                error: `timed out after ${Math.round(deadlineMs / 1000)}s`,
+            };
+        }
         return {
             ok: false,
             status: 0,
+            failure: 'network',
             error: err instanceof Error ? err.message : String(err),
         };
     }
@@ -72,7 +124,9 @@ export async function postReply(options, path, bodyKey, message, runId, extra) {
     // `extra` first, so the message can never be clobbered by a `body_extra` key
     // that happens to collide with the body field. The reply text is the one
     // thing in this request that must survive.
-    return post(options, path, { ...extra, [bodyKey]: message }, `prohost-cli-run-${runId}`);
+    // Byte-identical on every attempt: the server hashes the body against the
+    // key, so a replay must serialise exactly as the original did.
+    return post(options, path, { ...extra, [bodyKey]: message }, `prohost-cli-run-${runId}`, false, SEND_TIMEOUT_MS);
 }
 function booleanField(body, key) {
     if (!body)
@@ -107,7 +161,7 @@ export async function heartbeatRun(options, path, progress) {
         return { kind: 'unknown' };
     if (result.status === 409)
         return { kind: 'resolved' };
-    return { kind: 'error', status: result.status, detail: result.error };
+    return { kind: 'error', status: result.status, detail: result.error, failure: result.failure };
 }
 /**
  * Report a run's terminal state. Called for every run — including one whose
@@ -116,12 +170,17 @@ export async function heartbeatRun(options, path, progress) {
  * A ``409`` is reported as success: it means the run already reached a terminal
  * state (a redelivery we raced, or the 2h stale-run sweeper got there first).
  * Treating that as a failure would only produce noise about work that is done.
+ *
+ * ``model`` is the model id the run used, when the harness knows it. Omitted
+ * otherwise, so a plain ``--exec`` command's completion body is unchanged.
  */
-export async function completeRun(options, path, outcome) {
+export async function completeRun(options, path, outcome, model) {
     const body = outcome.ok
         ? { status: RUN_STATUS_SUCCEEDED }
         : { status: RUN_STATUS_FAILED, error: outcome.error.slice(0, MAX_ERROR_CHARS) };
-    const result = await post(options, path, body);
+    if (model)
+        body.model = model.slice(0, MAX_MODEL_CHARS);
+    const result = await post(options, path, body, undefined, false, SEND_TIMEOUT_MS);
     if (result.status === 409)
         return { ...result, ok: true };
     return result;

package/dist/agent/claude.d.ts

@@ -15,6 +15,7 @@
  * happens and still completes. These are enhancements that must fail soft.
  */
 import { MCP_SERVER_NAME } from './mcp.js';
+import type { RuntimeObservation } from './runtime_status.js';
 export { MCP_SERVER_NAME };
 /**
  * What goes to `--allowedTools` so the ProhostAI tools are callable.
@@ -151,6 +152,12 @@ export interface ClaudeStream {
     activity(): string | undefined;
     /** The tail of the last thing the agent wrote, for a run that was killed. */
     salvage(): string | undefined;
+    /**
+     * Model, Claude Code version and capacity windows the stream announced —
+     * `system/init.{model, claude_code_version}` and the last
+     * `rate_limit_event`. Fields the stream never mentioned are absent.
+     */
+    observed(): RuntimeObservation;
     /**
      * The turn's outcome. ``stdout`` is the complete captured output, used only
      * when the stream held no `result` event — a crashed binary, a login prompt,

package/dist/agent/claude.js

@@ -18,6 +18,7 @@ import { chmodSync, mkdirSync, writeFileSync } from 'node:fs';
 import path from 'node:path';
 import { prohostHome } from './credentials.js';
 import { MCP_SERVER_NAME } from './mcp.js';
+import { fromClaudeRateLimitInfo } from './runtime_status.js';
 import { SHELL_CONTROL_OPERATORS, shellQuote } from './shell.js';
 export { MCP_SERVER_NAME };
 /**
@@ -315,10 +316,21 @@ export function readClaudeStream() {
     let lastActivity;
     let lastText;
     let result;
+    const observed = {};
     const handle = (line) => {
         const event = asObject(line);
         if (!event)
             return;
+        if (event.type === 'system' && event.subtype === 'init') {
+            observed.model = text(event.model) ?? observed.model;
+            observed.runtime_version = text(event.claude_code_version) ?? observed.runtime_version;
+        }
+        else if (event.type === 'rate_limit_event') {
+            // Last one wins; absent for API-key / Bedrock / Vertex sessions.
+            const windows = fromClaudeRateLimitInfo(event.rate_limit_info);
+            if (windows.length > 0)
+                observed.quota_windows = windows;
+        }
         // Present on the `system`/`init` event, and repeated on most others. Taken
         // from whichever arrives first — they all name the same session.
         if (!session)
@@ -359,6 +371,7 @@ export function readClaudeStream() {
         },
         sessionId: () => session,
         activity: () => lastActivity,
+        observed: () => ({ ...observed }),
         salvage: () => {
             const trimmed = lastText?.trim();
             if (!trimmed)

package/dist/agent/command.js

@@ -13,6 +13,7 @@ import { agentLogPath, buildSystemdUnit, harnessArguments, installLaunchdDaemon,
 import { PairError, runPair } from './pair.js';
 import { CredentialsMissingError, ensureWorkspace, loadCredentials, prohostHome } from './credentials.js';
 import { DEFAULT_EXEC_TIMEOUT_MS, DEFAULT_IDLE_TIMEOUT_MS, runAgentHarness } from './run.js';
+import { announceUpgradeIfAvailable } from '../upgrade.js';
 function flagString(flags, name) {
     const value = flags[name];
     return typeof value === 'string' ? value : undefined;
@@ -306,6 +307,9 @@ async function runCommand(flags) {
     };
     process.on('SIGINT', onSig);
     process.on('SIGTERM', onSig);
+    // Deliberately not awaited: the registry lookup must never delay or fail the
+    // connection. It prints one line if a newer build exists and nothing else.
+    void announceUpgradeIfAvailable((line) => process.stdout.write(`${line}\n`));
     try {
         const metrics = await runAgentHarness({
             exec,

package/dist/agent/contract.d.ts

@@ -29,6 +29,8 @@ export declare const RUN_STATUS_SUCCEEDED = "succeeded";
 export declare const RUN_STATUS_FAILED = "failed";
 /** Server-side cap on the `error` field of a completion (`MAX_ERROR_CHARS`). */
 export declare const MAX_ERROR_CHARS = 1000;
+/** Server-side cap on the `model` field of a completion (`MAX_MODEL_CHARS`). */
+export declare const MAX_MODEL_CHARS = 100;
 /**
  * The completion `error` that means "a person asked for this run to stop".
  *

package/dist/agent/contract.js

@@ -29,6 +29,8 @@ export const RUN_STATUS_SUCCEEDED = 'succeeded';
 export const RUN_STATUS_FAILED = 'failed';
 /** Server-side cap on the `error` field of a completion (`MAX_ERROR_CHARS`). */
 export const MAX_ERROR_CHARS = 1000;
+/** Server-side cap on the `model` field of a completion (`MAX_MODEL_CHARS`). */
+export const MAX_MODEL_CHARS = 100;
 /**
  * The completion `error` that means "a person asked for this run to stop".
  *

package/dist/agent/heartbeat.js

@@ -21,7 +21,7 @@
  *   failure mode — an old server that 404s, a dropped network, a handler that
  *   throws — costs at most the beat it happened on.
  */
-import { heartbeatRun } from './api.js';
+import { describeFailure, heartbeatRun } from './api.js';
 /**
  * How often each open run is reported.
  *
@@ -154,8 +154,9 @@ export class HeartbeatLoop {
             // Transient by assumption: keep the cadence rather than give up on the
             // run. A run whose beats all fail is reaped server-side eventually, which
             // is the correct end state for a machine that cannot reach the API.
-            this.options.log(`    ! heartbeat for run ${target.runId.slice(0, 12)} failed (HTTP ${outcome.status})` +
-                `${outcome.detail ? ` ${outcome.detail}` : ''}`);
+            this.options.log(`    ! heartbeat for run ${target.runId.slice(0, 12)} failed ` +
+                `(${describeFailure({ ok: false, status: outcome.status, error: outcome.detail, failure: outcome.failure })})` +
+                `${outcome.status !== 0 && outcome.detail ? ` ${outcome.detail}` : ''}`);
         }
         catch (err) {
             this.options.log(`    ! heartbeat for run ${target.runId.slice(0, 12)} threw: ` +

package/dist/agent/run.d.ts

@@ -25,6 +25,7 @@
 import type { spawn } from 'node:child_process';
 import WebSocket from 'ws';
 import type { AgentCredentials } from './credentials.js';
+import type { QuotaProvider } from './runtime_status.js';
 /**
  * Default ceiling on one agent invocation: none.
  *
@@ -121,6 +122,22 @@ export interface AgentRunOptions {
      * inside a test's lifetime.
      */
     heartbeatIntervalMs?: number;
+    /**
+     * How long the server may go silent before the socket is torn down and
+     * reconnected. Defaults to {@link PING_LIVENESS_MS}; tests shorten it.
+     */
+    livenessTimeoutMs?: number;
+    /**
+     * How often a connected harness logs that it is still connected. Defaults
+     * to {@link HEARTBEAT_LOG_INTERVAL_MS}; tests shorten it.
+     */
+    heartbeatLogIntervalMs?: number;
+    /**
+     * Where idle capacity numbers come from (see `runtime_status.ts`). Defaults
+     * to asking the detected agent CLI itself; `null` disables idle refresh.
+     * Tests inject a fake so no real `claude` / `codex` is spawned.
+     */
+    quotaProvider?: QuotaProvider | null;
 }
 export interface AgentRunMetrics {
     connections: number;
@@ -134,6 +151,8 @@ export interface AgentRunMetrics {
     ignored: number;
     /** Repeat deliveries of a run already handled this session. */
     duplicates: number;
+    /** Sockets torn down locally because the server went silent past the liveness window. */
+    livenessTimeouts: number;
     /**
      * Set when the harness stopped for a reason retrying can't fix (a rejected
      * credential). The CLI exits nonzero on it, so a service manager doesn't