azrinaldi/gemini-stealth-bridge

如果你已经有可用的 Gemini Web 账号，并且想让现有 OpenAI 格式客户端接上它，这个项目值得花时间评估；但要把它的 OpenAI 兼容性当成文档中列明的子集，而不是无缝替代。

解决什么问题

开发者手上有一个只会说 OpenAI Chat Completions 或 Responses 格式的客户端或编程 Agent，同时有一个能使用 Gemini Web 的 Google 账号。没有桥接时，要么维护一个浏览器进程当代理，要么改客户端去对接另一套 API，两条路都不轻松。这个项目改变了中间那一步：客户端把 OpenAI 格式请求发给本地守护进程，守护进程翻译成带认证的 Gemini Web 请求，再把结果转回 JSON 或 SSE。最终效果是，现有的 OpenAI SDK 代码可以指向本地地址，拿到对话回复、生成媒体和工具调用对象。

有什么不同

核心机制是按账号维护 uTLS/HTTP2 传输，并携带有序的浏览器请求头，使用 Chrome PSK 配置，而不是长期跑一个无头浏览器进程。作者自己的说法是这个配置替代浏览器进程，但并不模拟真实浏览器的全部属性，这个描述比较准确地概括了取舍：少了一个需要看护的浏览器，但上游是 Gemini 的网页客户端，不是正式 API。在传输层之上，项目还提供账号池、感知额度的故障转移、模型与额度刷新任务，以及 cookie 轮换与持久化。函数调用通过把工具定义转成提示词契约来实现，返回参数会按 JSON Schema 校验，并尝试修复常见错误，再输出 OpenAI 风格调用，工具本身由客户端执行。

取舍集中在 README 明确写出的兼容边界上。temperature、top_p、max_tokens 等采样控制不会转发，因此不会改变生成。Responses 客户端必须在 input 里重新发送对话历史；previous_response_id、响应检索、删除和后台任务都没有实现。Token 用量是本地估算的，不是来自 Google 的分词或计费接口；宣称的上下文窗口和输出上限元数据并不保证每个账号或请求都能达到。这些不是以后才会发现的边角情况，而是直接决定了哪些客户端适合接进来。

谁值得试

适合的人：已经在用 OpenAI 格式客户端，想把本地流量接到 Gemini Web 账号，且客户端不依赖采样控制或响应续接，账号池和故障转移对你有实际价值。不适合的人：客户端依赖精确的 temperature/max_tokens 行为、previous_response_id 续接、OpenAI Files、embeddings 或音频，这些都被明确排除在文档化范围之外。没有可用 Gemini Web 的 Google 账号的人，传输层做得再好也用不上。

使用条件与边界

守护进程支持 Linux、macOS、Windows 的 amd64 和 arm64，提供静态二进制；从源码构建需要 Go 1.26.0 或更新版本。登录和 cookie 导入可以选择用浏览器，但正常运行并不强制需要浏览器，Docker 也是可选的。默认监听回环地址，API Key 默认是 public，且该模式下允许未认证访问，所以要把服务暴露到 localhost 之外必须主动配置。守护进程只提供明文 HTTP，不负责 TLS 终止。

日常维护是这件事的一部分。模型与额度状态按定时器刷新，轮换的 cookie 会被重写并持久化到账号文件，续接元数据会写入缓存文件。由于上游是 Gemini Web 而不是有版本号的 API，调用方应预期兼容性跟随网页客户端变化，而不是遵循一份公开契约；在把客户端押上去之前，README 的兼容性一节是最该先看的地方。函数调用基于提示词，格式错误或不符合 schema 的工具调用可能以 tool_call_error 失败。

HotRepo 点评

HotRepo 在 2026-10-25 记录到该项目总星数 101、新项目榜（不是总榜）第 21 名；从 2026-10-24 开始跟踪以来只有一个记录日期。这是对一个 9 天新仓库的单日快照，不是增长序列，因此无法据此判断热度能否持续。决定采用前，请用你实际依赖的客户端字段逐条对照兼容性边界，文档列明的缺失项最可能带来集成上的意外。

项目源码与说明