Answer card
The best market data for a context window is not the fullest feed; it is the one shaped so a model can re-read it cheaply. Raw tick JSON and chart screenshots both cost the model its whole token budget every turn. A Kestrel VIEW renders the market as a compact text Frame: an append-only tape, one row per candle, relative moves in basis points, anchored by keyframes. Perception cost is O(new bars), not O(screen), and KV-cache-friendly. Start with one VIEW over a generic instrument and watch the token math flatten.
Why this is a real question
If you have ever piped a market feed into a language model, you have felt the problem. The data is not wrong; it is the wrong shape. A full order-book snapshot is thousands of numbers the model must re-parse on every turn. A minute of ticks is a wall of noise. A chart image asks a vision model to re-read the entire pixel field just to notice one new bar.
This is the Interface Thesis: the two failures of LLM trading are interface (perception and latency), not intelligence. The model is smart enough. It is being handed data in a format that burns its context and hides the signal. "Best market data for a context window" is really a question about representation, not coverage.
The three shapes you can hand a model
Raw feed / JSON API. Ground-truth bars and ticks, normalized across venues. Perfect for a pipeline: a backtester, a feature store, an ML training set. Handed to a model in-context, it is brutal: the payload scales with the window you show, every field is absolute, and the model re-reads the whole blob each turn to find what changed. It is accurate and illegible at the same time.
Chart screenshot (vision). Intuitive for a human, and a vision model can read it. But an image is O(screen): the cost is the whole picture, every turn, whether or not anything moved. You also lose exact values, and you cannot cache "the part that didn't change." One new candle costs a full re-read.
Compact text Frame (Kestrel VIEW). The market rendered for a model. A vertical, append-only tape: one row per candle, newest last. Candles are relative, expressed in basis points versus the prior close, so the numbers are small and comparable. Periodic keyframes re-anchor absolute price so the tape never drifts. Because it only ever appends, adding a candle is a few tokens and the earlier rows stay byte-identical. The chart is in text, and it is KV-cache-friendly.
The decisive property is O(new bars), not O(screen). A raw feed and a screenshot both make perception scale with how much you show. A Frame makes it scale with what actually changed.
What a VIEW looks like
Illustrative only, generic instrument: this is how an agent could perceive a market, not a recommendation to trade anything.
USING signal SPX exec SPY 0dte
VIEW tape budget 900
candles 5m
velocity 5m
keyframe every 30mThe budget 900 caps the Frame at a token ceiling; the runtime keeps the tape within it by anchoring on keyframes and dropping stale detail, not by truncating blindly. candles 5m is the append-only tape, velocity 5m a derived pane, keyframe every 30m the periodic absolute-price anchor. The model reads a small, stable text block, and next turn, only the new row is new.
The token math
Consider a model watching a session, turn after turn. With a raw feed or a screenshot, each turn re-pays for the entire visible history: perception cost grows with the window and never amortizes. With a Frame, the prefix is unchanged, so a KV-cache serves it for free and you pay only for the appended bars.
That is the whole argument in one line: perception cost is O(new bars), not O(screen). Over a long session the difference is not incremental; it is the difference between a budget that blows up and one that stays flat.
Comparison table
Radically fair: each shape wins somewhere. Pick by who the reader is.
| Dimension | Raw feed / JSON API | Chart screenshot (vision) | Kestrel VIEW (text Frame) |
|---|---|---|---|
| Primary reader | A pipeline (code) | A vision model or human | A model that reads, parses, and acts |
| Perception model | Absolute bars/ticks, full payload | Pixels, whole image | Compact text Frame; relative candles + keyframes |
| Cost per turn | O(window shown) | O(screen) | O(new bars); KV-cache-friendly |
| Exact values preserved | Yes | No (read off pixels) | Yes (bps vs prior close + keyframes) |
| Agent in the hot path? | N/A (data only) | N/A (data only) | No; pair with a PLAN, fire-then-inform |
| Latency floor | Feed delivery latency | Render + vision latency | Runtime fires PLANs in ms; agent woken in parallel |
| Native interface / MCP | HTTP API + client libs | Screenshot tooling | Four equal faces: HTTP+SSE, TS SDK, CLI, MCP |
| Agent-native auth (Envelope) | API keys | N/A | Envelope {scope, budget, ceiling, expiry, revocation} |
| Machine payment | Standard billing | N/A | HTTP 402 offer; agent wallet or human claim-and-fund |
| Evaluation honesty | Out of scope | Out of scope | GRADE, contamination-fenced, VS null / VS ungated |
| Provenance | Documented feed | None | Certified Blotters + Grades; shareable proof URL |
| Live model (custody) | N/A | N/A | Certification over custody; BYO-broker, never custody |
| Data licensing | Direct feed licensing | Your screenshots | Databento served as derived works; BYO Alpaca |
| Activation path | Account + API key | Ad hoc | Proof-before-account: trial → free catalog → free SIM |
| Pricing | Feed / usage pricing | Free-ish | OSS core free; paid boundary at the 402 (founding) |
| Best for | Feeding code a pipeline | A quick human glance | An LLM that must perceive and act |
Where a Frame is not the fit
Be honest about the limits. If your consumer is code, a Frame is strictly worse than the raw feed: you want the numbers, not a rendering of them, and you should read directly from a provider like Databento. If you need full-depth microstructure or venue-accurate tick fidelity, a compact Frame deliberately drops detail to stay in budget; that is a feature for a model and a bug for a matching-engine study. And if a human just wants a glance, a chart is more intuitive than a tape. A Frame earns its keep only when the reader is a language model that must see and act inside a context window.
It is also worth stating plainly where the platform stands. As of mid-2026: anonymous trial sims, certified Grades, shareable proof URLs, and 402 Offers with Stripe settlement are live; always-on paper presence and the human-signed live path are in build. The free tier needs no signup. The durable core is the open-source language and runtime; the Frame is the part you can reason about now.
The bottom line
Coverage is not the constraint. Every serious provider can hand a model more data than it can afford to read. The constraint is representation: a format the model can re-read cheaply, turn after turn, without re-paying for history that did not change. Raw feeds are for pipelines; screenshots are for glances; a Frame is for an agent that has to keep perceiving.
The best market data for a context window isn't more data; it's data shaped so perception costs O(new bars), not O(screen).