oira666_pi-limits-wait 0.5.3 → 0.5.5

package/README.md

@@ -1,149 +1,171 @@
-# Pi Limits Wait
-
-[![npm](https://img.shields.io/npm/v/oira666_pi-limits-wait?style=flat-square&logo=npm&logoColor=white&label=npm&color=7c3aed)](https://www.npmjs.com/package/oira666_pi-limits-wait) [![node](https://img.shields.io/badge/node-%3E%3D22.19-7c3aed?style=flat-square&logo=nodedotjs&logoColor=white)](https://nodejs.org)
-
-Pi extension that keeps requests alive when a provider rate-limits you or returns `server_is_overloaded`.
-
-## Install
-
-```bash
-pi install npm:oira666_pi-limits-wait
-```
-
-Restart Pi or run `/reload` after installing.
-
-## What it does
-
-- Targets Pi 0.80.10+ (developed and tested against Pi 0.83.0) and works with model providers that use `ModelRuntime.streamSimple`.
-- Intercepts the current runtime without registering synthetic providers; every retry and fallback re-enters Pi's normal provider/auth/base URL/configured-header composition, including OAuth refresh checks.
-- Reload-safe ownership ensures `/reload` transfers interception cleanly and aborts waits still owned by the previous extension instance. The interception has one process-global active extension owner, matching the interactive Pi CLI's single active session runtime lifecycle; SDK processes running multiple concurrent Pi sessions are not supported.
-- On rate-limit errors (`429`, `rate_limit`, `too many requests`, quota/reset messages), waits and retries in a loop.
-- Uses provider retry timing when exposed through response callbacks or provider errors (`retry-after`, `retry-after-ms`, `retry in ...`, reset messages).
-- If no retry timing is available for a rate limit, waits 30 minutes before retrying.
-- On `server_is_overloaded`, waits 5 minutes, then retries. If the provider is still overloaded after Pi's normal retries, it waits another 5 minutes and repeats.
-- On transient network/transport failures — including undici idle-timeout aborts (`UND_ERR_HEADERS_TIMEOUT` / `UND_ERR_BODY_TIMEOUT`), `fetch failed`, `terminated`, `ECONNRESET`, `ETIMEDOUT`, etc. — treats the error as retryable with a short backoff (default 15s, or the provider's `retry-after`) instead of giving up. This prevents a stalled streaming request from turning into a silent hang.
-- For any other (unclassified) provider error — including an API `Internal server error` and HTTP `400`/`403` failures — waits and retries the same model. There is deliberately no permanent-HTTP-status allowlist. This retry-all behavior is enabled by default and uses a configurable retry limit and interval; it does not alter model-limit wait intervals.
-- Reports retry/fallback waits in chat notifications without adding persistent TUI status lines.
-- Press Enter during a retry wait to skip the wait and retry immediately.
-- Optionally falls back to configured models when the current/default model is rate-limited. Every fallback to a different model—even on the same provider—deliberately discards request-owned credentials, headers, environment overrides, and provider-specific options so the target runtime resolves its own configuration.
-- Preserves Pi's `before_provider_request` / `after_provider_response` callback flow and sanitises only the exact Anthropic OAuth system-block shape generated by current Pi; Pi remains responsible for OAuth identity insertion.
-
-### Unsupported interception limitation
-
-Pi 0.83 has no public stream middleware that can intercept a failed provider stream, wait, and re-enter `ModelRuntime` for another attempt. For that reason, limits-wait still installs a reload-safe trampoline on `ModelRuntime.prototype.streamSimple`. This is an unsupported internal interception point and could require changes when Pi changes `ModelRuntime`; it also assumes the interactive CLI's one active session runtime per process. SDK processes with multiple concurrent Pi sessions are not supported.
-
-`after_provider_response` is preserved for observers, but it is not an equivalent retry hook: it cannot replace stream-error interception, own retry/fallback control flow, or recreate a complete target-model request. In particular, Pi 0.83 still does not expose a public factory for rebuilding the SDK's target-model-aware `transformHeaders` callback. Reusing the source request's closure on a fallback would apply source-model attribution and could leak extension-added headers, so limits-wait intentionally omits it for every different-model fallback. The target `ModelRuntime` still resolves target auth, base URL, configured provider/model headers, environment, and provider implementation canonically, but `before_provider_headers` cannot be re-fired for that fallback through the current public API.
-
-## Wait event contract
-
-Every positive extension-managed wait emits public telemetry on Pi's shared event bus. Import the channel constant and payload union from the package entry point:
-
-```ts
-import {
-  LIMITS_WAIT_EVENT_CHANNEL,
-  type LimitsWaitEventPayload,
-} from "oira666_pi-limits-wait";
-
-pi.events.on(LIMITS_WAIT_EVENT_CHANNEL, (data) => {
-  const event = data as LimitsWaitEventPayload;
-  // event.version === 1; event.phase is "start" or "end"
-});
-```
-
-The versioned, namespaced channel is `oira666.pi-limits-wait.wait.v1`. No event is emitted for a zero/negative-duration wait.
-
-Both phases contain:
-
-- `version: 1`, `phase`, and a correlating `waitId`;
-- optional `periodId` for the associated extension retry period;
-- `reason` (`rate-limit`, `overloaded`, `authentication`, `model-frozen`, `network`, or `retry`);
-- `plannedDurationMs`, `plannedDeadline`, and `startedAt` (`plannedDeadline`/`startedAt` are Unix milliseconds);
-- optional `model: { provider, id }` and a normalized `error` string.
-
-The `end` phase additionally contains `endedAt`, `actualElapsedMs`, and `outcome: "waited" | "skipped" | "aborted"`. Start and end are emitted for normal completion, Enter-to-skip, Escape, signal abort, and pre-aborted positive waits. Telemetry is observational: event-bus failures are isolated and cannot cancel or alter a wait.
-
-## Session retry summaries
-
-A retry period begins only when a failure will lead to another extension-created attempt or fallback. For each contiguous extension-managed retry period/stream, limits-wait queues one standard Pi custom entry and appends it after the associated assistant turn (normally on `turn_end`, with `agent_end` and `session_shutdown` as duplicate-safe fallbacks):
-
-```json
-{
-  "type": "custom",
-  "customType": "limits-wait",
-  "data": {
-    "totalWaitingTime": 12.345,
-    "reasons": ["HTTP 429 retry-after-ms 10000", "fetch failed"],
-    "retries_total": 2
-  }
-}
-```
-
-`totalWaitingTime` is actual elapsed extension wait time in seconds, not the planned duration. `reasons` contains whitespace-normalized error messages, deduplicated while preserving first-seen order. `retries_total` counts attempts/fallbacks created by this extension: the initial provider request and retries performed internally by a provider SDK do not count; an immediate fallback or zero-wait retry does count. A wait aborted before another attempt does not create a retry count by itself.
-
-Pi custom entries created with `pi.appendEntry()` do not participate in LLM context. The summary is transcript metadata only.
-
-## Optional fallback models
-
-By default, if you do not configure fallback models, the extension behaves exactly as before: it waits for the current model's limit to reset and retries.
-
-To enable automatic model fallback, add `fallback-models` to a `limits-wait.json` file.
-
-The extension reads these files in order; later files override earlier ones:
-
-| Location | Scope | Trust behavior |
-|----------|-------|----------------|
-| `~/.config/.pi/limits-wait.json` | Global defaults | Always loaded |
-| `<Pi agent dir>/limits-wait.json` (for example `~/.pi/agent/limits-wait.json`, or `PI_CODING_AGENT_DIR/limits-wait.json`) | Pi agent directory | Always loaded |
-| `.limits-wait.json` | Project root override | Loaded only when `ctx.isProjectTrusted()` is `true` |
-| `.pi/limits-wait.json` | Pi project override | Loaded only when `ctx.isProjectTrusted()` is `true` |
-
-For an untrusted project, both project-local paths are ignored completely (including malformed-file warnings); global and agent settings still apply. The trust decision is Pi's effective session trust, including temporary/CLI trust decisions. The same rule is applied every time settings are reread before an LLM call.
-
-Example:
-
-```json
-{
-  "fallback-models": [
-    {
-      "provider": "anthropic",
-      "modelname": "claude-sonnet-4-5",
-      "reasoning effort": "medium"
-    },
-    {
-      "provider": "openai",
-      "modelname": "gpt-5.1-codex"
-    }
-  ]
-}
-```
-
-Each `fallback-models` entry supports:
-
-- `provider` — required. The Pi provider name, for example `anthropic`, `openai`, `google`, etc.
-- `modelname` — required. The model id/name as Pi knows it.
-- `reasoning effort` — optional. One of `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`. If omitted, Pi's current/default reasoning level is used.
-
-Fallback behavior:
-
-1. Pi starts with the normal default or user-selected model.
-2. If that model is rate-limited, the extension tries models in this order:
-   - the original default/user-selected model;
-   - then every model from `fallback-models`, top to bottom.
-3. The first model that responds without a rate-limit becomes the active Pi model for the rest of the session/task.
-4. If that model later becomes rate-limited too, the extension starts again from the same ordered list.
-5. Rate-limit reset times are remembered only in memory, so known-limited models are skipped until their countdown expires. This memory is cleared when Pi restarts.
-
-The extension rereads these files before every LLM call, so changes made during a long-running task take effect on the next LLM call without restarting Pi or using `/reload`. Tool calls do not trigger a settings read. When the settings are loaded, the extension shows the full usable fallback model list. When models become rate-limited, it reports the wait in chat notifications.
-
-## Environment variables
-
-| Variable | Default | Description |
-|----------|---------|-------------|
-| `PI_LIMITS_WAIT_DEFAULT_WAITING` | `true` | Whether unclassified/unknown provider errors enter the wait-and-retry cycle. Set to `false` (also accepts `0`, `no`, `off`) to surface the error immediately. Rate-limit, overload, authentication, and network retry behavior is unchanged. |
-| `PI_LIMITS_WAIT_MAX_RETRY` | `999999` | Maximum extension-created retries for an unclassified/unknown provider error. The initial failed request and provider-internal retries do not count. HTTP 400/403 remain eligible. Must be a non-negative integer. |
-| `PI_LIMITS_WAIT_RETRY_INTERVAL` | `5` | Seconds to wait between unclassified/unknown provider-error retries. Must be a non-negative integer (values above 2147483 are capped to Node's maximum reliable timer delay). This does not affect model-limit wait intervals. |
-| `PI_LIMITS_WAIT_FREEZING_ENABLED` | `true` | When a model keeps failing with a non-retryable error, it is normally "frozen" for 10 minutes and skipped in favour of other configured models. Set this to `false` (also accepts `0`, `no`, `off`) to disable freezing entirely: the extension will instead try each configured candidate once (after the bounded retries) and then surface the error, never blocking on a long "model-frozen" wait. Useful for non-interactive / subagent runs where no one can press Enter to skip. |
-
-## License
-
-MIT
+# Pi Limits Wait
+
+[![npm](https://img.shields.io/npm/v/oira666_pi-limits-wait?style=flat-square&logo=npm&logoColor=white&label=npm&color=7c3aed)](https://www.npmjs.com/package/oira666_pi-limits-wait) [![node](https://img.shields.io/badge/node-%3E%3D22.19-7c3aed?style=flat-square&logo=nodedotjs&logoColor=white)](https://nodejs.org)
+
+Pi extension that keeps requests alive when a provider rate-limits you or returns `server_is_overloaded`.
+
+## Install
+
+```bash
+pi install npm:oira666_pi-limits-wait
+```
+
+Restart Pi or run `/reload` after installing.
+
+## What it does
+
+- Targets Pi 0.80.10+ (developed and tested against Pi 0.83.0) and works with model providers that use `ModelRuntime.streamSimple`.
+- Intercepts the current runtime without registering synthetic providers; every retry and fallback re-enters Pi's normal provider/auth/base URL/configured-header composition, including OAuth refresh checks.
+- Reload-safe ownership ensures `/reload` transfers interception cleanly and aborts waits still owned by the previous extension instance. The interception has one process-global active extension owner, matching the interactive Pi CLI's single active session runtime lifecycle; SDK processes running multiple concurrent Pi sessions are not supported.
+- On rate-limit errors (`429`, `rate_limit`, `too many requests`, quota/reset messages), waits and retries in a loop.
+- Uses provider retry timing when exposed through response callbacks or provider errors (`retry-after`, `retry-after-ms`, `retry in ...`, reset messages).
+- If no retry timing is available for a rate limit, waits 30 minutes before retrying.
+- On `server_is_overloaded`, waits 5 minutes, then retries. If the provider is still overloaded after Pi's normal retries, it waits another 5 minutes and repeats.
+- On transient network/transport failures — including undici idle-timeout aborts (`UND_ERR_HEADERS_TIMEOUT` / `UND_ERR_BODY_TIMEOUT`), `fetch failed`, `terminated`, `ECONNRESET`, `ETIMEDOUT`, etc. — treats the error as retryable with a short backoff (default 15s, or the provider's `retry-after`) instead of giving up. This prevents a stalled streaming request from turning into a silent hang.
+- Leaves context-overflow recovery entirely to Pi. The extension uses Pi's own `isContextOverflow()` detector and immediately surfaces matching failures without waiting, retrying, or selecting another fallback. If the overflow came from a fallback already attempted for the request, the extension makes that attempted model current when Pi is still on the request's original model and accepts the switch; it never overrides a newer user model selection. Pi intentionally ignores overflow errors from non-current models. Successful over-window responses and zero-output length stops also pass through unchanged, allowing Pi to compact and perform its built-in recovery.
+- For any other (unclassified) provider error — including an API `Internal server error` and HTTP `400`/`403` failures — waits and retries the same model. There is deliberately no permanent-HTTP-status allowlist. This retry-all behavior is enabled by default and uses a configurable retry limit and interval; it does not alter model-limit wait intervals.
+- Reports retry/fallback waits in chat notifications without adding persistent TUI status lines.
+- In non-interactive hosts (`rpc` and `json` modes) the extension never reports a planned retry as an error. While it is waiting to retry, it publishes `info`-level liveliness notifications (plus a `setStatus` entry) describing what it is doing, how long it will wait, and why. An `error`-level notification is emitted only when the extension stops retrying and surfaces the terminal failure. See [Non-interactive (RPC) reporting](#non-interactive-rpc-reporting).
+- Press Enter during a retry wait to skip the wait and retry immediately.
+- Optionally falls back to configured models when the current/default model is rate-limited. Every fallback to a different model—even on the same provider—deliberately discards request-owned credentials, headers, environment overrides, and provider-specific options so the target runtime resolves its own configuration.
+- Preserves Pi's `before_provider_request` / `after_provider_response` callback flow and sanitises only the exact Anthropic OAuth system-block shape generated by current Pi; Pi remains responsible for OAuth identity insertion.
+
+### Unsupported interception limitation
+
+Pi 0.83 has no public stream middleware that can intercept a failed provider stream, wait, and re-enter `ModelRuntime` for another attempt. For that reason, limits-wait still installs a reload-safe trampoline on `ModelRuntime.prototype.streamSimple`. This is an unsupported internal interception point and could require changes when Pi changes `ModelRuntime`; it also assumes the interactive CLI's one active session runtime per process. SDK processes with multiple concurrent Pi sessions are not supported.
+
+`after_provider_response` is preserved for observers, but it is not an equivalent retry hook: it cannot replace stream-error interception, own retry/fallback control flow, or recreate a complete target-model request. In particular, Pi 0.83 still does not expose a public factory for rebuilding the SDK's target-model-aware `transformHeaders` callback. Reusing the source request's closure on a fallback would apply source-model attribution and could leak extension-added headers, so limits-wait intentionally omits it for every different-model fallback. The target `ModelRuntime` still resolves target auth, base URL, configured provider/model headers, environment, and provider implementation canonically, but `before_provider_headers` cannot be re-fired for that fallback through the current public API.
+
+## Non-interactive (RPC) reporting
+
+In RPC/JSON mode Pi turns `ctx.ui.setWorkingMessage()` into a no-op, so the interactive countdown is invisible to clients. To keep those clients informed without misreporting recoverable situations as failures, the extension separates progress from failure:
+
+| Situation | RPC output |
+| --- | --- |
+| Rate limit, overload, auth refresh, network error, unknown error, frozen model — a retry/fallback is still planned | `extension_ui_request` `notify` with `notifyType: "info"`, repeated every `PI_LIMITS_WAIT_LIVELINESS_INTERVAL` seconds while waiting, plus a `setStatus` entry under key `oira666.pi-limits-wait` |
+| Wait finished, retry started, or request completed | The `setStatus` entry is cleared |
+| Retries exhausted / retrying disabled — the request ends with a provider error | one `extension_ui_request` `notify` with `notifyType: "error"` describing the model and the final error, alongside the normal terminal `error` event |
+| Aborted by the client | no error notification (abort is not a failure); the status entry is cleared |
+
+Liveliness messages include the retry reason, the model, the remaining wait, and the originating error message, e.g.:
+
+```
+⏳ pi-limits-wait: rate limited on anthropic/claude-sonnet-4-5; still alive, waiting 12m 04s before the next retry. Why: HTTP 429 retry-after-ms 724000
+```
+
+Interactive (TUI) behavior is unchanged: retry notices remain `warning`-level chat notifications with the live countdown, and no duplicate error notification is added because the terminal error event is already rendered in the transcript.
+
+## Wait event contract
+
+Every positive extension-managed wait emits public telemetry on Pi's shared event bus. Import the channel constant and payload union from the package entry point:
+
+```ts
+import {
+  LIMITS_WAIT_EVENT_CHANNEL,
+  type LimitsWaitEventPayload,
+} from "oira666_pi-limits-wait";
+
+pi.events.on(LIMITS_WAIT_EVENT_CHANNEL, (data) => {
+  const event = data as LimitsWaitEventPayload;
+  // event.version === 1; event.phase is "start" or "end"
+});
+```
+
+The versioned, namespaced channel is `oira666.pi-limits-wait.wait.v1`. No event is emitted for a zero/negative-duration wait.
+
+Both phases contain:
+
+- `version: 1`, `phase`, and a correlating `waitId`;
+- optional `periodId` for the associated extension retry period;
+- `reason` (`rate-limit`, `overloaded`, `authentication`, `model-frozen`, `network`, or `retry`);
+- `plannedDurationMs`, `plannedDeadline`, and `startedAt` (`plannedDeadline`/`startedAt` are Unix milliseconds);
+- optional `model: { provider, id }` and a normalized `error` string.
+
+The `end` phase additionally contains `endedAt`, `actualElapsedMs`, and `outcome: "waited" | "skipped" | "aborted"`. Start and end are emitted for normal completion, Enter-to-skip, Escape, signal abort, and pre-aborted positive waits. Telemetry is observational: event-bus failures are isolated and cannot cancel or alter a wait.
+
+## Session retry summaries
+
+A retry period begins only when a failure will lead to another extension-created attempt or fallback. For each contiguous extension-managed retry period/stream, limits-wait queues one standard Pi custom entry and appends it after the associated assistant turn (normally on `turn_end`, with `agent_end` and `session_shutdown` as duplicate-safe fallbacks):
+
+```json
+{
+  "type": "custom",
+  "customType": "limits-wait",
+  "data": {
+    "totalWaitingTime": 12.345,
+    "reasons": ["HTTP 429 retry-after-ms 10000", "fetch failed"],
+    "retries_total": 2
+  }
+}
+```
+
+`totalWaitingTime` is actual elapsed extension wait time in seconds, not the planned duration. `reasons` contains whitespace-normalized error messages, deduplicated while preserving first-seen order. `retries_total` counts attempts/fallbacks created by this extension: the initial provider request and retries performed internally by a provider SDK do not count; an immediate fallback or zero-wait retry does count. A wait aborted before another attempt does not create a retry count by itself.
+
+Pi custom entries created with `pi.appendEntry()` do not participate in LLM context. The summary is transcript metadata only.
+
+## Optional fallback models
+
+By default, if you do not configure fallback models, the extension behaves exactly as before: it waits for the current model's limit to reset and retries.
+
+To enable automatic model fallback, add `fallback-models` to a `limits-wait.json` file.
+
+The extension reads these files in order; later files override earlier ones:
+
+| Location | Scope | Trust behavior |
+|----------|-------|----------------|
+| `~/.config/.pi/limits-wait.json` | Global defaults | Always loaded |
+| `<Pi agent dir>/limits-wait.json` (for example `~/.pi/agent/limits-wait.json`, or `PI_CODING_AGENT_DIR/limits-wait.json`) | Pi agent directory | Always loaded |
+| `.limits-wait.json` | Project root override | Loaded only when `ctx.isProjectTrusted()` is `true` |
+| `.pi/limits-wait.json` | Pi project override | Loaded only when `ctx.isProjectTrusted()` is `true` |
+
+For an untrusted project, both project-local paths are ignored completely (including malformed-file warnings); global and agent settings still apply. The trust decision is Pi's effective session trust, including temporary/CLI trust decisions. The same rule is applied every time settings are reread before an LLM call.
+
+Example:
+
+```json
+{
+  "fallback-models": [
+    {
+      "provider": "anthropic",
+      "modelname": "claude-sonnet-4-5",
+      "reasoning effort": "medium"
+    },
+    {
+      "provider": "openai",
+      "modelname": "gpt-5.1-codex"
+    }
+  ]
+}
+```
+
+Each `fallback-models` entry supports:
+
+- `provider` — required. The Pi provider name, for example `anthropic`, `openai`, `google`, etc.
+- `modelname` — required. The model id/name as Pi knows it.
+- `reasoning effort` — optional. One of `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`. If omitted, Pi's current/default reasoning level is used.
+
+Fallback behavior:
+
+1. Pi starts with the normal default or user-selected model.
+2. If that model is rate-limited, the extension tries models in this order:
+   - the original default/user-selected model;
+   - then every model from `fallback-models`, top to bottom.
+3. The first model that responds without a rate-limit becomes the active Pi model for the rest of the session/task.
+4. If that model later becomes rate-limited too, the extension starts again from the same ordered list.
+5. Rate-limit reset times are remembered only in memory, so known-limited models are skipped until their countdown expires. This memory is cleared when Pi restarts.
+
+The extension rereads these files before every LLM call, so changes made during a long-running task take effect on the next LLM call without restarting Pi or using `/reload`. Tool calls do not trigger a settings read. When the settings are loaded, the extension shows the full usable fallback model list. When models become rate-limited, it reports the wait in chat notifications.
+
+## Environment variables
+
+| Variable | Default | Description |
+|----------|---------|-------------|
+| `PI_LIMITS_WAIT_DEFAULT_WAITING` | `true` | Whether unclassified/unknown provider errors enter the wait-and-retry cycle. Set to `false` (also accepts `0`, `no`, `off`) to surface the error immediately. Rate-limit, overload, authentication, and network retry behavior is unchanged. |
+| `PI_LIMITS_WAIT_MAX_RETRY` | `999999` | Maximum extension-created retries for an unclassified/unknown provider error. The initial failed request and provider-internal retries do not count. HTTP 400/403 remain eligible. Must be a non-negative integer. |
+| `PI_LIMITS_WAIT_LIVELINESS_INTERVAL` | `15` | Seconds between liveliness notifications published while waiting in non-interactive (`rpc`/`json`) modes. Must be a non-negative integer; values below 1 second are clamped to 1 second. Ignored in TUI mode. |
+| `PI_LIMITS_WAIT_RETRY_INTERVAL` | `5` | Seconds to wait between unclassified/unknown provider-error retries. Must be a non-negative integer (values above 2147483 are capped to Node's maximum reliable timer delay). This does not affect model-limit wait intervals. |
+| `PI_LIMITS_WAIT_FREEZING_ENABLED` | `true` | When a model keeps failing with a non-retryable error, it is normally "frozen" for 10 minutes and skipped in favour of other configured models. Set this to `false` (also accepts `0`, `no`, `off`) to disable freezing entirely: the extension will instead try each configured candidate once (after the bounded retries) and then surface the error, never blocking on a long "model-frozen" wait. Useful for non-interactive / subagent runs where no one can press Enter to skip. |
+
+## License
+
+MIT

package/package.json

@@ -1,52 +1,52 @@
-{
-  "name": "oira666_pi-limits-wait",
-  "version": "0.5.3",
-  "description": "Extension for PI that allows to automatically wait for limits to reset and retry the request",
-  "type": "module",
-  "exports": {
-    ".": "./src/index.ts"
-  },
-  "license": "MIT",
-  "files": [
-    "src",
-    "!src/__tests__",
-    "README.md",
-    "LICENSE"
-  ],
-  "engines": {
-    "node": ">=22.19.0"
-  },
-  "repository": {
-    "type": "git",
-    "url": "https://github.com/gee666/pi-limits-wait.git"
-  },
-  "bugs": {
-    "url": "https://github.com/gee666/pi-limits-wait/issues"
-  },
-  "homepage": "https://github.com/gee666/pi-limits-wait#readme",
-  "publishConfig": {
-    "access": "public"
-  },
-  "scripts": {
-    "check": "tsc -p tsconfig.json --noEmit",
-    "test": "tsx src/__tests__/test-extension.ts",
-    "pack:check": "npm pack --dry-run",
-    "prepublishOnly": "npm run check && npm test && npm run pack:check"
-  },
-  "pi": {
-    "extensions": [
-      "./src/index.ts"
-    ]
-  },
-  "dependencies": {},
-  "peerDependencies": {
-    "@earendil-works/pi-ai": ">=0.80.10",
-    "@earendil-works/pi-coding-agent": ">=0.80.10"
-  },
-  "devDependencies": {
-    "@earendil-works/pi-ai": "0.83.0",
-    "@earendil-works/pi-coding-agent": "0.83.0",
-    "tsx": "^4.20.6",
-    "typescript": "^5.9.3"
-  }
-}
+{
+  "name": "oira666_pi-limits-wait",
+  "version": "0.5.5",
+  "description": "Extension for PI that allows to automatically wait for limits to reset and retry the request",
+  "type": "module",
+  "exports": {
+    ".": "./src/index.ts"
+  },
+  "license": "MIT",
+  "files": [
+    "src",
+    "!src/__tests__",
+    "README.md",
+    "LICENSE"
+  ],
+  "engines": {
+    "node": ">=22.19.0"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/gee666/pi-limits-wait.git"
+  },
+  "bugs": {
+    "url": "https://github.com/gee666/pi-limits-wait/issues"
+  },
+  "homepage": "https://github.com/gee666/pi-limits-wait#readme",
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "check": "tsc -p tsconfig.json --noEmit",
+    "test": "tsx src/__tests__/test-extension.ts",
+    "pack:check": "npm pack --dry-run",
+    "prepublishOnly": "npm run check && npm test && npm run pack:check"
+  },
+  "pi": {
+    "extensions": [
+      "./src/index.ts"
+    ]
+  },
+  "dependencies": {},
+  "peerDependencies": {
+    "@earendil-works/pi-ai": ">=0.80.10",
+    "@earendil-works/pi-coding-agent": ">=0.80.10"
+  },
+  "devDependencies": {
+    "@earendil-works/pi-ai": "0.83.0",
+    "@earendil-works/pi-coding-agent": "0.83.0",
+    "tsx": "^4.20.6",
+    "typescript": "^5.9.3"
+  }
+}

package/src/constants.ts

@@ -1,38 +1,44 @@
-export const CLAUDE_CODE_IDENTITY =
-  "You are Claude Code, Anthropic's official CLI for Claude.";
-
-export const PI_REMOVAL_ANCHORS = [
-  "pi-coding-agent",
-  "@earendil-works/pi-coding-agent",
-  "badlogic/pi-mono",
-] as const;
-
-export const PI_IDENTITY_SENTENCE_PATTERN =
-  /(?:^|\n)\s*You are pi\b[^.!?\n]*(?:[.!?](?=\s|$)|(?=\n|$))/gi;
-
-// Strips the host-harness identity clause pi prepends to its system prompt, e.g.
-// "You are an expert coding assistant operating inside pi, a coding agent harness."
-// The Claude Code identity block already establishes who the assistant is, so
-// leaving this clause in tells the model (and Anthropic) it is running inside pi.
-export const PI_HARNESS_IDENTITY_PATTERN =
-  /\s+operating inside pi,\s*a coding agent harness/gi;
-
-export const CLAUDE_CODE_IDENTITY_PATTERN =
-  /(?:^|\n)\s*You are Claude Code, Anthropic's official CLI for Claude\.\s*/gi;
-
-export const DEFAULT_RATE_LIMIT_WAIT_MS = 30 * 60 * 1_000; // 30 minutes
-export const DEFAULT_OVERLOADED_WAIT_MS = 5 * 60 * 1_000; // 5 minutes
-export const DEFAULT_NETWORK_WAIT_MS = 15 * 1_000; // 15 seconds
-export const DEFAULT_NON_RETRYABLE_FREEZE_MS = 10 * 60 * 1_000; // 10 minutes
-
-// Unknown provider errors are retried separately from rate-limit, overload,
-// authentication, and network failures.
-export const DEFAULT_UNKNOWN_ERROR_MAX_RETRIES = 999_999;
-export const DEFAULT_UNKNOWN_ERROR_RETRY_INTERVAL_MS = 5 * 1_000; // 5 seconds
-
-export const SETTINGS_FILE_NAME = "limits-wait.json";
-export const FALLBACK_MODELS_KEY = "fallback-models";
-export const FREEZING_ENV_VAR = "PI_LIMITS_WAIT_FREEZING_ENABLED";
-export const DEFAULT_WAITING_ENV_VAR = "PI_LIMITS_WAIT_DEFAULT_WAITING";
-export const MAX_RETRY_ENV_VAR = "PI_LIMITS_WAIT_MAX_RETRY";
-export const RETRY_INTERVAL_ENV_VAR = "PI_LIMITS_WAIT_RETRY_INTERVAL";
+export const CLAUDE_CODE_IDENTITY =
+  "You are Claude Code, Anthropic's official CLI for Claude.";
+
+export const PI_REMOVAL_ANCHORS = [
+  "pi-coding-agent",
+  "@earendil-works/pi-coding-agent",
+  "badlogic/pi-mono",
+] as const;
+
+export const PI_IDENTITY_SENTENCE_PATTERN =
+  /(?:^|\n)\s*You are pi\b[^.!?\n]*(?:[.!?](?=\s|$)|(?=\n|$))/gi;
+
+// Strips the host-harness identity clause pi prepends to its system prompt, e.g.
+// "You are an expert coding assistant operating inside pi, a coding agent harness."
+// The Claude Code identity block already establishes who the assistant is, so
+// leaving this clause in tells the model (and Anthropic) it is running inside pi.
+export const PI_HARNESS_IDENTITY_PATTERN =
+  /\s+operating inside pi,\s*a coding agent harness/gi;
+
+export const CLAUDE_CODE_IDENTITY_PATTERN =
+  /(?:^|\n)\s*You are Claude Code, Anthropic's official CLI for Claude\.\s*/gi;
+
+export const DEFAULT_RATE_LIMIT_WAIT_MS = 30 * 60 * 1_000; // 30 minutes
+export const DEFAULT_OVERLOADED_WAIT_MS = 5 * 60 * 1_000; // 5 minutes
+export const DEFAULT_NETWORK_WAIT_MS = 15 * 1_000; // 15 seconds
+export const DEFAULT_NON_RETRYABLE_FREEZE_MS = 10 * 60 * 1_000; // 10 minutes
+
+// Unknown provider errors are retried separately from rate-limit, overload,
+// authentication, and network failures.
+export const DEFAULT_UNKNOWN_ERROR_MAX_RETRIES = 999_999;
+export const DEFAULT_UNKNOWN_ERROR_RETRY_INTERVAL_MS = 5 * 1_000; // 5 seconds
+
+// Non-interactive hosts (RPC/JSON) cannot render the TUI countdown, so retry
+// progress is published as periodic liveliness notifications instead.
+export const LIVELINESS_STATUS_KEY = "oira666.pi-limits-wait";
+export const DEFAULT_LIVELINESS_INTERVAL_MS = 15 * 1_000; // 15 seconds
+
+export const SETTINGS_FILE_NAME = "limits-wait.json";
+export const FALLBACK_MODELS_KEY = "fallback-models";
+export const FREEZING_ENV_VAR = "PI_LIMITS_WAIT_FREEZING_ENABLED";
+export const DEFAULT_WAITING_ENV_VAR = "PI_LIMITS_WAIT_DEFAULT_WAITING";
+export const MAX_RETRY_ENV_VAR = "PI_LIMITS_WAIT_MAX_RETRY";
+export const RETRY_INTERVAL_ENV_VAR = "PI_LIMITS_WAIT_RETRY_INTERVAL";
+export const LIVELINESS_INTERVAL_ENV_VAR = "PI_LIMITS_WAIT_LIVELINESS_INTERVAL";