Context windows and stale market data
A model has no clock. Everything in its context is equally present to it — prices from thirty seconds ago and prices from thirty minutes ago read exactly the same. In a market that moves, that is a correctness problem before it is a cost problem.
The staleness failure
You ask about a position. The model calls a tool, gets a price, and answers.
Five messages later you ask a follow-up. The model answers from the price already in its context, because it is there and it looks like data.
Nothing in the architecture flags it. There is no field saying “fetched at 14:02”, and even if there were, the model has no reliable notion of what time it is now. Old data and current data are indistinguishable to it.
The consequence: analysis that was correct when generated, restated confidently after it stopped being correct.
This compounds with the delayed-data problem. If your feed is delayed — Alpaca’s latest fifteen minutes requires a subscription, for instance — the model has no way to know, because delayed data looks exactly like current data. See Alpaca paper trading API.
Why it accumulates
A conversation is cumulative. Every turn resends the accumulated history, so by turn ten the context contains nine snapshots of varying age plus your reasoning about each.
The model weighs all of it. Sometimes it uses the newest figure; sometimes it blends; sometimes it uses one from six messages ago because that is where the relevant sentence sits.
There is no rule you can rely on, which is the point.
The fix is architectural
Re-fetch before acting, always. Any calculation that feeds a decision should be based on a fresh tool call in that turn, not on a number already in context.
Timestamp everything at ingestion. Not so the model can reason about it — it cannot — but so your own code can reject stale inputs before they reach a plan.
Keep sessions short. A long session accumulates contradictory snapshots. A fresh session with current state is cheaper and more accurate.
Structure the state block. One clearly-labelled current-state section that gets replaced rather than appended beats nine scattered readings.
Validate the plan against live data. When a model produces a structured plan, check the entry against the current price before showing it for approval. A plan built on a stale quote should be rejected by a function, not spotted by a human.
The cost side
Context length also costs money, and the shape surprises people.
Every turn resends the accumulated history as input tokens. So conversation cost grows roughly quadratically in turns — turn ten pays for all nine previous turns plus its own.
But output is typically priced several times higher than input, so a verbose response often costs more than a long context. Run your own numbers through the LLM cost calculator and look at the output-share row: the lever is usually the response format, not the prompt.
Caching helps where a large stable block repeats — a system prompt, instrument definitions, your rules — which is exactly the shape of a trading assistant. It does not help with accumulating conversation history, because that is new material each turn.
Degradation at long context
Separate from staleness and worth knowing: models do not use very long contexts uniformly. Material in the middle of a long window is attended to less reliably than material at the ends.
For trading this means a risk constraint stated early in a long session is less reliably applied later — which is one more concrete reason that limits belong in code rather than in a prompt. A limit that decays with conversation length is not a limit.
The tool-call multiplier
A single question can trigger several tool calls. “How is my portfolio doing” may fetch balances, positions, then tickers for each symbol, then recent fills.
Each result enters the context and each round trip is billable. It is also why rate limits arrive faster than expected in an MCP setup — see rate limits in an MCP trading setup.
The reflex to reduce calls by reusing earlier results is exactly the wrong one, because that is the staleness problem. Fetch fresh and keep sessions short, rather than fetching once and reasoning from it for an hour.
FAQ
Does an AI know if its market data is stale?
No. Everything in its context is equally present to it, with no reliable sense of when any of it arrived or what time it is now. Old prices and current prices are indistinguishable, which is why freshness has to be enforced by your code rather than noticed by the model.
How do I stop an AI using outdated prices?
Re-fetch before any calculation that feeds a decision, rather than reusing a value already in context. Timestamp data at ingestion so your own code can reject stale inputs, and validate a generated plan against the live price before it reaches an approval screen.
Why does a long AI conversation cost so much?
Because each turn resends the accumulated history as input, so cost grows roughly quadratically in turns. That said, output is usually priced several times higher than input, so a verbose response format is often the larger expense — worth checking before optimising the prompt.
Should I keep one long trading session or start fresh?
Fresh, frequently. A long session accumulates snapshots of different ages that the model cannot distinguish, costs more per turn, and attends less reliably to constraints stated early in a long window. A new session with current state is cheaper and more accurate.