Never send a big request blind.
1. Count with the same shape you will send. The token counting endpoint accepts the same structured inputs as message creation: system instructions, tools, images, PDFs. Build the real request object first, then count it. Counting a simplified version gives a number for a different request.
2. Send images and PDFs as base64 for counting. The endpoint rejects image or document blocks with a url or file source, and it rejects server tools, the MCP connector, and most server-side tools with invalid_request_error. For those inputs, read the usage object on the real response instead of pre-counting.
3. Treat the count as an estimate. Actual input tokens on the real call can differ by a small amount. Add a safety margin (5 to 10 percent) between your count and the context window limit.
4. Enforce a budget rule. Define max input tokens per call from the model's window minus your max_tokens output budget minus headroom for tool results and citations. Reject or chunk any request over the budget before it hits the API: a 400 for context overflow is a wasted call.
5. Route on the count. Under the budget, pick the cheapest model that fits; near the top, step up to the larger-window model or chunk the input. Log the count with the request so cost anomalies trace back to specific inputs.
6. Recount after prompt changes. Any edit to system instructions, few-shot examples, or tool schemas changes the count. Re-run the preflight in CI when prompts change, or your budgets silently drift.