relore - repository memory for coding agents
GPTNeoXJapanese crashes for any rotary_pct != 1.0 because
RoPE ignores partial_rotary_factor.
Within a day, a contributor had posted a correct diagnosis and a maintainer had answered, ‘a PR is very much welcome.’ Within two days, two different people had opened fixes. When Serge, our CI agent, picked up the issue, it was about to write another patch without realizing that work was already in flight.
The information was all on GitHub. The problem was that it lived in different issues, PRs, and comments, and none of it was visible from the issue Serge started with.
gh can fetch any individual issue, PR, or comment. The hard part is knowing
which ones to fetch: the fix may live in another PR, the rationale in a review
comment, and the relevant maintainer decision in a thread the current issue
never links to.
We built relore for this: index the repository’s history, keep track of who said what, and connect those discussions back to the code that exists today.
There are proposals to record decision context explicitly in git history. We started from the opposite end: projects should not have to change how they work. The knowledge already exists, trapped in years of GitHub discussions.
What relore is
Plain search turned out not to be enough. A maintainer saying “yes, do this” is different evidence from a contributor guessing at a cause, or a bot leaving an automated review.
relore (REpository LORE) records who said what, treats maintainer decisions differently from contributor claims, and excludes machine-generated content from the default evidence set. See how search works.
Repository history is only half of the picture: an agent also needs to connect those decisions to the code as it exists now. relore therefore keeps a working clone beside the history index and serves both over one HTTP API.
One run, end to end
The field report shows the core flow and the different versions of relore runs.
Serge started from issue #48630. The first question was simple: is someone already fixing this?
Today, that is what inflight answers:
$ relore inflight 48630
2 threads claim to close huggingface/transformers#48630
1. huggingface/transformers#48652 pr open (approved) 5d closes @blipbyte
> [GPTNeoXJapanese] Fix RoPE ignoring partial_rotary_factor
2. huggingface/transformers#48672 pr closed by its author 5d closes @truongsontung
> fix: respect partial_rotary_factor in GPTNeoXJapaneseRotaryEmbedding
Instead of writing a third patch, it can inspect the work already in progress.
inflight did not exist when we started this experiment. Serge originally found the open fix while searching partial_rotary_factor across repository history. The PR was not linked from the issue, so finding it was a lucky side effect of a symbol search. That failure mode deserved its own verb.
Finding the existing PR avoided duplicate work, but Serge still needed the reasoning behind the fix. For that, the agent can inspect a discussion with thread. relore keeps track of who said what, so a maintainer request, a contributor diagnosis, and an automated comment are not flattened into equivalent evidence. In this case, the maintainer's comment reframed the task. What looked like a fix for one model became a repo-wide audit of regressions introduced by the same refactor.
Serge then searched authoritative repository history for the refactor behind the regression:
$ relore search "standardize rope partial_rotary_factor refactor all models" --trust authoritative
→ #39847 🚨 [v5] Refactor RoPE for layer types
The result pointed to the same maintainer who had described the regressions in the issue. Together with the breaking-change marker, that was enough to identify the refactor that introduced the bug.
From there, Serge needed to find the same pattern elsewhere in the current codebase. At the time of the field report, this was where relore stopped: Serge cloned the repository and finished the audit with grep and a Python AST scan. That gap led to code-browsing verbs such as defs and copies, powered by tree-sitter, which indexes Python symbols so the agent can inspect program structure directly instead of reconstructing it from text search.
In one field test, the agent reported that relore defs gave it a better overview of a file than reading the whole thing, for roughly 5% of the tokens.
One question the agent explicitly wanted to ask was: why does this line exist? why makes that direct:
relore why src/.../modeling_gpt_neox_japanese.py:90
git blame tells you which commit last changed a line. relore why follows
that commit to its pull request and surfaces the review comments around that
line, often recovering the discussion behind the change.
See the full list of relore verbs.
Queries are served locally. Only ingestion contacts GitHub to keep the index fresh. See the architecture.
Conclusion
We built relore because our agents needed a better way to remember Transformers. But there is nothing Transformers-specific about the problem.
Transformers has almost a decade of reasoning scattered across issues, reviews, and pull requests. Maintainers carry a lot of that context in their heads. Serge didn’t. The goal of relore is to give an agent access to that same trail of decisions while it works on the current codebase.
relore is Apache-2.0 licensed and works with any GitHub repository you are willing to index (see how. We currently run it internally across several Hugging Face projects, including Transformers, and Serge uses it when reviewing patches or investigating issues.
Code, docs, and issues: https://github.com/huggingface/relore
