Skip to main content
auto checks subscription eligibility and quota budgets separately. Use this guide when a connected ChatGPT subscription is not funding a session as expected, especially for work started by a GitHub bot.

​
Choose the project policy

In project settings, open General → Personal OpenAI subscription. With a usable connected subscription, choose the policy that matches the work you want to cover: The automation option is unavailable while another account holds the project’s automation funding role. Recovering a session’s automation origin does not enable or change a subscription policy. See the quickstart to connect a subscription.

​
How GitHub automation qualifies

When work has no requester, an existing project own_and_automations policy can sponsor it using trusted automation provenance. If stored provenance is missing, auto can recover the origin of a GitHub bot-triggered session from retained platform records:
  • Exactly one router started receipt must identify the session, whose agent belongs to the expected organization and project.
  • The receipt must reference an authenticated GitHub provider event routed through triggers, not a record-only event.
  • The event’s normalized author must be a bot, its payload type must match the recorded event key, and the event must not identify a requester.
  • The event must belong to the same organization. An organization-scoped event may qualify for the project that received it; an event scoped to a different project cannot.
Missing or ambiguous receipts, unknown authors, conflicting scope, and caller-supplied event IDs or bot identities do not establish this eligibility. Recovery does not substitute automation sponsorship for work with a human or asserted requester. GitHub events and routing describe how triggers start sessions. This recovery applies to new and existing sessions when funding is next resolved, not retroactively. It does not rewrite historical charges, session metadata, or stored provenance, and does not change the session API format.

​
Quota checks and fallback

For budget-gated subscription requests, quota refreshes use the same configured Node egress relay as model calls. This avoids a direct quota probe being blocked while relayed model calls succeed. A freshly measured quota remains the current operational state even when the following model response omits quota headers. The relay does not bypass your budget. Requests still fall back to platform funding when the configured quota cutoff is reached (quota_budget_reached) or quota cannot be measured (quota_unknown). A successful, under-budget refresh can restore subscription use; successful model calls alone do not prove that a quota probe succeeded.

​
Operator rollout notes

The bridge sends an authenticated POST to the relay. For the fixed upstream quota path /backend-api/wham/usage, the relay derives a bodyless GET. Internal authentication and the request-header allowlist still apply. Targets are restricted to the fixed backend host and allowed paths; URLs with credentials, query strings, or fragments are rejected. This is not a general-purpose proxy. Deploy the web relay’s quota-target support before the bridge starts relaying quota reads. An older relay rejects the new target, so a bridge-first rollout can leave quota-gated requests on platform fallback. A merged code change does not establish that both services have been deployed.