Introducing IndexLM-2.0: Doing More with More

When we introduced IndexLM-1.0, the core idea was that indexing is not just a prompting problem. The hard part of a book index is not that the model needs to know what an index looks like. Any decent frontier model can imitate the shape of an index. We believe that the hard, and most important, part is taste.

A real index requires tens of thousands of judgment calls about which concepts matter, which names deserve entries, which passing mentions should be ignored, which headings should be merged, which subentries should exist, and how all of it should be phrased and formatted so that a reader can actually use the back of the book.

IndexLM-1.0 was our first serious attempt to distill that kind of editorial judgment into a specialized model. As documented in our first paper, we found that a relatively small, domain-trained model could significantly outperform much larger frontier models at indexing selection because the task was highly specialized, domain specific, and not directly influenced, or aided, by the general intelligence of frontier models.

With IndexLM-1.0, we could take a large amount of real indexing knowledge, examples, formatting conventions, and editorial taste, and distill it into a model that was much better suited to the work than a general-purpose model two or three times its size. It was trained first and foremost to understand what belongs in an index, how professional indexes are structured, and how human indexers think about inclusion, omission, subentries, cross-references, and locators.

That made IndexLM-1.0 very good at the first version of the problem we were trying to solve: given a book, figure out what should be indexed, then create the index from that list.

From Two Stages To Three

As our customers shifted from mostly individual authors to more publishers, larger books, and as we scaled to more titles every month, we realized indexing is not really a two-stage process. It is three stages:

• First, the system has to know what to index.
• Second, it has to actually index those terms across the book.
• Third, it has to format, verify, polish, normalize, and audit the result.

IndexLM-1.0 was built mostly for the first two stages. IndexLM-2.0 is built for the third stage too, and in practice that third stage is where an enormous amount of the quality comes from.

Our internal pipeline changed a lot over the last few months. Earlier IndexerLabs pipelines already used a lot of compute. A normal high-quality job for a 500 page book could consume around 50 million tokens because we were already using multiple subagents on extraction, formatting, locator checks, candidate-term review, and cleanup.

Initially, there was a manager agent coordinating a lot of specialized subagents working in parallel, each handling a narrow part of the job. That architecture gave us much better indexes than a few free-form model calls, but it also made the token usage much higher than people would expect from the outside.

The first place this tradeoff became obvious was final formatting. One of the hardest problems was consistent entry phrasing and CMOS-style index structure.

At first, it seemed plausible that we could put a frontier model inside an editing harness, give it the full index, and ask it to keep revising until every heading and subentry followed professional style. In practice, that broke down on larger indexes. During our evaluations, once an index had more than 1,000 entries, even very strong frontier models such as GPT-5.5 or Claude Opus 4.8 could still miss roughly 10-15% of formatting issues when reviewing the whole index at once.

The index was simply too large, and the mistakes were too local. Each mistake is small on its own, but a professional index is made out of exactly these small decisions.

The only reliable solution we found was much more literal: give each entry its own focused review. Instead of asking one model to clean up the entire index in a single broad pass, IndexLM-2.0 can create a focused formatting agent for each entry, give it the relevant locator context, and ask it to make that one entry as clean as possible.

The agent can look closely at the heading, the subentries, the names, the locators, and the surrounding evidence without being distracted by the rest of the index. This is the kind of narrow, repetitive editorial work that small specialized models are already extremely good at, and it is one of the biggest reasons IndexLM-2.0 produces cleaner, more publication-ready indexes.

Smaller Agents, Narrower Jobs

Once we saw that this worked for formatting, the broader lesson became obvious. The system became more reliable whenever we stopped asking one model to solve large chunks of the index at once and instead gave smaller agents narrower, more inspectable jobs.

Formatting, locator verification, styling, cross-references, name normalization, duplicate detection, and entry cleanup all improved when we treated them as focused editorial checks rather than one giant agentic revision pass. Each agent could look at a small piece of the index, compare it against the relevant context, make a specific judgment, and return something we could audit.

That became the basic philosophy behind IndexLM-2.0: split the index into tens of thousands of smaller decisions, give each decision the context it needs, and assemble those decisions back into a cleaner final index.

The result is that our newer workflows use an order of magnitude more tokens than the earlier ones. In our first pipeline, a single indexing run of The Oxford History of the French Revolution took around 5 hours to complete, consumed around 30 million tokens, and made roughly 8,000 API calls. With our revised pipeline using IndexLM-2.0, a single pass of our Oxford History of the French Revolution demo used more than 300 million tokens, took over 12 hours to complete end to end, used over 45,000 API calls, and only cost about 20% more.

On our previous model-serving setup, a job like that could cost well over $750 while taking more than two days to complete, mainly because we were constrained by GPU capacity and token-serving throughput. Interestingly, if we ran the same workflow on GPT-5.5, it would be completely uneconomical for professional indexing. With cache hits it could still cost well over $2,500, and without cache it could go over $3,500. That is more than many professional human indexers charge for an entire book of a similar size.

The Economics Of High-Quality AI Indexing

This is the strange thing about high-quality AI indexing right now. A frontier model is powerful enough to help, but if you use it for every formatting pass, every locator check, every evidence call, every candidate-term decision, and every polishing step, the economics break very quickly.

In the future, a GPT-7-class model could easily be orders of magnitude better than today’s systems and still cost more than a professional human indexer if you use it this way. Perhaps one day, general-purpose AI systems will be agentic and persistent enough that an author can upload a finished book, let the system work for several hours, and receive a perfect index at the end. That may happen eventually.

But today, the reliable path is much more structured: break the indexing process into smaller editorial decisions, verify those decisions against the book, and assemble the final index from tens of thousands of focused checks.

We do not believe the issue is that frontier models are bad. The issue is that indexing has the shape of a massive search and verification problem. If you want to check every possible route, every possible term, every possible locator, and every possible formatting decision, you need a system that can spend a frankly ridiculous amount of compute without making the job economically impossible.

Why We Built IndexLM-2.0 On Gemma 4

That is why we built IndexLM-2.0 on Gemma 4. The lesson from IndexLM-1.0 was that indexing taste can be compressed. We had already seen that a specialized model could outperform much larger general-purpose models at the parts of indexing that matter most and fundamentally steer the shape of the rest of the index.

With IndexLM-2.0, we wanted to take that idea much further by fine-tuning a much smaller open model for the repetitive, CMOS-compliant, evidence-grounded parts of the workflow. Gemma 4 is nearly 20 times smaller than the class of model we had been using before, and an order of magnitude more compute efficient.

We have discovered that we do not need a massive general-purpose frontier model to decide whether one heading should be inverted, whether one locator is weak, or whether one subentry is parallel with another. We need a model that has indexing taste and can apply it tens of thousands of times.

IndexLM-2.0 was post-trained from the Gemma 4 base checkpoint, rather than built by prompting a general-purpose instruction-tuned model. That gave us much more control over the model’s default behavior. Instead of asking the model to infer CMOS style from prompts at runtime, we trained it directly to produce CMOS-compliant headings, subentries, and completions by default.

We also rebuilt the post-training pipeline we used for IndexLM-1.0. The original pipeline was focused mainly on indexing taste: what belongs in an index, what should be omitted, and how professional indexers think about structure.

For IndexLM-2.0, we added roughly 250 million additional tokens of formatting-focused training data, including CMOS-style completions and tool-call traces generated from both real-world examples and synthetic indexing tasks. Across this stage, we trained on roughly 500 million tokens of real and synthetic indexing data, using approximately 1,000 A100-equivalent GPU-hours.

”Tokenmaxxing” For Indexing

This is basically “tokenmaxxing” for indexing. That sounds slightly ridiculous, but it is the most accurate description of what changed.

We believe high-quality indexing is fundamentally a very hard search and verification problem. The quality comes from checking more paths, not from hoping a few model calls get everything right. A general-purpose agent with a book and a set of tools may produce something plausible, but plausibility is not the bar. The bar is whether every important topic has been considered, whether every locator is defensible, whether every heading is formatted correctly, and whether the final artifact can pass strict human review.

For customers, the immediate change is simple. All IndexerLabs tiers now use IndexLM-2.0 by default. Our pricing has not changed, but the underlying system has become much more capable. Customers should see better formatting consistency, stronger locator verification, cleaner name handling, better evidence generation, and more reliable polishing. We are also adding a model picker so customers can choose between IndexLM-1.0 and IndexLM-2.0 if they wish.

We are also adding a fourth tier at $499 for customers who want the most compute-intensive version of the system. This tier uses an early version of the architecture we are building toward IndexLM-3.0. It spends even more compute on candidate discovery, locator verification, cross-reference generation, formatting review, and final editorial checks.

Internally, our most intensive indexing runs are already averaging around half a billion tokens per book, and we are on track to sustainably scale our annual token consumption to more than a trillion tokens by this time next year.