xllm-go/bypass: an OpenAI-compatible adapter for reverse-engineered chat backends

What xllm-go/bypass actually adapts

The repository describes itself as a service that integrates the chat interfaces of several AI products and exposes them through a single OpenAI-compatible endpoint. The README lists the sources it converts to a v1 interface: Coze international, new Bing Copilot, the Cursor editor, the Windsurf editor, Qodo, DeepSeek, Chatbot Arena LMSYS, You.com, Grok, and Hugging Face for drawing. The stated goal is compatibility with the ChatGPT interface, including streaming output and multi-turn conversation.

The audience is narrower than that list suggests. This is not a general-purpose gateway for official APIs. It is a wrapper around browser and editor sessions that were not published as APIs, and the README's own discussion links (ja3 fingerprinting, the Copilot flow, Cursor and Windsurf protobuf plus gzip) make the intended reader clear: someone studying how those clients talk to their servers. If you want a supported path to a model, the official provider API is the shorter route. If you want to see how a client-side protocol can be reshaped into the OpenAI schema, this repository is the example.

The iocgo build step and what it changes

The most unusual design decision here is that the project does not build with a plain go build. The README's prerequisites section tells you to install a build-time tool first, and the Makefile confirms it: the install target runs go install -ldflags="-s -w" -trimpath ./cmd/iocgo, and every build target passes -toolexec iocgo to the Go toolchain. That means the compiler invokes iocgo for each compilation step rather than the default tool.

The repository layout supports this reading. There is a cmd/ directory holding iocgo, a wire/ directory, a core/ directory, a relay/ directory, and a main.go at the root. The go.mod file depends on github.com/iocgo/sdk and carries a replace directive mapping github.com/samber/do/v2 to a fork at github.com/iocgo/do/v2. In other words, the dependency injection layer is patched at the module level, and the build tool is the thing that wires it together.

This is a real constraint, not a detail. Any Go command that compiles this module needs the -toolexec flag, and the README says other go commands follow the same rule. A contributor who forgets it will get a build that fails or behaves differently from the released binary. The trade-off is that the project gets compile-time wiring without hand-written registration code, at the cost of a toolchain that no standard Go environment has by default.

Installing and making a first request

The README gives three paths: a make-based local build, a Docker image, and a Hugging Face Space duplicate. The make route installs the build tool, then builds, then runs the binary with a -h flag to print usage.

make install

make build

./bin/[os]/server[.exe] -h

The Makefile shows what the build produces: bin/linux/server, bin/linux/server-arm64, bin/osx/server, and bin/windows/server.exe, each compiled with CGO_ENABLED=0 and -trimpath. The -h output is the only place the README points to for flags, so run it before assuming a port.

If you prefer a container, the README's Docker command mounts a config file into the image and publishes port 8080.

docker run -p 8080:8080 -v ./config.yaml:/app/config.yaml ghcr.io/bincooo/chatgpt-adapter:latest

The mount is the part that matters. The image expects /app/config.yaml, and the README does not inline the contents of that file, so the configuration keys are documented on the external documentation site rather than in the repository. Until you read that page, you cannot know which upstream service a given request will reach.

For a persistent process the README offers a systemd unit, which sets WorkingDirectory to a placeholder path and starts the binary with --port 7860. Note that this contradicts the Docker example's 8080; the port is a runtime flag, not a fixed property of the service.

[Unit]
Description=ChatGPT adapter
After=network.target

[Service]
Type=simple
WorkingDirectory=/your_work_dir
ExecStart=/your_app --port 7860
Restart=on-failure

[Install]
WantedBy=multi-user.target

The README does not show a sample chat completion request or a response body, so the first real use has to be inferred from the stated compatibility with the OpenAI interface. Point an OpenAI client at the host and port you started, and expect the adapter to route to whichever backend the configuration selects.

Reverse-engineered upstreams are the failure mode

Every backend in the list is a service the project reaches without a published API contract. The README is explicit about the technique: discussion posts cover JA3 fingerprinting, the Copilot flow, and protobuf plus gzip for Cursor and Windsurf. Those are defenses against client impersonation, and they are exactly the parts that change without notice when a vendor ships a new client build.

The go.mod file shows how much of the integration lives outside this repository. Coze, Edge (the Copilot path), You.com, and an emit.io package are all separate modules pinned to pseudo-versions with commit timestamps. When one of those upstream services rotates a header, a token format, or a serialization scheme, the fix lands in one of those modules first, and this repository picks it up only when the dependency is bumped. There is no version compatibility guarantee in the README for any of them.

This is also where the project is the wrong tool. If your requirement is a stable endpoint with an uptime number attached, a wrapper around reverse-engineered sessions cannot provide it. The README's own special notice says the code is for testing and learning research, forbids commercial use, and asks the reader to delete the contents within 24 hours of download. That statement is the clearest signal about intended use in the whole repository.

Where it sits next to LiteLLM and one-api

The obvious comparison is with gateways such as LiteLLM or one-api, which also present an OpenAI-shaped interface over multiple providers. The difference is the direction of the integration. Those projects call documented HTTP APIs with keys you supply; they normalize request and response schemas, handle retries, and expose spend tracking. Their reliability is bounded by the provider's API contract.

xllm-go/bypass inverts that. It does not hold provider keys for most of the listed services; it reproduces the client behavior of a browser or editor session. That is why the README includes a JA3 fingerprinting write-up and why the build depends on TLS client libraries such as github.com/bogdanfinn/tls-client and github.com/bogdanfinn/utls. A gateway will not help you if the vendor has no API. This adapter will not help you if the vendor has one and you are allowed to use it.

The second difference is the build. LiteLLM and one-api are conventional Python and Go projects that build with standard tooling. Here, the -toolexec iocgo requirement means the source is not directly compilable by a stock Go install, which raises the cost of forking and patching compared with a normal module.

Licence, maintenance and the cost of keeping up

The repository is licensed GPL-3.0. That matters for how you can distribute anything built from it: the licence carries copyleft obligations, and the README's separate notice forbids commercial use and redistribution by media accounts. Those two statements can pull in different directions, and resolving them is a question for a lawyer, not for this article.

On maintenance, the last push to the default branch was on 2026-06-24. The most recent tagged release listed is v3.0.0 from 2025-02-06, with v2.1.2 and v2.1.0 before it. So the gap between the newest release and the newest commit is several months, which is worth knowing before you pin to a tag. The repository is not archived, and the commit history is more recent than the release history.

The upgrade cost follows from the architecture. Because the upstream integrations live in separate modules and the build runs through iocgo, a dependency bump can change generated wiring as well as runtime behavior. The README does not document a migration path between major versions, and there is no stated support window. Budget for reading the diff of go.mod and the wire/ directory, not just for swapping a tag.

Editorial conclusion

Adopt xllm-go/bypass only if you are doing research on protocol adaptation and accept that the upstream services can change at any time. Do not use it as a production dependency for a commercial product, because the README forbids commercial use and the upstream endpoints are reverse-engineered. Before anything else, verify that the iocgo build tool installs cleanly on your Go 1.23.3 toolchain and that the container image tag ghcr.io/bincooo/chatgpt-adapter:latest still exists, since the README's Docker line is the only deployment path it documents.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xllm-go/bypass on GitHub