What 36,000 people reported, and who should own each fix.

Organic issues only. Drivers come from text clusters fit on the 21 training weeks and named by Claude from a review file that shows training issues only. Counts are rounded to two significant figures, because reseeding the clustering keeps only 77% to 83% of issues in the same driver. Drivers marked provisional dissolve under reseeding. Catch-all buckets are left out of the ranking: low-content, empty reports, and assorted feature requests, 4,394 issues (9.4%).

Weekly bars: gray is training, blue is the 4-week holdout. Reactions per issue shows a driver's rank by total reactions when it differs from its rank by count by 10 or more places (rank correlation 0.44). Reactions favor older issues and GitHub-template reports, and /bug reporters never see existing issues to react to. Data-loss counts the maintainers' data-loss label: 429 organic issues, 60% of them in lost or unresumable sessions (107), file read, write, and edit tools (68), git worktree isolation (49), instruction-following and overclaiming complaints (34). Inferred owner is the driver's most common area:* label. Confidence is high when it covers at least 75% of labelled issues, medium at 50% to 75%, and otherwise the driver needs an owner. Label fit stands in for team fit; for the safeguard drivers, area:model likely spans several teams. Closed without fix covers non-duplicate issues created before July 28, closed as stale, not planned, or after an unanswered request for information. Provisional: mean overlap below 0.5 across five reseeds and one refit.

A driver is flagged on a release when organic reports that state that version are over-represented against the driver's share across the previous eight releases: at least 8 reports, 2.5 times expected, and Poisson p < 0.001. 50 spikes met the bar. Only 56% of organic issues can be tied to a release, so this view sees just over half the traffic. The monitor replay runs the same test each time a report arrives, on every version and driver.

Top 12 of 50 by excess reports. Version-specific compares the driver's share among reports stating the onset release with reports stating older releases filed in the same 7 days (Fisher p < 0.05 and at least 1.5 times). A spike that rises as much on older versions is a calendar event, such as an outage or a server-side change, and routes to infrastructure or safeguards. A server-side feature that needs a new version still shows as version-specific. Signature volume counts issues textually close to the spike's reports; a dark line marks the onset release and a dashed green line the matched fix. Back to pre-onset level compares weeks 4 to 6 after onset with the 4 weeks before it.

For each spike, the pipeline proposes up to three Fixed … lines from later release notes, ranked by text similarity to the spike's report titles. A reviewer then confirms one or rejects all. Claude reviewed the 13 spikes that had candidates, confirmed 3, and rejected 10, each of which fixed a different bug on the same surface. The rest had no candidate.

Confirmed fixes beside the null baseline

Did the spike clear?

Each spike's signature is compared with its own level in the 4 weeks before onset. Back to baseline means the average of weeks 4 to 6 after onset sits within 25% of the distance from baseline to peak. Events group spikes on the same side that began within two days of each other, so one launch that spiked four drivers counts once.

Client spikes that returned to baseline took a median of 1 week and at most 2. Changes to safeguards, routing, and capacity likely ship server-side, so release notes rarely confirm fixes for model-side drivers, and their launch waves took months to clear. For those drivers the loop needs a different confirmation signal, such as classifier and routing changes joined to report volume.

The stale bot closes most of this tracker. Among issues at least 90 days old, excluding duplicates and automated filers, 76% of client and app issues closed without a fix. Model-side issues reached 88%, and disputed safeguard blocks 94%. Safeguard-block closes come from the stale bot (70%) and from requests for information that timed out (21%). 6% were completed.

Deflection metrics fail the same way. A queue can post a high closure rate and a short time to close while its inflow grows, because the closes measure automation. Disputed safeguard blocks rose 133% from the first eight weeks to the last eight (five of the first eight came before the Claude Fable 5 launch) and still close without a fix more than nine times in ten. This loop measures recurrence for that reason: whether reports with the same signature keep arriving.

33,168 organic issues closed in the window: 69% as not planned, 18% as duplicates, and 13% as completed. 17,598 carry the stale label. The tracker has no autoclose label.

• Three intake paths appeared the week of September 20. The GitHub-integration form, the in-app report, and agent-filed reports made up 15% of organic holdout issues (1,061 of 7,171), plus 117 from the self-reporting agent. They move driver volume without the product changing.
• Near-empty form reports moved to the catch-all. 321 GitHub-integration form reports answered both questions in under 30 characters combined. They cluster on template text, so v0 counted them in the GitHub integration driver. Of that driver's remaining issues (about 1,300), 50% came through the form, which makes it mostly an intake bucket.
• Model-behavior reports. Reports filed with the [MODEL] template ran 71 to 97 a month from May through September, then 219 from October 1 to 24. 117 of October's came from one user's agent.
• Reporters. 36,154 accounts filed the organic issues, and 87% of them filed exactly one. 89 accounts filed more than 10 each, together 6.3% of organic issues. The heaviest filed 559, almost all through the documentation template. The driver table shows reporters beside issues so a heavy filer stands out.
• Labels. 27% of organic issues carry no area:* label. area:model covers 5,974 organic issues, and it takes 11 text drivers to cover 80% of them: 19% instruction-following and overclaiming complaints, 14% unwanted model fallback or downgrade, 11% disputed cyber safeguard blocks, 9% disputed safety-filter blocks (bio, general). Judging from issue content, that label likely spans at least three teams: safeguards, model behavior, and model routing in the client.
• Empty reports. 464 issues are empty reports whose generated title says the title generator had nothing to summarize, almost all from /bug. Each one hides the reason for the case.

The predictor and the judge are separate scripts. The v0 prediction and outcome rules were committed before the final data run (commit 6955ae7). The v0 predictions were written from training data only, hashed, and committed (467cfc6) before the judge ran. That pre-registered result stands: momentum caught 3 of 9 growers with 3 false alarms, at 52% accuracy against 61% for assuming nothing changes, with a rank correlation of +0.23.

This version applies the same rules to organic issues. The holdout had been seen by then, so the organic run is a sensitivity check. A single four-week fold is also one draw, so a backtest replays the rule from ten weekly start points. The cluster model is in-sample for the earlier start points, which should favor the rule.

• Rule A, momentum: call GROW when a driver's share of organic issues in the last 4 weeks is at least 1.25 times its share in the 8 weeks before, with at least 20 reports. Call SHRINK at 0.80 times or less.
• Rule B, fresh regression: call GROW when a release-linked spike began in the last 2 weeks.
• Outcome: GREW when the driver's share over the next 4 weeks is at least 1.25 times its share in the last 4 and the count rose by 10 or more.

Ten-start-point backtest

Organic holdout, September 27 to October 24

Rows: every driver called GROW or that grew. The full table for all 46 judged drivers is in report/snapshot/judge_organic.json.

• Disputed cyber blocks. On organic counts, momentum was 0.86, so the rule called the driver flat, and its share grew 1.40 times. In v0 the automated bursts pushed the call to shrink, and the driver scored flat at 0.90.
• Hits. GitHub integration, desktop sidebar, and voice dictation. GitHub integration's growth coincides with the new integration form.
• False alarms. Desktop app general, Remote Control, and high token consumption.
• Missed growers. Disputed auto-mode blocks, which sat below the 20-report floor, plus auto mode and plan mode, permission rules, hooks, disputed cyber blocks, and two drivers called SHRINK: terminal rendering and AskUserQuestion.
• Rule B made no calls. No organic spike began in the last two training weeks.
• Novelty was modest. 12% of holdout issues fell below the training set's 10th-percentile similarity to a centroid, against 10% expected.

At a four-week horizon, trend is a weak forecast of which drivers will grow, and the release monitor does not forecast growth either. Use the monitor for speed and routing, and judge it on time to alarm and precision. Use forecasting for staffing, and score it this way every month.

• Calendar alarm first, release attribution second. Run a Poisson CUSUM on reporter-deduplicated daily counts per driver to answer whether something is happening, then the version-specific test to answer which release and whose team. In the surveillance review, CUSUM flagged most release spikes and also caught calendar events the release test cannot see, such as the new intake form. That comparison has not been rerun here.
• Overdispersed baselines. Reviewers measured driver counts at about 1.5 times Poisson variance, so the release test is anti-conservative. Negative-binomial or quasi-Poisson baselines should cut false alarms.
• Blast radius at alarm time. Estimate the excess share of a version's reporters, (observed minus expected) divided by reports on that version, when the alarm fires. Absolute user counts need adoption telemetry.
• A weekly operating view. Last week against the 4-week baseline for every driver, with open backlog, inferred owner, and one recommended next action.

• GitHub issues are not support cases. The public tracker is a technical, self-selected slice. Billing, account, and most consumer problems go to other channels. Reporter counts come from salted hashes of GitHub logins, so one person with two accounts counts twice, and there is no usage denominator for cases per user.
• Automated filers were found by template. Two tools are fingerprinted from their report templates and confirmed against reporter hashes. Other bulk filers may remain. 9 other accounts filed 20 or more issues on a single day; their 1,366 issues stay in the organic counts, 15% of them in the catch-alls. The reporters column in the driver table shows where one account carries a driver.
• Duplicates count as recurrence, by design. 19% of organic issues are duplicate-flagged. For a support loop that is signal, and it means volume and unique bugs are different numbers.
• Disputed blocks are the reporters' view. The safeguard drivers count reports that a block was mistaken. They do not establish that a classifier erred. The v2.1.170 release notes describe Fable 5 as "made safe for general use", so some blocking is by design.
• Release attribution is correlation, and it needs a stated version. A spike is tied to the release where its reports began, which does not show the release caused it. Only 56% of organic issues can be tied to a release. Server-side changes do not ship as CLI versions, so a spike that coincides with one is attributed to whichever release was current.
• Clustering is simple and partly unstable. TF-IDF, LSA, and k-means with k = 60, English-centric. Reseeding keeps 77% to 83% of issues in the same driver. 6 drivers dissolve under reseeding and are marked provisional: AskUserQuestion prompts, disputed auto-mode safety blocks, MCP OAuth flows, settings and config not honored, themes and colors, thinking-block API errors (2,711 issues). The safeguard family holds together better than its internal split. In a 60-issue spot check, two Claude passes found 46 and 41 assignments that fit. The stricter pass, blind to the first and reading each issue body, placed 4 of the 6 sampled cyber-block issues elsewhere, 3 of them in neighboring safeguard drivers. That is a small sample, but it matches the reseeding result, so treat the cyber counts as approximate within the safeguard family. No human has graded the sample; report/spotcheck.csv has a column for one.
• Some spikes will be noise. With driver labels shuffled, the monitor replay still fires about 30 times, so treat the 8-to-10-report spikes as leads.
• Before-and-after cannot separate a fix from a burst ending. Update lag, dedupe bots, and attention shifts also move volume.
• Predictor and judge share an author. Claude wrote both. The v0 rules were committed before the final data run, though partial holdout data was visible while debugging. The split into model-side and client drivers was defined after the v0 results existed.

Data. Issues created May 3 to October 24, 2026, pulled with the GitHub REST API into SQLite: title, a 4,000-character body excerpt, labels, dates, close reason, stated version, and the bug template's regression fields. Pull requests are excluded. The fetch ended at 03:17 UTC on October 26. A second pass stored each issue's reporter as an HMAC of the login under a random salt that stays on the local machine. Logins and hashes are never published. Releases and their notes come from the repository's GitHub releases (154 in the window).

Intake. Each issue gets an intake channel from template fingerprints. The automated channel covers two tools, both confirmed against reporter hashes: a safeguard-block filer (1,509 issues from 5 accounts, 99.7% from one) and one user's agent reporting its own process violations (117 issues from one account). Automated issues are left out of every driver statistic and shown separately.

Drivers. Template boilerplate is stripped (environment blocks, checklists, auto-attached error logs, and lines repeated across many issues). Titles are weighted three to one against bodies. The model is fit on the training window only, and holdout issues are assigned to the nearest training centroid. Claude read a training-only review of each cluster's top terms and nearest issues, then named and merged 60 clusters into 49 drivers plus 3 catch-alls (drivers.json). Cluster ids are pinned to anchor issues in cluster_anchors.json, and a refit with the versions in requirements.txt reproduces every assignment.

Null baselines. Confirmed fixes are compared with unfixed spikes measured the same way. The monitor replay is compared with shuffled driver labels. Subsidence is measured against each spike's own pre-onset level and counted by event. The forecast is compared with "nothing changes" from ten start points. Every threshold is a named constant in scan/, and the fix verdicts are in fix_review.json.

Review. Four fresh-context Claude reviewers each examined v0 with one field's methods: applied statistics, support-operations analytics, outbreak surveillance, and a red team for accuracy and publication risk. Three of the four independently found the automated filer. They also found that fixed and unfixed spikes decline alike, that subsidence needed each spike's own pre-onset baseline, that the single holdout fold flattered the forecast, that several drivers do not survive reseeding, and that the tracker has no autoclose label. This version recomputes those checks in the pipeline and changes the headline. In v0 the safeguard family was the largest at 4,075 issues (8.4%), there were 52 spikes, and 31 of 32 client spikes against 2 of 13 model-side spikes had subsided by a peak-based rule. The 60-issue spot check has two Claude passes and no human grades (see Limitations).

Check the numbers. report/snapshot/ holds driver-by-week counts, driver statistics, spikes, the judge and backtest outputs, and stability results, with no titles, bodies, or reporter hashes.