Lite docs: a conversation with encrypted history stays on its upstream (Lite 2026.10.28)

src/content/docs-lite/en/codex-other-models.md

@@ -31,7 +31,7 @@ ThinkWatch Lite connects Codex to a gateway on the same computer that accepts th
 
 - **Codex's model table.** Codex carries metadata for its own models, such as the context window, inside the program. A model it does not know, such as a Claude or Gemini model, runs on fallback metadata with a 272,000-token context window, and Codex warns: "Model metadata for `<model>` not found. Defaulting to fallback metadata; this can degrade performance and cause issues." For a model with a smaller window, `model_context_window` in `config.toml` sets the window Codex assumes. The gateway's model list does not appear in Codex's model picker, as Codex expects a catalog in its own format.
 - **Conversion.** Requests and streamed answers are converted in both directions. Traffic marks such requests **Converted**; fields the target format cannot carry are dropped and listed in the request details. Server-side tools such as web search run only at the provider they belong to and are dropped in conversion. Codex accepts only `responses` for `wire_api`, so this conversion is what makes a Chat Completions-only relay usable.
-- **Tools, history and compaction.** From ThinkWatch Lite 2026.10.11, every tool Codex declares reaches the upstream, including those it lists in its input rather than in `tools`, and tool calls come back under the names Codex gave them. Local shell calls, tool search and reasoning-effort changes in the history are converted as well. Compacting a long session works: the upstream writes a summary, which Codex keeps as its compaction and sends back in later requests. A compaction encrypted by OpenAI cannot be read by another upstream, and a request that carries one is refused with an error saying so. Instructions Codex adds in the middle of a conversation stay where they are, so the system prompt stays the same from turn to turn and the prompt cache keeps hitting.
+- **Tools, history and compaction.** From ThinkWatch Lite 2026.10.11, every tool Codex declares reaches the upstream, including those it lists in its input rather than in `tools`, and tool calls come back under the names Codex gave them. Local shell calls, tool search and reasoning-effort changes in the history are converted as well. Compacting a long session works: the upstream writes a summary, which Codex keeps as its compaction and sends back in later requests. History that OpenAI encrypted, such as a compaction or the messages Codex sub-agents send each other, can be read only by the account that encrypted it. From ThinkWatch Lite 2026.10.28, a conversation that carries it goes back to that upstream even after its route changes; if that upstream was removed, or another upstream is asked to read it, the request fails with an error saying so. Instructions Codex adds in the middle of a conversation stay where they are, so the system prompt stays the same from turn to turn and the prompt cache keeps hitting.
 - **Credentials.** With `requires_openai_auth = false`, Codex authenticates to the gateway with its own key and sends no OpenAI key or ChatGPT token. A ChatGPT account signed in from the app can still serve the OpenAI models next to Claude or Gemini: each request goes to an upstream that lists the model asked for.
 - **Sessions.** Codex lists sessions started before and after connecting separately. `codex resume <session ID> -c model_provider=thinkwatch` continues an earlier session through the gateway. After **Restore…**, sessions started while connected can still be opened, and go straight to OpenAI.
 - **Cost.** A rewritten request is priced as the model actually sent. Codex marks no prompt-cache breakpoints, so on a route to an upstream in Anthropic Messages format, or to a Claude model on Bedrock that AWS lists for prompt caching (Claude 3.5 Sonnet v2, Claude 3.7 Sonnet, and Claude 4.5 and later), the gateway marks the tools, the system prompt and the last two user turns, and each turn reads what the previous one cached. Older Claude models on Bedrock, such as Sonnet 4, get no marks, and an upstream that refuses them receives the request again without them. Cache writes and reads are priced at the price sheet's cache rates; at Anthropic, writes cost 25% more than input and reads a tenth of it.

src/content/docs-lite/en/failover-and-load-balancing.md

@@ -34,7 +34,7 @@ A strategy only sets the order; every member remains available for failover.
 - **Usage limits.** **Usage limits** under **Advanced settings** in the upstream dialog (for a ChatGPT account, below its **Concurrency limit**) keep an upstream within the quota of the relay or plan behind it. Each caps the requests, tokens or cost in USD per minute, hour, day, week or month; a minute or hour limit can also span several, from 1 to 60 minutes or 1 to 24 hours, such as 10,000,000 tokens every 5 minutes. When a minute or hour limit is full, the upstream is passed over like a full one: a conversation that stays on it waits for room, and other requests go to the next member. When a day, week or month limit is used up, requests go to the next member until it resets, at local midnight, on Monday or on the 1st; none waits for it. Every request sent to the upstream counts, except one it answered with 429. Tokens and cost come from the answer: tokens are uncached input, cache writes and output, and **Count cache reads** adds cache reads to a token limit; a free upstream, and a model without a price, count as $0 toward a cost limit. Being at a limit is not a failure. The Upstreams page tags such an upstream **Usage limit reached · back in 1 min 10 s**, or **Daily usage limit reached** (weekly, monthly) for a used-up period, and hovering over the tag or the **Quota / billing** cell lists each limit with its use. After a restart, day, week and month limits are added up again from the request records, which must therefore be kept for at least 1, 7 or 31 days; minute and hour limits start empty.
 - **Waiting.** A request waits for upstreams that cannot take it yet, because they are full, rate limited or at a minute or hour usage limit, for at most **Wait at most** in Settings › Failover: 120 seconds by default, from 0 to 600, with 0 for no wait. The same time also covers a key's per-minute and per-hour usage limits. A conversation that stays on an upstream for its prompt cache waits for it when it can recover within that time, and otherwise moves on, where its cache starts over; any other request goes to the next member at once. When no member is left, the request waits for the first one that becomes available. A streamed request receives the response headers and keep-alive comments meanwhile (Gemini clients get the headers only), so the client sees only a slower first token. If none becomes available in time, the client receives a 429 with `Retry-After` set to when the first one will, or the error of an earlier attempt when one was sent. When every member has used up a day, week or month limit, `Retry-After` gives the earliest reset and the response tells the client not to retry before then. On the Traffic page, a waiting request is **Queued**, with the upstreams it waits for in place of the upstream and, on hover, how long it waits at most; its **Routing** tab gives each wait, such as **Queued 12 s**.
 - **Pauses.** A failing upstream is paused for as long as Settings › Failover sets: by default 60 seconds after 3 **Consecutive failures**, doubling up to 600; 30 minutes for **Insufficient balance**; until the reset time, or 60 minutes, for **Quota used up**. A rule with a single upstream is never held back by these pauses, and when every member is paused they are tried anyway. A request aborted on the Traffic page does not count against its upstream.
-- **Sessions and prompt cache.** Within a turn, while the client sends tool results back, requests keep the rule chosen at the start of the turn and the upstream that answered. Across turns, a conversation stays with the upstream that answered last if that answer read or wrote at least 1,024 cached tokens within the last five minutes; moving would rebuild the cache at full price. Otherwise, or when that upstream is paused after failures, is rate limited past the wait limit, or has used up a day, week or month limit, the strategy orders the members again, which is when **Round robin** moves on. The **Conversation** line on a request's **Routing** tab shows when a request stayed.
+- **Sessions and prompt cache.** Within a turn, while the client sends tool results back, requests keep the rule chosen at the start of the turn and the upstream that answered. Across turns, a conversation stays with the upstream that answered last if that answer read or wrote at least 1,024 cached tokens within the last five minutes; moving would rebuild the cache at full price. Otherwise, or when that upstream is paused after failures, is rate limited past the wait limit, or has used up a day, week or month limit, the strategy orders the members again, which is when **Round robin** moves on. A conversation carrying history that an OpenAI Responses upstream encrypted, such as a ChatGPT account's, goes back to that upstream whatever the rule now picks, since no other upstream can read it; when only reasoning is encrypted, that upstream is tried first and the others remain as fallbacks. The **Conversation** line on a request's **Routing** tab shows when a request stayed.
 - **Same model name.** Every member is asked for the model the client sent, or the name a rule rewrote it to. A member whose model list lacks it is skipped; one without a list is tried, and its 404 moves the request on. A model that a member serves but leaves out of its list can be added with **Add models…** in the member's model list on the Upstreams page, or in the **Models** section of its edit dialog.
 - **Falling back to another model.** Add a rule with the condition **Selected upstream** set to the backup upstream, **On match** set to **Continue matching**, and its model in **Change model to** under **Parameter rewrites**. Such a rule is evaluated for each upstream as it is tried, failover included. The changed model no longer hits the cached prompt, and the request is priced by the name sent.
 

src/content/docs-lite/zh-CN/codex-other-models.md

@@ -31,7 +31,7 @@ ThinkWatch Lite 把 Codex 接到本机的网关上，网关接收 OpenAI Respons
 
 - **Codex 的内置模型表。**Codex 把自家模型的元数据（上下文窗口等）编在程序里。它不认识的模型，例如 Claude 或 Gemini 的模型，按兜底元数据运行，上下文窗口为 272,000 token，并提示「Model metadata for `<模型>` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.」。模型的上下文窗口更小时，可在 `config.toml` 中用 `model_context_window` 设定 Codex 采用的窗口。网关的模型列表不会出现在 Codex 的模型选择中，因为 Codex 要求的是它自己格式的模型目录。
 - **格式转换。**请求和流式回答双向转换。「流量」页把这类请求标为「已转换」，目标格式无法承载的字段被丢弃，并在请求详情中列出。网页搜索这类服务端工具只能由所属的服务商执行，转换时被丢弃。Codex 的 `wire_api` 只支持 `responses`，只提供 Chat Completions 的中转正是靠这一转换才能使用。
-- **工具、历史与压缩。**自 ThinkWatch Lite 2026.10.11 起，Codex 声明的所有工具都会发给上游，包括写在输入中而不在 `tools` 里的工具，工具调用按 Codex 给出的名称返回。历史中的本地 shell 调用、工具搜索和推理强度的变更同样会转换。长会话的上下文压缩可以正常进行：由上游写出摘要，Codex 把它作为压缩结果保存，并在之后的请求中带回。OpenAI 加密的压缩结果无法由其他上游读取，带有这类内容的请求会被拒绝，并说明原因。Codex 在对话中途加入的指令留在原位，系统提示词因此每轮保持不变，提示缓存持续命中。
+- **工具、历史与压缩。**自 ThinkWatch Lite 2026.10.11 起，Codex 声明的所有工具都会发给上游，包括写在输入中而不在 `tools` 里的工具，工具调用按 Codex 给出的名称返回。历史中的本地 shell 调用、工具搜索和推理强度的变更同样会转换。长会话的上下文压缩可以正常进行：由上游写出摘要，Codex 把它作为压缩结果保存，并在之后的请求中带回。OpenAI 加密的历史（例如压缩结果、Codex 子代理之间的消息）只有加密它的账号能够读取。自 ThinkWatch Lite 2026.10.28 起，带有这类内容的对话在路由改动后仍送回该上游；该上游已被删除，或由其他上游读取时，请求失败并说明原因。Codex 在对话中途加入的指令留在原位，系统提示词因此每轮保持不变，提示缓存持续命中。
 - **凭据。**`requires_openai_auth = false` 使 Codex 用自己的网关密钥连接网关，不发送 OpenAI 密钥或 ChatGPT 令牌。应用内登录的 ChatGPT 账号仍可同时作为 OpenAI 模型的上游：每个请求都交给模型列表中有所请求模型的上游。
 - **会话。**接管前后的会话在 Codex 中分开显示。运行 `codex resume <会话 ID> -c model_provider=thinkwatch` 可以通过网关继续之前的会话。「还原…」之后，接管期间的会话仍可打开，此时直连 OpenAI。
 - **费用。**改写过模型名的请求按实际发出的模型计价。Codex 不标注提示缓存断点，因此发往 Anthropic Messages 格式的上游，或 Bedrock 上 AWS 列为支持提示缓存的 Claude 模型（Claude 3.5 Sonnet v2、Claude 3.7 Sonnet 以及 Claude 4.5 起的模型）时，网关在工具、系统提示词和最后两轮用户消息处标注，每一轮都能读取上一轮写入的缓存。Bedrock 上更早的 Claude 模型（如 Sonnet 4）不标注；上游拒绝这些标注时，网关去掉标注重新发送一次。缓存写入与读取按价目表的缓存单价计费；Anthropic 的缓存写入比输入贵 25%，读取为输入的十分之一。

src/content/docs-lite/zh-CN/failover-and-load-balancing.md

@@ -34,7 +34,7 @@ ThinkWatch Lite 把每个中转站的每把密钥建成一个上游，再把多
 - **用量上限。**上游对话框「高级设置」中的「用量上限」（ChatGPT 账号在「并发上限」下方）让上游不超出中转站或套餐本身的额度。每条上限限定每分钟、小时、天、周或月最多使用的请求次数、token 数或费用（美元）；分钟与小时上限还可以跨越多个单位，可设 1 到 60 分钟或 1 到 24 小时，例如每 5 分钟 10,000,000 token。分钟或小时上限已满时，上游按并发已满处理：留在它上面的对话等待空出用量，其他请求交给下一个成员。天、周或月上限用满后，请求交给下一个成员，直到本地时间零点、周一或每月 1 日重置，不等待它。发给上游的每个请求都计入，上游返回 429 的除外。token 与费用按回答计算：token 为未命中缓存的输入、缓存写入与输出，勾选「计入缓存读取」后 token 上限也计入缓存读取；不计费的上游和没有价格的模型按 0 计入费用上限。达到上限不算失败。上游页把这样的上游标为「用量已满 · 1 分 10 秒后恢复」，用满一整期的标为「今日用量已满」（或本周、本月），悬停在标签或「额度 / 计费」一格上可以查看每条上限的用量。重启之后，天、周、月上限的用量按请求记录重新累计，因此请求记录至少要保留 1、7 或 31 天；分钟与小时上限从零开始。
 - **等待。**上游并发已满、正在限流或达到分钟、小时用量上限而暂时无法接收时，请求最多等待「设置 › 故障转移」中的「最多等待」，默认 120 秒，可设 0 到 600 秒，0 表示不等待。密钥的分钟、小时用量上限共用这段时间。为保留提示缓存而留在某个上游的对话，在它能于这段时间内恢复时等待它，否则换到下一个成员，在那里重新建立缓存；其他请求直接交给下一个成员。没有可用的成员时，请求等待最先恢复的那一个。等待期间，流式请求先收到响应头和保活注释（Gemini 客户端只收到响应头），客户端只会感到首 token 慢了一些。到时仍没有成员可用，客户端收到 429，`Retry-After` 为最早恢复的时刻；此前已有尝试发出时，返回那次尝试的错误。所有成员都用满了天、周或月上限时，`Retry-After` 为最早的重置时刻，并告知客户端在此之前不要重试。流量页把等待中的请求标为「排队中」，在上游的位置列出它等待的上游，悬停可以查看最晚等到何时；请求的「路由」标签写明每次等待的时长，例如「排队 12 秒」。
 - **暂停。**失败的上游按「设置 › 故障转移」暂停使用，默认值为：「连续失败」3 次后暂停 60 秒，此后每次加倍，最长 600 秒；「余额不足」暂停 30 分钟；「额度用完」暂停到重置时刻，未给出时暂停 60 分钟。只有一个上游的规则不受这些暂停影响；所有成员都在暂停时，网关仍会逐个尝试。在流量页手动中止的请求不计入上游的失败。
-- **会话与提示缓存。**同一轮之内（客户端回传工具结果期间），请求沿用这一轮开头确定的规则和回答它的上游。跨轮时，如果上次回答在五分钟以内、且读写了至少 1,024 个缓存 token，对话继续使用该上游，因为换到别处要按全价重建缓存；否则，或者该上游因失败而暂停、限流要到等待时限之后才结束、已用满天、周或月上限时，由策略重新排序，「轮询」正是在这时轮到下一个成员。请求「路由」标签中的「对话延续」一行说明请求是否因此留在原上游。
+- **会话与提示缓存。**同一轮之内（客户端回传工具结果期间），请求沿用这一轮开头确定的规则和回答它的上游。跨轮时，如果上次回答在五分钟以内、且读写了至少 1,024 个缓存 token，对话继续使用该上游，因为换到别处要按全价重建缓存；否则，或者该上游因失败而暂停、限流要到等待时限之后才结束、已用满天、周或月上限时，由策略重新排序，「轮询」正是在这时轮到下一个成员。对话带有 OpenAI Responses 类上游（如 ChatGPT 账号）加密的历史时，由于其他上游无法读取，无论规则现在选择哪个上游，对话都送回该上游；加密的只有推理内容时，先尝试该上游，其余成员仍作为备选。请求「路由」标签中的「对话延续」一行说明请求是否因此留在原上游。
 - **模型名相同。**每个成员收到的都是客户端请求的模型名，或者规则改写之后的模型名。模型列表中没有该模型的成员会被跳过；没有模型列表的成员照常尝试，它返回 404 时请求换到下一个。成员能服务、却没有列进模型列表的模型，可以在上游页该成员的模型列表中选择「添加模型…」加上，也可以在它的编辑对话框的「模型」一节中添加。
 - **回退到另一个模型。**添加一条规则：条件「选定上游」选择后备上游，「命中后」选择「继续匹配」，在「改写参数」的「模型改为」中填写它的模型。这样的规则在每次选定上游之后判断，故障转移之后同样适用。更换模型后已缓存的 prompt 不再命中，费用按发出的模型名计算。