Built for massive changesets
Prume wasn't built as a theoretical tool. It was born from a real-world need to untangle enormous, interleaved changes in a large open-source project.
The Origin Story
Prume was developed during the Apache Unomi 3 rewrite — multi-tenancy, sweeping API redesigns, and deep architectural changes across the entire codebase.
500+
files changed
12+
distinct concerns
1
working branch
∞
hours of git add -p
Tenant isolation, API migration, schema changes, config updates, test rewrites, documentation — all interleaved across the same files. Traditional approaches simply don't work at this scale.
We tried AI first. It wasn't enough.
Every AI-based approach failed on this codebase.
Whole-diff classification
Hit context window limits immediately on a 500+ file changeset.
Per-hunk AI classification
Prohibitively slow (5–15 minutes) and expensive ($2–4 per session).
Cross-cutting patterns
AI couldn’t recognize multi-tenancy changes spanning 40+ files.
These failures drove us to build a hybrid architecture — deterministic rules for the 90%, AI only for the edge cases.
The Prume Approach
No context window
Operates on the file system, not through a language model. 5 files or 500, it works the same.
Deterministic rules first
File path matchers, keyword rules, and regex handle the bulk of classification instantly.
Hunk-level precision
A single file can contain changes for multi-tenancy, API migration, and a bug fix. Prume splits them apart.
Conflict highlighting
When a hunk matches multiple groups, Prume flags it rather than silently guessing.
Built for iteration
Rules evolve with the project. New patterns get new rules that apply immediately.
From open-source rewrites to AI agent workflows
Today, Prume handles AI agent workflows just as well — because the problem is the same: lots of changes, multiple concerns, one working directory.
If Prume handles the Apache Unomi 3 rewrite, it can handle anything a Cursor session produces.