One way pours every record into the model — the bill grows with your data, and it stops working the moment your data won’t fit in the model’s context window. The other sends only the question; your data stays where it is, and the answer comes back computed over every record. Here is the difference, measured on real records.
| Your data | Read it all in | Write the query | Difference | Cost / question* | Fits a 200K-token model? |
|---|---|---|---|---|---|
| 1,000 | 74,079 | 483 | 153× | $0.2222 | fits |
| 100,000 | 7,365,979 | 483 | 15,250× | $22.10 | no — ~37 calls |
| 1,000,000 | 73,655,979 | 483 | 152,497× | $220.97 | no — ~369 calls |
| 100,000,000 | 7,365,555,979 | 483 | 15,249,598× | $22,096.67 | no — ~36828 calls |
Reading it all in crosses a 200K-token window at just ~2,715 records, and even a 1M-token window at ~13,575 records. Past that it can’t run as one request at all — it’s split into hundreds or thousands of calls that each see only a slice. Writing the query never moves off 483 tokens, and gets cheaper still when the same question is asked again.
Measured, answering over every record — not a retrieved handful:
*Measured on a real records dataset. Token counts use a deliberately conservative estimate — real business records tokenize denser than the estimate, so the gap in practice is larger, not smaller. Costs shown at a representative $3 per million input tokens; scale to your model’s price. The read-in time is an estimate from token volume. Every figure is reproducible.