[Contributor Credits] Reward substantial verified bug-reporting work with additional Work/Codex usage

Summary

OpenAI should provide additional Work/Codex usage credits to users who spend substantial time producing high-quality, actionable product bug reports and diagnostics.

This is not a request to reward every complaint, thumbs-down, duplicate, or casual feedback submission. It is a request for a structured feedback-contributor credit program for users who materially help OpenAI reproduce, diagnose, classify, and improve product defects.

For active users, especially paid users, serious bug reporting can become hours of unpaid QA work:

• reproduce the defect repeatedly;
• compare desktop vs web or one product surface vs another;
• capture screenshots and exact app versions;
• run /feedback and preserve the Feedback ID;
• start performance traces or collect logs;
• search existing GitHub issues for duplicates;
• write a minimal, technically useful reproduction;
• redact private data for a public tracker;
• respond to duplicate-detection bots;
• clarify product terminology or affected surfaces;
• follow up when maintainers request more evidence;
• cross-check Help/Learn documentation;
• sometimes repeat the same report through Community, Discord, Help Center support, or other fragmented channels because it is unclear which one actually reaches the responsible team.

That contribution has real value to OpenAI. It improves engineering signal, reduces internal reproduction work, identifies regressions earlier, and gives maintainers evidence that often would otherwise have to be collected internally.

At the same time, the user doing this work may be consuming the same paid Work/Codex allowance they would otherwise use for their own work.

A reasonable form of recognition would be additional Work/Codex usage, not necessarily cash.

Motivation

Users should not feel that reporting OpenAI's defects is itself a second unpaid job that consumes both their time and their paid product allowance.

There is a major difference between:

“This is broken.”

and a report that contains:

• controlled A/B reproduction;
• exact affected product/mode;
• app/build version;
• Feedback ID;
• logs or performance trace;
• duplicate search;
• expected vs actual behavior;
• screenshots;
• isolation of client vs server behavior;
• follow-up evidence across releases;
• identification of documentation or taxonomy contradictions.

The latter is genuine product-quality contribution.

Concrete example of the burden

A single issue can require a user to:

1. notice and reproduce a defect;
2. verify it against another client such as chatgpt.com;
3. search the public tracker;
4. submit in-product feedback;
5. preserve a generated Feedback ID;
6. prepare a public-safe report;
7. file it on GitHub;
8. review an automated potential-duplicate comment;
9. inspect the proposed duplicate and explain why the issues are materially different;
10. update the report when new evidence appears;
11. monitor labels, comments, state changes, fixes, or releases;
12. sometimes navigate separate Community, Discord, or support channels when GitHub is not clearly the authoritative destination.

For users who report multiple regressions in a rapidly changing desktop application, this can easily consume hours that would otherwise be spent using the paid product for actual work.

Proposed solution: Feedback Contributor Credits

Create a program that grants bonus Work/Codex usage when a report provides meaningful engineering value.

Possible names:

• Feedback Contributor Credits
• Product Quality Credits
• Bug Reporter Credits
• OpenAI Contributor Usage

The credits should be separate from the user's normal purchased allowance and should not reduce or alter the underlying subscription entitlement.

What should qualify

Credits should be discretionary and based on objective contribution quality rather than simply issue count.

Potential qualifying signals:

• issue confirmed by OpenAI or independently reproduced;
• high-quality minimal reproduction;
• new regression not already reported;
• useful diagnostic bundle or Feedback ID;
• performance trace that identifies the failure window;
• logs that materially isolate the cause;
• controlled comparison across clients/builds/models;
• report that uncovers an issue affecting multiple users;
• substantial follow-up requested by maintainers;
• discovery that an apparent duplicate is actually a distinct failure mode;
• documentation or product-taxonomy inconsistency that causes support/triage errors;
• report leading directly to a fix, PR, rollback, documentation change, or known-issue entry.

A report should not qualify merely because it is long.

Suggested credit model

OpenAI could use simple tiers rather than trying to calculate an hourly wage.

For example:

Contribution acknowledged

For a useful, non-duplicate report with sufficient reproduction evidence:

• small bonus Work/Codex usage grant.

Confirmed / high-value report

For a confirmed regression, strong diagnostic isolation, or material engineering follow-up:

• larger temporary usage grant or one additional usage reset.

Exceptional contribution

For a report that identifies a serious defect, produces a reliable reproducer, uncovers a root-cause family, or directly helps land a fix:

• larger bonus allowance determined by the product team.

The exact amounts are a product-policy decision. The key principle is that useful QA contribution should sometimes increase the user's available Work/Codex capacity instead of consuming it with no recognition.

Alternative: reimburse reporting usage

A more conservative implementation would simply reimburse usage consumed while preparing an accepted diagnostic report.

For example, if a user spends a Work/Codex session reproducing the bug, collecting evidence, comparing logs, and preparing the report, OpenAI could return some or all of that consumed usage once the report is triaged as useful.

This would avoid treating bug reporting as free extra quota while still preventing the user from effectively paying to diagnose OpenAI's own defect.

Integration with the proposed OpenAI-native issue tracker

This would fit naturally with #37583, which proposes an OpenAI-native issue tracker and reporting app/plugin.

A trackable report could expose a contribution state such as:

Report: OAI-DESKTOP-12345
Status: Confirmed
Contributor credit: 1 Work/Codex usage grant
Reason: New regression + reproducible desktop/web A/B + diagnostics attached

The credit decision should be transparent enough that users understand why a contribution did or did not qualify.

Abuse prevention

The program should explicitly avoid incentives for spam.

Safeguards could include:

• no automatic credit merely for creating an issue;
• no credit for obvious duplicates unless the new evidence materially advances the canonical issue;
• no credit for fabricated or low-effort reports;
• rate limits on contributor rewards;
• credit granted only after automated + human/engineering triage, or after objective confirmation criteria are met;
• merge corroborating reports into one canonical issue while preserving useful private evidence;
• reward quality, diagnostic value, and novelty—not volume.

Paid users and fairness

This matters particularly for paid users who rely heavily on Work/Codex for professional or consequential work.

If a user is already paying for a constrained usage allowance and then loses hours to diagnosing product defects, asking that user to consume additional paid allowance to prepare the report creates the wrong incentive:

• reporting becomes costly;
• users stop documenting defects carefully;
• high-quality diagnostics are abandoned;
• engineering receives lower-quality signal;
• frustrated users move the discussion to Reddit/Discord rather than producing a structured report.

A modest usage-credit program would make the incentives point in the opposite direction.

Why usage credit instead of cash

This proposal does not require a universal cash bug bounty.

Additional Work/Codex usage is closely aligned with the affected users' actual need and is operationally simpler than paying cash for ordinary product bugs.

It also creates a constructive loop:

user finds defect
→ user invests time producing actionable evidence
→ OpenAI benefits from better engineering signal
→ user receives additional product capacity
→ user can return to the work that was interrupted by the defect

Security vulnerabilities should continue to use whatever dedicated security/bounty process OpenAI considers appropriate; this request concerns ordinary product-quality contributions.

Related but distinct issues

I searched before filing and did not find an exact request for contributor usage credits tied to substantial bug-reporting work.

Related issues include:

• #32225 — requests service/feedback-channel improvements and raises the problem of users investing substantial effort in proprietary incident reporting.
• #36471 — asks about service credit where repeated product failures degrade paid use.
• #26745 — argues users should not bear usage costs caused by the model repeatedly fixing its own mistakes.
• #37583 — proposes an OpenAI-native issue tracker and reporting app/plugin with trackable cases.
• #37581 — documents taxonomy/reporting fragmentation across the unified desktop app and GitHub.

Those issues concern wasted usage, reporting infrastructure, or specific failures. This request is specifically about recognizing valuable user QA contribution with additional Work/Codex capacity.

Acceptance criteria

• OpenAI defines a documented mechanism for granting bonus usage for meaningful product-quality contributions.
• Credits are based on report value/confirmation, not raw report count.
• The user can see when a report qualified and what was granted.
• Credits are additive and do not silently replace the user's purchased allowance.
• Confirmed duplicates can still receive credit when the reporter contributes materially new diagnostic evidence.
• /feedback, performance traces, GitHub/OpenAI issue IDs, and maintainer requests can be used as evidence of contribution.
• The process includes abuse/spam safeguards.
• Users are not required to publish private data to qualify.
• The program distinguishes ordinary product bug contribution from formal security vulnerability bounty programs.

Expected outcome

Users who spend significant time helping OpenAI reproduce and diagnose its own product defects should not feel that they are paying twice: once with their subscription and again with hours of unpaid QA work that consumes the same product allowance.

For substantial, verified contributions, OpenAI should return some value in the form most directly useful to these users: more Work/Codex usage.