Estimating Cost Before a Large Refactor Run

A large refactor is exactly the kind of task where "let's just start and see what it costs" is a worse plan than it sounds — by the time you have a real cost figure from watching it run, you may already be most of the way through spending it, with no earlier checkpoint where a cheaper approach could have been chosen instead.

Why refactors are harder to estimate than ordinary tasks

A typical request has a fairly predictable shape — roughly known input, roughly known output. A large refactor's actual token consumption depends on how many files it touches, how much surrounding context each file needs to be understood correctly, and how many iterative turns it takes to get everything consistent — none of which is fully knowable until the refactor is substantially underway. That uncertainty is exactly why a rough estimate before starting is worth the effort, even knowing it won't be precise.

Building a rough estimate from a representative sample

Rather than trying to estimate the whole refactor's cost directly, running it against a small, representative slice first — one or two files, handled the same way the full refactor will handle every file — gives you a real, measured per-file cost you can multiply out. This isn't perfect, since later files in the actual refactor may need more or less context than the sample suggested, but it's a dramatically better starting point than a pure guess with no measured data behind it at all.

Accounting for the accumulated context, not just per-file cost

A refactor kept in a single long session accumulates context turn over turn, which means later files in the same session can cost more to process than the same file would in isolation, purely because of everything the session has already read and generated by that point. A cost estimate built purely from an early, low-context sample will understate the true cost of files handled later in a long session — worth padding your estimate to account for this, or better, breaking the refactor into the Codex-sized steps this site covers separately, each with a smaller, more predictable accumulated context.

Checking against the long-context repricing threshold specifically

For a refactor large enough to plausibly approach a model's long-context repricing threshold, a cost estimate needs to explicitly account for the cliff, not just linear per-token pricing — a refactor that crosses the threshold partway through will see a real jump in per-request cost from that point forward, and an estimate that doesn't model this explicitly will be wrong in a specific, predictable direction once the threshold gets crossed.

Comparing service tiers before committing to Standard by default

A large refactor that doesn't need to happen synchronously — nobody's watching it in real time, waiting on the result — is a candidate worth checking against Batch pricing before defaulting to Standard purely out of habit. The discount is real and the completion window is generous for most refactor timelines; running the same estimate against both tiers before choosing is a cheap comparison that can meaningfully change the total.

Deciding on a model before estimating, not after

Because per-token price varies substantially across this site's roster, the model choice needs to be part of the estimate from the start, not a separate decision made afterward — a rough estimate built against one model and then applied to a different model chosen later will be wrong by whatever the price difference between the two actually is. Pick the model deliberately, informed by the refactor's actual context needs, and estimate against that specific choice.

Setting a checkpoint partway through, not just an upfront estimate

Even a careful upfront estimate can turn out to be wrong once real work starts revealing complexity the sample didn't capture. Setting an explicit checkpoint — after the first quarter or third of the refactor, say — to compare actual spend so far against the original estimate, and adjusting the plan if the two have diverged meaningfully, catches a bad estimate while there's still time to change course, rather than only noticing after the whole refactor is complete and the final number is already locked in.

Why this discipline is worth the extra planning time

A large refactor already requires real planning — the structuring, the sequencing, the definition of done this site covers elsewhere. Adding a cost estimate to that planning process is a small additional step relative to everything else already being decided, and it's the step most likely to prevent an unpleasant surprise on exactly the kind of task large enough for a surprise to actually hurt.

What to do if the estimate comes back higher than expected

An estimate that lands well above what you expected before running any of the sample is genuinely useful information, not a reason to proceed unchanged out of momentum — it's worth treating as a prompt to reconsider scope, model choice, or service tier before committing to the full run, rather than something to note and push through anyway because the planning work already happened. The whole point of estimating before starting is having a real decision point while one still exists.

Recording the actual outcome for next time

Once the refactor is complete, comparing the actual final cost against the original estimate and noting how far off it was — and in which direction — builds a genuinely useful reference for the next large refactor you plan, since your own historical accuracy at estimating this specific kind of task is a better calibration tool than any generic guidance, including this page's.