Proposal: optional ChatGPT plan usage for owner-only dashboard answers

[oudouusa]

Summary

Would an optional ChatGPT provider for the built-in dashboard's answers be useful?
An owner who already has an eligible ChatGPT plan could explicitly authorize
Second Brain to use that plan through Sign in with ChatGPT and the public
Responses API. Workers AI would remain the default, with no sign-in required.

The benefit is an additional inference option for the dashboard. I am not claiming
better answer quality, lower cost, or lower latency without a paired evaluation.
This is a design discussion, not a ready-to-merge upstream implementation.

Initial scope

• Disabled by default; explicitly enabled by the deployment owner.
• Dashboard answer generation only, using the owner's personal workspace.
• No team/member usage, background classification, merges, or nightly jobs.
• Preserve MCP recall without server-side synthesis, as in #219.
• No access to ChatGPT conversation history. No changes to search, embeddings,
  memory storage, the desktop installer, or existing authentication.

An upstream patch would need server-established personal retrieval scope.
Client-supplied workspace labels alone do not prove where answer context came from.

Authentication and inference boundaries

• Bind one active credential session to the deployment owner. Keep a stable,
  opaque host ID and separate registrations by Worker origin and account profile.
• Complete OAuth locally with state, nonce, PKCE and signed ID-token validation;
  securely transfer credentials to the owner-authenticated Worker. Let the Worker
  own refreshes, with encrypted D1 storage and conditional updates preventing
  stale refreshes or disconnects from overwriting a newer session.
• Use the signed-in account's model catalog and an explicitly qualified model
  allowlist. Missing models must produce an actionable error.
• Call the public Responses endpoint with store: false and stream: true.
  Require response.completed; interrupted or failed streams must not leave a
  partial answer presented as complete. Bound response size and request lifetime.
• Show the active provider and a Manage usage link using existing translations.
  Distinguish usage limits, expired/revoked sessions and transient failures. Do not
  automatically retry a selected ChatGPT request through a billable API provider.

This would add credential lifecycle maintenance. A first experimental flow could
use an advanced-owner CLI; a complete dashboard account/recovery UI would need
separate work. The proposal does not require a VPS, proxy service, new runtime
dependencies, or a new Durable Object binding.

Evidence and checks before adoption

A fork prototype exercises owner/workspace isolation, encrypted credentials,
refresh/disconnect races, loopback OAuth and stream completion with synthetic
tests. These checks are not a Workers AI comparison or proof of production
latency, resource cost, or general deployment eligibility. The fork also explores
other operations; those are outside this first upstream proposal.

Before adoption, I would prepare a minimal upstream patch and check:

1. Default installations still work without ChatGPT credentials; team, member,
   mixed-context and unconfigured requests cannot consume the owner's plan.
2. Credential rotation, account mismatch, revoked consent, usage limits and
   interrupted streams have reproducible tests and clear recovery steps.
3. A shared answer fixture set compares Workers AI and ChatGPT for source-backed
   accuracy, citations, dates, time to first text, and completion time.
4. Worker CPU/wall time and storage usage are measured on the upstream route,
   rather than inferred from the fork's execution architecture.

Open questions

OpenAI's overview
describes open-source/local apps and directs paid or remotely hosted apps to an
interest form. Its self-hosted VM guide
describes credential transfer and remote refresh ownership; I am treating that as
a design reference, not confirmation that an owner-managed Cloudflare Worker is
eligible. Deployment eligibility needs confirmation before general distribution.
The inference guide
defines the public endpoint and completion contract above.

Would this limited, owner-only answer provider be worth exploring, and is an
advanced-owner experiment an acceptable starting point for the project?

[rahilp]

Would love the community’s perspective on this proposal. The issue I can immediately call out is that CF does not have access to a users subscription to ChatGPT or other providers. But open to learning how this could be accomplished

[oudouusa]

Thanks for raising this. I have a reference implementation in my fork using Sign in with ChatGPT and Cloudflare Durable Objects. Access to eligible ChatGPT plan usage comes from the owner's explicit OAuth consent; the Worker then uses the issued access token to call OpenAI's public Responses API.

OpenAI documents this in Sign in with ChatGPT for open-source apps and Models and inference.

The flow in my fork is:

1. The deployment has a persistent host ID. The owner completes OAuth locally, with PKCE, state/nonce checks, signed ID-token validation, and verification of the plan-usage permission.
2. The CLI transfers the credentials over HTTPS to an owner-authenticated Worker endpoint. They are encrypted in D1 using a Worker secret. The application on the Worker owns subsequent refreshes, with conditional D1 updates protecting against concurrent token rotation.
3. The Cloudflare runtime calls https://api.openai.com/v1/responses with the OAuth bearer token, store: false, and stream: true, and requires response.completed before treating the answer as successful. This path does not require a VPS or CLIProxyAPI.

Durable Objects provide the execution boundary in this implementation: the fork's existing executor handles credential administration and dashboard answer streaming, while a separate object in the same namespace handles nightly maintenance. Credentials remain in D1, rather than in Durable Object storage. Weekly insights retain their separate scheduled invocation.

My own deployment has the provider enabled more broadly than the initial upstream proposal, for eligible owner-personal processing:

• Classification of captured memories, including deferred-classification retries.
• Smart-merge decisions and contradiction detection.
• Optional retrieval summaries and dashboard answers.
• Nightly digest generation from eligible memories.
• Weekly insight generation and reasoning about relationships between memories.

These operations are individually selectable and scoped to the deployment owner's personal workspace. Embeddings and reranking continue using Workers AI. MCP recall still returns retrieved memories without server-side synthesis. The broader fork configuration is context for the implementation; the initial upstream proposal would remain disabled by default and limited to owner-personal dashboard answers.

The implementation notes describe the scope and recovery behavior. The executor and provider are available as reference code.

Two points still need work before upstream adoption. OpenAI's self-hosted VM guide describes credential transfer and remote refresh ownership, but the overview directs remotely hosted apps to an interest form; I would not treat this prototype as confirmation of Workers deployment eligibility. Also, an upstream answer route should establish personal retrieval scope on the server: the fork's current client-supplied context does not prove the provenance of arbitrary submitted text.

Would this reference implementation help evaluate the approach? I would be happy to prepare a smaller, answer-only patch around the agreed boundaries.