Sort or tag a thousand items in a single request. Annotate, summarize or extract findings across hundreds of papers. Beaver keeps a ledger of every item, so the work is finished — and reported — item by item.
File each item into the existing subject collection matching what the paper is about.
One request covers the entire population — every unfiled item, every untagged item, a whole collection, every record missing a DOI. Beaver works through it item by item and tells you exactly where each one ended up.
A batch job is a ledger of decisions, not a to-do list. Every item ends up either changed or recorded as needing no change — and Beaver cannot tick an item off by claiming it.
Beaver names the job in one line — one operation, one set of items — and resolves the set straight from your library: everything unfiled, everything untagged, one collection, every record missing a DOI. The whole set is resolved in one step rather than a page at a time, so you see the exact count before anything runs.
A batch job is shown to you as a card with the count, the goal and an estimated credit cost. Anything destructive — tags it will remove, values it will overwrite — is stated separately from the goal, so what you stand to lose never hides inside what Beaver intends to do.
Each item is credited from the tool call that actually touched it. There is no “mark as done” step, because being done is derived from the ledger rather than claimed. A failed call credits nothing at all.
A running tally shows where items are landing — 125 into Cancer & Immunology, 119 into Neuroscience — built from the calls themselves. Beaver is warned when one destination starts to swallow the batch, while there is still work left in which to change course.
Long jobs get a budget to match, and Beaver hands itself a fixed slice of items at a time, so a job of hundreds of items does not wander. If you stop it, the job is paused rather than lost — say “continue” and it picks up the same job instead of starting a new one.
When the last item has a decision, the job closes with a durable record: how many items went where, how many needed no change and why, what could not be read. The write-up you read is composed from those numbers, and the record stays in the conversation to answer follow-up questions later.
Limits are per job, and a job is one operation. A multi-stage request — tag, then sort — is one job per stage.
Beaver is evaluated against a frozen 866-item Zotero library on the jobs researchers actually run. Each case below was run on the same model with the same budget in both arms — the only difference is whether batch jobs were available.
Counted from the library afterwards, not from what Beaver said it did. Items that received only a blanket label do not count.
| Job | Measure | 0.23 | 0.24 |
|---|---|---|---|
Sort into collections 680 unfiled items | Items filed — best of three runs | 332 | 617 |
| Items filed — worst of three runs | 0 | 600 | |
| Share landing in the largest collection | 16–27% | 20–21% | |
Tag 616 untagged items | Items given a tag that tells them apart | 0 | 615–616 |
| Distinct subject tags used | 0–1 | 9–91 | |
Annotate 11 papers in a collection | Papers annotated | 11 | 11 |
| Highlights created | 28–29 | 36–44 |
Without batch jobs the same model finds the population correctly and then settles it differently each time: one run reported the size of the job and asked how to proceed, one filed 206 items and stopped, and one gave all 616 untagged items the single tag “subject:biology”. All three are defensible answers to an open-ended request — none of them is the finished library you asked for.
Each case runs against a frozen 866-item Zotero library, reset to the same state before every run, on Beaver’s default model with the same request budget in both arms — three runs per arm, mean shown. Coverage is read back from the library afterwards, never from what the assistant said it did, and an item only counts when it received a tag or collection that actually tells it apart from the rest: a run that gives everything the same label scores zero, however many items it touched.
You never ask for a batch job. You ask for the work, and Beaver opens one when the job is big enough to need it.
“All six or seven hundred unfiled items” works better than “a few of my unfiled items”. Beaver resolves the set from your library either way, but understating the scale makes it stop early — that was measurable in our evaluations.
The goal is judged one paper at a time. “File it into the existing subject collection that matches what the paper is about” gives Beaver something it can hold a single item against; “tidy up my library” does not.
“Don't create new collections”, “reuse my existing tags”, “leave anything you can't verify and tell me”. These become part of the job and are checked against every item, rather than being forgotten twenty items in.
Tag, then sort, then write notes — three jobs, run one after the other. A single request mixing all three gives every item a blurrier target and a longer run.
The approval card carries an estimated credit cost, and approving a job raises the ceiling for it so it isn't interrupted halfway through. Big jobs genuinely cost more than one wrong call — that's what doing the work per item means.
A job you interrupted is paused, not lost. “Continue” resumes the same ledger with the same denominator — asking again from scratch starts a second job over the same items.
The final counts come from the ledger: how many items went where, how many were examined and left alone, what failed. If something is missing, that number is where it shows up.
A batch job doesn't change how Beaver touches your library. Edits are shown before they are applied and can be undone, and anything a job will remove or overwrite is declared on the approval card before it starts.