Short answer: stop sending raw OHLCV every turn. The same signal fits in a fraction of the tokens — and fewer tokens means lower latency and lower cost.
Approximate estimates · not a lab benchmark
Raw OHLCV is the most expensive shape you can feed an LLM. A 200-candle window is roughly 1,000+ numbers — very roughly a few thousand tokens — re-sent on every turn and per ticker. A token-compact market-state brief carries the same signal (patterns, levels, regime, interpreted indicators, one-line summary) in roughly a few hundred tokens. Fewer tokens means lower latency and lower cost.
Honesty note: the numbers on this page are approximate estimates from typical payload sizes and shapes — not a precise lab benchmark. Exact token counts depend on the model's tokenizer, numeric precision, how many candles you request, and JSON formatting. Treat every figure here as an order of magnitude, and read the competitor categories as estimated ranges, not measured results.
A single candle is about six numbers: timestamp, open, high, low, close, volume. Multiply that out:
So a 200-candle window is on the order of 1,000+ raw numbers before overhead. And because transformer attention cost grows with sequence length, longer contexts are not just more tokens to pay for — they also add latency and dilute the model's focus. Raw numeric arrays are the worst case here: they are long, they are repetitive, and LLMs are prone to making arithmetic mistakes when asked to reason over them directly. See the token cost of OHLCV candles for the breakdown.
Approximate tokens-per-call for a single ticker/timeframe request, and what your agent still has to compute itself. These are estimates from typical payload sizes — label them as such; they are not measured competitor benchmarks.
| Approach | Approx. tokens / call (estimate) | You still compute |
|---|---|---|
| Raw OHLCV array — exchange / CCXT-style, CoinGecko-style raw candles, or a raw-candle MCP (~200 candles) | ~3,000–6,000 (est.) | Patterns, support/resistance, indicators, regime — all of it, in-context |
| Generic crypto data API — raw candles + a few fields, JSON-heavy | ~3,000–6,000 (est.) | Most analysis; you parse and interpret the numbers yourself |
| patternfetch market-state brief — compact candles + precomputed structure | ~300–600 (est.) | Nothing — patterns, levels, regime, interpreted indicators and a one-line summary arrive precomputed |
Ranges depend heavily on candle count, precision and tokenizer. The point is the order of magnitude: a digested brief is roughly 5–10× lighter than re-sending a raw candle array — an estimate, not a guarantee. Raw approaches like CCXT-style exchange feeds and CoinGecko-style candles are perfectly good sources; they just hand you undigested numbers, so the token cost and the analysis cost both land on your agent.
Token count drives model cost, but the data itself has a price too. patternfetch is pay-per-call: $0.01 per brief, with a no-signup demo and a free key ($0.05 starter credit, ~5 briefs) — no card, no account. Many raw data APIs require a plan or an account before you can pull candles at volume.
To be fair: a raw OHLCV feed gives you full granularity — every tick, every field, no opinion baked in — which you may want if you are running your own indicator pipeline offline rather than in an agent's context window. The brief is optimized for the in-context agent case. See the side-by-side on compare market-data APIs to pick the right tool.
One call replaces the candle-array-plus-analysis dance:
// ~3,000–6,000 tokens, re-sent every turn
[
[1718000000, 60125.4, 60480.0, 59890.1, 60310.7, 1284],
[1718014400, 60310.7, 60590.2, 60110.0, 60450.9, 1102],
… 198 more rows …
]
// then: make the model find patterns,
// levels, regime, RSI/EMA itselfPOST https://patternfetch.com/v1/brief
Authorization: Bearer pf_…
{ "ticker": "BTC/USDT", "timeframe": "4h" }
// ~300–600 tokens back: compact candles +
// patterns, levels, regime, interpreted
// RSI/EMA, and a one-line nl summaryYou don't lose the raw numbers: the brief carries a compact candle codec in codec.rows, and you can always pull full candles with POST /v1/candles when you genuinely need every value. Full reference in the docs; try it live on /try.
It scales with the candle count. A candle is ~6 numbers (t, o, h, l, c, v), so a 200-candle window is ~1,000+ numbers plus JSON overhead — very roughly a few thousand tokens, re-sent every turn and multiplied per ticker. Approximate estimate from typical payload sizes, not a measured benchmark; exact counts depend on tokenizer, precision and formatting.
No. The brief includes a compact candle codec (the codec.rows field), and full candles are available via POST /v1/candles. You get the digested market state and the underlying numbers when you need them.
No. The figures here are approximate estimates derived from typical payload sizes and shapes, not a precise lab benchmark. Real token counts vary by model tokenizer, numeric precision, candle count and JSON formatting. Treat the ranges as orders of magnitude.
No. It's impersonal market data and algorithmic signals, for informational purposes only — not advice, not personalized, non-executing. See the disclaimer.