I scan my daughter’s picture books, page by page, so she can flip through them on a tablet the same way she flips through the paper ones. Turning a folder of page photos into something that reads like an actual book means two things: straightening out crooked, badly cropped scans, and getting the pages into the right order — cover first, then left-right spreads, back cover last.

I asked Claude Code to do both. It could do both. But doing both, every time, on every new book, was burning through my usage far faster than the work seemed to justify.

What Was Actually Happening

Cropping and rotating a scan is a judgment call — how much of the edge to trim, which way a page tilts, whether a smudge is part of the art or a scanner artifact. That part genuinely needs a model looking at the actual image.

Arranging the pages, once they’re clean, is not a judgment call. It’s arithmetic: page 1 is the front cover, the last page is the back cover, and everything in between pairs up left-right in order. I’d been asking the same model to do both jobs together, every single time, which meant paying for image reasoning on a step that’s really just counting.

I only noticed because my usage for one session was unusually high, and when I checked what had actually happened, it was book-page arrangement — the boring half — that had eaten most of it.

What Fixed It

I split the two jobs apart. Cropping and rotating stayed a manual step I do myself, or ask for individually when a page genuinely needs a second look. The arrangement step became a small, fixed-rule skill: given a folder of already-clean images, place image 1 as the cover, the last image as the back cover, and pair up everything between them left-right in sequence, with no image analysis at all. It runs on plain file logic — Pillow for the image handling, no model call in the loop — and treats every book the same way, because every one of these books is bound the same way.

The first version tried to be smart about it — detect spreads, guess orientation from content. The version that actually works does none of that. It just follows the rule.

Step by Step

  1. Do the judgment-call work first, separately, and finish it completely. I crop and rotate every page myself before arrangement ever runs — checking edges, straightening tilt, confirming nothing important got cut off. Arrangement never touches a page that hasn’t already passed this check.
  2. Name the files so the order is obvious before any code runs. My scans are named in plain sequence (page 1, page 2, page 3…), with the front cover first and the back cover last. If the file order is already right, the arrangement logic has nothing to guess.
  3. State the layout as a fixed rule, in plain language, before writing any code. For these books it’s: file 1 is the front cover (shown alone), the last file is the back cover (shown alone), and everything in between pairs up left-right in order — file 2 with file 3, file 4 with file 5, and so on.
  4. Write that rule as plain file-handling code — no image model in the loop. The script just counts files and pairs them by position. It never opens a file to “look” at it, which is what keeps the cost at zero: it’s arithmetic on filenames, not image reasoning.
  5. Run the same skill on every new book, unchanged. Because every one of these books is bound the same way (cover, spreads, back cover), the rule doesn’t need to change per book — only the cropped images going in do.
  6. Keep the two jobs in two separate steps, even in your own head. The moment “clean up this scan” and “put the pages in order” get asked for in the same request, you’re paying image-reasoning prices for the arithmetic half too.

💬 Prompt that worked “Build a skill that only arranges files — it does not crop, rotate, or touch the image at all. Given a folder where I’ve already fixed every page myself, treat file 1 as the front cover, the last file as the back cover, and pair up everything in between as left/right spreads in order.”

🗂 Claude.md Rule Before asking a model to do a multi-step job, check whether one of the steps is actually deterministic. If it can be stated as a fixed rule (“first item is the cover, then pair the rest in order”), write that as plain code, not a prompt — save the model for the step that genuinely needs judgment.

What it was costing me: unusually fast usage on a step that turned out to be pure arithmetic. The fix runs on file logic alone, for $0, every time.