ThinkWatch

Images

• ghcr.io/thinkwatchproject/think-watch-server:3.10.0
• ghcr.io/thinkwatchproject/think-watch-web:3.10.0

Helm

helm install think-watch ./think-watch-3.10.0.tgz \
  --namespace thinkwatch --create-namespace

Upstreams that fail for the moment before any of the answer reached the client are now tried again instead of the error going straight back, and a model can set the reasoning effort its requests carry, with the gateway adapting when an upstream refuses a level. The thinkwatch-core crates move from v0.81.0 to v0.83.1.

One new setting (gateway.retry_wait_secs), one new column (models.reasoning_effort, added on startup) and one new metric; no route or setting is removed.

Read before upgrading

• models gains a nullable column, reasoning_effort. The schema applied at startup adds it (ADD COLUMN IF NOT EXISTS); existing models keep it empty and their requests go out unchanged.
• A reasoning level an upstream refuses is changed and sent again, for every model. This applies whether or not the model has a reasoning setting and cannot be turned off: when an upstream answers 400 because of the reasoning level a request carries, the request goes out once more with a level the upstream accepts, or without one, and the change is remembered for that provider and model for 7 days. The level sent can differ from the one the caller asked for, in either direction.
• A request whose upstreams fail for the moment can take up to two minutes to fail. When every route of a model failed with an overload or a server error, or could not be reached, before any of the answer reached the client, the gateway now waits and sends the request again instead of returning the error at once, for up to gateway.retry_wait_secs (120 seconds by default) after the request arrived. Clients and load balancers with a shorter timeout than that may give up first. Set gateway.retry_wait_secs to 0 to keep the earlier behaviour.
• A whole answer that runs into the request timeout is now an error with a log row. A non-streaming request's upstream attempt is cut 2 seconds before the gateway's 120-second request timeout (counted from when the request reached the gateway port), and the client gets the last upstream error, or a 504 ProviderTimeout when there was none, with its gateway_logs row, instead of an empty 408. A retry starts only when its wait and another attempt as long as the last one fit before then.
• A stream's opening events arrive with its first content. While a stream can still be sent again, what the upstream sends before any content (Anthropic message_start and ping, Responses response.created and response.in_progress, a Chat chunk with only the role) is held back and goes out together with the first content. While it is held, and while the gateway waits to send again, the client receives an SSE comment (: keep-alive) after every 15 seconds without data — except Gemini clients, which never receive one. The status is 200 as before.

Added

• A model can set its reasoning (models.reasoning_effort, the Reasoning control in the model editor): off takes reasoning out of requests that have it on, and a level (low, medium, high, xhigh, max) changes the effort of requests whose reasoning is on. Requests without reasoning, such as title generation, go out unchanged. The setting is written the way each hop's upstream format writes it: with off, OpenAI Chat and Responses upstreams receive none, Gemini 2.5 Flash a thinking budget of 0, and Anthropic and Bedrock upstreams no thinking; Gemini models that cannot stop thinking (2.5 Pro, Gemini 3) get no thinking configuration. The response cache keys on the request together with the setting.
• A reasoning level the upstream refuses is sent again once with one it accepts. On a 400 about the reasoning level, the request goes

Images

• ghcr.io/thinkwatchproject/think-watch-server:3.9.1
• ghcr.io/thinkwatchproject/think-watch-web:3.9.1

Helm

helm install think-watch ./think-watch-3.9.1.tgz \
  --namespace thinkwatch --create-namespace

A conversation whose history a provider encrypted, such as a Codex conversation over OpenAI's Responses API, now stays with that provider instead of failing on every turn once it moves, and a provider that cannot read such history says why. The thinkwatch-core crates move from v0.77.0 to v0.81.0.

No setting, schema or API route changes.

Fixed

• A conversation whose history a provider encrypted goes back to that provider. OpenAI's Responses API with store: false (Codex always sends it) hands the client encrypted state that comes back every turn: reasoning, remote compactions, Codex's messages between agents, encrypted tool output. Only the account that encrypted it can read it, so a conversation that moved to another provider — after five idle minutes, a tripped breaker or a failover — was refused on every turn from then on with invalid_encrypted_content. The gateway now remembers, for 30 days and whatever the affinity settings say, the provider that last answered each conversation (the authenticated user and the request's x-session-id, or else the session header the client sends by itself, such as Codex's session_id; over HTTP and over the WebSocket). The log row's session_id still comes from x-session-id only. A Responses request carrying encrypted content that cannot be left out goes only to that provider: no strategy pick, no failover, and its open breaker does not stop it. When that provider has no route for the model any more, the request is refused up front with 409, naming the provider and saying to start a new conversation. A request carrying only encrypted reasoning goes to that provider first and still fails over. Requests that name no conversation are routed as before. The request's log row records "pinned_by": "encrypted_history" when the provider was picked this way.
• A provider that cannot read a conversation's encrypted history says so. Its refusal, as a 4xx answer or as the error event of a stream that opened with 200, now reaches the caller and the log as SealedHistoryRefused: the provider cannot read this conversation's encrypted history because another provider encrypted it; route the conversation back to that provider or start a new conversation. The upstream's own words follow. It no longer counts against the route's breaker.

Images

• ghcr.io/thinkwatchproject/think-watch-server:3.9.0
• ghcr.io/thinkwatchproject/think-watch-web:3.9.0

Helm

helm install think-watch ./think-watch-3.9.0.tgz \
  --namespace thinkwatch --create-namespace

The Add to ThinkWatch Lite link from a rotated key now carries the key's request limits. A database failure during authentication answers 503 or 500 with the usual JSON error instead of an empty 500, and password hashing no longer runs on the request workers. Monitoring that matches only on 500 sees a database outage during authentication as a 503 from this release on. The thinkwatch-core crates stay at v0.77.0.

No setting, schema or API route changes.

Added

• The rotated-key dialog's Add to ThinkWatch Lite link carries the key's request limits. The key's own enabled, unexpired AI-gateway rules that count requests over a window of whole minutes up to 60, or whole hours up to 24 (the console's 1 minute, 5 minutes, 1 hour, 5 hours and 24 hours among them), go into the link's limits parameter as Lite's rolling windows of the same length; of two rules on one window the smaller count goes, and at most 16 windows, those allowing the fewest requests per second. Token rules stay out, since they count weighted tokens and Lite counts plain ones; so do sliding 7-day rules (Lite's week is a calendar week), budgets, MCP rules and the owner's limits. A link with limits needs ThinkWatch Lite 2026.10.26 or later, which the dialog states under the button. Reading the rules needs rate_limits:read in a scope covering the key; without it, or when the rules cannot be read, the link is built without limits as before. A new key has no limits of its own yet, so its link carries none.

Fixed

• A database outage during authentication is a 503 with an error body, not an empty 500. When the session or API-key check could not reach Postgres (most often a connection-pool timeout), the console and the gateway answered 500 Internal Server Error with no body and, for the permission lookup, no log line. These lookups now answer like every handler does: 503 Service Unavailable with the usual JSON error when the database is unavailable, 500 with it for any other database error, and an error log naming the lookup that failed.
• Password hashing no longer holds up other requests. Logins, password changes and resets, new users, turning off two-factor authentication and first-run setup ran Argon2 (tens of milliseconds of CPU by design) on the server's async workers, so every other request scheduled on that worker waited for it. They now run it on the blocking thread pool, at most one run per CPU at a time as before, so a burst of logins holds no more memory than it did (19 MiB per run). The hashes and the constant-time login are unchanged.

Images

• ghcr.io/thinkwatchproject/think-watch-server:3.8.3
• ghcr.io/thinkwatchproject/think-watch-web:3.8.3

Helm

helm install think-watch ./think-watch-3.8.3.tgz \
  --namespace thinkwatch --create-namespace

Tool-call inspection in streamed answers now decides only on arguments that have settled, and a hit that is recorded carries the whole call. The thinkwatch-core crates move from v0.75.0 to v0.77.0. The web image is built with Node.js 24.22.0 and pnpm 12.14.0.

No setting, schema or API route changes.

Changed

• The thinkwatch-core crates move from v0.75.0 to v0.77.0.
• Since a recorded hit now waits for the complete call, a streamed tool call that never completes (the upstream stream breaks off, or the client leaves, in the middle of it) leaves no tool-inspection row. Such a call was never whole on the client side either. Rules that cut still check the arguments while they arrive.
• The web image's build stage uses Node.js 24.22.0 and pnpm 12.14.0. The served image (nginx) is unchanged.
• The development compose file (deploy/docker-compose.dev.yml) runs Zitadel v4.19.5.

Fixed

• Tool-call inspection no longer judges arguments that are still arriving. A streamed tool call was checked against its arguments as far as they had come in. A host cut off in the middle of its name (http://127 before .0.0.1) looked external, and a pattern anchored at the end could match the half-received tail. A hit now counts only once it is settled; rules that cut still act as early as possible.
• A recorded hit carries the whole call. A hit that is only recorded, and every hit in observe mode, was recorded with the arguments as they stood at the first match. It is now recorded once the call is complete. A Chat Completions call with no finish_reason or [DONE] is checked when the stream ends.
• -T is an upload only in curl. The upload rule took any -T for curl -T, so docker compose exec -T next to a URL was recorded as a file upload.