A Chinese panel wraps CodeBuddy behind one chat endpoint
WorkBuddy2API Panel exposes /v1/chat/completions and /v1/models in an OpenAI-compatible shape while sending work to Tencent CodeBuddy accounts. The README and operational guidance are written in Simplified Chinese, and the root contains no English guide. A browser panel handles OAuth login, account status, usage, model information, configuration, logs, and reward tasks. This is a focused adapter for one upstream account system, not a general model gateway.
Its account pool is the reason to consider it. Selection can weigh expiring credits and cost, limit in-flight work, cool accounts after upstream errors, trip a circuit breaker, and keep a conversation on one account. Redis can mirror sticky-session state, while local state supports restart recovery. The panel also shows request timing and source metadata without recording prompts, response bodies, or credentials in its JSONL archive.
What happened when we ran it
Our sandbox installed commit 9478287 in 4 seconds. Go fetched 13 packages, and the checkout occupied 2 MB with 160 files and about 46,073 lines of source. The build completed successfully in 38 seconds. We used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Go 1.24, and no secrets.
The test step passed in 23 seconds. go test reported 30 passed and zero failed out of 30. The repository had two CI workflow files, a Dockerfile, and a Compose file, although our scan found no separate tests directory because Go tests live beside package code. Those results cover repository mechanics. We did not authorize a CodeBuddy account or send traffic to Tencent.
This is a reassuring baseline for the code we could exercise. A 4-second dependency fetch, successful 38-second build, and complete 30-test result make the local development path credible. They do not verify account longevity, upstream policy compatibility, reward-task behavior, model output, or resilience under real rate limits. Those require an authorized account and live service conditions that were absent from the sandbox.
Plaintext OAuth files make private deployment mandatory
The project stores each account's access token and refresh token in plaintext under auths/, along with account metadata. It documents restrictive file permissions, but permissions do not help if the host, backup, image, or mounted volume is exposed. Treat that directory as a credential store: exclude it from Git, encrypt backups, limit host access, and rotate the associated accounts after any suspected copy.
Network defaults need equal attention. Docker Compose maps port 7863 on all interfaces, and the service supplies plain HTTP rather than TLS. An empty api_key means the API and panel allow requests without authentication. The README tells public operators to set the key and put Nginx or Caddy in front. Follow that advice before the first OAuth login, not after the endpoint appears in a scan.
The browser keeps the panel API key in localStorage when authentication is enabled. That is workable on a dedicated admin origin, but it raises the cost of any script injection or shared-browser mistake. Security headers, constant-time key comparison, path checks, and front-end escaping are useful defenses already described by the project. They do not reduce the impact of a stolen refresh token.
OpenAI compatibility stops short of newer native protocols
The documented client surface centers on chat completions, models, status, and health. Streaming requests are rebuilt as server-sent events, while nonstreaming replies are aggregated locally. The gateway normalizes roles and tool choices, fills reasoning content, chooses supported effort levels, and sanitizes selected fingerprints. Those transformations help existing chat-completions clients, but they also create behavior that differs from a direct official API.
Open issue 89 asks whether native Responses support is absent, and issue 9 requests native Anthropic Messages support. A client that merely uses the OpenAI SDK is not automatically compatible if it depends on those newer routes. Open issue 81 also documents a conversation where repeated tool-call IDs led to upstream rejection and repeated 503 responses. The report calls its diagnosis a high-confidence inference rather than a closed reproduction, which is the right caveat to preserve.
Seventeen automated reward tasks increase policy risk
The panel says it can complete 17 of 18 growth tasks through APIs, including fabricated client event chains and a small number of real model conversations. That engineering is detailed, but it is also the part most exposed to upstream policy and schema changes. The repository calls itself unofficial and says it is for self-owned accounts, local or private testing, check-ins, and personal tool access.
The README explicitly rejects bulk registration, quota resale, paid API pooling, and repackaged commercial distributions. It says the target service terms prohibit bulk accounts and commercial resale. The deleted upstream repository is mentioned, but the author does not claim to know why it disappeared. A buyer should take that uncertainty seriously. Even personal automation can stop when Tencent changes endpoints, fingerprints, task rules, or account enforcement.
Version 1.12.0 is active after only three weeks
GitHub showed 2,077 stars and 42 open issues and pull requests on October 7, 2026, split into 39 issues and 3 pull requests in the API response. The repository was created on September 12 and pushed on October 6. Release v1.12.0 shipped on October 5 with CI-built binaries for five platforms plus checksums. The activity is current, though the public history is still measured in weeks.
That combination explains our score. The Go project builds, all 30 tests passed, container assets exist, releases are packaged, and the Chinese README is unusually detailed about failure modes and secrets. The upstream dependency remains unofficial, plaintext tokens carry real consequences, and protocol gaps appear in open issues. For one careful self-hoster using personal accounts, it is capable. For a public API business, the project's own rules and risk profile say no.