# Half of a Stanford paper repo's 946 stars look bought · GitHub open-source projects

> Source: https://stringers.io/en/github/gh_nuglifeleoji__Sentry.html (Stringers / 什么值得做, generated 2026-11-08)
> Stringers answers one question every day: what small product can one or two people build in a few months and actually make money from. Numbers come from 15 databases we collect daily, each with source and date.
> For agents: these verdicts and the underlying databases (verified revenue, App Store / Google Play charts, ad libraries, GitHub, Product Hunt…) are queryable live over MCP — tools today / hot / products / directions / direction / data. Setup: https://github.com/komako-workshop/stringers (the user logs in at stringers.io → "配置 agent" to get a personal URL). Site index: https://stringers.io/llms.txt

> Stars are mainly inflated: the fork accounts are new accounts registered in batches in late October. Stars and forks spiked together in 10-19 to 10-22 and again in 11-03, with a batch cleared by GitHub in between. Real interest amounts to the academic attention on one Stanford ACE team paper.

[GitHub open-source project](https://stringers.io/en/github/index.md) · written 11-6

nuglifeleoji/Sentry · nuglifeleoji

# Half of a Stanford paper repo's 946 stars look bought

**What it is** An external failure-management layer for LLM agents. When it detects an agent stuck in a loop, drifting off course, or outputting malformed results, it pulls a few matching lessons from an external playbook to have the agent correct itself. It only saves a lesson once the fix is confirmed to work.

**Why it blew up** Most of the stars are fake. The fork accounts were registered in batches in late October, and stars and forks spiked twice, at 10-19–10-22 and 11-03. GitHub then cleared a batch of them. The real interest is just the attention one Stanford paper got in academic circles, from the ACE team.

**D** **How to follow it:** Stop building another paper repo. If you build, make a hook or plugin for Claude Code / Codex that only surfaces lessons when something breaks and saves them once they're fixed, plus a screen recording that shows the setup stuck before and the workaround after.

Grade D: most of its heat was bought. The small real part rests on the Stanford lab and the ACE authors' names, which followers can't borrow. The same niche already has Reflexion, ACE and other thousand-star projects. The idea is worth understanding, but I wouldn't copy it. Few people know about it yet

Data (updated daily) · Repo created 2026-10-02 · 1,048 stars · 7 days +458

GitHub · stars

Data 2026-10-09 → 2026-11-08 (31 days, 31 observations). Points before 10-28 come from deeply / archive backfill, not every day has one

Sentry is the companion code for a real Stanford paper. It attaches a "failure management layer" to LLM agents: when it detects an agent stuck or drifting, it passes only the matching lessons to the agent, and it records a lesson only after the fix works. The paper is real, and its authors include ACE's authors and Stanford professor Kunle Olukotun. But on GitHub it reached nearly a thousand stars in a month, and mostly not because people read the paper. Below: what it is, where the stars came from, how much real interest there is, and what someone building a similar project can take from it.

### Nov 5 morning: 10 forks

Nov 2026, 5 UTC, from about 5 to past 6 a.m., the Sentry repo picked up a run of forks in just over an hour. Newest first: chloewilson22 at 06:18:38, then taohanefw at 06:18:37, one second apart. Going back: gardenderekavk, adamcoopermrf and jiang-guangkga (the last two also one second apart), carl-pricevwj, yang-leijf, adam-wilsonwje, devclarachan, and hanjunnfr. The last two landed in the same second (GitHub fork list, 11-06).

The names all follow the same pattern: an English name or pinyin, followed by three or four random letters. Looking back to the 100th fork, they were all created in the three days from 11-03 to 11-05. I checked 15 of these accounts: all were registered between Oct 20 and 22, each has four or five repos and 0 followers, and each has starred only one repo ever. These are accounts farmed in bulk by a star-and-fork service, not people reading papers.

### What it actually is

In one line: while the agent runs a task, keep a "duty officer" beside it.

Every 5 steps, Sentry checks whether the agent has gone wrong. If the format is off (bad tool-call arguments, illegal action), it tells the agent to retry in the right format. If the agent is stuck in a loop, drifting off task, or reasoning from nothing, it pulls 5 matching lessons from an external playbook, keyed to fine-grained failure labels, and passes them over. It then watches 10 more steps to confirm the agent actually recovered, and only then writes the lesson back to the playbook. The whole playbook never enters the agent's context.

The paper's core claim (arXiv 2610.02994,10-02) is that failure lessons are "conditional knowledge" and shouldn't sit permanently in context. Methods like ACE and Reflexion keep lessons in the prompt all the time, which can mislead the agent when the error isn't occurring. The paper reports results on WebShop, AppWorld, SWE-bench Lite and Mind2Web: an average 37% above the strongest runtime-intervention methods, and 39% above ACE-style methods. Token usage is 1.54 times the original agent's. It recovered 81.7% of the 939 failures it detected (from the README and arXiv abstract; no one has reproduced it).

Integration is light too: after each step, pass that step to `runner.step()`. If it returns a repair hint, insert it into the agent's messages. The agent itself doesn't need changes.

The author, Leo Ji (Changxiu Ji), is a Stanford math and CS student in Olukotun's PPL lab. Co-author Qizheng Zhang is an author of ACE (ace-agent/ace, about 1,430 stars). You can think of Sentry as follow-up work from the ACE team.

### Star curve: two spikes, one rollback

| Date | star | fork | What happened |
|---|---|---|---|
| 10-17 | 244 | 4 |  |
| 10-19 | 311 | 34 | Forks suddenly start climbing |
| 10-22 | 474 | 76 |  |
| **10-23** | **349** | **5** | Down 125 stars and 71 forks in one day |
| 10-31 | 532 | 4 |  |
| 11-02 | 607 | 6 |  |
| **11-03** | **703** | **67** | +96 stars in one day, forks up 61 in a day |
| 11-06 | 828 | 103 | GitHub's live page shows 946 |

(GitHub star and fork counts, recorded daily)

Real users' stars don't vanish overnight, and forks don't drop from 76 back to 5. The Oct 23 rollback most likely means GitHub purged a batch of fake accounts (an inference, but a confident one). Then star and fork counts both spiked again in Nov 3, which lines up with the batch of accounts registered in late October starting to do their work.

The days without the spike show the real baseline: from 10-24 to 11-02, stars grew 15–30 a day, while forks stayed at 4–6. At that rate, its real star count is probably between 400 and 500 (estimate; I can't verify directly because the list of people who starred it isn't accessible).

The author's other repos look the same: the student-style Options-Analytics-Agent at 646 stars / 85 forks, Factor-Research at 422 / 62, Job-Recommendation-System at 234 / 36, all long unmaintained, and the fork lists include random names like miliwe3vision. Whether the author bought these or a boosting service picked trending new repos to warm up its accounts, outsiders can't tell. Since several repos show the same pattern, the former is more likely (inference).

### How many people actually know about it

Very few. The paper was posted to Hacker News on Oct 6 and got 1 points, with no comments. On X, searches for "Sentry agent failures," the arXiv ID, and the author's handle turned up nothing in the last 40 days. The only hits were one personal LinkedIn post and auto-indexed paper pages on alphaXiv, ResearchGate and Moonlight. There is also an OpenReview submission on the same topic, "Sentry: A Self-evolving Failure Manager for Agentic LLM Systems," but I couldn't find its review status.

The repo's last commit, "Release Sentry," was pushed on Oct 11. It has 5 commits in total, has not been updated since, and has 0 issues. A project with nearly a thousand stars and not one issue filed by a real user says a lot by itself.

There's also a naming problem: "Sentry" collides with sentry.io, the error-monitoring company. Searching "Sentry agent" mostly returns sentry.io's AI monitoring features, so people actually looking for this project have a hard time finding it.

### Who else is doing the same thing

| Project | What the others do | star(11-06) |
|---|---|---|
| Reflexion | Self-reflect after the task, try again next time | 3,403 |
| ace-agent/ace | Lessons go into an evolving playbook that stays in context; same team | 1,434 |
| Agent Workflow Memory | Records successful workflows, ignores failures | 482 |
| ag2ai/Agents_Failure_Attribution | Failure-attribution benchmark | 396 |
| Dynamic Cheatsheet | Cumulative cheatsheet kept in context at test time | 279 |
| ExpeL | Distills insights from successful and failed trajectories into the prompt | 251 |
| AgentDebug | Post-hoc failure attribution, no runtime repair | 108 |
| AgentOps / Langfuse / sentry.io | Only observes and alerts; doesn't fix or learn | Thousands of stars / commercial product |

On the paper level, its position is clear: between ACE/Reflexion, which keep lessons in context, and fixed-rule runtime monitoring. But these projects are all paper code. A form developers would actually use day to day, such as a plugin installed directly into Claude Code or Codex, nobody has built yet.

### If it were you

**Verdict** : Most of Sentry's near-thousand stars were bought. The real interest is a Stanford paper's few dozen stars a day in a small academic circle, and that came from the ACE team's and Stanford's names, which you can't borrow. Making another "agent failure recovery" paper repo isn't worth it.

**Who it's for** : developers building coding-agent tools who are tired of agents getting stuck in loops and tool errors. The thing worth taking is the paper's idea: give the agent failure lessons only when the matching failure appears, and record them only after a fix works.

**Who it's not for** : people hoping to collect stars through "paper reproduction + a pretty README." The niche already has Reflexion, ACE and other thousand-star projects. Without a paper or lab backing, it won't take off.

**How to do it** : if you do build it, the only interesting direction is the part it doesn't cover: package the idea as a hook or plugin for Claude Code / Codex. When the same tool errors repeatedly or the same command runs three times in a row, pull two or three matching hints from a local lesson file and inject them. Afterward, check whether the problem was resolved before deciding whether to save the lesson. Include a recording showing the setup failing before install and the user working around it after (inference: this form is more likely to get bookmarked by developers than paper code).

**How to get users** : Claude Code and Codex plugin and skill collection repos, and the developer circles on X building agent tools. Put a screen recording and a one-line install command in the first screen of the README. Don't buy stars: this repo had 125 fake accounts wiped in one day in Oct 23, and when fake accounts get cleared, the star curve shows it for everyone to see.

**When to move** : Claude Code and Codex are both adding features that learn automatically from failures, so the window for the hook approach is probably only a few months (estimate).

**What would show I'm wrong** : (1) the paper gets into a conference, or a well-known account shares it and drives growth from real users rather than fork-spam, which would mean academic interest here is bigger than estimated; (2) someone builds it as a coding-agent plugin and quickly gets hundreds of real stars, meaning failure-triggered lessons are something developers really want and worth getting in early on; (3) Claude Code or Codex ships the same mechanism officially, which makes an external layer unnecessary.

[GitHub repo ↗](https://github.com/nuglifeleoji/Sentry)

**Research notes: competitor table, acquisition evidence, full research report**

Competitors

| Name | Where | Launched | Scale | How it differs from this one |
|---|---|---|---|---|
| ACE (ace-agent/ace) | Open source | 2025-11 | 1434 stars | Evolving playbook that keeps lessons in context; Sentry only surfaces lessons when a failure is detected; same team, can be combined |
| Reflexion | Open source | 2023-03 | 3403 stars | Self-reflection after tasks, learning across trials; Sentry repairs and verifies in real time during the task |
| ExpeL | Open source | 2023-12 | 251 stars | Distills insights from trajectories into the prompt, with no failure-triggered injection or recovery verification |
| Dynamic Cheatsheet | Open source | 2025-04 | 279 stars | Cumulative cheatsheet kept in context at test time |
| Agent Workflow Memory | Open source | 2024-08 | 482 stars | Records successful workflows, not targeted at failures |
| AgentDebug / Agents_Failure_Attribution | Open source | 2025 | 108 / 396 stars | Post-hoc failure attribution and evaluation, no runtime recovery |
| AgentOps / Langfuse / sentry.io AI Observability | Other | From ¥2023 | Thousands of stars / commercial product | Only observes and alerts; no automatic repair or learning |

Where users come from

- **Verified** **star/fork farming** : the latest 100 forks were all created between 11-03 and 11-05. A spot check of 15 accounts shows they were all registered between 10-20 and 10-22,0, with 4–5 followers and repos, and only 1 stars given. After 10-23 stars were removed, the count dropped by 125 and forks by 71 on the next check. The author's other student projects sit at 234–646 stars and have stalled.

- **Verified** **arXiv paper + Stanford team backing** : arXiv 2610.02994, authors include Qizheng Zhang (ACE) and Kunle Olukotun; indexed on alphaXiv, Moonlight, ResearchGate.

- **Verified** **HN** : submitted 2026-10-06, 1 points.

- Inferred **X / big-account shares** : x-radar shows 40 posts in the last 0 days.

## nuglifeleoji/Sentry: why it ran

**In one line** : Sentry is open-source code for a Stanford arXiv paper (2610.02994). It is a "failure management layer" for LLM agent runtimes: it detects failures, guides repairs, and after a fix is verified, stores the lesson in an external playbook. The paper is real, but a large share of its 946 GitHub stars were bought. Nearly all the fork accounts I could check are bulk-registered bot accounts, and the drop in stars and forks at 10-23 was GitHub clearing a batch of fake accounts. In our data it "ran" mainly because of bought traffic, not real spread.

### 1. Basics

- Repo: github.com/nuglifeleoji/Sentry, created 2026-10-02, MIT license. Through 10-11 it had 5 commits in total (the last is "Release Sentry") and no pushes since (GitHub API, 2026-11-06).

- Author: Leo Ji (Changxiu Ji), bio reads "Math & CS @ Stanford @stanford-ppl", with 124 followers.

- Paper: *Sentry: Learning to Recover from LLM Agent Failures at Test Time*, by Changxiu Ji, Amy Lu, Qizheng Zhang, Kunle Olukotun (citation_author fields on the arXiv page), v1 submitted 2026-10-02. Qizheng Zhang is an author of ACE (Agentic Context Engineering, ace-agent/ace, 1434 stars); Olukotun is a professor at Stanford PPL. This can be seen as a follow-up to ACE's team.

- Method: every 5 recent steps it checks whether a failure has occurred. Format errors trigger a hard repair, which makes the agent retry in the right format. Stuck loops, drift, and unsupported reasoning trigger a soft repair, which pulls k=5 experiences matched by fine-grained failure labels. Then it observes 10 more steps, and only if recovery is confirmed does it write the experience into the playbook. The whole playbook never goes into the agent's context. The paper claims: 37% higher average than the strongest runtime-intervention baseline, 39% higher than context-evolution baselines (ACE-style), token usage 1.54× the base agent, and recovery in 81.7% of the 939 detected failures (README, arXiv abstract, Moonlight review).

### 2. Star curve and inflation evidence

Data card / repo_day library:

| Date | stars | forks |
|---|---|---|
| 10-17 | 244 | 4 |
| 10-19 | 311 | 34 |
| 10-22 | 474 | 76 |
| **10-23** | **349** | **5** |
| 10-31 | 532 | 4 |
| 11-02 | 607 | 6 |
| **11-03** | **703** | **67** |
| 11-06 | 828 (GitHub live 946) | 103 |

- **The fork accounts are all alt accounts** : pulled the latest 100 forks via the GitHub API. All were created within 11-03 to 11-05, three days in total. The account names follow a "English first name + 3–4 random letters" pattern (chloewilson22, taohanefw, gardenderekavk, adamcoopermrf, jiang-guangkga, carl-pricevwj…). In a sample of 15, all registration dates fall between 2026-10-20 and 10-22, each has 4–5 repos, 0 followers, and has starred only 1 repo(s). This is a typical star/fork-farming service account pattern.

- **10-23 rollback** : in one day, stars went 474→349 (down 125), forks 76→5 (down 71). Consistent with GitHub clearing out a batch of fake accounts. 11-03 forks then jumped from 6 to 67 in one go, and stars gained 96 in a single day (the highest single-day gain on the data card), suggesting another batch came in.

- **Organic baseline** : outside the inflation windows (10-24 to 11-02), stars grew roughly 15–30 per day and forks stayed at 4–6. Real reader scale is likely in this range.

- **The author's other repos show the same signs** : the student project Options-Analytics-Agent has 646 stars / 85 forks, Factor-Research has 422 / 62, Job-Recommendation-System has 234 / 36, and all have now stalled (github.repo_profile). Many names in the fork list also look randomly generated (miliwe3vision, bnz2299Holzsch, etc.). Star counts this high for a job-search portfolio project are abnormal on their own; I haven't verified each one individually.

- The suspect column in the library is empty: its rules (zero forks, batch-identical descriptions, etc.) can't catch this kind of joint star-and-fork inflation.

### 3. Real exposure

- HN: 2026-10-06 submission(s) of the paper link, 1 points (HN Algolia).

- X: x-radar searched "Sentry agent failures", "2610.02994", "nuglifeleoji", and "Sentry playbook" over the past ~40 days, with 0 results total. No major-account reposts found.

- Elsewhere: a LinkedIn personal post (Harshit Mishra, about 2 weeks ago), a ResearchGate listing, an AI literature review on Moonlight, and an alphaXiv page. There is also an OpenReview submission on the same topic, *Sentry: A Self-evolving Failure Manager for Agentic LLM Systems* (id QT7ROtt9Lh; the page requires a CAPTCHA, so I didn't read it). All of this is at the level of automatic paper aggregation.

- Conclusion: it's known only within a small academic circle and hasn't broken out.

### 4. Competitors

| Name | Form | Launched | Scale | How it differs from Sentry |
|---|---|---|---|---|
| ACE(ace-agent/ace) | Open source / paper | 2025-11 | 1434 stars | Writes experiences into an evolving context playbook that stays in context all the time. Sentry argues this causes false triggers, so it only surfaces experiences when a failure is detected. The two come from the same team and can be combined. |
| Reflexion | Open source / paper | 2023-03 | 3403 stars | Self-reflects in natural language after a task ends and learns across trials. Sentry repairs in real time during the task. |
| ExpeL | Open source / paper | 2023-12 | 251 stars | Distills insights from successful and failed trajectories and puts them into the prompt. No failure-triggered retrieval or recovery verification. |
| Dynamic Cheatsheet | Open source / paper | 2025-04 | 279 stars | Accumulates a cheatsheet at test time, also always in context. |
| Agent Workflow Memory | Open source / paper | 2024-08 | 482 stars | Records successful workflows, not aimed at failures. |
| AgentDebug(ulab-uiuc) | Open source / paper | 2025-09 | 108 stars | Does post-hoc failure attribution and debugging, not runtime recovery. |
| ag2ai/Agents_Failure_Attribution | Open-source benchmark | 2025-04 | 396 stars | Failure-attribution benchmark |
| GEPA | Open source | 2025-08 | 7311 stars | Offline prompt optimization, not a runtime mechanism. |
| AgentOps / Langfuse / sentry.io AI Observability | Commercial / open source | From ¥2023 | Thousands of stars / commercial product | Observes and alerts only, with no automatic repair or learning. The name collides with sentry.io. |
| neosigmaai/auto-harness, Tracely-ai | Open source | 2026 | 500–1000 stars | Mines failures offline and does regression testing. Tracely also had a -168 star reversal. |

(Star counts from GitHub GraphQL / github library, 2026-11-06)

### 5. Differentiation

The paper's differentiation is clear: "failure knowledge is conditional knowledge, surfaced only when its condition is met," plus "store only verified recoveries." That sits between always-in-context methods like ACE/Reflexion and fixed-rule runtime monitors. Integration is also light: it's an add-on layer beside the agent loop, with no agent changes needed. But this differentiation is not why it's gaining stars on GitHub. Real exposure is nearly nonexistent, and the star growth timing lines up with the registration dates of the fork alt accounts.

### 6. Takeaways

- The paper's idea (retrieve on failure triggers, store only verified recoveries) is useful for people building agent harnesses. It could be turned directly into a Claude Code / Codex hook: when a loop or consecutive tool errors are detected, inject a few matching experiences.

- On product selection: for a newly created academic repo, stars and forks rising together, fork accounts created in batches, and a large drop midway point strongly to inflation. The suspect column alone isn't enough; you need to check the fork accounts yourself.

### 7. Uncertain

- Stargazer details can't be pulled with our token (REST returns 404, GraphQL totalCount=0; the control repo pallets/click behaves the same, so it's a permissions issue). So the share of inflated stars wasn't measured directly and can only be inferred indirectly from fork accounts and reversals. Estimating from about 20 stars/day in non-inflation periods, the real star count is roughly 400–500 (unverified).

- Whether the author bought the inflation or an inflation service picked a trending new repo to "age" its accounts can't be determined. However, the author's other repos also show high stars with low activity, so the former seems more likely.

- The paper's results haven't been reproduced, and I didn't read the OpenReview review status.

This article was written by AI from public data and the data we collect daily. Numbers are sourced, and inferences are labeled.