Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Measure token use at two points: count the exact structured request before sending it, then record the provider’s usage object after the response. Log the model, endpoint, project or organization, UTC timestamp, user, complete messages and tools, retries, response usage, and errors. Reconcile those records with the provider dashboard in its UTC timezone. If a short visible answer causes a spike, inspect hidden message structure, tool schemas, images or files, cached input, reasoning tokens, retries, model changes, and interrupted streams before changing limits.
What token usage actually measures
A token is a unit produced by a model-specific tokenizer, not a word, character, message, or line on the screen. As a rough English estimate, one token is about four characters or three-quarters of a word, but those figures are only heuristics. Billing and rate limits use the destination model’s tokenizer and the complete request, not an estimate based on visible text.
The provider can count content that never appears in the final answer. A chat request normally includes role labels, message boundaries, system instructions, conversation history, tool definitions, JSON schemas, and other serialization overhead. Output usage can include tool calls, response-channel structure, and reasoning tokens that are not shown to the user. Images, PDFs, uploaded files, retrieval passages, and cached input have their own accounting categories or rules.
Visible text versus billable structure
- Input text: system, developer, user, assistant-history, retrieved, and tool-result content.
- Protocol structure: roles, delimiters, message wrappers, response-format instructions, and provider-added formatting.
- Tools and schemas: function names, descriptions, parameter definitions, enum values, and nested JSON Schema. A tool that is not called can still add input tokens because its definition is sent with the request.
- Multimodal data: image detail, PDF pages, and file contents may be represented as tokens or provider-specific units.
- Output: visible text plus tool calls, structured output, hidden reasoning, or other response channels.
- Operational events: retries and failed attempts can consume per-minute request or token capacity even when the application eventually returns one successful answer.
Do not infer zero usage from an empty answer, a client timeout, or a broken stream. A request can consume input and output resources before the client loses the connection.
Use two measurements, not one
Preflight counting answers “what will this payload cost?”
A preflight counter receives the same structured input you intend to send and reports an estimate or count before generation. It is the right control for admission checks, budget forecasts, context-window checks, and explaining why a request grew before it is submitted. Count the destination model and include every block that will actually be sent. Counting only the user’s prose produces a misleading baseline.
Post-request usage answers “what did this attempt consume?”
The response usage object is the authoritative record for that attempt. Store input, output, and total fields, along with cached-input and reasoning details whenever the provider returns them. Post-request values can differ from an earlier estimate because of provider formatting, generated tool calls, reasoning, retries, or a payload that changed between counting and sending.
| Question | Use this measurement | What it cannot prove |
|---|---|---|
| Will this request fit a context or spending budget? | Preflight count against the exact destination model and payload | The eventual output, reasoning, retries, or server-side changes |
| How much did one attempt consume? | Final response usage object | Usage from another retry or an interrupted attempt with no final usage |
| Why did the monthly bill rise? | Aggregated logs reconciled with the provider dashboard | Any event missing from your logs |
| Why did a stream fail near completion? | Captured chunks plus final usage, if present | Zero usage when the final chunk is absent |
Build a measurement record for every request
Store one durable record per attempt, not just one record per user interaction. If a client retries three times, the bill and rate-limit counters can reflect four attempts even though the user sees one answer.
1. Capture request identity before sending
- Record the exact model name and version, endpoint type, project, organization, tenant or user, and application feature.
- Write a UTC timestamp at request creation and another at completion or failure. Keep the provider request ID when one is returned.
- Persist the complete structured input: system and developer messages, conversation history, tool definitions, schemas, response-format settings, image or file references, retrieval results, and output limits. Redact secrets and personal data while retaining enough structure to reproduce the count.
- Assign an attempt number and a stable interaction ID. A retry gets the same interaction ID but a new attempt number.
2. Record the response usage object
For OpenAI Chat Completions, save prompt_tokens, completion_tokens, and total_tokens. For the Responses API, save input_tokens, output_tokens, and total_tokens. Preserve any cached-input and reasoning subfields rather than flattening them into one number. Also store finish reason, tool calls, HTTP status, error code, and latency.
A normalized internal record can retain provider-specific fields without losing comparability:
{"interaction_id":"...","attempt":1,"provider":"...","model":"...","endpoint":"...","project_or_org":"...","user_or_tenant":"...","started_at_utc":"...","request_id":"...","input_tokens":0,"output_tokens":0,"total_tokens":0,"cached_input_tokens":0,"reasoning_tokens":0,"status":"success","error_code":null}Use null or an explicit unknown state when a field was not returned. Do not turn a missing value into zero.
Run a preflight count against the real payload
Keep the preflight call next to request construction so it cannot silently omit a tool, image, file, or schema. Serialize the same message array and options for both calls, and count against the model that will generate the response.
OpenAI
The Responses input-token counting endpoint accepts the same Responses payload, including tools, schemas, images, files, and conversation content. Use it immediately before sending when an exact input count is needed. The returned count is for the submitted input; it does not predict generated output or retries.
Anthropic
The Messages count_tokens operation accepts structured messages, tools, images, and PDFs. Its documentation lists exclusions, including some server-tool and URL or file-source cases, so treat unsupported blocks as a separate accounting risk. Anthropic describes the count as an estimate and notes that automatically added system-optimization tokens may appear in counts even though billing reflects customer content.
Google Gemini
Call countTokens with the same text and multimodal contents that will be sent. After generation, read usage_metadata and retain its input, output, and total categories. Do not substitute a text-only count for a request that includes images or files.
Make preflight a gate, not a bill
- Reject or summarize requests that exceed your context or cost budget.
- Log the preflight count beside the eventual usage so drift is measurable.
- Alert when the ratio of post-request input to preflight input changes materially for the same model and feature.
- Recount whenever you change model, tokenizer, tool schema, response format, or multimodal content.
Reconcile application logs with the provider dashboard
Dashboard totals are useful for accounting, but only after the filters match your logs. OpenAI’s Usage Dashboard displays data in UTC. Select the same UTC start and end times, project, organization, user or API-key scope, model, and endpoint dimensions used in your export. A local-time midnight can split a day differently from a UTC dashboard day.
Recommended Free Tools
- Export or query the dashboard for the smallest practical time window around the spike.
- Apply the project and organization filters first, then user, model, and endpoint filters if available.
- Sum successful attempts, failed attempts, and retries from your logs separately. Compare each category with the dashboard rather than comparing only one grand total.
- Check whether batch jobs, background workers, server-side tools, or another key share the same project. A user-facing log may not contain those requests.
- Investigate time-zone boundaries and dashboard aggregation intervals before declaring a discrepancy.
| Log field | Dashboard dimension to match | Common mismatch |
|---|---|---|
| started_at_utc and completed_at_utc | UTC interval | Filtering by local calendar day |
| project_or_org | Project and organization selectors | Key belongs to a different project |
| model and endpoint | Model or operation filters | Combining Responses and Chat Completions totals |
| attempt and status | Successful, failed, or total usage categories | Ignoring retries and unsuccessful requests |
| user_or_tenant | User or API-key breakdown | Shared service account hides the originating tenant |
Instrument streaming so usage is not lost
For OpenAI streaming Chat Completions, set stream_options.include_usage: true. The service sends an additional usage chunk immediately before [DONE]. Read and persist that chunk independently of the text assembly code.
If the connection closes before the final chunk, mark input, output, and total usage as incomplete or unknown. A missing final chunk does not establish that the request used no tokens. Keep the partial text, received chunk count, HTTP status, timeout, and request ID, then reconcile the attempt through dashboard data or provider support records rather than inserting zero.
Safe stream handling pattern
- Create the attempt record before opening the stream.
- Append content and tool-call deltas as they arrive, but do not treat them as final usage.
- When the usage chunk arrives, atomically store its fields and mark the attempt complete.
- When
[DONE]arrives without usage, retain the response but mark usage unavailable. - On disconnect, timeout, or client cancellation, mark the attempt interrupted and prevent automatic accounting as zero.
Why a short answer can consume many tokens
Conversation history grew invisibly
Many applications resend the entire conversation on every turn. A one-sentence reply can therefore carry thousands of historical input tokens. Log the serialized message count and input-token total per turn; compare the spike request with the immediately preceding request, not with the visible answer alone.
System instructions or schemas were duplicated
Repeated policy text, long examples, verbose tool descriptions, and nested schemas are charged each time they are included unless the provider’s caching rules apply. Diff the system and developer messages and the tool list between a normal request and a spike request.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteTools and retrieval added large hidden payloads
A tool definition can be larger than the user question. Tool results, retrieved documents, database rows, and serialized JSON are input even when the model ultimately decides not to call a tool. Log the byte or item count of retrieval context and the names and sizes of tool results.
Images, PDFs, and files changed the accounting
Multimodal requests are not comparable to text-only requests using character counts. Image detail, page count, OCR or extracted text, and provider-specific file handling can raise input usage. Include references and modality metadata in the request record and preflight the full multimodal payload where the provider supports it.
Reasoning was hidden, not free
Reasoning models can spend output tokens on internal reasoning that is not displayed. A short final answer does not prove that output usage was small. Save reasoning fields when returned and avoid setting an output-token allowance far above the answer your feature needs.
The tokenizer or model changed
Tokenization is model-specific. Anthropic documents that Claude 4.7 and later use a newer tokenizer and produce approximately 30% more tokens than earlier models for the same text on average, with workload-dependent variation. Recount identical payloads against the destination model after an upgrade; do not carry thresholds from an older model forward without checking.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Retries multiplied the bill and the rate-limit load
Transient failures, client timeouts, and overly aggressive retry loops can submit the same expensive input repeatedly. Store every attempt, honor the provider’s Retry-After value, and use bounded exponential backoff with jitter. A successful final answer does not erase the tokens consumed by earlier failed attempts.
Diagnose rate-limit and token spikes from the error itself
An HTTP 429 is not one condition. OpenAI documents request-rate limits, token-rate limits, exhausted prepaid credits, and organization usage limits as possible causes. Read the response body and error code before changing model settings or adding retries.
Decision path
- Identify the limit: determine whether the error names requests per minute, tokens per minute, credits, or an organization usage limit.
- Verify identity: confirm the organization, project, and key used by the failing worker. A key can point at a different project from the dashboard you are viewing.
- Check burst shape: compare concurrent requests and token totals in the affected minute. Spread bursts over time if requests per minute is the limiting dimension.
- Reduce token pressure: shorten repeated context, trim retrieval results, simplify schemas, and lower an unnecessarily high output allowance if tokens per minute is the limiting dimension.
- Retry safely: honor
Retry-After, apply bounded exponential backoff with jitter, and cap attempts. Count every retry in your usage ledger. - Escalate account limits only when appropriate: exhausted credits or an organization usage limit cannot be fixed by prompt trimming alone.
Do not automatically retry every 429 immediately. An unbounded loop can turn a temporary request spike into sustained token and request pressure.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Find the exact difference between a normal request and a spike
Take one request with ordinary usage and one with unexpected usage. Compare a canonical, redacted representation rather than screenshots of the UI.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Model name, version, endpoint, and response format.
- Number and total size of system, developer, user, and historical messages.
- Tool count, description length, schema depth, enum size, and tool-result payloads.
- Retrieved context, database rows, conversation summaries, images, PDF pages, and files.
- Maximum output setting, reasoning configuration, and stop conditions.
- Preflight input count versus final input count.
- Retry count, HTTP status, timeout, cancellation, and stream completion state.
- Cached-input and reasoning categories returned by the provider.
A useful diff reports both absolute and percentage changes. For example, a stable user prompt with a doubled input count usually points to history, tools, retrieval, or formatting; a stable input count with a larger output count points to generation, reasoning, tool calls, or an output limit.
Design a token-usage observability system
Minimum fields
At minimum, retain model, endpoint, project or organization, tenant, UTC timestamps, request ID, interaction ID, attempt number, preflight input count, provider input and output counts, total count, cached-input and reasoning fields when available, status, error code, and stream completion state. Keep a redacted payload fingerprint so identical requests can be grouped without storing sensitive content.
Useful alerts
- Input tokens per request exceed a feature-specific threshold.
- Post-request input is materially higher than the preflight count for the same model.
- Retries per interaction exceed one or a configured maximum.
- Interrupted streams lack final usage for more than a short reconciliation window.
- Token use per successful user action rises while visible output length stays constant.
- A model upgrade changes the token distribution for an unchanged payload.
Keep categories separate
Do not collapse all usage into one number in operational dashboards. Show input, output, cached input, reasoning, retries, and unknown or interrupted attempts separately. This lets an engineer answer whether a spike came from prompt growth, generation, hidden reasoning, caching behavior, or duplicate attempts.
Provider comparison at a glance
| Provider and interface | Preflight method | Post-request fields | Important qualification |
|---|---|---|---|
| OpenAI Responses | Input-token counting endpoint using the same Responses payload | input_tokens, output_tokens, total_tokens, plus returned cached-input or reasoning details |
Include tools, schemas, images, files, and conversation content in the counted payload |
| OpenAI Chat Completions | Use the provider’s available counting method or an equivalent exact payload count | prompt_tokens, completion_tokens, total_tokens |
For streams, request the final usage chunk with stream_options.include_usage: true |
| Anthropic Messages | count_tokens for structured messages, tools, images, and PDFs |
Read usage returned by the Messages response | Counts are described as estimates; exclusions apply to some server-tool and URL or file-source cases |
| Google Gemini | countTokens |
usage_metadata after generation |
Use the multimodal contents, not a text-only approximation |
A practical incident runbook
- Freeze the evidence: save the request and response metadata, redacted payload, dashboard filters, and all attempt IDs.
- Classify the symptom: high input, high output, high retries, missing stream usage, dashboard mismatch, or a 429.
- Recount: run the provider’s preflight counter against the exact payload and destination model.
- Diff: compare messages, tools, schemas, files, retrieval, output settings, model version, and retry behavior with a normal request.
- Reconcile: query the dashboard in UTC with matching project, organization, user, model, and endpoint filters.
- Apply the smallest fix: trim duplicated context, bound retrieval, simplify schemas, adjust output limits, spread bursts, or correct project routing.
- Verify: send a controlled request, capture preflight and final usage, and confirm the new record appears in the expected dashboard scope.
What to remember
Token usage is a property of the complete request lifecycle, not the amount of text a person can see. Exact payload counting explains what you are about to send; the response usage object explains what one attempt consumed; dashboard reconciliation explains how those attempts map to account totals. Treat retries and interrupted streams as real but possibly unmeasured work, recount after model changes, and inspect the provider’s error code before responding to a rate-limit spike.
Frequently Asked Questions
Should I estimate tokens from character count in production?
No. Character-to-token rules are rough English heuristics. Use the destination provider’s preflight counter for controls and the returned usage object for accounting.
What should I record when a stream disconnects before the usage chunk?
Record the attempt, partial output, request ID, status, and disconnect details, then mark token usage unknown or incomplete. Do not write zero; reconcile the attempt later with provider-level data.
Why can two providers report different counts for identical text?
Tokenizers and request serialization differ by model and provider. Recount the same structured payload with the tokenizer used by the service that will receive it.
Can a failed request count against a rate limit?
Yes. Failed attempts and retries can contribute to per-minute request or token limits, so include them in your attempt ledger and retry budget.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
