Billing Math

Billing Math

The whole product rests on one asymmetry: providers bill text per token, but bill an image by its dimensions. A 1568×728 page costs the same number of tokens whether it holds 200 characters or 20,000.

OmniGlyph never guesses this cost — it computes each provider's exact formula and only converts when the image is strictly cheaper. The math is exported at the package root (anthropicImageTokens, resolveAnthropicVisionTier, tier caps) and is consumed directly by OmniRoute.

Anthropic (measured to zero residual)

Billed in 28 px patches after a per-tier resize, plus a fixed per-image-block overhead:

image_tokens = ⌈w / 28⌉ × ⌈h / 28⌉ + block_overhead

• block_overhead = +3 on Claude Fable 5, +4 on Claude Sonnet 4.5 (measured).
• A standard 1568×728 page = ⌈1568/28⌉ × ⌈728/28⌉ + overhead = 56 × 26 + 4 = 1,460 tokens — flat, regardless of text inside. It carries 28,080 chars ≈ 19.2 chars/token vs ~2 chars/token as dense text.
• The retired w·h/750 formula predicts 1,522 for that page (off by 62) and is not used.

Worked example

Plain text:  1015 characters  ≈ 254 text tokens
Rendered:    438 × 120 PNG    =  84 image tokens
                               ─────────────────
Saved:       254 → 84         =  66.9%

OpenAI & Gemini

Both formulas are audited against the official "calculating costs" tables and covered by tests. detail and media_resolution levels are taken from each model's profile — sending a level a model doesn't support is treated as out-of-contract and avoided.

Why "exact" matters

The profitability gate is only trustworthy if the cost estimate is exact. Every number here has a receipt in benchmarks/*/results/, produced by the billing-sweep harness against the provider's real count_tokens endpoint. An off-by-a-little estimate would convert blocks that actually cost more — so the sweep is run to zero residual before any formula ships.

Full methodology and every table: BENCHMARKS.md.