Project keys replace copied provider credentials
TokenHub sits between applications and AI providers. A platform team connects OpenAI, Azure OpenAI, Anthropic, Gemini, DeepSeek, Qwen, Codex subscriptions, local models, or compatible upstreams once, then gives each application a project-scoped key. The gateway exposes OpenAI-compatible chat, Responses, embeddings, and image routes, plus Anthropic Messages endpoints. English is the main documentation language, with Simplified Chinese and Japanese versions linked from the README.
The project is more than a provider switch. Administrators define models, routes, priorities, weights, failover order, quotas, and concurrency limits. Usage can be attributed to users, projects, teams, models, and cost centers. A user manages allowed models and personal usage, a team leader owns project membership and costs, and an administrator handles providers, identity, routing, and audit. That division is useful once shared model access becomes an internal platform.
More than 150 templates do not guarantee every protocol
The README describes native adapters for major providers and a catalog of more than 150 templates. Templates without a native adapter use an OpenAI-compatible endpoint. Stable internal model names can point to different resources, and routes can account for priority, weight, health, and fallback. Provider reconciliation connects gateway records to upstream bills so finance can ask which team generated a charge.
Compatibility still needs contract testing. Open issue 163 shows Codex voice chat receiving a 404 because /v1/live is absent, even though other Codex and Responses routes work. Issue 184 requests a unified rerank API rather than documenting one as available. Inventory every endpoint, streaming event, usage field, tool call, image input, and error shape your clients expect before putting TokenHub under them.
Subscription routing also deserves a policy review. Open issue 215 asks whether using a code subscription through TokenHub complies with the applicable terms, and the fetched thread contains no answer. That is not proof of noncompliance. It is a reason for each organization to check its provider agreement instead of treating technical connectivity as permission.
What happened when we ran it
Our sandbox installed 107 Go packages in 32 seconds at commit b297007. The backend build succeeded in 82 seconds. The test step then failed with exit code 1 after 452 seconds: Go reported 0 passed and 1 failed out of 1. This is a failed suite, even though installation and compilation completed.
The last log lines showed many responseWorker goroutines waiting in select inside response_jobs.go at line 292. The tokenhub/backend/internal/server package reported failure after 360.317 seconds. That tail does not show a failed assertion or enough context to name a cause, so we will not label it a deadlock or timeout. It shows that the measured backend test package did not finish successfully in our environment.
The checkout contained 878 files, about 194,876 source lines, and occupied 24.8 MB. Our scan found 5 CI workflow files, a Dockerfile, and no tests directory. The run used a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. We did not connect live providers, compare bills, or benchmark gateway throughput.
SQLite starts simply, while PostgreSQL needs load testing
The native Linux installer verifies release checksums, installs a systemd service, and supports update and rollback. Docker Compose starts the backend and console after operators replace every placeholder secret. The initial admin password is either printed once by the native installer or supplied through TOKENHUB_BOOTSTRAP_ADMIN_PASSWORD. Default browser and API ports are 3000 and 8080, with a health route on the backend.
SQLite is the private single-instance path. PostgreSQL supports multiple replicas, shared state, and connection pools. Open issue 246 identifies a process-wide mutex used in synchronous store operations for both databases and asks for PostgreSQL-specific concurrency work. The report calls it a potential bottleneck and explicitly requests measurement, so it is not a published performance result. Run your own fixed-concurrency and tail-latency test before sizing replicas.
Production also needs HTTPS, proxy policy, tested backups, monitoring, and retention rules. Replicas must share stable encryption material, while provider credentials and stored payloads remain sensitive.
First-run and API-key pools still expose console gaps
Issue 274 says production startup rejects missing, placeholder, or short bootstrap secrets and can put an unconfigured Kubernetes pod into a restart loop. The proposed secure claim mode is not shipped merely because it has a detailed design. Kubernetes operators should create valid stable secrets before startup and test that replacement pods can read existing encrypted data.
Issue 268 reports that ordinary API-key provider resources, including per-resource maximum concurrency, can be managed through the backend API but not through the current admin console. Console-only administrators therefore cannot configure that pool. The reporter also warns that partial PATCH bodies use overwrite semantics. Teams using multiple upstream keys should script and test the management calls rather than assuming the visible provider form covers the backend's resource model.
The repository is also in motion. Issue 297, opened August 25, pauses incoming pull requests for about one week while a plugin-mode refactor reorganizes the core. It says existing features will be retested against the new architecture. That candor is useful, but it makes this a poor week to standardize an extension against internal boundaries.
v0.7.0 is active, young, and not yet a sole gateway
GitHub recorded 1,187 stars, 36 combined issues and pull requests, and a last push on August 25, 2026. Release v0.7.0 shipped the same day, while issue discussions remained active on August 26. Those dates show current work. They do not cancel the failed 452-second suite or turn a version below 1.0 into an established enterprise default.
TokenHub is worth a controlled trial when project ownership, provider policy, and cost reconciliation would otherwise become internal software. Pin one release, test every protocol, shadow traffic, and compare its usage records with provider bills. Keep a direct-provider escape path until the plugin refactor settles and the exact backend build passes your concurrency, upgrade, and recovery tests.