You open the dashboard and see a counter: 10,000,000 tokens, free. Your first instinct is to paste an entire repository into a prompt and ask for a rewrite. Then you watch the counter fall by 30,000 tokens in one request, and the math becomes personal. The gap between the advertised number and the work you can actually complete is the subject of this article. I will build a simple cost model for AI coding tasks, apply it to a realistic workload, and show you how to stretch a fixed token budget with prompt design.
Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source project that currently offers ten million free tokens and a free server option for running jobs. The cost model below is generic, but I use MonkeyCode's free tier as the concrete budget because it is the offer I can verify. I am not claiming the free tier is unlimited or production-grade; the point is to help you decide whether it is enough for your experiment.
The Two Token Streams
Every AI API call has two token streams: input and output. Input is everything you send, including the system prompt, the conversation history, and the code you want analyzed. Output is the generated response. The total cost is the sum of both, and most people underestimate the input side because they only think about the final answer.
A rough heuristic is that one token equals about four characters of English text. That means a typical code file with 1,000 lines and 40 characters per line consumes roughly 10,000 input tokens. A 2,000-line file is 20,000 tokens before the model writes a single line of output. Add a system prompt and a question, and a single review request can cost 25,000 tokens.
A Realistic Workload Model
Let us define three common AI coding tasks and estimate their token consumption. These are order-of-magnitude numbers, not exact measurements, because tokenizers vary by model. Use them as planning estimates.
| Task | Input tokens | Output tokens | Total per call |
|---|---|---|---|
| Generate a SQL query from a schema | 800 | 200 | 1,000 |
| Review a 500-line pull request | 6,000 | 1,000 | 7,000 |
| Refactor a 2,000-line file | 20,000 | 4,000 | 24,000 |
With a ten million token budget, the math is sobering. You can generate roughly 10,000 SQL queries, review about 1,400 pull requests, or refactor about 400 files. The SQL number sounds generous, but the refactor number is small enough that you will hit the ceiling faster than you expect.
A Token Counting Script
The following Python script estimates the token cost of a prompt before you send it. It uses the four-character heuristic and a simple output estimate based on the number of lines you expect. This is not a substitute for a real tokenizer, but it is accurate enough for budget planning.
def estimate_tokens(text, output_chars=0):
input_tokens = len(text) / 4
output_tokens = output_chars / 4
return int(input_tokens + output_tokens)
prompt = open("prompt.txt").read()
expected_output = 2000 # characters
total = estimate_tokens(prompt, expected_output)
print(f"Estimated total tokens: {total}")
Run this on your real prompts and you will quickly see which tasks dominate your budget. The script is deliberately simple so you can adapt it to your own workload.
A Worked Example: SQL Generation
Suppose you want to generate SQL queries for a schema with 10 tables. Your prompt includes the schema DDL (2,000 characters), a question (100 characters), and a system prompt (50 characters). The input is 2,150 characters, which is about 537 tokens. If the model outputs a 200-character query, that is 50 tokens. Total per call is about 587 tokens.
With 10 million tokens, you can run about 17,000 such calls. But if you paste the entire schema every time, and the schema is 10,000 characters, the input jumps to 2,500 tokens per call, and the total drops to 4,000 calls. The difference is a 4x change in throughput, and it comes entirely from prompt design.
Stretching the Budget with Prompt Design
The cheapest token is the one you never send. Three techniques reduce input size without losing much accuracy.
First, trim the context. Instead of pasting an entire file, include only the relevant functions and a comment describing the missing parts. A 500-line file can often shrink to 100 lines without changing the task.
Second, use a compact system prompt. Write "Return only the SQL query" instead of a paragraph explaining the desired output format. Every word in the system prompt is multiplied by every call you make.
Third, batch related questions. If you need to analyze five functions, send them in one request with a numbered list instead of five separate calls. This saves the repeated system prompt and shared context.
Limitations and Who Should Skip This
The four-character heuristic is a rough approximation. Real tokenizers can produce different counts, especially for code, where punctuation and spacing vary. If you need exact numbers, use the tokenizer provided by the model vendor. Also, the free tier may have rate limits or concurrency restrictions, so your actual throughput could be lower than the token math suggests.
You should skip this cost model if your workload is tiny, because the planning effort outweighs the savings. You should also skip it if you have no visibility into your prompt sizes, because the model will not help you if you do not know your own usage. Finally, if you are evaluating a model for production, cost is only one dimension; accuracy and latency matter more.
The Verdict
Ten million tokens is a real budget, but it is not infinite. The difference between a useful free tier and a frustrating one is whether you know what a token costs in your own workflow. Run the counting script on your next prompt, and you will know exactly how far the budget goes. If you want to test the model with a concrete budget, MonkeyCode's free tier is a reasonable place to start. Try it, measure your own token consumption, and share your numbers in the comments.
MonkeyCode provides free models that can run this workflow.
Top comments (0)