AI Token Budgets Explained: Plan Prompts, Documents and API Costs Before Sending a Request

An AI request is rarely just one prompt. Applications add instructions, previous turns, documents, JSON schemas and tool definitions. A request that looks small in a text editor can occupy far more context once those pieces are assembled.

Measure the text with a tokenizer appropriate to the model, leave room for the response, and distinguish a local estimate from what the API provider eventually bills. The AI token counter and context inspector can help prepare that budget. Our introduction to the token counter gives a quick overview; this article works through the planning decisions.

Why words, characters and tokens are different

Tokenizers break text into pieces according to a specific vocabulary. Common words may fit into one token; unfamiliar names, punctuation, code and some languages may split into multiple pieces. A newline or a space can also influence how the next text is encoded.

These examples illustrate why a word count is insufficient:

• A paragraph of ordinary prose might tokenize differently from an equally long block of JSON.
• Indentation and repeated field names add text that matters to the count.
• Emoji, accented characters and non-English writing systems do not follow an English word-to-token rule.
• Two model families can use different tokenizers for exactly the same text.

The Web2Generators counter supports o200k_base and cl100k_base. Choose the encoding that matches your target model, rather than treating either as a universal standard. The 100k and 200k labels describe tokenizer vocabulary families, not a 100,000- or 200,000-token context window.

A local tokenization tool counts the literal text provided to it. An actual API request can add message framing, tool schemas, multimodal content and other provider-specific overhead. If your provider exposes a request token-counting endpoint, use it to check the complete request, and compare the result with the usage reported after execution.

Step 1: Separate the parts of a real request

Before trimming anything, list where your context comes from. For a support chatbot, the request may look like this:

Do not add confidential customer records or secrets to a third-party prompt just to measure them. The Web2Generators counter processes entered text locally in the browser, but you should still follow your organization’s data-handling rules, particularly before exporting a report that contains the text.

Step 2: Assemble the context instead of adding separate counts

Suppose an application constructs a prompt from four blocks:

INSTRUCTIONS
You are a support assistant. Answer only from the supplied policy.

HISTORY
Customer: Can I change the delivery address?
Assistant: Please confirm whether the order has shipped.

DOCUMENT
Address changes are available before dispatch.

QUESTION
My order has not shipped. Can I update the address?

The separators and headings are part of the request. Measure the assembled text, not just four independently counted snippets. Token boundaries can change where blocks join, and a sum of separate counts can differ from the count of the final combined text.

In the token counter, choose Plan context, enter the actual blocks and set a target capacity. The tool assembles nonempty blocks in display order with two line breaks between them. If your application adds other delimiters, count that exact final representation separately too.

The counter does not automatically create API chat message objects or calculate every provider’s framing overhead. That distinction is useful: you can inspect the text you control without assuming it is the entire network request.

Step 3: Reserve output tokens before filling the input

Imagine a purely illustrative context capacity of 32,000 tokens:

The budgeting rule is simple:

remaining = capacity - input_text - output_reserve - overhead_allowance

In this example, input_text is 22,000 tokens. An output reserve is planning space, not an assertion that every call will generate that many tokens. An overhead allowance is also an estimate, not a guarantee. Real context limits, API response limits, reasoning usage and input accounting vary by provider and model.

If the remaining value goes negative, reduce or select input before sending the request. Do not solve a context-limit problem by silently dropping the current user’s message or shortening a critical security instruction.

Step 4: Reduce waste without losing important information

A smaller prompt is only an improvement if it preserves the information needed for a correct response. Work through these changes in order:

1. Remove duplicate retrieved passages. Two excerpts repeating the same policy add cost without adding evidence.
2. Retrieve narrower sections. Prefer the relevant heading and surrounding context over an entire manual when the task is specific.
3. Limit chat history deliberately. Retain decisions, constraints and unresolved questions; summarize low-value exchanges with care.
4. Trim decorative structure. Repeated introductions, verbose wrappers and unnecessary whitespace can add tokens in large JSON payloads.
5. Keep identifiers and values intact. Do not compress away dates, error codes, field names or citations that the answer needs.

For prompt editing, use the counter’s Compare text mode to compare a draft and its revision under the same encoding. The result tells you whether the count changed; it does not measure answer quality. Test outputs against realistic tasks after any large rewrite.

For structured inputs, distinguish the JSON body from the information inside it. Minifying JSON removes some whitespace, but key names, nesting and values remain. You can review how JSON differs from other request formats in JSON vs Form Data vs Multipart.

Step 5: Estimate cost using rates you can verify

API prices often differ for uncached input, cached input and generated output. Images, audio and tool calls can add charges; reasoning tokens may also count toward billed output, depending on the provider. Instead of inserting an arbitrary ‘price per token’ into a spreadsheet, build a scenario from your provider’s published rates.

For text-only usage, one useful approximation is:

cost = (
  uncached_input_tokens * input_rate_per_million
  + cached_input_tokens * cached_rate_per_million
  + output_tokens * output_rate_per_million
) / 1_000_000

Multiply by the planned number of requests only if the input and output assumptions remain reasonably stable. Chat histories grow, document retrieval changes and cache eligibility depends on the provider’s rules.

The counter’s Cost scenario accepts editable rates, expected output and repeated-call quantities. Its starting rates are dated reference examples, not live pricing or an automatic match to the selected tokenizer. The calculation includes your input overhead allowance; expected output is separate from the reserved output space. Record the model, pricing date and assumptions with your estimate so the calculation can be reviewed later.

A common mistake is to mistake ‘unused context capacity’ for a monetary charge. A capacity limit describes what can fit; billing depends on what was actually processed and generated under the provider’s rules.

Step 6: Prepare the API request separately

Once you have a measured prompt, build the actual HTTP request. Keep application secrets outside screenshots, browser-share links and committed source files. A minimal JSON body might be:

{
  "model": "YOUR_MODEL_ID",
  "input": "Summarize the following policy in three sentences: ..."
}

This is an illustrative payload, not a claim that every AI provider uses the same endpoint or request schema. Check your selected provider’s documentation for the correct fields and limits.

Use the cURL Command Builder to assemble a request for your actual endpoint, then copy it into a local test environment. The builder prepares commands; it does not execute the request. For authentication, headers and quoting conventions, see the existing cURL Command Guide.

You can also check exactly what the browser sends with the Network inspection guide. Do not assume that a local count includes all the provider’s API framing or non-text content.

Step 7: Add token checks to your test process

A one-off estimate is useful, but a repeatable workflow catches regressions:

• Store representative small, medium and worst-case input examples in your test suite, without real personal data.
• Measure each fixture using the model-specific tokenizer or the provider’s counting service.
• Reserve enough space for the longest acceptable response.
• Alert when a request approaches your chosen budget threshold.
• Compare measured API usage with estimates in logs that exclude raw secrets and sensitive text.
• Review token growth after changes to document retrieval, chat retention or tool definitions.

For a multilingual app, include samples from the languages your users actually write. The same number of visible characters can use different token counts across encodings and scripts.