linguo2625469/workbuddy2api-panel

WorkBuddy2API Panel – A self‑hosted OpenAI‑compatible gateway for Tencent CodeBuddy

What it is – A Go‑based reverse‑proxy that lets you use any OpenAI‑compatible client (ChatGPT SDKs, CLI tools, etc.) against Tencent CodeBuddy (copilot.tencent.com). It wraps one or more CodeBuddy accounts, handles OAuth device‑flow login, refreshes tokens, and presents a single /v1/chat/completions endpoint that mimics the OpenAI API.

Why it exists – Tencent does not expose a public OpenAI‑style API. The project lets individuals who own CodeBuddy accounts reuse those credits through the familiar OpenAI interface, enabling zero‑code integration with existing tools.

---

Core capabilities (as described in the README)

Feature	What it does
OAuth one‑click login	login.sh or the web panel’s Add Account button runs the device‑authorization flow, stores the credential JSON and hot‑loads the new account without restarting the service.
Multi‑account pool	Keeps a pool of credentials, selects an account per request using a three‑factor weighted random algorithm (credits, idle‑time bonus, success‑rate). Top‑5 candidates are considered and a short “anti‑burst” delay prevents rapid re‑use.
Circuit‑breaker & cooldown	Soft‑cooldown for 429 responses (exponential back‑off up to 2 h), fixed 60 s cooldown for 404, hard‑cooldown to next day 04:00 for 402 (balance exhausted), plus failure‑count‑based breaker.
Session stickiness	Requests that share a conversation_id (or derived hash) are routed to the same upstream account for the life of the session (default TTL 30 min, refreshed on each successful call). State can be mirrored to Upstash Redis to survive restarts.
Scheduled tasks	Automatic daily sign‑in, activity reporting, “cat travel”, token keep‑alive and a “black‑cat” night‑owl task. Each task has an independent on/off switch and configurable hour(s).
Streaming & non‑streaming	Outbound calls are forced to stream:true; the gateway re‑assembles streamed chunks into a single response when the client asks for non‑streaming.
Model‑level compatibility	Pass‑through of model names, plus DeepSeek “thinking chain” injection, automatic effort‑level downgrade, and response‑content back‑fill.
System‑prompt handling	By default replaces client‑provided system messages with a custom prompt (removing the original to avoid CodeBuddy’s content‑filter false positives). A passthrough mode is also available.
Fingerprint sanitisation	Black‑listed fields (e.g., device fingerprints) are stripped from outbound payloads; can be disabled.
Observability	One‑line CSV log per request (TTFB, token rate, uid), /healthz endpoint with service status, optional Redis mirroring.
Web management panel	Single‑page UI (embedded via go:embed) for: adding accounts, viewing pool health, editing config.json live, triggering growth‑task automation, inspecting logs, and running scheduled tasks manually.
Growth‑task automation	17 of the 18 CodeBuddy “growth” tasks can be completed automatically from the panel (sign‑in, canvas creation, chat activity, expert summons, etc.) with one‑click execution and automatic reward claiming.

---

Quick start (Docker Compose – the recommended way)

# clone the repo
git clone https://github.com/linguo2625469/workbuddy2api-panel.git
cd workbuddy2api-panel

# copy the example config and edit if you want a custom API key
cp config.example.json config.json   # edit config.json if desired

# start the service (Docker will build the Go binary)
docker compose up -d --build

# health check
curl -s http://localhost:7863/healthz
# → {"healthy":0,"total":0,"service":"workbuddy2api"}

Open a browser at http://localhost:7863/panel/, click Add Account, follow the OAuth device‑flow link, sign in with your CodeBuddy credentials, and the new account appears in the pool instantly.

---

Running without Docker (single‑binary)

1. Download the released wb2api.exe (Windows) or build from source (go build -trimpath -ldflags="-s -w" -o wb2api ./cmd/server).
2. Run it: ./wb2api -config config.json – the first start will generate a random api_key if you left the field empty.
3. Open http://127.0.0.1:7863/panel/ and add accounts as above.

---

Configuration highlights

Key	Default	Meaning
listen	:7863	HTTP bind address.
api_key	empty	Bearer token required by clients; empty disables authentication (not recommended for public exposure).
auth_dir	./auths	Directory where OAuth credential JSON files are stored.
state_file	./data/state.json	Persistent pool state.
server.max_body_mb	8	Max request payload size; larger bodies are rejected with 413.
cooldown.soft_rate / soft_rate_max	600s / 2h	Base and ceiling for exponential back‑off after 429.
schedule.*_enabled	true	Switches for the five scheduled jobs (sign‑in, activity, travel, keep‑alive, black‑cat).
upstash.url / upstash.token	empty	If set, pool state and session bindings are mirrored to Upstash Redis for crash‑resilience.
prompt.mode	custom	custom replaces client system prompts; passthrough leaves them untouched.
features.sanitize_blacklist_fingerprints	true	Remove known fingerprint fields from outbound payloads.

All fields can be overridden at runtime via environment variables prefixed with WB2A_ (e.g., WB2A_API_KEY).

---

How it works internally (high‑level overview)

1. Incoming request – The HTTP handler validates the optional API key, enforces the body size limit, rewrites the payload (stream flag, prompt handling, tool‑call normalisation) and selects an upstream account from the pool.
2. Pool logic – Accounts are filtered for disabled / cooling / breaker status, weighted, and a random top‑5 candidate is chosen. The selection respects idle‑weight and recent‑use anti‑burst rules.
3. Session stickiness – If the request contains a conversation_id (or similar metadata) the handler tries to bind the call to the same upstream account for the TTL of the session.
4. Upstream call – A thin client streams the request to CodeBuddy (/v1/chat/completions). Responses are streamed back to the caller, optionally aggregated for non‑streaming calls.
5. Error classification – Responses are categorised (balance exhausted, rate‑limit, session loss, 5xx, etc.) and the pool updates cooldown counters, breaker state, or disables the account as needed.
6. Observability & persistence – Each request logs a CSV line; the pool state is written atomically to state.json and optionally mirrored to Redis. The /healthz endpoint reports overall pool health for load‑balancers.
7. Web panel – The UI (embedded in the binary) talks to the same HTTP API to display pool metrics, edit config.json live, run the growth‑task automation, and view logs.

---

Who might use this?

• Individual developers who have a personal CodeBuddy subscription and want to reuse it with tools that only understand the OpenAI API.
• Power users managing several CodeBuddy accounts (e.g., to spread load or avoid per‑account rate limits).
• Self‑hosted AI playgrounds that need a drop‑in OpenAI endpoint but prefer to keep the underlying service private.

---

Legal / compliance note

The README stresses that this is an unofficial gateway. It should only be used with accounts you own, in a private environment, and not exposed publicly without proper authentication. The tool does not bypass Tencent’s licensing; it merely automates the device‑flow login and token refresh.

---

TL;DR

WorkBuddy2API Panel = a Go server that turns your Tencent CodeBuddy accounts into a standard OpenAI‑compatible API, adds a multi‑account pool with smart routing, automatic daily tasks, and a built‑in web UI for management. Deploy with Docker or a single binary, add accounts via OAuth, and point any OpenAI client at http://localhost:7863/v1/....