Login with ChatGPT shifts the model bill from you to your users

Letting the user pay for the model

This SDK adds a sign-in button that authenticates a visitor with their existing ChatGPT account, and then lets your application make model calls that draw on that person's own subscription rather than on your API budget.

The first bullet in the README is the whole product: users bring their own subscription. That inverts the economics of building anything on a language model. The usual arrangement is that the developer holds an API key, pays per token, and watches costs scale with adoption, which is why so many small applications are either rate limited, paywalled, or quietly abandoned. Here the cost sits with the person already paying a monthly fee for the model.

The audience is anyone building a tool for people who already subscribe: a writing aid, a code helper, an internal utility, a side project that would otherwise need a billing relationship before it could have users.

The second design decision matters just as much. Tokens never reach the browser. The visitor's session is a cookie marked inaccessible to scripts, the browser asks your backend which models the account can use, and generation streams through your server.

Four packages, split along a sensible seam

The SDK ships as four packages and the division tells you where the work happens.

A core package holds the authentication flow, token refresh, model discovery, the private voice transport and the browser client for application-server communication. A server package is the backend handler, covering login, model listing, responses, voice signalling and tool handoffs. A React package provides the button component and its hook. A fourth package supplies providers for a widely used AI toolkit.

Splitting the framework binding into its own package is correct, because it means the authentication and proxying logic is reusable by anyone not on that framework, while the button stays a small optional convenience. The separate toolkit provider package does the same job for the generation side.

The claim that matters operationally is that a streaming call can be issued from the client and flow through the proxy, so the familiar generation interface works without the developer wiring a bespoke endpoint for every call. Everything ships as modern modules with types, against a Node runtime floor of version 18.

Beyond text, the README lists image generation and editing with control over size, quality, format and masks, including streaming previews, and an explicitly experimental real-time audio transport with native interruption plus a handoff mechanism for allowlisted tools requiring explicit confirmation.

Installing it, and the agent skill

Installation is the four packages together, shown with one runtime's package manager and documented as working with the others.

bun add @opencoredev/loginwithchatgpt-core @opencoredev/loginwithchatgpt-server @opencoredev/loginwithchatgpt-react @opencoredev/loginwithchatgpt-ai

After that the documented path is the quickstart in the repository's documentation directory, with separate documents for the security model and a production checklist. Shipping a production checklist as a first-class document, rather than as a paragraph, is a good sign for something handling other people's credentials.

The project also publishes an agent skill, installed through a dedicated tool.

npx skills add opencoredev/login-with-chatgpt

The reasoning given for it is specific and worth repeating, because it describes two failure modes the authors evidently saw. An agent wiring this up should not invent API keys, since there are none in this design, and it should not assume one model identifier works for every account, since availability varies by subscription. Both are exactly the mistakes a model would make by pattern-matching to the conventional setup it has seen far more often.

Packaging that correction as an installable skill, versioned alongside the code, is a more reliable fix than hoping the README is read.

The security model is the reason to look closely

For an SDK whose entire function is holding someone else's account session, the handling deserves scrutiny, and the stated design holds up on the points the README covers.

Tokens stay behind the proxy path by default. The browser receives only a session cookie marked inaccessible to scripts, which is the standard defence against a cross-site scripting flaw turning into account theft, since a script that runs in your page cannot read the cookie.

Model discovery runs server side too. The browser asks your backend which models the account has rather than querying the provider directly, so the account's capabilities are revealed through your server rather than by a call the page could be tricked into making.

That arrangement puts real responsibility on the deployer. Your server now holds refresh credentials for your users' accounts, and the blast radius of a compromise there is every account that has signed in. The repository provides a dedicated security document and a production checklist, and reading both before deploying is the minimum.

The one thing the repository does not address, in what is published here, is whether this integration is sanctioned by the provider whose accounts it authenticates against. That silence is worth noticing rather than assuming either way, because an integration built on a consumer subscription flow depends on that flow continuing to work and continuing to be permitted.

No releases, and other things to weigh

The repository has no tagged releases and the last push was on 2026-08-01. For an SDK holding credentials, the absence of a release history means no changelog boundary, nothing to pin against beyond a commit, and no signal about which states were considered stable.

The real-time audio transport is labelled experimental by the project, with a dedicated guide covering its limitations, so it should be read as a demonstration rather than a dependency.

Model availability being per account is a genuine design consequence rather than a defect, and it changes how you write your application. You cannot hardcode a model identifier and assume it resolves, so the interface has to handle an account whose subscription does not include what your feature expects. That is the kind of branch developers skip until a user reports the failure.

There is also a support asymmetry to consider. When a user's generation fails, the cause may be their subscription, their account state or their rate limit rather than anything in your code, and you have limited visibility into any of it. Building on a resource you do not control and cannot inspect makes support harder, and that cost arrives later than the savings do.

The repository is a workspace monorepo with packages, examples, documentation and skills directories, plus a container file whose comment explains it deploys the demonstration from the repository root so that workspace dependencies resolve and no build step is needed.

Your own API key is the alternative, and the split is who pays

The alternative is the conventional arrangement: hold a provider API key, call the model from your server, and pay for every token your users consume.

The difference decides more than the bill. With your own key you control which model is used, you can guarantee it exists, you see every error, you can cache, batch and rate limit as you choose, and your application works for a visitor who has no subscription at all. You pay for all of it, and your costs rise exactly as your product succeeds.

This SDK moves that burden to the user and takes the control with it. Your addressable audience narrows to people who already subscribe, the model available varies per account, and failures can originate somewhere you cannot see. In exchange a project with no revenue can offer real model capability to any number of users without a budget.

The decision follows from what you are building. For a product sold to customers, the conventional key is correct, because you cannot condition your paid product on a subscription to someone else's. For a free tool, an internal utility, or anything aimed at developers who certainly already pay for a subscription, shifting the cost is what makes the thing possible at all.

MIT terms and what to check before deploying

The project is MIT licensed, which is the permissive choice and raises nothing in review for the SDK itself. The terms governing the accounts it authenticates against are a separate question the repository does not settle, and that is the licensing question that actually matters here. This is not legal advice.

The repository is arranged as a workspace with the four packages, runnable examples, a documentation site, an agent skill and a container file for deploying the demonstration. Test and type-checking scripts are defined at the root, and the container installs from a frozen lockfile, which is the correct choice for reproducible deployment.

Before putting this in front of users, three things are worth settling in order. Read the security document and the production checklist, since your server becomes the custodian of your users' sessions. Decide how your interface behaves for an account whose subscription does not include the model your feature wants, because that branch is required rather than optional. And pin a commit, since there are no releases to pin instead.

Editorial conclusion

This SDK fits a free tool, an internal utility or anything aimed at developers who already hold a subscription, where shifting model cost to the user is what makes the project viable at all. It is the wrong foundation for a paid product, since you cannot condition what you sell on a subscription your customer buys elsewhere, and it excludes every visitor without one. Read the security document and production checklist before deploying, because your server becomes custodian of your users' sessions, handle the case where an account lacks the model your feature expects rather than hardcoding an identifier, and pin a commit, since the repository publishes no tagged releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. opencoredev/login-with-chatgpt on GitHub
4. Project website
5. README