How to count tokens without an API key

See also / canonical cluster. Pillar for token & cost estimation: How to estimate LLM token costs before you ship. Interactive: token & cost estimator. This page stays on a different intent — see the intro.

Intent here: offline / no-key counting methods (heuristics, local tokenizers, CI gates) — not the full monthly cost formula. After you can count, fold volumes and rates into the estimation pillar or the token estimator. Background: token counting explained.

Why count without calling the API

• Budgeting — Finance wants a range before you enable a feature.
• Design — You are choosing between short system prompts and long RAG packs.
• Privacy — Sample prompts contain customer text you should not send to a vendor yet.
• CI — You want a gate that fails oversized prompts without network access.

Vendor usage.prompt_tokens remains the source of truth for invoices. Offline methods are for planning and guardrails.

Method 1: Character / word heuristics

For English prose, a common rule of thumb is ~4 characters per token, or ~0.75 words per token. That is enough for rough monthly forecasts when you multiply by call volume and retries.

Use heuristics when:

• You need an order-of-magnitude answer in five minutes
• The text mix is mostly natural language (not dense code or JSON)
• You will validate later with a real tokenizer or a small live sample

Do not treat heuristics as invoice-grade. Code, URLs, Markdown tables, and CJK text skew the ratio. Our token estimator exposes an editable chars-per-token field so you can stress-test assumptions.

Method 2: Local / open tokenizers

Many model families publish or mirror tokenizer files you can run offline (library packages, WASM builds, or CLI tools). Local counting is the right move when:

• You already know which model family you will call
• Prompt size sits near a hard context limit
• You want CI to reject oversized templates without secrets in the runner

Caveats:

• Tokenizer must match the family you bill against (or accept a known error band)
• Updating models means updating the local vocab — pin versions in docs
• Some vendors do not ship a public tokenizer; then approximate and sample-validate

Document which tokenizer artifact you used next to the prompt version. Treat it like a dependency.

Method 3: Browser estimators (no key, no upload)

Client-side estimators (including sudoai.net’s) keep text in the browser, apply a simple rule, and pair it with editable USD rates. Good for:

• Writers and PMs who will not install Python packages
• Quick “what if we cut this section” comparisons
• Workshops where you cannot share API keys

They are not substitutes for vendor usage fields. Label estimates as planning numbers in RFCs.

Method 4: Tiny paid sample, then extrapolate

If you have a key but want to minimize spend:

1. Tokenize or estimate offline to get a baseline
2. Send one short representative call
3. Compare usage.prompt_tokens to your estimate
4. Scale the correction factor across the full corpus

That single calibration call is often cheaper than debating ratios for an hour.

A practical counting workflow

1. Freeze the prompt shape — system + user template + typical RAG chunk sizes.
2. Estimate offline — heuristic or local tokenizer on 3–5 real examples (p50 / p90).
3. Add output headroom — max_tokens and typical completion length, not just input.
4. Fold in retries and agents — multi-step tools multiply input tokens; see also rate limit backoff.
5. Convert to money — paste into the token estimator with your invoice rates.
6. Gate in CI — fail PRs that push system prompts past an agreed ceiling.

Common mistakes

• Counting only the user message and forgetting the system prompt and tool schemas
• Using GPT-era rules for a different vendor’s tokenizer
• Ignoring whitespace-heavy JSON and base64 blobs in context
• Estimating once on a happy-path sample and never checking the p90 case
• Shipping without a documented chars-per-token or tokenizer version

When you still need the API

Use live usage when:

• You are reconciling an invoice dispute
• Context packing is within a few hundred tokens of the limit
• Tool-calling schemas change token cost in ways offline tools miss

Until then, count offline, document the method, and keep secrets out of early design loops.

Quick checklist

• Primary keyword / feature has a written prompt template
• Offline estimate method named (heuristic vs local tokenizer)
• p50 and p90 samples measured
• Output and retry multipliers included
• Rates match current vendor list prices (edited in the estimator)
• CI or review gate exists for prompt size regressions

For compressing prompts after you count them, read reduce prompt tokens without losing quality. For RAG-specific blowups, see RAG context window cost estimation.

Tie-in to sudoai.net tools

Paste a representative system+user string into the token & cost estimator, adjust chars-per-token for your language mix, and save the monthly figure next to the feature RFC. When the same text is messy chat residue, run it through the prompt cleaner first so you are counting the prompt you will actually ship — not the Slack chrome around it.