ThinkWatch Lite 2026.9.21

Upgrade notes: the bundled core is now 0.53.0, which speaks control-plane protocol 26. A remote server has to run core 0.53.0 too: this version does not connect to an older core, and 2026.9.20 and earlier do not connect to 0.53.0. Request history is kept. Upstreams now see ThinkWatch's User-Agent instead of the client's, so an upstream that admits only certain clients, such as Kimi For Coding, Bailian Coding Plan or a relay restricted to official clients, needs the new Forward client identity switch in its connection settings.

What upstreams receive:

• Each upstream receives the request and only the headers its API needs. Before, almost every header a client sent went along: Claude Code's User-Agent, x-app, SDK details and session ID, Gemini CLI's installation ID, and a browser client's cookies and origin. Upstreams now see ThinkWatch's User-Agent and the credential and headers configured for the upstream. From the client's request they get only the headers of the upstream's own protocol: anthropic-* for Anthropic, Idempotency-Key and X-Client-Request-Id for OpenAI, and none for Gemini.
• Identity fields that clients fill in on their own are removed from the request body, such as Claude Code's metadata.user_id, which holds a device ID, an account ID and a session ID.
• Forward client identity, a new switch in the connection section of the upstream dialog, sends that upstream the client's own User-Agent and identity, unchanged. It is off by default, including for upstreams created by the Z.ai sign-in, and ChatGPT accounts do not offer it.

ChatGPT accounts:

• Newer models that the account can use, such as GPT-6-Luna, appear in the upstream's model list and can be requested. Before, the gateway answered "No upstream serves model gpt-6-luna" even though the account had the model.
• Requests from the Codex in the ChatGPT app no longer pass that app's attestation and installation ID on to OpenAI. On one account, OpenAI revoked the sign-in within seconds of the first such request.
• Request bodies are compressed with zstd, as Codex does, so long conversations upload faster.

Downloads

Platform	File
macOS, Apple silicon	ThinkWatch-Lite-2026.9.21-arm64.dmg
Windows, x64	ThinkWatch-Lite-2026.9.21-x64-setup.exe
Windows, ARM64	ThinkWatch-Lite-2026.9.21-arm64-setup.exe
Linux, x86_64	ThinkWatch-Lite-2026.9.21-x86_64.AppImage
Linux, aarch64	ThinkWatch-Lite-2026.9.21-aarch64.AppImage

Each file is published with a .sha256 file beside it. latest.json is the manifest for in-app updates, and install.sh is the Linux install script.

On macOS, Homebrew installs the same disk image:

brew install --cask thinkwatchproject/tap/thinkwatch-lite

On Linux, the install script downloads the AppImage for the machine's architecture, checks its SHA-256 and installs it as ~/Applications/ThinkWatch-Lite.AppImage:

curl -fsSL https://github.com/ThinkWatchProject/ThinkWatch-Lite/releases/latest/download/install.sh | sh

Both commands install the latest release. First-launch steps for each platform, such as removing the quarantine attribute from a copy downloaded on macOS, are described in the README.

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 macOS:

shasum -a 256 -c ThinkWatch-Lite-2026.9.21-arm64.dmg.sha256

On Linux:

sha256sum -c ThinkWatch-Lite-2026.9.21-x86_64.AppImage.sha256

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

(Get-FileHash .\ThinkWatch-Lite-2026.9.21-x64-setup.exe).Hash -eq (Get-Content .\ThinkWatch-Lite-2026.9.21-x64-setup.exe.sha256).Split()[0]

The Homebrew cask and the Linux install script check the SHA-256 themselves.

What's Changed

• Use core v0.53.0: each upstream gets only what it needs; forward the client's identity only where an upstream asks for it by @fylorn in #238
• chore: 2026.9.21 by @fylorn in #239

Full Changelog: v2026.9.20...v2026.9.21