[FEATURE] Token credit program for bug investigation and reporting — align incentives for community QA

Resolved 💬 6 comments Opened Mar 3, 2026 by smconner Closed Apr 2, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single feature request

Feature Description

Create a community contributor program that compensates Claude Code users for the tokens and time they spend investigating, reproducing, and reporting bugs. This isn't just about fairness — it's about opening a massively wider pipeline of product feedback at near-zero marginal cost to Anthropic, using Anthropic's own unique competitive advantage: AI-powered triage.

---

The User's Pain

Bug investigation is expensive for users. The cost is invisible, compounding, and falls entirely on the person doing Anthropic's QA work.

| Activity | Token Cost | Who Benefits |
|---|---|---|
| Normal productive work | User's quota | User |
| Bug destroys a conversation mid-task | User's quota | Nobody |
| Investigating the bug (reading logs, testing hypotheses) | User's quota | Anthropic |
| Writing a detailed reproduction report | User's quota | Anthropic |
| Cross-referencing related issues | User's quota | Anthropic |

The user pays at every stage — for Anthropic's bugs consuming their tokens, and for the investigation work that saves Anthropic's engineers hours of triage.

A concrete example from today

A bug where accumulated PDF reads permanently killed two conversations (#30542). Here's the actual cost — verified from the JSONL conversation files:

| Conversation | Purpose | Total Tokens | API Calls |
|---|---|---:|---:|
| 1fac3c7e | Productive work (letter writing) — hit the bug | 4,374,537 | 114 |
| 1cbdcd48 | Debugging the bug — also hit the bug | 3,621,578 | 82 |
| 98037ab2 | Investigating, analyzing, and filing 3 reports (#30542, #30546, this issue) | 5,749,545 | 139 |
| Grand Total | | 13,745,660 | 335 |

<details>
<summary>Token breakdown by type (all three conversations combined)</summary>

| Token Type | Count |
|---|---:|
| Input tokens | 862 |
| Output tokens | 53,499 |
| Cache creation tokens | 460,374 |
| Cache read tokens | 13,230,925 |
| Total | 13,745,660 |

Cache read tokens dominate because every API call resends the full conversation context — this is exactly the compounding problem described in #30542.

</details>

The bug investigation and reporting consumed ~9.4 million tokens — more than double the ~4.4 million tokens spent on the actual productive work. That's 2.1× the productive cost, spent entirely doing Anthropic's QA.

This isn't a one-off. The most valuable community members — the ones who write the best reports — burn the most tokens doing it. The current incentive structure actively punishes thoroughness.

---

The Scale: Anthropic's Largest Unpaid QA Team

| Metric | Count | Source |
|---|---:|---|
| Total issues filed | 29,287 | GitHub search API |
| Unique issue authors (confirmed, from 10K sample) | 7,899 | Deduplicated from paginated API |
| Unique issue authors (estimated, all 29K issues) | ~15,000–21,000 | Power law extrapolation |
| Currently open issues | 5,473 | GitHub API |

<details>
<summary>Methodology for contributor estimate</summary>

GitHub's page-based pagination caps at 10,000 results. From that sample:

  • Pages 1–50 (issues 1–5,000): 4,195 unique authors (83.9% unique rate)
  • Pages 51–100 (issues 5,001–10,000): 3,704 new unique authors (74.1% new rate)

The declining new-author rate follows a power law: U(n) = a × n^0.913. Extrapolating to 29,287 issues gives ~21,000 unique contributors. The lower bound (~15,000) accounts for higher repeat-reporter rates in the unsampled tail.

</details>

That's 15,000–21,000 individual people filing issues — many with reproduction steps, logs, and cross-references. By any measure, one of the largest community QA operations for a commercial developer tool.

Right now, the incentive structure is:

Report a bug thoroughly   → Burn your own tokens, get nothing back
Report a bug lazily       → Burn fewer tokens, same result
Don't report at all       → Save your tokens, keep working

The users Anthropic most wants to encourage — meticulous reporters who isolate root causes — are the ones most penalized.

---

Why Anthropic Is Uniquely Positioned to Solve This

Traditional bug bounty programs (Chrome VRP, HackerOne, Bugcrowd) face a fundamental constraint: human triage is expensive. Every report, good or bad, costs 15–30 minutes of engineer time to read, classify, and respond. This forces them to build elaborate gate-keeping mechanisms — reputation systems, proof-of-concept requirements, tiered access — to prevent garbage from overwhelming the pipeline. The gates work, but they also suppress legitimate contributions from less-experienced reporters.

Anthropic doesn't have this constraint. Anthropic is an AI company — it would be extraordinary if they weren't already running Claude on incoming issues for classification, clustering, and triage. The infrastructure to process reports at scale almost certainly exists today. The unique competitive advantage is that the triage cost is near-zero:

| Triage Model | Cost per Report | 10× Volume Impact |
|---|---|---|
| Human engineer (traditional) | ~$50–100 (30 min × $100–200/hr) | Pipeline collapse |
| Claude-powered AI triage | ~$0.01–0.05 in tokens | Negligible |

When your filter is your own AI product:

  • A report that says "Claude broke when I read a PDF" — useless to a human triager — is rich signal for Claude, which can match it against hundreds of similar reports, cross-reference telemetry, and extract environment/version/model metadata
  • Reports that a human would classify as "garbage" still contain useful patterns: error messages, environment info, usage flows, implicit reproduction steps
  • Clustering thousands of low-quality reports can reveal systemic issues that no single high-quality report would surface
  • The marginal cost of processing one more report is essentially zero

This inverts the traditional mechanism design problem. Instead of building expensive gates to keep garbage out, you extract signal from everything. The threshold for "useful" drops dramatically. And if Anthropic is already running AI triage (as any AI company should be on day one), then the incremental cost of adding a credit-assignment step is essentially zero — the pipeline exists, it just needs a webhook on the output.

What this means for incentive design

The traditional tradeoff — openness vs. quality — dissolves when triage is AI-powered:

Traditional:  Gate heavily → Small pipeline → High quality → Expensive triage
Anthropic:    Open widely → Massive pipeline → Mixed quality → Near-free AI triage

The optimal strategy is radically open: low barriers, generous credits, broad participation. Even "noisy" contributors generate aggregate signal that's enormously valuable. The game mechanics should shift from "preventing bad contributions" to "amplifying good ones."

---

The Three Mechanical Problems

Any contributor program must solve three hard problems: Attribution (who gets credit), Quality (how to reward signal over noise), and Accounting (how to bound costs). Here's how established frameworks from mechanism design, causal inference, and game theory address each.

1. Attribution — Causal credit assignment

The core question: "Did this report actually cause value, or would the bug have been found anyway?"

Judea Pearl's counterfactual framework provides the principled answer: surgically remove a contribution from the causal graph and evaluate whether the outcome changes. In practice:

| Scenario | Causal Credit | Reasoning |
|---|---|---|
| First report with reproduction steps | High | Counterfactual: without this, engineers spend days |
| Duplicate report, same information | Near-zero | Marginal value in coalition with the original is ~0 |
| Duplicate report, new information (e.g., identifies root cause) | Partial | Adds genuine causal value beyond the original |
| Cross-reference linking related issues | Moderate | Reduces triage time — causal contribution to fix speed |
| Low-quality report that joins a cluster of 50 similar reports | Small but real | Contributed to pattern detection at aggregate level |

For redundant contributions (multiple people reporting the same bug), Shapley values provide mathematically fair attribution: compute the average marginal contribution across all possible orderings of contributors. This handles the hard cases — partial contributions, overlapping discoveries, contributions that build on each other — with formal guarantees (symmetry, efficiency, null-player axioms).

AI advantage: Claude can automate the Shapley-style evaluation by reading all related reports and computing marginal information contribution. No human judgment required.

2. Quality — Incentivize signal, not volume

<details>
<summary>Research basis: DARPA Red Balloon Challenge, game mechanics, behavioral economics</summary>

The DARPA Red Balloon Challenge (2009) demonstrated that recursive incentive structures can mobilize massive networks without attracting garbage. MIT's winning mechanism used a geometric payment series ($2,000 → $1,000 → $500 → ...) that made propagation a dominant strategy while being inherently Sybil-resistant — inserting fake intermediaries fragments rewards without increasing total extraction.

Stack Overflow's privilege escalation is the gold standard for graduated trust: earn 15 rep to upvote, 125 to downvote (costs 1 rep), 2,000 to edit without review, 10,000 to access moderation tools. Time-gating + activity-gating defeats bot farms while giving newcomers a clear progression path.

HackerOne's signal-to-noise ratio provides reputational skin in the game: every spam report permanently damages your visible track record, creating loss aversion (Kahneman/Tversky: losses felt ~2× as strongly as equivalent gains) that self-polices quality.

</details>

But here's the key insight: with AI triage, the quality bar shifts. You don't need to prevent low-quality reports — you need to extract maximum signal from whatever arrives. The mechanism should:

  1. Reward depth, not volume: Flat base credit for any confirmed bug + variable bonuses for exceptional reports (reproduction steps, root cause analysis, cross-references). Variable-ratio reinforcement sustains engagement without encouraging spam.
  1. Make quality visible, not gated: Instead of blocking low-quality reporters, give them a visible signal-to-noise ratio on their profile. Social pressure + loss aversion does the rest.
  1. Let AI assess contribution quality: Claude can evaluate report completeness, check for reproduction steps, identify novel information vs. duplicates, and assign a quality score — automatically, at near-zero cost.
  1. Graduated trust unlocks better rewards, not access: Everyone can report. But reporters with a track record of confirmed, high-quality bugs unlock higher credit tiers, faster processing, and recognition. Clear progression path, but no one is locked out.
3. Accounting — Bounded costs by construction

The DARPA Red Balloon mechanism's critical property: total liability is bounded a priori. MIT's geometric series ($2,000 × Σ(1/2)^k) converges to exactly $4,000 per balloon regardless of chain depth. The mechanism designer's exposure is known before the program launches.

For Anthropic, the accounting math is straightforward:

| Parameter | Value | Notes |
|---|---|---|
| Contributors | ~20,000 | Current estimate |
| Monthly credit per confirmed bug | ~$5–10 in tokens | ~500K–1M tokens at API pricing |
| Worst-case: every contributor files 1 confirmed bug/month | $100K–200K/month | Upper bound |
| Anthropic's estimated annual revenue | Multi-billion | This is a rounding error |
| Cost of one senior engineer doing the same triage work | ~$15K–25K/month | One person, doing worse work |

Even the worst-case scenario — every single contributor filing a confirmed bug every month — costs less than two engineering salaries. And that worst case is also the best case for product quality: it would mean 20,000 confirmed bugs being found and fixed per month.

The cost is self-evidently worth it. The only question is mechanism design, not budget.

---

Proposed Mechanism

Combining the frameworks above into a concrete system:

Layer 1: Automatic loss detection (zero friction)

When Claude Code detects a conversation destroyed by its own bug (N consecutive rate limit errors, crash loops, abandoned-after-error), automatically:

  1. Flag the conversation as bug-impacted
  2. Estimate wasted tokens from retries and failed resumes
  3. Credit the user's account — no action required

This compensates for damage regardless of whether the user reports it. Detection is based on Claude Code's own error patterns, making it fraud-resistant.

Layer 2: Report-and-credit (low friction)

When a user files a GitHub issue:

  1. AI triage (Claude) reads the report, evaluates completeness, checks for duplicates, assigns a quality score
  2. Base credit applied immediately for any non-duplicate report that passes minimum quality (has an error message, version, or any useful signal)
  3. Bonus credit when staff confirms the bug (labeled bug + confirmed or has repro)
  4. Attribution credit distributed via Shapley-style evaluation if multiple reports contribute to the same fix

This is radically open — the base credit is small enough that gaming isn't worth it, but large enough to signal that contributions are valued. AI triage keeps the cost near-zero.

Layer 3: Reputation and recognition (sustained engagement)
  • Signal-to-noise ratio visible on contributor profiles (social incentive + loss aversion)
  • Tiered rewards: Newcomer → Established → Trusted. Higher tiers earn larger credits and get recognized in release notes
  • Variable bonuses for exceptional reports (root cause identified, fix suggested, cross-references provided). Creates variable-ratio reinforcement that sustains engagement
  • Reputation decay for inactivity and sharp drops for invalid reports (loss aversion > gain seeking)
Layer 4: Propagation incentives (network effects)

Borrowing from the DARPA Red Balloon mechanism: when a contributor's report cross-references another report that leads to a fix, both reporters receive credit (geometric decay). This makes helping other reporters improve their submissions a dominant strategy — you can never lose by making someone else's report better.

---

Why This Is Different From Traditional Bug Bounties

| Dimension | Traditional (Chrome VRP, HackerOne) | Proposed (Anthropic) |
|---|---|---|
| Triage cost | $50–100/report (human) | $0.01–0.05/report (AI) |
| Gate strategy | Heavy (PoC required, reputation gates) | Light (AI extracts signal from anything) |
| Quality enforcement | Pre-submission filters | Post-submission AI evaluation |
| Garbage handling | Prevent it (expensive) | Process it (cheap, still contains signal) |
| Optimal openness | Restricted (cost-constrained) | Radically open (cost is negligible) |
| Aggregate signal | Limited to expert reporters | Massive (every user is a sensor) |
| Budget risk | High (bounties are large) | Negligible (token credits are cheap) |

The fundamental insight: Anthropic can afford to be generous because the triage cost is near-zero, and the aggregate signal from 20,000 contributors — even the noisy ones — is enormously valuable. No other company in the bug bounty space has this advantage.

---

Legal Precedent: This Is a Solved Problem

Every major tech company already runs a reward program for external bug reporters, and the legal structure is well-established:

| Program | Term Used | Structure |
|---|---|---|
| Google VRP | "Reward" | Discretionary, no guaranteed minimum |
| Microsoft MSRC | "Bounty" / "Award" | Determined "in its sole discretion" |
| HackerOne (platform) | "Bounty" | Participants explicitly "not employees, contractors, or agents" |
| Apple Security Bounty | "Reward" | Voluntary, no exclusivity |

Worker classification risk is minimal when properly structured. No case law has ever classified bug bounty reporters as employees. California's AB5 (2020) raised theoretical concerns, but no enforcement actions followed against any bounty platform. The key safe harbors are well-documented:

  1. "Rewards," never "compensation" — framing matters (though economic reality governs, per Commissioner v. Duberstein)
  2. Discretionary amounts — company determines "in its sole discretion," no guaranteed minimum
  3. No exclusivity — participants can report to anyone, anytime
  4. No control over methods — reporter chooses what to test, when, and how
  5. Voluntary participation — entirely at the reporter's initiative
  6. Unilateral modification/cancellation — program can be changed or ended at any time
  7. Tax responsibility on participant — "Participant is solely responsible for all applicable taxes"

For token credits specifically: In-kind rewards are technically taxable at fair market value, but the 1099-NEC reporting threshold was raised to $2,000 starting 2026. Token credits for bug reports would almost certainly fall below this threshold, making the administrative burden negligible for both Anthropic and participants.

<details>
<summary>Sources</summary>

</details>

---

Minimum Viable Version

If the full program is too complex for v1, start with just Layer 1 + a simplified Layer 2:

1. Auto-detect conversations destroyed by bugs (consecutive errors, crash loops). Credit the user automatically. 2. When a GitHub issue is labeled bug + confirmed by staff, automatically credit the reporter's linked Claude account with a flat token reward (e.g., 500K tokens).

This is:

  • Simple to implement (error heuristic + GitHub webhook → account credit)
  • Low fraud risk (auto-detection is based on Claude Code's own error patterns; manual confirmation requires staff)
  • Legally precedented (same structure as Google VRP, Microsoft MSRC, Apple Security Bounty)
  • Directly aligned (rewards the behavior Anthropic wants)
  • A foundation to build Layers 3–4 on once the pipeline is proven

---

US Employment Law Carveout: Why This Won't Create an Employment Relationship

A reasonable concern from Anthropic's legal team would be: "Does rewarding bug reporters create an employer-employee or independent contractor relationship?" The answer is no — and there is extensive precedent establishing this.

The controlling legal tests

Federal (IRS 20-factor test / common law): The IRS evaluates worker classification based on behavioral control, financial control, and relationship type. Bug reporters fail every prong of the employment test:

| Factor | Employee | Bug Reporter |
|---|---|---|
| Behavioral control | Company directs when, where, how | Reporter chooses what to test, when, and how |
| Financial control | Company controls business aspects | Reporter uses own tools, bears own costs |
| Relationship type | Ongoing, with benefits | Sporadic, voluntary, no expectations |
| Exclusivity | Typically one employer | Can report to any company simultaneously |
| Payment structure | Regular wages/salary | Discretionary, per-event rewards |

California (ABC test under AB5, Cal. Lab. Code § 2775): California's stricter test presumes employment unless all three prongs are met:

  • (A) Free from control and direction — Bug reporters choose what to investigate, when to report, and whether to participate at all. No assignments, no deadlines, no supervision. ✅
  • (B) Outside the usual course of business — This is the closest call. Anthropic's business is building AI, not finding bugs. Bug reporting is a customer feedback activity, not a core business function. The same analysis applies to every existing VRP — Google's business is search/ads, not vulnerability research. ✅
  • (C) Independently established in that trade — Bug reporters are users of the product exercising their own judgment. They are not held out as being in the business of bug hunting (unlike HackerOne researchers, who arguably are). ✅

When AB5 was enacted in 2020, employment lawyers specifically analyzed its impact on bug bounty platforms. UC Hastings professor Veena Dubal noted the law "is not black and white" for dedicated security researchers who work primarily through one platform — but the concern was about full-time bounty hunters on HackerOne/Bugcrowd, not product users reporting bugs they encounter during normal use. There is a material legal distinction between a professional security researcher (who might look like a contractor) and a paying customer who reports a bug they hit while doing their actual work.

No enforcement actions have been brought against any bug bounty program under AB5 or any other worker classification statute as of 2026.

Case law: rewards ≠ compensation

Commissioner v. Duberstein, 363 U.S. 278 (1960): The Supreme Court held that whether a transfer is a "gift" vs. "compensation" depends on the transferor's intent — specifically, whether it proceeds from "detached and disinterested generosity" or from "the incentive of anticipated benefit." Under this test, a discretionary token reward for a bug report is closer to a promotional incentive than to compensation for services rendered. The reporter didn't perform work at the company's direction — they encountered a problem during their own use and chose to share it.

Nationwide Mutual Insurance Co. v. Darden, 503 U.S. 318 (1992): The Supreme Court established that the common-law agency test governs employment relationships under ERISA, centering on the employer's right to control the manner and means of the worker's performance. Bug reporters are subject to zero control — Anthropic does not direct what they test, when they test, or how they report.

Dynamex Operations West, Inc. v. Superior Court, 4 Cal. 5th 903 (2018): The California Supreme Court decision that established the ABC test (later codified as AB5). The court's concern was companies misclassifying workers who are economically dependent on the hiring entity and integrated into its business operations. Paying customers who voluntarily file bug reports are neither economically dependent on Anthropic's reward program nor integrated into Anthropic's engineering operations.

Structural safeguards in this proposal

The proposed mechanism is designed to stay clearly on the "reward" side of every legal line:

  1. Customers first, reporters second — Participants are existing paying customers (Claude Max subscribers) who encounter bugs during normal use. They are not recruited, solicited, or directed to find bugs.
  2. Discretionary rewards, not obligatory payments — Anthropic determines amounts "in its sole discretion" with no guaranteed minimum. The program can be modified or cancelled at any time.
  3. In-kind credits, not cash — Token credits are a platform benefit, not wages. They have no cash-out mechanism and are consumed within the same product the user is already paying for.
  4. No exclusivity, no assignments, no deadlines — No element of control or direction exists in the relationship.
  5. Below 1099 reporting threshold — At ~500K tokens per confirmed bug (well under $2,000 FMV), individual participants would almost certainly fall below the 2026 reporting threshold of $2,000, eliminating 1099 administrative burden.
  6. Industry-standard Terms of Participation — The same disclaimer language used by Google, Microsoft, Apple, and HackerOne for over a decade: "Participants are not employees, contractors, or agents of Anthropic."
The bottom line

Discretionary token rewards for voluntary bug reports by paying customers sit squarely within the legal framework that has governed Google VRP ($12M+ paid), Microsoft MSRC, Apple Security Bounty, and HackerOne ($300M+ paid to researchers) for over a decade — without a single adverse employment classification ruling. The proposed program is actually lower-risk than any of these, because Anthropic's reporters are existing paying customers who encounter bugs organically, not recruited security researchers.

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗