FHIR Token, Cost & Context-Window Calculator

How many tokens is a FHIR patient bundle? A single real patient can serialize to hundreds of thousands of tokens — enough to overflow a 32k window and silently break your agent. Paste a record or a search query below and see exactly where the budget goes. Everything runs in your browser; nothing is uploaded.

Part of the open research program the numbers behind this tool: the overflow findings → all research →
100% local — your FHIR never leaves this page. No upload, no PHI.
Why Claude / Gemini are estimates (exact-via-your-key: coming soon)

OpenAI counts here are an exact o200k_base count (in-browser) — but GPT-5.x's reuse of o200k is assumed, not confirmed by OpenAI, so those rows carry an est tag. Claude and Gemini ship no client-side tokenizer, so they're shown as proxy estimates (~±15%). An exact non-OpenAI count would require calling the provider with your own key — which would send the pasted resource off this page — so it's not yet implemented here; everything on this page stays local.

Methodology & honest caveats

The lever, per our secondary external comparison (MIMIC-IV-on-FHIR, a FHIR-AgentBench re-grade): the things engineers reach for did nothing — purpose-built typed tools were a null (+0.08, 95% CI [−0.12,+0.28], p=0.69), and a code interpreter at matched context budget was −3.6pp, p=0.18 (not significant). The one thing that moved accuracy was avoiding context overflow on large patients (raw FHIR overflowed a 32k window on 64% of questions). That's a post-hoc, single-seed/model/substrate result — a caveated corollary, not a headline. See the benchmark →

  • OpenAI = exact o200k_base count (via gpt-tokenizer), shown with an est tag because GPT-5.x reuse of o200k is assumed, not confirmed.
  • Claude / Gemini = proxy estimates (~±15%); no client-side tokenizer exists for either.
  • Window thresholds: 32k and 100k were the budgets actually tested in the re-grade; 128k / 200k / 1M are compare-only.
  • Prices are list input prices, sourced from models.dev — they drift; re-verify before relying on the $ column. Claude/Gemini $ figures use a proxy token count, so treat them as estimates.
  • Projected-slice savings are illustrative — a fixed assumed reduction ratio, not a live projection of your record. Anchor: Flexpa reported ~240k→19k tokens (~92%) via SQL-on-FHIR projection; bonfireDB computes the real cited slice.
  • Generic context-window calculators exist; this is the first FHIR-aware one we know of (per-resourceType + free-text share + fan-out cost + projection savings).

Open source (Apache-2.0): npx fhir-token-calculator chart.json (coming to npm) · the engine is @fhir-craft/tokens, also coming to npm.

Your agent shouldn't see a 1.2M-token record.

bonfireDB's MCP layer hands it a cited, ABAC-scoped, projected slice — not the raw FHIR. That's the lever the benchmark says actually moves accuracy.

Become a design partner See the MCP projection layer →