@bastani/atomic 0.9.45 → 0.9.46

package/docs/models/reference.md

@@ -115,57 +115,29 @@ Atomic advertises PDF only where its runtime can serialize a document block: Ant
 
 `"pdf"` means PDF specifically. A document block's media type must be `application/pdf`; other values are rejected by name.
 
-### GPT-6-Astra Built-in Models
-
-Atomic ships `openai/gpt-6-astra` and `openai-codex/gpt-6-astra`. Both accept text and image input, expose tool search and additional tools, and offer exactly `low`, `medium`, `high`, `xhigh`, and `max` reasoning. `off`, `minimal`, and Codex's client-side `ultra` orchestration preset are not API reasoning levels and do not appear in Atomic's selector.
-
-The built-in OpenAI and Codex entries use a 272,000-token default input/context limit and a 128,000-token maximum output. OpenAI documents a 1,050,000-token API maximum, but requests above 272,000 aggregate input tokens enter the long-context price tier for the whole request. Override `contextWindow` only when the larger window and its price are intentional.
-
-| Aggregate input | Input | Cached input | Cache write | Output |
-| --- | ---: | ---: | ---: | ---: |
-| Up to 272,000 | $10 | $1 | $12.50 | $50 |
-| Above 272,000 | $20 | $2 | $25 | $75 |
-
-Rates are per million tokens. `openai/gpt-6-astra-fast` and `openai-codex/gpt-6-astra-fast` are derived canonical choices. They send upstream ID `gpt-6-astra` with `service_tier: priority` while Atomic records `gpt-6-astra-fast`. Usage is priced at OpenAI's published Fast rates when Fast serves the request:
-
-| Aggregate input | Input | Cached input | Cache write | Output |
-| --- | ---: | ---: | ---: | ---: |
-| Up to 272,000 | $20 | $2 | $25 | $100 |
-| Above 272,000 | $40 | $4 | $50 | $150 |
-
-`openai/gpt-6-astra-ultrafast` and `openai-codex/gpt-6-astra-ultrafast` send the same upstream ID with `service_tier: "ultrafast"` and are priced at OpenAI's published Ultrafast rates, six times Standard:
-
-| Aggregate input | Input | Cached input | Cache write | Output |
-| --- | ---: | ---: | ---: | ---: |
-| Up to 272,000 | $60 | $6 | $75 | $300 |
-| Above 272,000 | $120 | $12 | $150 | $450 |
-
-GPT-6 Astra and GPT-6.1 Sol have an Ultrafast choice on Codex and the OpenAI API; GPT-5.6 Sol has one on the OpenAI API only. Auto routing requires an Ultrafast choice's exact ID in `modelConstraints.allowedModels`. Base-model evaluations are reused through explicit route metadata, with no separate Ultrafast benchmark or latency score. See [Fast and Ultrafast tiers](/providers#fast-and-ultrafast-tiers).
-
-Amazon Bedrock exposes `openai.gpt-6-astra`, `global.openai.gpt-6-astra`, and `us.openai.gpt-6-astra` through the `amazon-bedrock` provider. These entries keep the same 272,000 input and 128,000 output limits, text and image input, and five reasoning levels; Atomic sends the selected effort as Bedrock's OpenAI `reasoning_effort` field. They do not get Fast or OpenAI tool-search metadata. Atomic sends each Bedrock ID unchanged and records all four price fields as zero because AWS had not published Astra pricing. Zero means unknown here, not free.
-
-Atomic does not synthesize Azure OpenAI Astra entries. Live-provider catalogs remain authoritative: the current OpenRouter catalog publishes `openai/gpt-6-astra` and `openai/gpt-6-astra-pro`, while the Vercel AI Gateway publishes `openai/gpt-6-astra` and `openai/gpt-6-astra-fast`. Atomic imports those exact IDs and their request-wide long-context prices. Vercel owns its suffixed ID, so it remains route-less and does not gain Atomic's first-party fast-route behavior.
-
-On OpenAI Responses, Astra uses the newer prompt-cache payload. `cacheRetention: "long"` sends `prompt_cache_options.ttl: "30m"` instead of the legacy `prompt_cache_retention: "24h"`; `none` sends explicit mode without a cache key, and `short` sends neither cache option. Earlier Responses models keep the 24-hour field for long retention.
-
-<a id="gpt-6-1-sol" />
-
-### GPT-6.1 Sol
-
-Select `openai/gpt-6.1-sol` with either API-key authentication or ChatGPT subscription sign-in, or `openai-codex/gpt-6.1-sol` with a ChatGPT subscription. Both accept text and images and support `low`, `medium`, `high`, `xhigh`, and `max`. Reasoning cannot be turned off. Codex also offers a `minimal` UI alias that sends `low`, not a separate API effort.
-
-With ChatGPT subscription sign-in, `openai/gpt-6.1-sol` and `openai-codex/gpt-6.1-sol` use a 500,000-token context and a 128,000-token output limit. Account aliases inherit the limits for their own login method. Subscription usage has no long-context price tier on Standard, Fast, or Ultrafast.
-
-With API-key authentication, `openai/gpt-6.1-sol` and `openai-api/gpt-6.1-sol` use a 272,000-token default context and a 128,000-token output limit. Increase `contextWindow` through a model override only when you intend to use the larger API window and its whole-request long-context prices:
-
-| Aggregate input | Input | Cached input | Cache write | Output |
-| --- | ---: | ---: | ---: | ---: |
-| Up to 272,000 | $2 | $0.10 | $2.50 | $10 |
-| Above 272,000 | $4 | $0.20 | $5 | $15 |
-
-Rates are per million tokens. Derived `openai/gpt-6.1-sol-fast` and `openai-codex/gpt-6.1-sol-fast` choices send the same upstream model with priority routing. Fast costs twice the applicable rates; do not pre-multiply catalog costs. [Published evaluations](/models/evals) describe base-model results and measured efforts, not separate Fast measurements.
-
-`openai/gpt-6.1-sol-ultrafast` (also `openai-api/` and `openai-codex/`) sends `service_tier: "ultrafast"`. It uses OpenAI's published Ultrafast rates of $12 input and $60 output per million tokens. OpenAI has not listed Sol Ultrafast cache rates, so Atomic derives them at the same six-times-Standard ratio: $0.60 cached input and $15 cache write. With an API key, the usual long-context multipliers apply above 272,000 input tokens. Subscription sign-in keeps flat rates across the 500,000-token window. See [provider tier caveats](/providers#fast-models).
+### OpenAI Built-in Models
+
+Prices are in dollars per million tokens, as input / cached input / cache write / output. An empty cell means the fact does not apply or OpenAI has not published it.
+
+| Model | Provider IDs | Context window | Standard, up to 272,000 input | Standard, above 272,000 input | Fast | Ultrafast | Reasoning levels | `off` | `minimal` | Tool search | Additional tools | Mid-conversation effort |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| GPT-6 Astra | `openai/gpt-6-astra`, `openai-api/gpt-6-astra`, `openai-codex/gpt-6-astra`, `github-copilot/gpt-6-astra` | 272,000 on `openai`, `openai-api` and `openai-codex`; 1,000,000 on `github-copilot` | $10 / $1 / $12.50 / $50 | $20 / $2 / $25 / $75 | `-fast` on `openai`, `openai-api` and `openai-codex`: $20 / $2 / $25 / $100, above 272,000 $40 / $4 / $50 / $150 | `-ultrafast` on `openai`, `openai-api` and `openai-codex`: $60 / $6 / $75 / $300, above 272,000 $120 / $12 / $150 / $450 | `low`, `medium`, `high`, `xhigh`, `max` | No | No | `openai`, `openai-api`, `openai-codex` | `openai`, `openai-api`, `openai-codex`, `github-copilot` | `openai` and `openai-api` with an API key |
+| GPT-6 Astra on Amazon Bedrock | `amazon-bedrock/openai.gpt-6-astra`, `amazon-bedrock/global.openai.gpt-6-astra`, `amazon-bedrock/us.openai.gpt-6-astra` | 1,050,000 | `global.`: $10 / $1 / $12.50 / $50; `openai.` and `us.`: $11 / $1.10 / $13.75 / $55 | `global.`: $20 / $2 / $25 / $75; `openai.` and `us.`: $22 / $2.20 / $27.50 / $82.50 | | | `low`, `medium`, `high`, `xhigh`, `max` | No | No | No | No | No |
+| GPT-6.1 Sol | `openai/gpt-6.1-sol`, `openai-api/gpt-6.1-sol`, `openai-codex/gpt-6.1-sol`, `azure/gpt-6.1-sol`, `github-copilot/gpt-6.1-sol` | 500,000 on `openai-codex` and on `openai` with ChatGPT sign-in; 272,000 on `openai` and `openai-api` with an API key, and on `azure`; 1,050,000 on `github-copilot` (922,000 input) | $2 / $0.10 / $2.50 / $10 | $4 / $0.20 / $5 / $15 with an API key; none with ChatGPT sign-in | `-fast` on `openai`, `openai-api` and `openai-codex`: $4 / $0.20 / $5 / $20, above 272,000 with an API key $8 / $0.40 / $10 / $30 | `-ultrafast` on `openai`, `openai-api` and `openai-codex`: $12 / $0.60 / $15 / $60, above 272,000 with an API key $24 / $1.20 / $30 / $90 | `low`, `medium`, `high`, `xhigh`, `max` | No | Codex UI alias that sends `low`; no elsewhere | `openai`, `openai-api`, `openai-codex` | `openai`, `openai-api`, `openai-codex`, `github-copilot` | `openai` and `openai-api` with an API key |
+| GPT-6.1 Terra | `openai/gpt-6.1-terra`, `openai-api/gpt-6.1-terra`, `openai-codex/gpt-6.1-terra`, `azure/gpt-6.1-terra` | 500,000 on `openai-codex`; 272,000 on `openai`, `openai-api` and `azure` with either sign-in method | $1 / $0.05 / $1.25 / $5 | $2 / $0.10 / $2.50 / $7.50, including on Codex | `-fast` on `openai` and `openai-api`: $2 / $0.10 / $2.50 / $10, above 272,000 $4 / $0.20 / $5 / $15 | | `off`, `low`, `medium`, `high`, `xhigh`, `max` | Yes, sends `none` | Codex UI alias that sends `low`; no elsewhere | `openai`, `openai-api`, `openai-codex` | `openai`, `openai-api`, `openai-codex` | `openai` and `openai-api` with an API key |
+
+Notes for every row:
+
+- All entries accept text and image input and have a 128,000-token output limit.
+- Above 272,000 aggregate input tokens, the long-context price applies to the whole request. OpenAI documents a 1,050,000-token API maximum for Astra and Terra. Increase `contextWindow` through a model override only when you intend to use the larger window and its prices.
+- With ChatGPT subscription sign-in, GPT-6.1 Sol has no long-context price on Standard, Fast, or Ultrafast. Account aliases inherit the limits for their own login method.
+- A `-fast` choice sends the base upstream ID with `service_tier: priority`, and an `-ultrafast` choice sends it with `service_tier: "ultrafast"`; Atomic records the suffixed ID. Do not pre-multiply catalog costs. Ultrafast is 6× Standard for input, cached input, cache write and output, following OpenAI's published Ultrafast pattern; the [OpenAI API pricing](https://developers.openai.com/api/docs/pricing?latest-pricing=ultrafast) page lists these GPT-6 Astra and GPT-6.1 Sol rates. Codex does not list a Fast tier for Terra yet. Auto routing requires an Ultrafast choice's exact ID in `modelConstraints.allowedModels`. [Published evaluations](/models/evals) describe base-model results and measured efforts, not separate Fast or Ultrafast measurements. See [Fast and Ultrafast tiers](/providers#fast-and-ultrafast-tiers) and [provider tier caveats](/providers#fast-models).
+- Codex's `minimal` UI alias is not a separate API effort, and Codex's client-side `ultra` orchestration preset is not an API reasoning level; neither appears as its own effort in Atomic's selector.
+- Mid-conversation effort changes are explained in [Changing GPT-6 thinking levels](#changing-gpt-6-thinking-levels).
+- On Amazon Bedrock, Atomic sends each ID unchanged and sends the selected effort as Bedrock's OpenAI `reasoning_effort` field.
+- On GitHub Copilot, requests use Copilot's Responses endpoint, and account policy controls availability. Copilot Fast choices require exact account advertisement, and Codex's Ultrafast tier does not apply. The table lists no Copilot rates.
+- Atomic does not synthesize Azure OpenAI Astra entries. Other catalogs are imported as published: OpenRouter publishes `openai/gpt-6-astra` and `openai/gpt-6-astra-pro`, and the Vercel AI Gateway publishes `openai/gpt-6-astra` and `openai/gpt-6-astra-fast`, with their request-wide long-context prices. Vercel owns its suffixed ID, so it remains route-less and does not gain Atomic's first-party fast-route behavior.
+- On OpenAI Responses, these models use the newer prompt-cache payload. `cacheRetention: "long"` sends `prompt_cache_options.ttl: "30m"` instead of the legacy `prompt_cache_retention: "24h"`; `none` sends explicit mode without a cache key, and `short` sends neither cache option. Earlier Responses models keep the 24-hour field for long retention.
 
 ### Image Input Limits
 

package/docs/models.md

@@ -42,8 +42,7 @@ Each System One service takes images in its own request format, which the model'
 - [Supported APIs](/models/reference#supported-apis)
 - [Provider Configuration](/models/reference#provider-configuration)
 - [Model Configuration](/models/reference#model-configuration)
-- [GPT-6-Astra Built-in Models](/models/reference#gpt-6-astra-built-in-models)
-- [GPT-6.1 Sol](/models/reference#gpt-6-1-sol)
+- [OpenAI Built-in Models](/models/reference#openai-built-in-models)
 - [Request-wide Cost Tiers](/models/reference#request-wide-cost-tiers)
 - [Overriding Built-in Providers](/models/reference#overriding-built-in-providers)
 - [Per-model Overrides](/models/reference#per-model-overrides)
@@ -241,6 +240,6 @@ Moved to [Model configuration reference](/models/reference#constrained-tool-samp
 
 Moved to [Model configuration reference](/models/reference#catalog-freshness-and-precedence).
 
-## GPT-6-Astra Built-in Models
+## OpenAI Built-in Models
 
-Moved to [Model configuration reference](/models/reference#gpt-6-astra-built-in-models).
+Moved to [Model configuration reference](/models/reference#openai-built-in-models).

package/docs/providers.md

@@ -92,28 +92,22 @@ If the Codex backend reports that an OAuth/auth token was invalidated or revoked
 
 For Codex requests, `models.json` headers or per-request SDK headers can override `originator` and `User-Agent`. The transport still supplies the authenticated bearer token and ChatGPT account ID.
 
-GPT-6-Astra is selectable as `openai-codex/gpt-6-astra`. Atomic also derives the canonical `openai-codex/gpt-6-astra-fast` choice. The fast choice sends upstream model `gpt-6-astra` with `service_tier: priority` and keeps the first-party Codex transport identity described below. Access can still depend on the account, rollout, and minimum client policy even though Atomic lists the model.
+GPT-6 Astra, GPT-6.1 Sol and GPT-6.1 Terra are compared in one table, covering provider IDs, context windows by sign-in method, Standard, Fast and Ultrafast prices, and reasoning levels: see [OpenAI built-in models](/models/reference#openai-built-in-models). GPT-6 Sol and GPT-6 Luna are selectable as `openai/gpt-6-sol`, `openai/gpt-6-luna`, `openai-codex/gpt-6-sol`, and `openai-codex/gpt-6-luna`. Each of these models has a derived `-fast` choice where the table lists one, such as `openai-codex/gpt-6.1-sol-fast`, that sends the base upstream model with `service_tier: priority` and keeps the first-party Codex transport identity described below. For example, `atomic --model openai-codex/gpt-6.1-sol-fast:high` selects priority routing at high effort. Access can still depend on the account, rollout, and minimum client policy even though Atomic lists a model.
 
-GPT-6 Sol and GPT-6 Luna are selectable as `openai/gpt-6-sol`, `openai/gpt-6-luna`, `openai-codex/gpt-6-sol`, and `openai-codex/gpt-6-luna`. Each has a derived `-fast` choice, such as `openai-codex/gpt-6-sol-fast`, that sends the base upstream model with `service_tier: priority`. Copilot's bundled catalog and account policy determine which Sol models are available; fast siblings require an exact advertised ID.
-
-GPT-6.1 Sol is selectable as `openai/gpt-6.1-sol` and `openai-codex/gpt-6.1-sol`, with derived `-fast` siblings. For example, `atomic --model openai-codex/gpt-6.1-sol-fast:high` selects priority routing at high effort. Sol 6.1 supports `low`, `medium`, `high`, `xhigh`, and `max`; Codex's `minimal` UI alias also sends `low`. `off` is unavailable. See [Sol 6.1 limits and pricing](/models/reference#gpt-6-1-sol).
-
-GPT-6.1 Sol also has an `-ultrafast` choice on `openai/*`, `openai-api/*` and `openai-codex/*`, for example `openai/gpt-6.1-sol-ultrafast`.
-
-ChatGPT sign-in through either `openai` or `openai-codex` gives GPT-6.1 Sol a 500,000-token context on Standard, Fast, and Ultrafast, without long-context fees. API-key sign-in through `openai` or `openai-api` keeps the 272,000-token default and API long-context pricing. Account aliases follow their own authentication method. Fast and Ultrafast choices work with either authentication method when the account supports the requested tier.
+Account aliases follow their own authentication method. Fast and Ultrafast choices work with either authentication method when the account supports the requested tier.
 
 #### Fast and Ultrafast tiers
 
 Atomic offers a tier only for the models that advertise it, following Codex's per-model catalog and OpenAI's published API pricing:
 
-- **Fast** (`service_tier: priority`): every Codex model, and the `openai/*` models listed on OpenAI's [Fast pricing](https://developers.openai.com/api/docs/pricing) tab. For example, `openai/gpt-5-nano`, `openai/gpt-5-pro`, and `openai/o1` have no `-fast` choice.
+- **Fast** (`service_tier: priority`): every Codex model except GPT-6.1 Terra, and the `openai/*` models listed on OpenAI's [Fast pricing](https://developers.openai.com/api/docs/pricing) tab. For example, `openai/gpt-5-nano`, `openai/gpt-5-pro`, and `openai/o1` have no `-fast` choice.
 - **Ultrafast** (`service_tier: "ultrafast"`): GPT-6 Astra and GPT-6.1 Sol, as `openai/gpt-6-astra-ultrafast` and `openai/gpt-6.1-sol-ultrafast` (also under `openai-api/` and `openai-codex/`), plus GPT-5.6 Sol on the OpenAI API, as `openai/gpt-5.6-sol-ultrafast` (also under `openai-api/`). For example, `atomic --model openai-codex/gpt-6-astra-ultrafast:high`. Each keeps the base upstream model, following [Codex's tier-switching protocol](https://github.com/openai/codex/blob/17a9df60e420b58e3edc55efb1bb052e39492bbc/codex-rs/core/tests/suite/agent_websocket.rs#L518-L605). GPT-5.6 Sol Ultrafast is a limited preview, so most accounts get the fallback below.
 
 Listing a choice does not establish that your account has access. Ultrafast needs an eligible plan: Pro $500 or an eligible Enterprise or Edu workspace with ChatGPT sign-in. With an API key, it is available at low default rate limits. If the OpenAI API or the Codex backend rejects the tier of a Fast or Ultrafast choice you selected (for example `400 Invalid service_tier argument`), Atomic retries once at the default tier and warns that the choice ran at default instead of failing the turn. Other providers still fail the request. With an OpenAI API key, Atomic also warns when the response reports a slower tier than the one you chose. With ChatGPT sign-in, on `openai/*` or `openai-codex/*`, it does not, because the ChatGPT backend reports `default` for every tier, including Fast and Ultrafast requests it ran at that tier. The warning, for example `ultrafast isn't available for gpt-5.6-sol on this account; ran at default`, appears under the response in interactive sessions, on stderr in print mode, and in the message `diagnostics` in JSON mode.
 
 A tier the model does not advertise is left out of the request, which then runs at standard processing instead of failing. `flex` is always passed through. With Codex, an explicit `default` sends no tier, as in Codex. With the OpenAI API, `default` is sent as requested.
 
-Usage is priced at the tier that served the request, using OpenAI's published per-model rates. Fast is usually twice Standard but varies by model: GPT-5.5 is 2.5x and GPT-4o is 1.7x. GPT-6 Astra Ultrafast is six times Standard: $60 input, $6 cached input, $75 cache write, and $300 output per million tokens up to 272,000 input tokens, and $120, $12, $150, and $450 above that ([OpenAI API pricing](https://developers.openai.com/api/docs/pricing?latest-pricing=ultrafast)). GPT-6.1 Sol Ultrafast uses OpenAI's published $12 input and $60 output; its cache rates are not listed, so Atomic derives them at six times Standard. GPT-5.6 Sol Ultrafast has no published rates, so Atomic prices it at six times Standard ($24 input, $120 output). With an API key, if OpenAI reports a Fast request as served at Standard, the usage is priced at Standard; with ChatGPT sign-in it is priced at the tier you chose. With ChatGPT sign-in, [Codex](https://developers.openai.com/codex/speed) counts Fast against included limits at 2.5x and Astra Ultrafast at 8x, and bills purchased credits at 2x and 6x. Atomic's displayed cost uses the API rates.
+Usage is priced at the tier that served the request, using OpenAI's published per-model rates. Fast is usually twice Standard but varies by model: GPT-5.5 is 2.5x and GPT-4o is 1.7x. GPT-6 Astra and GPT-6.1 Sol Ultrafast rates are in [OpenAI built-in models](/models/reference#openai-built-in-models) ([OpenAI API pricing](https://developers.openai.com/api/docs/pricing?latest-pricing=ultrafast)). GPT-5.6 Sol Ultrafast has no published rates, so Atomic prices it at six times Standard ($24 input, $120 output). With an API key, if OpenAI reports a Fast request as served at Standard, the usage is priced at Standard; with ChatGPT sign-in it is priced at the tier you chose. With ChatGPT sign-in, [Codex](https://developers.openai.com/codex/speed) counts Fast against included limits at 2.5x and Astra Ultrafast at 8x, and bills purchased credits at 2x and 6x. Atomic's displayed cost uses the API rates.
 
 Auto routing excludes Ultrafast unless `modelConstraints.allowedModels` explicitly lists its exact provider/model ID. When explicitly allowed, it uses base-model benchmark evidence without an additional latency bonus. Normal and Fast choices keep their existing automatic selection behavior. Pick a fast identity only when the latency reduction is worth the higher usage and price.
 
@@ -171,11 +165,7 @@ Keys, `ANTHROPIC_AUTH_TOKEN`, and custom authorization headers take precedence.
 - Models come from the bundled `pi-ai` GitHub Copilot catalog; an OAuth credential narrows the list to the ids your account can actually use
 - If you get "model not supported", enable it in VS Code: Copilot Chat → model selector → select model → "Enable"
 
-GPT-6.1 Sol is included as `github-copilot/gpt-6.1-sol`. Select it with `atomic --model github-copilot/gpt-6.1-sol:high`. It uses Copilot's Responses endpoint and supports `low`, `medium`, `high`, `xhigh`, and `max`, not `off` or `minimal`.
-
-Copilot metadata lists a 1,050,000-token context, 922,000-token input limit, and 128,000-token output limit; account policy still controls availability. Copilot Fast choices require exact account advertisement. Codex's Ultrafast service tier does not apply to Copilot.
-
-Atomic includes a provisional `github-copilot/gpt-6-astra` entry routed through Copilot's Responses endpoint. Until Copilot publishes metadata, it uses Astra's known text/image capabilities, 272,000 default context, 128,000 output limit, and `low` through `max` reasoning. Zero catalog costs mean Copilot pricing is unknown, not free. Copilot metadata takes precedence when present, and the OAuth account catalog still controls availability. This entry does not guarantee that Copilot has enabled Astra for your account.
+Copilot includes `github-copilot/gpt-6.1-sol` and `github-copilot/gpt-6-astra`, for example `atomic --model github-copilot/gpt-6.1-sol:high`. Their context windows and reasoning levels are in [OpenAI built-in models](/models/reference#openai-built-in-models). The OAuth account catalog still controls availability, so a listed model does not guarantee that Copilot has enabled it for your account.
 
 `github-copilot/gpt-6-astra-fast` appears only when the OAuth account catalog advertises that exact fast ID. It sends `gpt-6-astra-fast` unchanged with no `service_tier`, unlike first-party OpenAI's priority route. A raw `COPILOT_GITHUB_TOKEN` cannot supply that fast entitlement.
 

package/docs/settings.md

@@ -344,7 +344,7 @@ Both fields must be non-negative safe integers, including ordinary settings. Inv
 | `retry.provider.maxRetries` | number | `0` | Provider/SDK retry attempts. Leave unset/`0` to let Atomic's agent-level retry handle transient failures |
 | `retry.provider.maxRetryDelayMs` | number | `60000` | Max server-requested delay before failing (60s); also caps how long an agent-level retry waits for a server retry hint |
 
-Agent-level retries use exponential backoff capped by `retry.maxAgentDelayMs`, including the shared main-chat and workflow retry policy and summary calls. When a failed response carries a server retry hint (`Retry-After-Ms` or `Retry-After` header, or a Cloudflare 5xx `retry_after` body field), Atomic waits as long as the server asks instead, up to `retry.provider.maxRetryDelayMs`. OpenAI, OpenAI-compatible and ChatGPT (Codex) providers report these hints. `retry.maxRetries` still limits the number of retries, so with the defaults a hinted outage can take up to about 3 × 60s before the turn fails or switches to a configured `fallbackModels` entry. Cloudflare 520-524 responses and connection resets count as transient errors; non-retryable 4xx and quota errors still stop immediately. This is independent of provider retry limits. Legacy `retry.maxDelayMs` still migrates to `retry.provider.maxRetryDelayMs`, not the agent cap.
+Agent-level retries use exponential backoff capped by `retry.maxAgentDelayMs`, including the shared main-chat and workflow retry policy and summary calls. When a failed response carries a server retry hint (`Retry-After-Ms` or `Retry-After` header, a Cloudflare 5xx `retry_after` body field, or a Google `RetryInfo.retryDelay` in the error body), Atomic waits as long as the server asks instead, up to `retry.provider.maxRetryDelayMs`. OpenAI, OpenAI-compatible, ChatGPT (Codex), Anthropic, Azure OpenAI, Mistral, Google (Generative AI and Vertex) and Amazon Bedrock providers report these hints. `retry.maxRetries` still limits the number of retries, so with the defaults a hinted outage can take up to about 3 × 60s before the turn fails or switches to a configured `fallbackModels` entry. Cloudflare 520-524 responses and connection resets count as transient errors; non-retryable 4xx and quota errors still stop immediately. This is independent of provider retry limits. Legacy `retry.maxDelayMs` still migrates to `retry.provider.maxRetryDelayMs`, not the agent cap.
 
 When a provider requests a retry delay longer than `retry.provider.maxRetryDelayMs` (e.g., Google's "quota will reset after 5h"), the request fails immediately with an informative error instead of waiting silently. Set to `0` to disable the cap.
 

package/docs/storage.md

@@ -249,9 +249,9 @@ export default {
 
 Select it with `sessions.storage: { "adapter": "./storage/libsql-adapter.ts" }`, `workflows.journal`, or shared top-level `storage` in [settings](/settings#workflow-storage). SDK sessions accept `sessionStore: { kind: "adapter", module, options, secrets, prefix }`; workflow runs accept `journal: { adapter, options, secrets, prefix }`. Relative module paths resolve from the agent directory, normally `~/.atomic/agent`; absolute module paths also work. A package name selects an adapter from an [installed Atomic package](#adapters-from-atomic-packages), or otherwise resolves from the agent directory. Project settings follow the same trust boundary as project extensions. A module executes with Atomic's privileges.
 
-Adapter modules import `@bastani/atomic/storage` and `@bastani/atomic` from the running Atomic, in the npm package and the standalone binary alike, exactly as extensions do. They need no installed or linked copy of Atomic, and Atomic recognizes the storage errors they throw. List `@bastani/atomic` in an adapter package's `peerDependencies`, not its `dependencies`.
+Adapter modules import `@bastani/atomic/storage` and `@bastani/atomic` from the running Atomic, in the npm package and the standalone binary alike, exactly as extensions do. This covers the adapter's entry file and the ES module and TypeScript files it imports by relative path, including `.mjs` files and `.js` files in a `"type": "module"` package. CommonJS files other than the entry file, such as a `.cjs` file or a `.js` file outside a `"type": "module"` package, resolve these specifiers from `node_modules` instead. Import the module in an ES module file and pass it to them. Adapters need no installed or linked copy of Atomic, and Atomic recognizes the storage errors they throw. List `@bastani/atomic` in an adapter package's `peerDependencies`, not its `dependencies`.
 
-When Atomic loads an adapter to open a workflow journal, the adapter can also import `@bastani/atomic/workflows` and gets the running Atomic's workflows module. An `openRunJournal` hook can build on `SqlRunJournal`, and errors such as `StaleLeaseError` pass Atomic's `instanceof` checks. Adapters loaded only for sessions or Intercom do not get this module.
+When Atomic loads an adapter to open a workflow journal, the adapter's files can also import `@bastani/atomic/workflows` and get the running Atomic's workflows module. An `openRunJournal` hook can build on `SqlRunJournal`, and errors such as `StaleLeaseError` pass Atomic's `instanceof` checks. This holds when the same adapter module also serves sessions, for example through `sessions.storage` and `workflows.journal`. Adapters loaded only for sessions or Intercom do not get this module.
 
 `options` is an object of SQLite scalar values or booleans. In JSON settings use strings, numbers, booleans, or null. `secrets` maps option names to `{ env }` or `{ file }`, and resolved values override same-named options. A `{ file }` secret is read as written, except that one trailing line ending (`\n` or `\r\n`) is removed, so a token saved with `turso db tokens create <db> > token` works as is. Other whitespace is kept. Keep credentials out of `options` and database descriptors. `context` contains `agentDir`, `domain: "sessions" | "journal" | "intercom"`, and an optional `signal`. Intercom brokers open the top-level `storage` selection with `domain: "intercom"` through `openDatabase`.
 

package/docs/tools.md

@@ -61,7 +61,7 @@ Set [codemode settings](/settings#tools) to control inline declaration size and
 
 Deferred tools and their namespaces are omitted from codemode's inline catalog. Discover them with `searchTools()`, `describeNamespace()`, or `ALL_TOOLS`; `tool_search` can load matching registered tools for direct calls.
 
-`tool_search` is inactive by default. Enable it with `"defaultTools": ["+tool_search"]` or include it in `--tools`. It ranks currently registered `codemode` and `deferred` tools by their metadata and activates matching tools for the next model call. It does not bypass session tool restrictions or replace MCP server discovery.
+`tool_search` is inactive by default. Enable it with `"defaultTools": ["+tool_search"]` or include it in `--tools`. It ranks currently registered `codemode` and `deferred` tools by their metadata and activates matching tools for the next model call. A query that is a tool's name, or the part after a `__` separator such as `thread_read` for `mcp__app__thread_read`, ranks that tool first. It does not bypass session tool restrictions or replace MCP server discovery.
 
 ## `code_search`
 

package/docs/tui.md

@@ -46,6 +46,8 @@ For inspection or navigation, pass `{ purpose: "navigation" }`. Atomic then moun
 
 Navigation still owns keyboard focus. In `getHostCustomUiState()` and its change listener, `blockingInlineCustomUiActive` counts all inline mounts. When navigation is present, `blockingInlineCustomUiNeedsInput` distinguishes real pending prompts from navigation-only mounts; when omitted, use `blockingInlineCustomUiActive`. This distinction is preserved across the isolated-engine bridge.
 
+Custom components do not report Atomic as waiting for you through [program status](/terminal-setup#program-status), because `ctx.ui.custom()` also hosts loaders and other non-blocking UI. When an inline component waits for an answer, pass `blocked: { kind: "question", message: "Pick a color" }` so supporting terminals show Atomic as blocked while the component is visible. `kind` is `"question"`, `"permission"`, or `"auth"`. Overlays ignore this option.
+
 Main-chat inline custom UIs share the editor slot. Completing or canceling an older mount leaves the current one visible; closing the current mount restores the most recently mounted UI that is still pending, including task navigation or an approval. The main editor returns only after the last inline owner closes. A foreground workflow graph keeps focus until you hide or close it, then the surviving inline UI is visible and receives input.
 
 Reserving bottom prompts (`reserveTranscriptRows`, including `ask_user_question`) also wait out of view while inline navigation or an overlay's `deferInlineCustomUiFocus` owns input. Leaving navigation restores the same pending prompt, not a new questionnaire. Escape belongs exclusively to the active navigation view until then; once the questionnaire returns, its ordinary Escape cancellation applies.

package/docs/workflows/api-reference.md

@@ -1165,8 +1165,18 @@ interface RunResult<
   readonly error?: string;
   readonly exited?: boolean;
   readonly exitReason?: string;
+  readonly failure?: RunFailureClassification;
   readonly stages: readonly StageSnapshot[];
 }
+interface RunFailureClassification extends WorkflowSerializableObject {
+  readonly kind: "auth" | "rate_limit" | "provider" | "cancelled" | "unknown";
+  readonly code?: string;
+  readonly retryable: boolean;
+  readonly resumable: boolean;
+  readonly recoverability?: "recoverable" | "non_recoverable" | "unknown";
+  readonly disposition?: "active_blocked" | "terminal_killed" | "terminal_failed";
+  readonly retryAfterMs?: number;
+}
 interface StageSnapshot extends WorkflowSerializableObject {
   readonly id: string;
   readonly name: string;
@@ -1185,6 +1195,15 @@ interface StageSnapshot extends WorkflowSerializableObject {
 
 Programmatic `run(...)` returns this type. `exited` identifies `ctx.exit(...)` termination, and `stages` contains the final stage snapshots.
 
+`failure` describes how a run that failed, or blocked on a failure, was classified. It is absent for runs that did not fail, and for results recorded before this field existed.
+- `kind` and `code` say what failed.
+- `retryable` says whether retrying the same work can succeed, as for a rate limit or an outage.
+- `resumable` says whether the run can be resumed.
+- `disposition` says whether the run failed (`terminal_failed`), was stopped (`terminal_killed`), or stays `running` and blocked until a resume (`active_blocked`). It is absent when the run failed outside any stage.
+- `retryAfterMs` is the server's retry hint, when it sent one.
+
+When a child workflow fails, its parent classifies the failure from the child's `failure`, never from workflow or stage names in the error text. An ordinary child failure fails the parent; a child blocked on a rate limit blocks the parent for resume. A child result without `failure` is classified from the child's own error text.
+
 Each stage snapshot carries its graph position: `parentIds` lists the stages it depends on, and `executionOrder` is its admission order among the run's stages and tool nodes. `model` is the effective model after fallback resolution; `routerSelection` is the automatic routing choice: `model` and `effort`, ranked `fallbacks`, and `candidates`, the full IDs of every model the router could choose from after [`modelRouting`](/settings#modelrouting) and `modelConstraints` filtering. Selections recorded before `candidates` existed omit it. Timestamps are epoch milliseconds and are absent until the stage starts or ends. The runtime may replace `parentIds` before a stage starts, so read it from the latest snapshot rather than caching it.
 
 ## Programmatic usage
@@ -1253,7 +1272,7 @@ The option is off by default. Without it, Atomic creates no pool tables, worker
 
 The pool runs children once any worker is ready and fails only when no worker starts. A worker that dies while it runs a child is replaced, and the child replays from its last committed checkpoint. Each worker's standard error is written to `worker-logs/<root run ID>/<worker ID>.log` in the journal's directory; worker failure errors name that file and include the end of its output. See [Worker startup and failures](/workflows/operations#worker-startup-and-failures).
 
-Workers are supported only on Linux and macOS hosts with native process identity and boot identity. Windows and hosts without those capabilities refuse activation, including when no process cap is configured. Remote hosts are not supported. Pooled SDK runs reject process-bound adapters, UI, persistence, and similar runtime overrides before worker launch. The CLI keeps its host-specific bindings at the root and gives worker sessions their own adapters.
+Workers are supported only on Linux and macOS hosts with native process identity and boot identity. Windows and hosts without those capabilities refuse activation, including when no process cap is configured. Remote hosts are not supported. Pooled SDK runs reject process-bound adapters, UI, persistence, and similar runtime overrides before worker launch. `ui` is accepted: it answers the `ctx.ui` prompts (`input`, `confirm`, `select`, `editor`) of children on local workers, and each answer is sent to the worker that asked. If a `ui` call rejects, the prompt fails in that child with the same error. `stageUiBroker` is accepted: a stage on a local worker that asks `ask_user_question` raises the same form there, and its answer is sent to the worker that asked. A `ctx.ui.custom` prompt in a child on a local worker fails that child with an error, since its component cannot be shown outside the worker. `stageControlRegistry` is accepted: while a stage runs on a worker, the registry holds a handle for it whose `sendUserMessage`, `steer`, `followUp` and `subscribe` reach that stage and report the same delivery actions as an in-process stage. The handle streams the stage's events only while something subscribes or a message is on its way. The CLI keeps its host-specific bindings at the root and gives worker sessions their own adapters.
 
 Admission limits count actual resources: a session from creation through disposal, including fallback and delegated sessions, and a managed tool process until confirmed cleanup. Yielding an observation wait does not free a process permit. Subprocesses started outside Atomic's managed APIs are not counted. Host load and free-memory thresholds are launch gates, not hard OS limits. `userLimits` are reliable only when every participating run uses the configured canonical database path; they are local-user coordination, not a tenant security boundary.
 

package/docs/workflows/operations.md

@@ -178,7 +178,7 @@ Graph node cards show each model stage's effective model and thinking level abov
 /workflow <name> [key=value ...]
 /workflow connect [run-id]
 /workflow attach [run-id] [stage-id-or-name]
-/workflow pause [run-id|--all]
+/workflow pause [run-id|--all] [stage-id-or-name]
 /workflow status [run-id]
 /workflow status --all
 /workflow quit <run-id|--all>
@@ -194,6 +194,7 @@ Common controls:
 /workflow connect <run-id>             # graph viewer, including terminal runs
 /workflow attach <run-id> <stage>      # chat with a single stage
 /workflow pause <run-id>               # pause resumably
+/workflow pause <run-id> <stage>       # pause one stage; the others keep running
 /workflow resume <run-id> [stage] msg  # forward a steer message and resume
 /workflow quit <run-id>                # pause gracefully and keep the run resumable
 /workflows [run-id]                    # retained alias for /workflow resume (history picker)
@@ -213,7 +214,7 @@ Surface behavior:
 - **Footer context** - An attached live stage chat shows its own current folder and Git branch and mirrors live extension status lines such as the MCP server indicator. Branch changes trigger a repaint through the host's cached footer provider. The compact `/tasks` picker retains this context and the stage's model and reasoning level even while its foreground turn streams; detail, transcript, input, and confirmation pages remain fullscreen.
 - **Working indicator** - Stage chat shows `∀` during accepted prompt startup and active work, including retained-session follow-ups. Retry, fallback, compaction, cancellation, and errors take precedence. `NO_COLOR` removes foreground colors; `ATOMIC_REDUCED_MOTION=1` makes the indicator static.
 - **Subagent statusline** - If a subagent is running while the fullscreen workflow graph is open, the graph statusline mirrors its summary so the run remains visible; hide the graph with `h`, leave it with `ctrl+x`, or reconnect later to return to the full below-editor widget.
-- **Run control** - Use `pause` and `resume` for resumable live work. Pause holds a stage's queued steering and follow-up items in place without dequeuing them or starting continuation; `resume` releases those items once in their existing per-queue order, but queue release alone does not start a model turn. `resume` on a non-paused run reopens the saved snapshot or overlay. Use `quit` to pause a live run gracefully while preserving it for `/workflow resume`. `/workflow pause` selects the active run by default, accepts a full run id or `--all`, and does not open a stage picker. Use the workflow tool's `stageId` for stage or tool-node targeting.
+- **Run control** - Use `pause` and `resume` for resumable live work. Pause holds a stage's queued steering and follow-up items in place without dequeuing them or starting continuation; `resume` releases those items once in their existing per-queue order, but queue release alone does not start a model turn. `resume` on a non-paused run reopens the saved snapshot or overlay. Use `quit` to pause a live run gracefully while preserving it for `/workflow resume`. `/workflow pause` selects the active run by default, accepts a full run id or `--all`, and does not open a stage picker. `/workflow pause <run-id> <stage>` pauses only that stage, named by id, name or unique prefix as `/workflow attach` resolves it, and `/workflow resume <run-id> <stage>` resumes it. The workflow tool's `stageId` does the same and also targets tool nodes.
 - **Rediscovery** - Use `/workflow reload` after adding, editing, installing, or removing workflow resources or package manifest workflow entries and you want Atomic to rediscover them in-process ([Reloading workflow resources](/workflows/operations#reloading-workflow-resources)).
 - **Status listing** - `/workflow status` lists all retained active and terminal top-level runs by default; implementation-owned nested child runs are flattened into their parent workflow rather than listed separately. `/workflow status --all` is retained as a compatibility alias.
 - **Status times** - `/workflow status <run-id>` displays `started` and `ended` in the system local timezone as `HH:mm:ss`. If they differ from your expected clock, check the timezone of the machine or container running Atomic and any inherited `TZ` environment setting. Elapsed durations and raw timestamps in structured results are unchanged.
@@ -322,7 +323,7 @@ Use slash commands for graph connect and stage attach because those are interact
 
 ### Diagnosing a stage with an empty history
 
-The run display shows stage execution durations without extra startup rows. To inspect startup diagnostics, use the workflow tool's `stage` / `stages` output. Live stages report `startup` with the current phase, total startup age, and seconds on the current step, for example `startup reload-active (45s total, 45s on current step; active)`. Phases are model resolution, route authority, resource preparation, queued/active resource reload, SDK creation, extension binding, attachment, delivery readiness, and first dispatch. An allocated session ID is not proof of attachment; first dispatch is not proof of a provider response or reviewer approval.
+The run display shows stage execution durations without extra startup rows. To inspect startup diagnostics, use the workflow tool's `stage` / `stages` output. Live stages report `startup` with the current phase, total startup age, and seconds on the current step, for example `startup reload-active (45s total, 45s on current step; active)`. Phases are model resolution, route authority, resource preparation, queued/active resource reload, SDK creation, extension binding, attachment, delivery readiness, and first dispatch. Once the stage sends its first prompt, the line stops tracking steps and reads `startup complete (dispatched after 2s)`, with the seconds from stage start to dispatch; it does not change again while the stage runs or after it finishes, so it does not mean the stage is stuck. An allocated session ID is not proof of attachment; first dispatch is not proof of a provider response or reviewer approval.
 
 Resource discovery allows up to four stage reloads at a time per Atomic process. `reload-queued` means the stage is waiting for a reload slot; `reload-active` means it has started loading resources. A slow active reload holds one slot, not the entire queue. This limit is separate from the workflow's stage concurrency setting.
 
@@ -883,13 +884,25 @@ The supported placement is multiple local processes on Linux or macOS. Windows a
 
 The root's existing `/workflow status`, `/workflow stages`, steering, pause, quit, and resume controls still address one root. A worker failure can replay an unfinished child from its last committed checkpoint. This is at-least-once recovery. An external effect that happens before its checkpoint can happen again; use stable logical idempotency keys for effects that must not duplicate.
 
+### Watching stages on local workers
+
+A stage that runs on a local worker opens from the workflow graph or `/workflow attach` like any other stage. While it runs, its chat shows the transcript so far and the reply as it streams, with tool calls. The chat header reads `on local worker`. Enter steers the running turn and Ctrl+F queues a follow-up, as for any stage. Queued messages show on the stage's graph node (`✉ N queued`) even when its chat is closed. `/workflow pause <run> <stage>` and the stage chat's pause and resume hold and release just that stage; other stages, including ones on other workers, keep running, and the paused stage keeps its worker. While the whole pool is paused, a single stage cannot be paused or resumed on its own; resume the run first.
+
+If the worker running an open stage dies or loses its lease, the chat header shows `RECONNECTING` until the stage runs again on a replacement worker. The chat then reloads from the replacement's transcript and sends again, once each, in the order and the mode you sent them (a steer still steers the running turn, a follow-up still waits for it), the messages the replacement does not have, such as messages that were still queued. The header then shows how many were redelivered. Messages you sent stay queued for the stage even if you close its chat before they arrive, and they are delivered when the stage runs again. If the stage or its run ends first, the header shows how many messages were not delivered.
+
+A child on a local worker can ask for input. A `ctx.ui` prompt (`input`, `confirm`, `select`, `editor`) shows on its stage like any workflow prompt: answer it in the stage chat or with the workflow tool's `answer` action, and the answer goes to the worker. A question a stage asks with `ask_user_question` shows the same form in its stage chat as for any stage; answer it there or with the workflow tool's `answer` action. A `ctx.ui.custom` prompt cannot be shown outside the worker that raised it: in a child on a local worker it fails the child with an error saying so. Use `input`, `confirm`, `select` or `editor` there, or run that child in process. If the worker dies while a `ctx.ui` prompt waits for its answer, the prompt shows again once the replacement worker reaches it; answer that one. Prompts answered before the worker died are not asked again. An `ask_user_question` form still waiting when the worker died shows again in the stage chat once the replacement worker resumes the stage, and your answer goes to the stage as that question's answer. A stage chat you keep open meanwhile shows the question the replacement asks, so you can answer there without reopening the stage. An answer you give after the worker died but before the replacement asks again is kept and given to that same question, so you are not asked twice. If the replacement asks a different question at that point (for example, one whose text depends on data), that question replaces the old one, an open stage chat shows it, and the kept answer is dropped.
+
+Only the stages you have open stream to the root process. A pool with many workers sends nothing extra for stages nobody is watching.
+
+When the stage finishes, close the chat and open the stage again to continue in post-mortem chat. A finished stage that ran on a local worker reopens for post-mortem chat in the same session and after a restart.
+
 ### Worker startup and failures
 
 Each worker process must report that it is ready within `localWorkers.startupTimeoutMs` milliseconds. By default the deadline is 30000 ms, scaled up when the pool has more workers than the machine has CPU cores or the machine is already busy: it is 30000 ms times (worker count + 1-minute load average) ÷ CPU cores, at least 30000 ms and at most 600000 ms. When a pool starts, it runs children as soon as one worker is ready. A worker that exits or times out during that startup is left out of the pool, and the run fails only when no worker starts. A replacement worker that cannot start fails the run. `startupTimeoutMs` is not saved with the root, so you can change it before resuming. If a run fails with `Local worker startup timed out after … ms: workers were too slow to start`, the machine could not start the workers in time; set `workflows.localWorkers.startupTimeoutMs` (or `localWorkers.startupTimeoutMs` in the SDK) to a higher value, or use fewer workers.
 
 A worker that exits is detected immediately, and its child is replayed from its last committed checkpoint on a replacement worker. A worker that is still running keeps its child as long as it keeps responding, even when the pool is briefly too busy to process its heartbeats. Only a running worker that has not responded for `localWorkers.leaseMs` milliseconds (30000 by default) is stopped and its child replayed. When a root is resumed after its process crashed, children that were held by the crashed process's workers are replayed on the new workers right away.
 
-A worker that exits or is killed while it runs a child does not stop the root. The root fences that worker's attempt and replays the child from its last committed checkpoint on a replacement worker, up to three attempts per child.
+A worker that exits or is killed while it runs a child does not stop the root. The root fences that worker's attempt and replays the child from its last committed checkpoint on a replacement worker, up to three attempts per child. A child that loses its third worker fails alone with `worker_retry_limit`; the pool and the root's other children keep running.
 
 If the root process exits, even when it is killed, the pool's coordinator and workers exit with it. Resume the root to continue its children. If the coordinator process itself dies, its workers exit with it, and each pooled child the root is waiting on fails with the retryable `worker_lost` fault and the message `Local worker pool coordinator exited (…)`.
 

package/npm-shrinkwrap.json

@@ -1,16 +1,16 @@
 {
 	"name": "@bastani/atomic",
-	"version": "0.9.45",
+	"version": "0.9.46",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "@bastani/atomic",
-			"version": "0.9.45",
+			"version": "0.9.46",
 			"license": "MIT",
 			"dependencies": {
-				"@bastani/atomic-natives": "0.9.45",
-				"@bastani/pi-ai": "0.9.45",
+				"@bastani/atomic-natives": "0.9.46",
+				"@bastani/pi-ai": "0.9.46",
 				"@earendil-works/pi-agent-core": "1.4.0",
 				"@earendil-works/pi-codemode": "1.4.0",
 				"@earendil-works/pi-tui": "1.4.0",
@@ -36,7 +36,7 @@
 				"open": "^11.0.1",
 				"p-limit": "^7.3.2",
 				"proper-lockfile": "4.1.2",
-				"quickjs-wasi": "3.6.2",
+				"quickjs-wasi": "3.6.3",
 				"semver": "7.8.5",
 				"turndown": "^7.2.0",
 				"typebox": "1.3.27",
@@ -427,18 +427,18 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.46.tgz",
 			"license": "MIT",
 			"optionalDependencies": {
-				"@bastani/atomic-natives-darwin-arm64": "0.9.45",
-				"@bastani/atomic-natives-darwin-x64": "0.9.45",
-				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.45",
-				"@bastani/atomic-natives-linux-arm64-musl": "0.9.45",
-				"@bastani/atomic-natives-linux-x64-gnu": "0.9.45",
-				"@bastani/atomic-natives-linux-x64-musl": "0.9.45",
-				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.45",
-				"@bastani/atomic-natives-win32-x64-msvc": "0.9.45"
+				"@bastani/atomic-natives-darwin-arm64": "0.9.46",
+				"@bastani/atomic-natives-darwin-x64": "0.9.46",
+				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.46",
+				"@bastani/atomic-natives-linux-arm64-musl": "0.9.46",
+				"@bastani/atomic-natives-linux-x64-gnu": "0.9.46",
+				"@bastani/atomic-natives-linux-x64-musl": "0.9.46",
+				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.46",
+				"@bastani/atomic-natives-win32-x64-msvc": "0.9.46"
 			},
 			"engines": {
 				"bun": ">=1.4.2",
@@ -446,8 +446,8 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives-darwin-arm64": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -458,8 +458,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-darwin-x64": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -470,8 +470,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-gnu": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -485,8 +485,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-musl": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -500,8 +500,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-gnu": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -515,8 +515,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-musl": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -530,8 +530,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-arm64-msvc": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -542,8 +542,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-x64-msvc": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.46.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -554,15 +554,15 @@
 			"optional": true
 		},
 		"node_modules/@bastani/pi-ai": {
-			"version": "0.9.45",
-			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.45.tgz",
+			"version": "0.9.46",
+			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.46.tgz",
 			"license": "MIT",
 			"dependencies": {
 				"@anthropic-ai/sdk": "0.129.0",
 				"@aws-sdk/client-bedrock-runtime": "3.1127.0",
 				"@earendil-works/pi-telemetry": "1.4.0",
 				"@google/genai": "2.21.0",
-				"@smithy/node-http-handler": "4.12.1",
+				"@smithy/node-http-handler": "4.13.0",
 				"http-proxy-agent": "9.1.0",
 				"https-proxy-agent": "9.1.0",
 				"openai": "7.19.0",
@@ -576,6 +576,20 @@
 				"node": ">=22.19.0"
 			}
 		},
+		"node_modules/@bastani/pi-ai/node_modules/@smithy/node-http-handler": {
+			"version": "4.13.0",
+			"resolved": "https://registry.npmjs.org/@smithy/node-http-handler/-/node-http-handler-4.13.0.tgz",
+			"integrity": "sha512-/GGcPoNJ2nzGytdAanpbx7mpp9Coa8LP+/Rpmbktr8YeLuIXs9B0SEz+X3AeonHdyzOIFJdKbN7jOZ+Tj+pMGw==",
+			"license": "Apache-2.0",
+			"dependencies": {
+				"@smithy/core": "^3.37.0",
+				"@smithy/types": "^4.19.0",
+				"tslib": "^2.6.2"
+			},
+			"engines": {
+				"node": ">=18.0.0"
+			}
+		},
 		"node_modules/@bastani/pi-ai/node_modules/agent-base": {
 			"version": "9.0.0",
 			"resolved": "https://registry.npmjs.org/agent-base/-/agent-base-9.0.0.tgz",
@@ -681,6 +695,12 @@
 				"node": ">=22.19.0"
 			}
 		},
+		"node_modules/@earendil-works/pi-codemode/node_modules/quickjs-wasi": {
+			"version": "3.6.2",
+			"resolved": "https://registry.npmjs.org/quickjs-wasi/-/quickjs-wasi-3.6.2.tgz",
+			"integrity": "sha512-FCqGtGOrMgzUiIrMNMA2YnsOxCNwo31dzqXvclXUC6xeT35NJLKXQJsvbeCTjvoFAwZgEAPg8U6+KAPDGXn8Mg==",
+			"license": "MIT"
+		},
 		"node_modules/@earendil-works/pi-telemetry": {
 			"version": "1.4.0",
 			"resolved": "https://registry.npmjs.org/@earendil-works/pi-telemetry/-/pi-telemetry-1.4.0.tgz",
@@ -1079,12 +1099,12 @@
 			"license": "Apache-2.0"
 		},
 		"node_modules/@smithy/core": {
-			"version": "3.33.3",
-			"resolved": "https://registry.npmjs.org/@smithy/core/-/core-3.33.3.tgz",
-			"integrity": "sha512-CsOeKq/9kA3y6VJHt+/+VTCtBaxJ4OTFpgrjIUhPpDIKxBci1k2bJaQASF2h/ELWrulGp+t97DZ0mevfAD8idg==",
+			"version": "3.37.0",
+			"resolved": "https://registry.npmjs.org/@smithy/core/-/core-3.37.0.tgz",
+			"integrity": "sha512-97imTcCyiPd8k0e9+ts/Sp0W65Dn9Ti357J7M09Ov4tI8Q1JDJVFSoAJtjEVKqfHEr3Pdo2jfolqKCaaiszH0g==",
 			"license": "Apache-2.0",
 			"dependencies": {
-				"@smithy/types": "^4.17.2",
+				"@smithy/types": "^4.19.0",
 				"tslib": "^2.6.2"
 			},
 			"engines": {
@@ -1148,9 +1168,9 @@
 			}
 		},
 		"node_modules/@smithy/types": {
-			"version": "4.18.0",
-			"resolved": "https://registry.npmjs.org/@smithy/types/-/types-4.18.0.tgz",
-			"integrity": "sha512-CgB6HHWer/vrKps24ulRIbpcpb7K4xAU7SkZ7YHzBPlwHsvsrCJFEXK421s+cJzX+ZrqtA/TuU5w1HzI7k9N8A==",
+			"version": "4.19.0",
+			"resolved": "https://registry.npmjs.org/@smithy/types/-/types-4.19.0.tgz",
+			"integrity": "sha512-r7jh49VJxGerfAcTQA6gXcKc+98zOp/tqRwzYjgOE+iSQsP6cEU1hq2QzbuipmP68QtYdY9wKEhiCQZIzHgZ4Q==",
 			"license": "Apache-2.0",
 			"dependencies": {
 				"tslib": "^2.6.2"
@@ -3453,9 +3473,9 @@
 			}
 		},
 		"node_modules/quickjs-wasi": {
-			"version": "3.6.2",
-			"resolved": "https://registry.npmjs.org/quickjs-wasi/-/quickjs-wasi-3.6.2.tgz",
-			"integrity": "sha512-FCqGtGOrMgzUiIrMNMA2YnsOxCNwo31dzqXvclXUC6xeT35NJLKXQJsvbeCTjvoFAwZgEAPg8U6+KAPDGXn8Mg==",
+			"version": "3.6.3",
+			"resolved": "https://registry.npmjs.org/quickjs-wasi/-/quickjs-wasi-3.6.3.tgz",
+			"integrity": "sha512-gDXhV2yi6oyVcGPYnACIzVbMNsmMlwjryhh3vAk8K589Xk/J06fb2SGbx8GJQnxyJv43pdrNbfP815dTkSYb9g==",
 			"license": "MIT"
 		},
 		"node_modules/range-parser": {