azrinaldi/gemini-stealth-bridge

Worth a look if you already have a Gemini Web login and want an OpenAI-shaped endpoint for existing tools; treat its OpenAI compatibility as a documented subset rather than a drop-in replacement.

The problem

A developer has a client or coding agent that speaks only the OpenAI Chat Completions or Responses format, and a Google account that can use Gemini Web. Without a bridge, adapting the client means either keeping a browser open as a proxy or rewriting the client to talk to a different API, and neither is appealing for a local setup. This project changes the middle step: the client sends an OpenAI-format request to a local daemon, which translates it into authenticated Gemini Web traffic and converts the reply back to JSON or SSE. The result is that existing OpenAI SDK code can point at a local address and receive chat responses, generated media and tool-call objects.

What's different

The core mechanism is a per-account uTLS/HTTP2 transport with ordered browser headers, using a Chrome PSK profile instead of maintaining a headless browser process. The author describes this as replacing a browser process, not as emulating every property of a real browser, which is a reasonable description of the trade-off: less to run and supervise, but the upstream surface is Gemini's web client rather than an official API. On top of the transport, the project adds account pooling, quota-aware failover, model and quota refresh workers, and cookie rotation and persistence. Function calling is implemented by translating tool definitions into a prompt contract, validating returned arguments against their JSON Schema, and repairing common mistakes before emitting OpenAI-style calls, with the client executing the tools.

The trade-offs are concentrated in the compatibility boundaries the README states explicitly. Sampling controls such as temperature, top_p and max_tokens are not forwarded, so they do not change generation. For Responses clients, conversation history must be resent in input; previous_response_id, response retrieval, deletion and background jobs are not implemented. Token usage is estimated locally rather than taken from Google's tokenizer or billing data, and advertised context and output limits are metadata, not guarantees. These are not edge cases to discover later; they shape what kinds of clients can use the bridge.

Who should try it

A good fit is someone who already works against OpenAI-format clients and wants to route local traffic through a Gemini Web account, especially where account pooling and failover matter and the client does not depend on sampling controls or response continuation. A poor fit is a client that relies on precise temperature/max_tokens behavior, previous_response_id continuation, OpenAI Files, embeddings or audio, since those are explicitly outside the documented surface. Someone without a Gemini Web-capable Google account has no use for the project regardless of the transport.

Requirements and limitations

The daemon runs on Linux, macOS or Windows for amd64 or arm64, and static binaries are available; building from source requires Go 1.26.0 or newer. Login and cookie import can optionally use a browser, but a browser is not required for normal operation, and Docker is optional. By default the daemon listens on loopback and the API key defaults to public with unauthenticated access allowed in that mode, so exposing it beyond localhost requires deliberate configuration. The daemon serves plain HTTP and does not terminate TLS.

Ongoing upkeep is part of the deal. Model and quota state are refreshed on a timer, rotating cookies are rewritten and persisted to account files, and continuation metadata is persisted to a cache file. Because the upstream is Gemini Web rather than a versioned API, callers should expect compatibility to follow the web client rather than a published contract; the README's compatibility section is the place to check before committing a client to it. Function-calling support is prompt-based, so malformed or schema-invalid tool calls can surface as tool_call_error.

HotRepo's take

HotRepo recorded 101 total stars and a #21 position on the NEW-REPOSITORY board (新项目榜, not the overall Trending board) on 2026-10-25, with a single recorded date since 2026-10-24 tracking began. That is a dated snapshot of a nine-day-old repository, not a growth series, so persistence cannot be judged from this evidence. Before adopting, verify the compatibility boundaries section against the exact client fields you depend on, since the documented omissions are where most integration surprises will come from.

Project source and documentation