1. 安装并完成 GitHub 登录

需要 Python、一个 GitHub 账户，以及该账户可用的 GitHub Copilot 权限。ghc-api 是兼容代理，不提供模型或额度。

Shell
pip install -U ghc-api
ghc-api

首次启动会按优先级读取 GITHUB_TOKEN、~/.ghc-api/github_token.txt，否则进入 GitHub Device Flow。默认监听 127.0.0.1:8313。

你也可以先打开 GitHub Copilot Features 设置 ↗，查看当前 GitHub 账户可以启用和使用的模型。组织账户还可能受到管理员策略限制。

2. 使用 -c 生成配置文件

Shell
ghc-api -c

配置文件位于 ~/.ghc-api/config.yaml；Windows 位于 %APPDATA%\ghc-api 目录。生成文件已经包含当前版本支持的字段、默认值和注释，因此本文不再复制一份可能随版本变化而过时的完整 YAML。

初次使用通常只需确认监听地址、端口、Copilot 账户类型和模型映射。请求日志、OneDrive、用户 Token 与远程部署属于可选或高级功能。

3. 为什么需要 model mapping

客户端发送的模型名不一定与 GitHub Copilot Backend 能识别的模型 ID 完全一致。Claude Code 尤其可能发送带版本日期的名称，例如 claude-opus-4-8-2026xxxx；GitHub Backend 可能只接受不带日期的稳定模型 ID。

另一个常见差异是分隔符：Claude CLI 可能发送 4-8 或 4-5，而 GitHub Copilot 对应模型使用的是 4.8 或 4.5。ghc-api 会在请求转发前使用 model_mappings 将客户端名称转换为 Backend 能识别的模型 ID。

映射方式适合场景
exact固定别名或固定错误格式，例如把一个完整的 4-8 名称转换成对应的 4.8 模型。
prefix处理末尾日期或版本会变化的名称。匹配稳定前缀后，统一转换为 GitHub 能识别的模型 ID。
映射只解决名称兼容，不会增加模型权限。

映射目标仍须是当前 GitHub 账户实际可用的模型。先检查 Copilot Features 页面和 ghc-api 返回的模型列表。

4. 验证服务和模型

Shell
curl http://127.0.0.1:8313/v1/models
curl http://127.0.0.1:8313/v1/models/full/

第一个端点适合快速查看模型 ID；第二个端点保留端点支持和能力参数。遇到问题时，依次确认 GitHub 登录、模型 ID、协议 URL，并在 Dashboard 查看原始请求、映射后的模型名、响应和 Raw SSE。

5. 接下来配置客户端

配置 Claude CodeAnthropic Base URL、Token 与模型选择 →配置 Codex CLIResponses Provider 与 reasoning effort →配置 pimodels.json 与模型能力参数 →配置 OpenClaw按协议拆分 Provider →

如果准备给多人使用或通过网络访问，请继续阅读靠后的高级配置：共享实例、鉴权与安全。

下一步

先查看当前账户真实可用的模型和端点，再把模型 ID 填入客户端配置。

查看模型与参数 →