# How much will this project cost me in tokens, before I start?
You cannot estimate a whole project up front, but you can absolutely estimate a single task. Find the task that will repeat most often in the project, run it once in the smallest version that still produces a real result, and multiply by the number of times it will run in a week. The model's price list is not an estimate, it is a price per unit, and your estimate is decided by the number of units.
As the person who signs off on work plans here before they run, there are three things I want to see before I approve a plan:
- The task worth measuring is the boring one. Most people measure the impressive task, the one that runs once at the start and then sleeps through the rest of the project. What eats the budget is the small loop that keeps coming back: read, check, update, report. Write down what you actually ask for over an ordinary week, and look for the line that shows up again and again.
- An estimate with one number in it is almost always the wrong number. Almost every plan that has crossed my desk had two repeating tasks rather than one, and one of them was always far cheaper than the other. Measure them separately, because an average across the two hides exactly the item that was most worth trimming.
- One line in the estimate moves on its own, and you want to know which. A task that reads the same three files will consume the same amount two months from now. A task that loads a file which grows over time will consume more every month without you touching it, and that is the only line in your estimate with a slope. (Mark it with a star today, because it is the one that will surprise you in six months.)
Above all, measure the work itself, not only the plan. We priced a video job of our own here off a number we took from a source that looked authoritative, and the live check came back 2.3 times higher, because that number described a different generation of the same model. The check itself took seconds and cost nothing, and it was the only thing in the whole process that returned a real number.
The answer going around the community is that there is no way to know, you just build and measure, and that is about half right. You do measure. You simply do not need to build a whole project to know what it will cost, one run of the loop that will repeat a thousand times is enough.
A prompt, on the house
Before I start this project I want a real cost estimate, not a guess.
1. Go through the plan and tell me which tasks will repeat the most
times. If there are two, treat each one separately.
2. Run each of them once, in the smallest version that still
produces a real result.
3. Report back in one line per task: how many files you read, and how
many tokens the task actually consumed.
4. Ask me how many times a week each one will run, and multiply.
5. If one of them loads a file that grows over time, tell me which.
That is the line that gets more expensive on its own, even if I
change nothing.
Do not give me an estimate before you have run step 2.In a month, pull this estimate back out and compare it to what actually happened. What will teach you to price the next project is the gap between the two, not the price list.
