The Minecraft anvil is a tree-cost optimization problem in disguise

I fell down this rabbit hole because of a small, annoying moment in a survival game.

I had a diamond pickaxe I liked, four enchanted books I wanted on it, and an anvil. I combined them in whatever order felt natural — book, book, book, book — and somewhere around the third combine the anvil flashed "Too Expensive!" and refused to continue. Same items, same tool, and yet the order I'd picked had walked me straight into a wall.

If you've played Minecraft you've probably hit this. What I didn't expect was that untangling why it happens turns out to be a genuinely nice little computer-science exercise. The anvil isn't a flat price list. It's a cost function over a binary tree, and the "right answer" is a small optimization problem. This post is about that structure — and why it's the kind of thing worth building a tool around rather than solving in your head each time.

A caveat before I start: Minecraft is a trademark of Mojang/Microsoft, and I'm writing as a player, not on behalf of anyone. Exact anvil numbers also shift between game versions and editions, so treat the specific figures below as illustrative of the shape of the problem rather than a spec to memorize.

Two rules that quietly interact

Most of the anvil's behavior comes from two rules that are simple on their own and awkward together.

Rule 1: enchantments have a cost. When you merge an enchanted book into an item, each enchantment adds some number of levels to the operation, roughly scaled by how "expensive" that enchantment is. Fine. Predictable. You could tally it on paper.

Rule 2: there's a prior-work penalty. Every time an item passes through an anvil, it carries a growing tax on the next time it's used. In many versions that penalty roughly doubles with each use — think of it as 2^n - 1 extra levels, where n is how many times that item has already been anvil-ed. The first combine is cheap. The second is a bit more. By the fourth or fifth, the penalty alone can blow past the game's hard cap.

Rule 1 says "enchantments cost something." Rule 2 says "touching the item repeatedly costs something, independent of what you're adding." The trap is that the second rule punishes a strategy the first rule makes feel natural: dumping every book onto your main item one at a time.

Why order is the whole game

Here's the part that makes it interesting. Combining a set of books isn't a straight line — it's a tree. Each anvil operation takes two inputs and produces one output, and that output can be an input to a later operation. So four books plus one tool can be assembled in several different tree shapes:

• Linear ("caterpillar"): tool + book, then + book, then + book, then + book. Your tool gets anvil-ed four times, so it accumulates the full stacked prior-work penalty. This is the shape that hits "Too Expensive!" first.
• Balanced ("bracket"): combine book A + book B into one book, combine book C + book D into another, then merge those two results, then apply the result to the tool. No single item gets anvil-ed more than a couple of times, so the penalty never compounds as hard.

Same four books. Same final gear. Wildly different total level cost, purely because of the tree you chose. That's the tell that you're looking at an optimization problem and not an arithmetic one.

If it feels familiar, it should: minimizing the total cost of pairwise merges under a penalty for reuse is a cousin of classic optimal-merge and Huffman-style problems. You're deciding how to pair things up so the expensive operations sit near the leaves and the cheap accumulation stays balanced. It doesn't reduce to a single greedy rule, because the enchantment costs and the doubling penalty pull in different directions — sometimes the greedy "cheapest pair first" move sets up a worse penalty downstream.

Why I stopped doing this in my head

You can brute-force it. With a handful of books the number of distinct combine trees is small enough that a search over orderings is trivial for a computer. The problem is that it is exactly not trivial for a human standing at an anvil with limited XP, because:

1. The penalty is exponential, so mistakes are punished disproportionately — one bad early combine can make an otherwise-fine plan illegal.
2. The costs aren't all visible at once; you find out you've overspent only when the game blocks you.
3. XP is a real, non-refundable resource in survival. A wrong tree isn't just slower — it can strand a good item halfway to being finished.

That last point is why I'm careful to frame any calculator here as a planning aid, not a guarantee. It estimates a good combine order under a model of the rules; the actual game is the source of truth, and version differences are real. What a tool buys you is the search: it can enumerate the tree shapes and hand you an order that stays under the cap, so you spend your levels on the plan instead of on discovering the plan.

That's the modeling job behind a small fan-made site I've been poking at, a Minecraft anvil cost planner called MCAnvil, which takes the set of enchantments you want and works out a combine order rather than making you feel it out one expensive mistake at a time. It's independent and fan-made — the interesting part, for me, was less the UI and more that the "obvious" flat-cost model is wrong, and getting the tree cost and prior-work penalty right is what makes the output actually match what the game does.

The takeaway for builders

Two things stuck with me from this.

First, it's a clean reminder that a lot of game "mechanics" are really cost functions, and the moment a cost function has a reuse penalty and a branching structure, you've quietly crossed from look-up into search. Recognizing that boundary is most of the work — once you see the tree, the algorithm to explore it is the easy part.

Second, it's a good argument for encoding fiddly rules into a small tool instead of a wiki page. A table that says "enchantment X costs Y" is accurate and still won't stop you overspending, because the cost that hurts is emergent from order. The value of a calculator here isn't that the arithmetic is hard; it's that the interaction between two simple rules produces a result humans are bad at eyeballing.

If you play and you've ever eaten a "Too Expensive!" on a favorite item, it's worth planning the tree before you commit the levels. And if you don't play but you like modeling systems, the anvil is a surprisingly tidy example of an ordinary-looking mechanic that turns out to have a real optimization problem hiding underneath.