> **Update 2026-05-25**: I've edited this issue to clarify the framing. The original wording made stronger empirical claims ("I've been running a small router-wrapper", "preflight failure rate ~0.4%", "context utilization up ~12%") than I can actually support — the design is from reading `Router`, `token_counter`, and `model_cost.json`, not from a measured production deployment. I've also removed a reference to issue #21558 that I couldn't independently verify. The design discussion stands; the specific numbers and personal use-case framing have been removed.

---

## Summary

I'd like to gauge interest in a **cross-provider token-budget normalization API** at the LiteLLM Router layer — a single `router.budget(model)` call that returns a normalized budget object (input max, output max, effective input after tool/system overhead, per-token cost, tokenizer reference), plus a `router.check_fit(messages, model, ...)` preflight that returns a structured decision instead of a downstream `ContextWindowExceededError`.

Today `model_cost.json` exposes `max_tokens` / `max_input_tokens` / `max_output_tokens` / `input_cost_per_token` / `output_cost_per_token` as a static lookup, and `token_cou…