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. Requesterless work does not enable or change a subscription policy by itself. See the quickstart to connect a subscription.
Allow corroborated agent attribution is a separate setting. It lets a server-corroborated agent assertion count as a request from your account; both your consent and server-side corroboration are required. It does not control requesterless automation funding.
How requesterless work qualifies
An existing projectown_and_automations policy can sponsor work when its effective requester is absent and the server recorded that absence. This includes cron, webhook, agent-spawned and ordinary project work without a requester. GitHub bot identity, trigger receipts and stored workProvenance are not required to establish this eligibility.
An explicit, inherited or asserted requester is not requesterless work, even if that identity cannot be resolved to an account. When a current message turn replaces the session’s static requester, funding uses that turn’s requester and capture status together; otherwise it uses the stored session’s paired values. It does not borrow a capture marker from a different attribution context.
Session records expose requesterCaptureComplete, a boolean that defaults to false for older records. Updated server writers set it to true when they capture requester presence or absence. Persisted message commands carry the same server-written marker; its absence in an older command means unknown, not requesterless. This is capture metadata, not a user-selectable funding policy.
Existing sessions and eligibility limits
Migration0301_curvy_ikaris adds requester_capture_complete with a default of false and does not backfill historical sessions. An older null requester alone cannot qualify for automation sponsorship. A fresh message whose server-captured requester is absent can establish eligibility for that turn when funding is next resolved, without reclassifying the session’s historical attribution or charges.
The subscription must still satisfy organization and project scope, owner membership, credential health, policy, harness, provider, model and quota eligibility. The broader definition of automation neither raises a quota budget nor forces an immediate funding switch. Existing fallback recovery still requires the exact stored rejection evidence described below.
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 use fallback funding when the configured quota cutoff is reached (quota_budget_reached) or quota cannot be measured (quota_unknown). Successful model calls alone do not prove that a quota probe succeeded.
Recover after a budget reset
An existing session can return from platform or tenant-provider funding to its connected subscription without restarting. This requires a stored funding decision that identifies the exact rejected subscription and recordsquota_budget_reached as the rejection reason. Launch and requester-attribution funding decisions record this evidence; not every fallback is eligible.
On a subsequent OpenAI /v1/responses or /v1/alpha/search request, auto rechecks the current subscription candidate, policy, access, requester or automation sponsorship, the actual request model, and the session’s harness eligibility. If the same subscription still qualifies and its current budget evaluation is under budget, the gateway can use it for that request. A reset alone does not override these checks.
Quota observations are shared across launch, requester attribution and the gateway, with a five-minute freshness window and a cross-process refresh claim. A cached over-budget observation can delay recognition of a reset. A fresh unavailable observation is also retained rather than probed on every request. When a refresh is already in progress and no usable observation is available, concurrent budget-gated requests remain on fallback instead of waiting for that probe.
Legacy rows without the exact rejection evidence, other rejection reasons, and a different current subscription candidate do not qualify for this recovery. Revoked or unusable credentials, missing eligibility, removed policies, and quota that remains over budget, stale or unknown also keep budget-gated requests on fallback.
The recovery write checks that the stored fallback source, provider grant, rejected subscription, rejection reason and attribution epoch still match. It changes current funding, not historical charges, budgets or subscription policy. Existing rows are not backfilled; a later normal funding decision must record the missing evidence. The database migration and backend rollout are separate operator work: a source merge does not prove live recovery is active.
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.