arthur@homelab:~$ cat ~/posts/open-webui-cliproxyapi-chatgpt-pro.md

Open WebUI, CLIProxyAPI, and a ChatGPT Subscription

How I connected an existing ChatGPT subscription to my private Open WebUI, and the security and support boundaries I accepted.

mtime 2026-07-22 · 4 min read

I like ChatGPT, but I do not necessarily want its interface to be the center of my AI workflow.

I already run Open WebUI in my homelab. It gives me one interface for local models, hosted APIs, experiments, and tools. Its primary conversation database is on infrastructure I operate. I control how the UI is exposed, backed up, and monitored.

The awkward part is that a ChatGPT subscription and an OpenAI API account are separate products. Subscription access is not ordinary pay-as-you-go API credit. For my personal setup, I experimented with CLIProxyAPI, an unofficial compatibility layer that can use an OpenAI Codex OAuth session and present an OpenAI-style endpoint to clients such as Open WebUI.

This works for me. It is not an architecture I would use for production software or other users.

The shape of the deployment

browser
   |
   v
Open WebUI
   |
   | private authenticated connection
   v
CLIProxyAPI
   |
   | OAuth session
   v
OpenAI

Open WebUI is the user-facing service. CLIProxyAPI is a private compatibility layer, not a public endpoint. Keeping them separate means the proxy owns the OAuth material while Open WebUI receives only a dedicated proxy credential.

The login used a device authorization flow: the proxy displayed a short-lived code, I approved it in a trusted browser, and the resulting session remained in the proxy’s protected auth storage. I did not give my account password to Open WebUI.

That does not make the proxy low-risk. It is third-party software holding a powerful credential, so updates, source provenance, network exposure, and backup handling belong in the threat model.

What remains local—and what does not

“Self-hosted” is too blunt for this stack:

The local UI gives me meaningful control of the experience and system of record. It does not turn cloud inference into local inference or override the provider’s current data controls.

When the economics make sense

If a subscription already earns its place in my budget, using its included interactive model access from my preferred personal interface increases its value. The incremental homelab cost is small.

For light or sporadic programmatic use, the official API may be simpler and cheaper. For customer-facing software, shared access, resale, unattended bulk automation, or anything requiring an availability promise, the official API is the appropriate foundation.

Subscription prices, model allowances, authentication behavior, and provider rules change. I do not treat this bridge as a permanent entitlement or compare it to API pricing as if the two products were interchangeable.

The continuity risk

The largest risk is that CLIProxyAPI depends on authentication and upstream behavior it does not control. Either project can release a breaking change. Available models can move. A working OAuth flow can stop working while the homelab itself remains perfectly healthy.

I reduce the blast radius by:

• keeping the proxy off the public internet;
• protecting it with a separate client credential;
• limiting it to my personal use;
• storing OAuth material outside Open WebUI;
• treating the provider as removable;
• keeping local models and supported APIs available as alternatives.

If the bridge disappears, I lose a convenient route—not my UI or conversation database.

Was it worth it?

Yes, within those boundaries. I get one private interface across local models, supported APIs, and the model access associated with an existing subscription. I retain control of the local system of record while being honest that hosted prompts still go to the hosted provider.

That is a useful personal homelab integration. It is not a loophole I would design a business around.

• ai
• open-webui
• self-hosting
• homelab