ThinkWatch: a Rust gateway that puts identity in front of AI APIs and MCP servers

The governance problem ThinkWatch is aimed at

The README opens with a list of failures that will be familiar to anyone who has watched AI tooling spread through an engineering org: API keys hardcoded in .env files and shared in Slack, no record of who used which model, every developer holding direct access to every model and every MCP tool, and monthly bills nobody can attribute. ThinkWatch's answer is a single deployment that sits between clients and providers. The stated audience is organisations, not individuals. The README compares the design to an SSH bastion host, and that analogy is load-bearing: the value comes from being the only path, not from being a convenient one. If traffic can bypass the gateway, the audit trail has holes. That framing also explains why the project ships an admin console on a second port rather than a CLI-only tool. Someone has to manage keys, budgets and upstream credentials, and the README treats that as a browser task.

Two listeners, one port each, and a provider router behind them

The architecture diagram in the README shows two processes. The gateway listens on port 3000 and terminates AI API traffic plus MCP traffic; the console listens on port 3001 and serves the management UI and admin API. Clients listed on the left are Claude Code, Cursor, a custom agent and a CI/CD pipeline. Providers on the right are OpenAI, Anthropic, Google Gemini, Azure OpenAI and AWS Bedrock. The gateway is described as natively serving OpenAI Chat Completions at /v1/chat/completions, Anthropic Messages at /v1/messages, and OpenAI Responses at /v1/responses on that single port, so a client pointed at the gateway keeps its existing SDK shape. Routing is partly automatic: the README says active providers are loaded from the database at startup and registered in the model router, with default prefixes (gpt-, o1-, o3-, o4- for OpenAI, claude- for Anthropic, gemini- for Google) selecting the provider. Azure and Bedrock are the exceptions and require explicit model registration. Format conversion between Anthropic Messages, Gemini, Azure OpenAI and Bedrock Converse is handled behind that unified interface. Streaming is forwarded as SSE pass-through, which the README describes as zero-overhead forwarding with real-time token counting. That last pairing is the one to scrutinise in a deployment: counting tokens while forwarding a stream means the gateway is parsing the stream it claims not to buffer, and the README does not quantify the cost.

Virtual keys, surfaces, and where the MCP design diverges

Authentication is built on virtual keys with a tw- prefix. The README states that the same tw- token works on both the AI gateway and the MCP gateway, gated by a per-key surfaces allowlist. That is a small detail with real consequences: one credential can be scoped to model calls only, tool calls only, or both, which is the kind of separation a CI key needs and a developer laptop key does not. Behind the key sit rotation with grace periods, a per-key inactivity timeout, expiry warnings and background policy enforcement. On the MCP side the README makes an explicit claim about what most competing proxies do: they pin one shared admin token to the server config, so the upstream's audit log records every action as the same service account. ThinkWatch instead propagates the calling user's own OAuth token or PAT to upstreams including GitHub, Notion, Linear, Slack, Atlassian, Feishu, GitLab, Cloudflare, Google and Discord, with credentials stored AES-256-GCM encrypted in a table named mcp_user_credentials. Users can bind multiple accounts per server (work and personal GitHub, for example), label them and set a default. Separately, a tw- key can be pinned to a specific upstream account on the same server, so a Cursor key and a CI key hit GitHub as different identities. Onboarding walks the RFC 9728 to RFC 8414 to RFC 7591 chain, and when Dynamic Client Registration is unavailable the UI falls back to a three-step manual flow. Public clients are detected via token_endpoint_auth_methods_supported containing none, in which case the Client Secret field is hidden. Upstreams that only accept PATs use a static-token vault, with tokens verified at paste time. This is the most concrete part of the README and, on the evidence given, the strongest reason to consider the project.

Getting it running: what the material actually specifies

The README does not include a quickstart block, install command or compose file in the material supplied, so the exact bring-up sequence cannot be reproduced here. What can be stated is the dependency set. The badge row names Rust, React, PostgreSQL, Redis, Docker and Kubernetes, and the prose confirms two runtime dependencies with distinct jobs: PostgreSQL stores providers, virtual keys, pricing and the mcp_user_credentials table; Redis backs the rate limiting. The gateway and console are separate listeners on 3000 and 3001, so a reverse proxy or ingress has to front both. Configuration keys that appear in the text are input_multiplier and output_multiplier, applied per model, which let gpt-4o tokens count more heavily than gpt-3.5 tokens against the same quota. Rate limits are described as multi-window sliding limits over 1m, 5m, 1h, 5h, 1d and 1w, and token budgets as natural-period daily, weekly or monthly, keyed per user, per API key, per provider or per MCP server. Provider routing depends on database rows being present before startup, since active providers are loaded at boot. Anyone evaluating this should read the repository's own deployment files rather than infer a command from this description.

Where the design will bite you

The cost of ThinkWatch's model is operational weight. PostgreSQL and Redis are not optional, so a team that wants a proxy on a laptop has to run both or accept the project's Docker or Kubernetes path. The provider registry lives in the database, which means a fresh deployment starts with no routable providers until rows exist; the README notes that Azure and Bedrock additionally require explicit model registration, so those two are not drop-in even after the database is populated. The MCP gateway's central claim, per-user upstream identity, is also its central constraint: it depends on the upstream honouring per-user OAuth or PATs. Where an upstream only issues one organisational token, the static-token vault stores that token per user, but the upstream audit log will still see whichever credential is attached, and the identity propagation the README argues for does not materialise. The README does not discuss what happens when a user's upstream token expires mid-session, nor how revocation propagates. The licence is the largest open question: the repository reports NOASSERTION, and nothing in the supplied material states terms. For an enterprise gateway that inspects prompts and tool calls, that is a blocker to resolve before a pilot, not after.

Compared with LiteLLM and self-managed proxies

The obvious alternative for the model-gateway half is LiteLLM, which also presents an OpenAI-compatible surface in front of many providers and also tracks spend. The difference in approach is where the state lives and what the project treats as the hard problem. LiteLLM's centre of gravity is provider normalisation and a Python config file; ThinkWatch is a Rust binary backed by PostgreSQL and Redis, with the provider list in the database and an admin console for lifecycle operations like key rotation with grace periods and inactivity timeouts. If your main need is to translate Anthropic calls to OpenAI format and log spend, LiteLLM's config-driven model is lighter. ThinkWatch's argument is the MCP half, and there the comparison is against the pattern the README calls out directly: MCP proxies that attach one shared service token to the server config. If your MCP servers are read-only or your team is small enough that a shared service account is acceptable, that distinction buys you nothing and you are paying for a database, a cache and a second listener. If your MCP servers write to GitHub, Linear or Notion and you need the upstream audit log to name a human, the per-user credential model is the feature that justifies the topology.

Maintenance, upgrades and the licence question

The release history in the material is short: v1.0.0 and v1.0.1, both dated 2026-05-27, with the last push to main on 2026-08-01. A 1.0 line that recent means upgrade paths are largely unproven, and there is no changelog in the supplied material describing what v1.0.1 changed. The dependency surface is the maintenance cost: Rust and React for the two components, PostgreSQL and Redis as stateful services, plus Docker and Kubernetes as the documented deployment targets. Any of those moving to a new major version is your problem, not the project's. The AES-256-GCM encryption of mcp_user_credentials means key management is yours as well; the README does not describe where the encryption key lives or how it is rotated. On licensing, the repository metadata reports NOASSERTION, which means no SPDX identifier was detected. That is not a statement that the project is unlicensed, and it is not a statement that it is permissive. It means the terms have to be read from the repository's own licence file before any commercial deployment, and if that file is absent or ambiguous, the question belongs with whoever handles legal review at your organisation. Nothing here is legal advice.

Editorial conclusion

ThinkWatch fits organisations that already run PostgreSQL and Redis and need one auditable entry point for both model traffic and MCP tool calls, particularly where per-user upstream identity matters. It is the wrong tool for a single developer who just wants a local proxy, since the topology demands a database, a cache and two ports before it does anything. Before adopting, verify three things yourself: the actual licence text, since the repository reports NOASSERTION; whether the MCP gateway's per-user credential model covers every upstream you use, because static-token and OAuth flows are documented separately; and whether the rate-limit windows and token multipliers in your config behave as expected under streaming, since the README describes SSE pass-through and real-time token counting but gives no figures.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ThinkWatchProject/ThinkWatch on GitHub