# openai-gemini: an OpenAI-compatible proxy in front of the Gemini API

> PublicAffairs/openai-gemini turns a personal Google Gemini API key into an OpenAI-shaped endpoint, so tools that only speak the OpenAI wire format can talk to Gemini. It is a translation layer, not a model, and its scope is deliberately narrow.

**PublicAffairs/openai-gemini** — ✦ Gemini ➜ OpenAI API proxy. Serverless!

- Repository: https://github.com/PublicAffairs/openai-gemini
- Website: https://my-openai-gemini-demo.vercel.app/
- Stars: 3,663 · Forks: 5,847
- Language: JavaScript
- License: MIT
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/publicaffairs-openai-gemini

## What openai-gemini actually solves

The Gemini API has a free tier with what the README calls generous limits, but a large amount of existing software only knows how to call the OpenAI API. That mismatch is the entire reason this project exists. It is a personal, OpenAI-compatible endpoint in front of Gemini, so an editor plugin, a CLI agent, or a chat front end that lets you override the base URL can be pointed at Gemini without patching that tool's source.

The audience is narrow and specific. This is for one person or a small team using their own Google API key. The README describes it as a personal endpoint and frames the free provider tiers as suitable for personal use. It is not a shared gateway for an organisation, it does not do key pooling, and nothing in the documentation suggests multi-tenant accounting. If you want a proxy that manages many users' credentials, this is the wrong layer.

The value proposition is mostly about avoiding work. You get an OpenAI-shaped surface for chat completions, embeddings, and model listing, backed by Gemini, and you can stand it up on a free serverless host or run it on your own machine. The trade-off is that you inherit every place where the two APIs do not line up, and the README is honest about several of them.

## How the proxy translates requests and models

The repository is a thin translation layer. Top-level entries include node.mjs, deno.mjs, bun.mjs, an src/ directory, an api/ directory, and a netlify/ directory, with host config files vercel.json, netlify.toml, and wrangler.toml. The README points at src/worker.mjs for the Cloudflare path, where the instructions say you can paste its contents into the Workers playground and press Deploy. So the same core logic is wrapped once per runtime rather than reimplemented per host.

Model routing is handled by name inspection. A request uses the model you specify if its name starts with gemini-, gemma-, or models/. Otherwise defaults apply: chat/completions falls back to gemini-flash-latest, and embeddings falls back to gemini-embedding-001. That means an application hardcoding a GPT model name will not error out on an unknown model; it will silently land on the Gemini default. That is convenient for getting something running and dangerous if you expected a failure when you typo a model name.

Gemini-only capabilities are reachable through the extra_body field, and the README singles out thinking_config as the most notable example. Web search is enabled by appending :search to the model name, for example gemini-2.5-flash:search. The README notes that the annotations message property is not implemented, so if your client expects citation annotations back, that part of the response will be missing.

Media input is supported for vision and audio according to the OpenAI specs, implemented through Gemini's inlineData. The parameter matrix in the README shows chat/completions largely filled in: messages, roles including system mapped to system_instruction, tool_calls, tools, tool_choice, response_format for json_object, json_schema, and text, streaming with stream_options.include_usage, seed, stop, temperature, top_p, and the penalty fields. Unchecked entries include logit_bias, logprobs, top_logprobs, and parallel_tool_calls, which the README says is always active in Gemini. The completions endpoint is not supported at all.

## Installing openai-gemini and making a first call

You need a personal Google API key from AI Studio. The README notes that even outside the supported regions it is still possible to acquire one using a VPN. After that you pick a host. The README gives button deploys for Vercel, Netlify, and Cloudflare Workers, and notes that button deploys guide you through forking the repository first, which is necessary for continuous integration.

If you prefer the CLI on Vercel, the README gives this command:

```bash
vercel deploy
```

For a local run instead of a cloud deploy, the Node path needs dependencies installed first, then a start script. The package.json defines these scripts exactly:

```bash
npm install
npm run start
```

The package.json also defines start:deno, start:bun, dev, dev:deno, and dev:bun. The dev variants watch source changes, and the Node dev mode requires npm install --include=dev because nodemon is a dev dependency. Deno and Bun do not need the install step for their start scripts.

Once deployed, opening the site in a browser returns 404 Not Found. The README says this is expected because the API is not designed for direct browser access. You point your client at the base URL with /v1 appended, in the form https://my-super-proxy.vercel.app/v1, and enter your Gemini API key in the client's key field. Netlify additionally exposes an /edge/v1 base backed by edge functions. For command-line tools you may need an environment variable instead, and the README gives two spellings:

```bash
OPENAI_BASE_URL="https://my-super-proxy.vercel.app/v1"
```

```bash
OPENAI_API_BASE="https://my-super-proxy.vercel.app/v1"
```

The README warns that not all software allows overriding the OpenAI endpoint, though many do, and that the setting can be buried under Advanced settings or a config file. That is the step most likely to cost you time.

## Where the OpenAI compatibility breaks down

The unchecked boxes in the README's parameter list are the honest answer to whether this is a drop-in replacement. It is not, in several places that matter to some applications. logit_bias, logprobs, and top_logprobs are not implemented. If your pipeline reads token-level log probabilities, for example to score confidence or to build a constrained decoder, this proxy cannot supply them. The completions endpoint is absent, so legacy code calling the older text completion route has nowhere to go.

parallel_tool_calls is listed as always active in Gemini, which means you cannot turn it off through the OpenAI-shaped interface. A client that assumes it can force sequential tool calls will get Gemini's behaviour instead. The n parameter is capped at a candidateCount below 8 and is not available for streaming. The README notes annotations are not implemented, so web search results come back without that message property.

There is also a host-level failure mode that has nothing to do with translation. Vercel Functions, Netlify synchronous functions, Netlify edge functions, and Cloudflare Workers all have their own limits, and the README links each host's limit page rather than restating the numbers. Long prompts, large inline images or audio, and long streaming responses are the cases where you should read those pages before committing to a host. The README does not document rollback, version pinning, or a migration path between hosts, so treat a host choice as a decision you will have to redo by hand if it turns out wrong.

Finally, the proxy is only as available as your key and your host. There is no retry layer, no key rotation, and no queue described in the README.

## Alternatives and the difference in approach

The closest alternative in spirit is LiteLLM, which takes the opposite architectural stance. LiteLLM is a Python library and proxy that normalises many providers behind one interface and runs as a service you operate, with provider routing, fallbacks, and budget tracking. openai-gemini does one direction only: OpenAI-shaped requests in, Gemini out. It has no provider abstraction, no fallback chain, and no cost accounting. If you need to switch between Gemini, OpenAI, and Anthropic from the same client without changing configuration, LiteLLM is built for that and openai-gemini is not.

The other alternative is to skip the proxy entirely. Several clients now accept a Gemini base URL natively, and the Gemini API itself documents an OpenAI-compatibility layer. If your tool supports that directly, adding a proxy between the two only adds a hop and a place for parameter translation to lose fidelity. The reason to still choose openai-gemini is deployment shape: it is a single small file per runtime, it deploys to free serverless tiers with a button, and it runs locally with one npm script. A general-purpose gateway is a heavier thing to operate for a single user.

A third option is writing the adapter yourself. The translation surface here is not enormous, and the README's parameter matrix is effectively a specification of what has to be mapped. If you only need chat completions with streaming, a few hundred lines would cover it. What you would be reimplementing is the host wrappers and the edge cases around roles, tool calls, and inline media.

## Maintenance, licence, and what you are signing up for

The repository is not archived, and the last push was on 2026-03-17. Six months have passed since then, so this is not a project to describe as actively developed. Recent releases are named after the Gemini models they track: gemini-3 in December 2025, gemini-2.5-flash in July 2025, and gemini-2.0-flash-thinking-exp in December 2024. The pattern suggests releases follow upstream model changes rather than a fixed cadence, which makes sense for a translation layer sitting under someone else's API.

The practical upgrade cost is low but not zero. You fork the repository for the button-deploy paths, so keeping up with upstream means pulling changes into your fork and redeploying. Because model names are matched by prefix and unknown names fall through to defaults, a new Gemini model generally does not require a code change to be reachable. A new request or response field would. The README's checkbox list is the thing to diff against when you upgrade, since it is the project's own statement of what is covered.

The licence is MIT, which is permissive and places few obligations on how you use or redistribute the code. This is not legal advice, and the more relevant terms here are the ones attached to the services you depend on: Google's Gemini API terms for the key, and your host's terms for the deployment. Read those separately, because the MIT licence on this repository says nothing about them.

## Conclusion

Adopt openai-gemini if you already have a Gemini API key and a tool that only accepts an OpenAI base URL, and you are comfortable with the gaps in the parameter matrix (no logprobs, no logit_bias, no completions endpoint). Do not adopt it if you need a managed multi-tenant gateway, per-user billing, or strict OpenAI parity on every field. Before deploying, verify two things: that your chosen host's function limits fit your prompt sizes, and that your client software actually exposes a base URL override, because the README notes these settings are sometimes deeply hidden. The last push to the repository was on 2026-03-17.

## FAQ

### Is OpenAI the same as Gemini?

No. They are separate services with different APIs. openai-gemini exists precisely because of that gap: it presents the Gemini API through an OpenAI-compatible endpoint so tools written for OpenAI can call Gemini.

### Can I use OpenAI with Gemini?

You can use OpenAI-shaped clients with Gemini through this proxy. You supply a personal Google API key and point the client's OpenAI base URL at your deployment with /v1 appended, in the form https://my-super-proxy.vercel.app/v1.

### Is Gemini AI free to use?

The README refers to a Gemini API free tier with generous limits, and describes the free provider tiers used for deployment as suitable for personal use. It does not state specific quota numbers, so check the linked pricing page for current limits.

### What is openai-gemini?

It is a proxy that exposes the Gemini API through an OpenAI-compatible endpoint, intended as a personal endpoint for tools that only work with the OpenAI API. The README describes it as serverless because it runs in the cloud without server maintenance.

### How do I open openai-gemini?

You do not open it in a browser. The README states that visiting your deployed site returns 404 Not Found, which is expected because the API is not designed for direct browser access. You enter the deployment address with /v1 appended as the API base in your software's settings.

## Sources

- [License: MIT](https://github.com/PublicAffairs/openai-gemini/blob/main/LICENSE)
- [Project website](https://my-openai-gemini-demo.vercel.app/)
- [PublicAffairs/openai-gemini on GitHub](https://github.com/PublicAffairs/openai-gemini)
- [README](https://github.com/PublicAffairs/openai-gemini/blob/main/README.md)
- [Releases](https://github.com/PublicAffairs/openai-gemini/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/publicaffairs-openai-gemini