Feeding Financial and Market Data to LLMs with TOON

TOON is the best token-efficient format for feeding financial and market data to an LLM. Price bars, trade ticks, and ledger rows are dense, uniform tables — exactly the shape where TOON cuts 58–59% of tokens while keeping field retrieval at 99.6%. The rule: encode rows as TOON, compute aggregates in your code first.

Why Financial Data Is TOON's Best Case

The core inefficiency of JSON is repetition: every object in an array pays the full key-and-punctuation tax. A JSON array of 500 daily OHLC bars repeats the field names date, open, high, low, close, and volume 500 times each. TOON eliminates that by declaring fields once in a header line and reducing every subsequent row to pure values.

Financial data happens to be the most uniform data category most developers deal with. A candlestick series for any instrument over any window has identical fields in every row. A trade blotter has the same columns for every fill. A positions ledger has the same schema for every holding. This structural regularity is precisely why TOON's official benchmarks show their largest savings on these shapes: 59.0% for time-series data (9,115 vs 22,245 tokens on a 60-day series) and 58.8% for flat uniform tables (67,778 vs 164,452 tokens).

The overall accuracy across all question types is 76.4% for TOON vs 75.0% for JSON, but for the one task that matters most when feeding price data — looking up a field value — TOON hits 99.6% accuracy. If you ask the model "what was the closing price on March 15?" it will get the right answer from a TOON-encoded series with near-perfect reliability.

OHLC Rows as JSON vs TOON: A Direct Comparison

Here is the same five-day AAPL price series serialized in both formats. The token difference grows linearly with the number of rows.

// JSON — keys repeated on every row, ~190 tokens for 5 rows
[
  {"date": "2024-03-11", "open": 172.14, "high": 174.20, "low": 171.82, "close": 173.65, "volume": 62341200},
  {"date": "2024-03-12", "open": 173.80, "high": 176.10, "low": 173.55, "close": 175.93, "volume": 71204400},
  {"date": "2024-03-13", "open": 176.40, "high": 177.80, "low": 174.10, "close": 174.67, "volume": 68912000},
  {"date": "2024-03-14", "open": 174.50, "high": 175.30, "low": 172.45, "close": 173.22, "volume": 55872100},
  {"date": "2024-03-15", "open": 173.10, "high": 175.90, "low": 172.88, "close": 175.41, "volume": 79403500}
]

// TOON — fields declared once, values only on each row, ~78 tokens for 5 rows
ohlc[5]{date,open,high,low,close,volume}:
  2024-03-11, 172.14, 174.20, 171.82, 173.65, 62341200
  2024-03-12, 173.80, 176.10, 173.55, 175.93, 71204400
  2024-03-13, 176.40, 177.80, 174.10, 174.67, 68912000
  2024-03-14, 174.50, 175.30, 172.45, 173.22, 55872100
  2024-03-15, 173.10, 175.90, 172.88, 175.41, 79403500

At 5 rows the saving is already material. Scale this to a 252-day trading year or a multi-year series and the token reduction compounds directly into lower API costs. See our guide to optimizing LLM API costs for the dollar math.

Which Financial Data Types Suit TOON?

Not all financial data is uniformly structured. The table below maps common data types to their fit with TOON and the specific caveat to watch for in each case.

For a broader view of format trade-offs across data shapes, see the TOON format comparison guide.

The Aggregation Warning: Pre-Compute Sums and Averages

The benchmark numbers for field retrieval are excellent, but TOON's accuracy on more demanding question types is meaningfully lower. The toonformat.dev benchmarks report aggregation accuracy at 61.9% and filtering accuracy at 56.8% — compared to 99.6% for simple field retrieval.

In a financial context this means: do not ask the model to calculate a total portfolio value, a period return, a moving average, or a sum of trading volume from a raw TOON payload. Roughly one in three or four aggregation queries will produce a wrong answer. The correct pattern is to do the math in your application code and then pass the pre-computed result into the prompt as a small TOON table or a single value.

// Anti-pattern: asking the model to aggregate raw data
// "Here is the trade log. What was total volume on March 12?"
trades[500]{date,ticker,side,price,qty}:
  2024-03-12, AAPL, buy, 173.80, 100
  2024-03-12, MSFT, sell, 415.20, 50
  ... (498 more rows)

// Better pattern: pre-compute the aggregate, send the result as TOON
// "Here is the daily volume summary. Explain the volume spike on March 12."
volume_summary[5]{date,total_volume,top_ticker}:
  2024-03-11, 62341200, AAPL
  2024-03-12, 142107900, NVDA
  2024-03-13, 68912000, AAPL
  2024-03-14, 55872100, MSFT
  2024-03-15, 79403500, AAPL

This pattern keeps the LLM doing what it is good at — interpreting, summarizing, and explaining — rather than arithmetic. It also dramatically reduces the token count you need to send.

How TOON Stacks with Cost-Optimization Techniques

Financial applications often make high-frequency, repetitive LLM calls — daily summaries, real-time alerts, portfolio commentary. The token savings from TOON compound with other cost levers.

Prompt caching on Anthropic charges 10% of the standard input rate for cache reads (a 90% discount) and 1.25x for writes. OpenAI's automatic caching applies a 50% discount to stable prefixes over 1,024 tokens. Because TOON reduces the total token count before caching, a smaller block is cheaper to write on first use and cheaper to read on every subsequent call. A TOON-encoded time-series that is 59% smaller than its JSON equivalent also hits the caching threshold faster and produces a proportionally smaller cache-write cost.

The independent arXiv study "Talking with Tables for Better LLM Factual Data Interactions" (arXiv 2412.17189) provides complementary evidence: tabular structures yield a 40.29% average performance gain over text blended with semi-structured formats, and attention analysis shows models attend to relevant information more accurately in tabular form. TOON's tabular block is exactly this structure — without the alignment-character overhead of markdown tables.

For the full picture on combining TOON with caching and batching, see optimizing LLM API costs.

Integrating TOON into a Financial Data Pipeline

A typical pattern for a market-data analytics service looks like this:

1. Fetch from source. Pull OHLC bars or trade records from your data provider as JSON or CSV.
2. Filter server-side. Reduce the dataset to the time range and tickers the query actually needs. Sending 10 years of daily bars when the question concerns the last quarter wastes tokens regardless of format.
3. Pre-compute aggregates. Run any sums, averages, or derived metrics (returns, ratios, z-scores) in your application layer and attach them as extra columns or a second TOON table.
4. Encode as TOON. Convert the filtered, enriched result to TOON using the free converter or the @toon-format/toon npm package. For large datasets requiring streaming or schema validation, consider TONL.
5. Prompt the model. Include the TOON payload with a brief format note. Models that have seen TOON in prior turns of a cached conversation need no re-explanation.

For RAG-style financial applications where retrieved market data is passed as context, see our guide on optimizing RAG pipelines with TOON. Retrieved positions or price records share the same uniform schema, which means the 99.6% field retrieval accuracy carries over directly.

When to Use JSON Instead of TOON for Financial Data

TOON is not always the right choice, even in a financial context. The 2026 arXiv study (2603.03306) on TOON vs JSON established a non-linear scaling threshold: TOON's per-row savings only amortize the format-instruction overhead once the payload is large enough. For small, one-off payloads — a single account summary object, a single trade confirmation — plain JSON is simpler and cheaper.

Similarly, if the LLM must output structured financial data (for example, generating a JSON object representing a parsed trade instruction), use JSON with constrained decoding. The same arXiv study found JSON wins on generation accuracy. The practical split: TOON for input context (the data you feed in), JSON for output schema (the format you ask the model to produce). See our JSON vs TOON comparison for the full breakdown.

Frequently Asked Questions