Shift Note: Token Checks Before the Request Leaves

The request is assembled, the conversation history is attached, and one more tool definition has pushed the payload into uncertain territory. Before sending it, you need to know whether it fits and what its input might cost. Three approaches compete for that preflight check: a rough text estimate, a local tokenizer and a provider counting endpoint. They answer similar questions with different levels of confidence.

The first check is the assembled request, not the draft

Counting only the latest user message misses much of the workload. System instructions, earlier turns, tool schemas and tool results can all contribute to input usage. Images, audio and other non-text content may follow model-specific accounting rules that a text tokenizer cannot reproduce.

Context planning also needs room for generation. Check the target model’s documented context and output limits rather than treating the entire context window as available input. Where reasoning tokens or other internal budgets apply, follow the provider’s rules. An input count alone is not proof that the complete request will fit.

Rough estimates win speed and lose boundary accuracy

A character- or word-based estimate is the cheapest check to implement. It can flag a growing transcript, catch an accidentally attached document or support a rough budget indicator while someone types. It needs no tokenizer package and no counting request.

Its weakness appears when text stops looking ordinary. Source code, identifiers, punctuation, multilingual content and serialized data can have very different token densities. Message formatting and non-text inputs add further uncertainty. A universal characters-per-token ratio is not a reliable admission rule.

Verdict: use estimates for early warnings, not hard acceptance decisions. They beat both alternatives on simplicity, but lose when a request is close to its limit or a cost ceiling matters.

Local tokenizers win repeated checks when compatibility holds

A local tokenizer gives a stronger text count without sending the prompt to another endpoint. It suits editors, batch preparation and applications that repeatedly check a changing conversation. Once installed, it also avoids a network round trip for each check.

The condition is compatibility. A tokenizer must match the selected model and relevant version; a familiar encoding is not automatically interchangeable across model families. Even a matching text tokenizer may not account for message wrappers, tool handling or multimodal conversion unless the integration explicitly implements those rules.

If an application switches between Claude Haiku 4.5 and Gemini 2.5 Flash, it should not carry one model’s counting assumptions across the switch. Route the counting logic with the model selection, and treat unsupported combinations as estimates.

Verdict: choose local counting for frequent text checks when you can maintain the mapping. It beats rough estimates on precision and remote counting on local responsiveness, but requires ongoing compatibility work.

Provider counting wins request fidelity where supported

A provider’s counting endpoint is usually the strongest preflight option when it supports the target model and request features. It can account for structures that a basic local tokenizer misses. Send the assembled request in the supported format, rather than flattening everything into a text string.

The trade-offs are another network dependency, possible authentication requirements, rate limits and any documented charges. Support also varies by endpoint and intermediary. Do not assume an OpenAI-compatible chat endpoint exposes a provider-specific counting operation.

A counting response is still not a complete invoice preview. Generated output remains unknown, and caching or other billing categories may affect the final charge. Record actual usage from completed requests and compare it with preflight counts.

Verdict: prefer provider counting for supported requests near a boundary. It wins on request fidelity, but not on availability or operational simplicity.

The handoff rule for a multi-model relay

Relay365 fits teams that want pay-as-you-go access across multiple model families through a common relay. Its API base is https://api.api365relay.com; OpenAI clients add /v1. That common connection point does not make tokenization or counting support universal, so verify the counting path for each selected model.

Create a Relay365 account if that access pattern suits your workflow, then test counting support before relying on it in production.

• Use rough estimates to warn early and cheaply.
• Use validated local tokenizers for repeated text checks.
• Use supported provider counting for boundary-sensitive requests, and reconcile every approach against actual usage.