ThinkWatch Core 0.52.1

This release fixes two routing problems: a routing rule that rewrites the model was judged by the model the client asked for, and requests in the OpenAI Responses and Gemini formats were never recognized as part of a conversation.

Upgrade notes

• The control-plane protocol version is unchanged (25) and so is the request store's schema (21). ThinkWatch Lite 2026.9.18 includes 0.51.0 (protocol 24) and does not connect to 0.52.x: a server used with it stays on 0.51.0 until the app is updated to a release that includes 0.52.1.
• New message codes: gw.model.no_upstream_rewritten and gw.model.not_allowed_rewritten.

Rewriting the model. A rule that sets the model, for example to send the Claude-style names that Claude Desktop requires to a GLM or DeepSeek upstream, was refused with "No upstream serves model …" whenever the target upstream lists its models. Admission, skipping the candidates that cannot serve a request, and the cheapest group's price comparison all looked at the model the client wrote, before any rule rewrote it. They now look at the model each upstream will actually be asked for, including a rewrite that applies to one upstream only (provider_would_be), so admission runs after the rules have decided. When a rewritten model is not served, the error names both models. The routing dry run judges the candidates the same way.

Conversations in the Responses and Gemini formats. Requests from Codex and other clients that use the OpenAI Responses or Gemini format were never assigned to a session, because the fingerprint read only the Anthropic and Chat Completions fields. A load-balancing group with session affinity, which is the default, sent all of them to its first upstream, and the traffic view did not group them into sessions. The fingerprint now also reads instructions and input, and systemInstruction and contents, and uses the request's prompt_cache_key when it has one. Codex sends one per conversation, and Codex conversations started in the same repository open with identical text.

Downloads

Platform	Binary	Archive for server installation
Linux, x86_64	twcore-x86_64-unknown-linux-gnu	twcore-x86_64-unknown-linux-gnu.tar.gz
Linux, aarch64	twcore-aarch64-unknown-linux-gnu	twcore-aarch64-unknown-linux-gnu.tar.gz
macOS, Apple silicon	twcore-aarch64-apple-darwin	—
Windows, x64	twcore-x86_64-pc-windows-msvc.exe	—
Windows, ARM64	twcore-aarch64-pc-windows-msvc.exe	—

Each file is published with a .sha256 file beside it. A Linux archive contains twcore, the systemd unit twcore.service and LICENSE. ThinkWatch Lite includes its own copy of twcore; the files here are for running core separately, such as on a server.

Server installation

On Linux (x86_64 or aarch64), the install script sets up twcore as a systemd service. This installs 0.52.1:

curl -fsSL https://raw.githubusercontent.com/ThinkWatchProject/ThinkWatch-Core/main/scripts/install.sh | sudo sh -s -- --version 0.52.1

An installation made with the script switches to 0.52.1 with:

sudo twcore upgrade --version 0.52.1 --restart

Configuration, the remote control port and connecting ThinkWatch Lite are described in docs/server.md.

Verifying a download

A .sha256 file holds the SHA-256 of the file followed by its name. With both files in the current directory, on Linux:

sha256sum -c twcore-x86_64-unknown-linux-gnu.tar.gz.sha256

On macOS:

shasum -a 256 -c twcore-aarch64-apple-darwin.sha256

On Windows, in PowerShell, the following prints True when the binary matches:

(Get-FileHash .\twcore-x86_64-pc-windows-msvc.exe).Hash -eq (Get-Content .\twcore-x86_64-pc-windows-msvc.exe.sha256).Split()[0]

The install script and twcore upgrade check the SHA-256 themselves.

What's Changed

• fix(gateway): judge a rewritten model by the name it sends; tell Codex and Gemini conversations apart by @fylorn in #215
• chore: v0.52.1 by @fylorn in #216

Full Changelog: v0.52.0...v0.52.1