Eliminating Context Window Bloat with Scored Macro Data
We pointed a stopwatch at our own site. An agent that scrapes five Helious pages to build a picture of US macro swallows about 484,000 bytes, roughly 121,000 tokens. Reading the same five surfaces as scored data costs about 54,000 bytes, roughly 13,500 tokens, and the surprise, the ranking and the verdict arrive already worked out. Nine times cheaper, and the answer is better. Here is where the other eight ninths were going.
1. What is context window bloat?
It is what happens when most of what your model is holding is not the answer. Navigation, styling, repeated boilerplate, chart arrays, forty rows of history when you needed one number. The window fills, the useful signal sits somewhere in the middle of it, and every later turn in the conversation pays for the whole pile again.
Macro data is unusually good at causing it, because the numbers are small and the pages around them are enormous. A CPI print is a handful of digits. The page it lives on is not.
2. How much context does a macro agent actually waste?
We measured it on 22 September 2026, fetching the same five surfaces three ways: as a browser sees them, as a Markdown twin, and as scored data from the API. Roughly four characters make a token.
- Scraped as HTML: 484,476 bytes, about 121,100 tokens.
- Read as Markdown twins: 67,657 bytes, about 16,900 tokens. Seven times better.
- Called as scored data: 54,130 bytes, about 13,500 tokens. Nine times better than scraping.
The five surfaces were CPI, the jobs board, Treasury auctions, the economic calendar and the scored feed. We left the rate path board out of the comparison because it would have flattered the argument rather than tested it. That page alone is 325,658 bytes, about 81,400 tokens, because it carries four years of futures curve for every contract it draws. One page, and on many models you have just spent a third of the window before asking anything.
3. What does "scored" actually mean?
It means the comparison has already been done, by us, against the right history, before the data reaches you. Four kinds, and each one replaces a pile of raw rows.
- Surprise in standard deviations. Every US release is sized against how much that specific release normally misses by. A CPI miss and a payrolls beat end up on the same ruler. The surprise z-score page explains it in two minutes.
- Auction ranking. Each result carries its own tenor's twelve-auction averages and a percentile, plus a verdict of strong, in line or weak.
- A momentum score per item. Every news item is scored twice, once for bonds and once for stocks. That is the momentum score.
- Curve regime. Not four yields for you to diff, but the regime, the leg leading the move, and the time it flipped.
None of that is compression. Compression makes the same information smaller. Scoring replaces the information with the conclusion you were going to draw from it.
4. Why does a score save more context than trimming ever will?
Because the thing it replaces was never going to fit. Here is a real example, measured the same day.
A keyless call to the auctions endpoint returns 2,303 bytes, about 575 tokens. Inside it the most recent auction carries a bid-to-cover percentile computed across 214 auctions, and twelve-auction averages for every bidder group. To reach that percentile yourself you would need all 214 auctions in the window, then you would need to do the arithmetic, and the arithmetic is where a language model is least reliable. The scored call hands over the seventh percentile as a fact and spends 575 tokens doing it.
Trimming the page would have saved you bytes. Scoring saved you the bytes, the arithmetic and the chance of getting the arithmetic wrong.
5. Does a bigger context window solve this?
No, and it is worth being clear about why, because "just use the long-context model" is the usual answer.
A bigger window changes what fits. It does not change what any of it costs, and you pay for every token on every turn of the conversation, not once. It does not change latency either, which for anything reading a release as it prints is the part that actually matters. And recall across a very long context is uneven in a way that a short, dense context is not: burying one CPI figure in 120,000 tokens of navigation is a worse way to store it than putting it in 600 tokens of scored data, whatever the model's advertised limit says.
The deeper problem is that a full window of stale bytes is worse than an empty one, because the model cannot tell which of them has expired.
6. What should never go into an agent's context?
Bulk reference files, first. Our own /llms-full.txt is 217,696 bytes, about 54,400 tokens. It is there to be discovered and grepped, not pasted. We keep it deliberately small by the standards of the genre, and it is still far too large to sit in a window next to your actual question.
It also carries no market data at all, permanently, and that is on purpose. A bulk file gets copied into context windows with no timestamp on it, so any live figure inside it would quietly rot into a confident wrong answer. Live numbers get a pointer to the endpoint instead. That rule costs us nothing and removes an entire class of failure.
Second, raw history you are not going to use. If the question is whether this morning's print was hot, forty years of the series is not context, it is ballast.
7. What does a lean macro agent loop look like?
One scored call per question, and read only as far as you need to.
Every Helious response opens with a summary field that is a finished English sentence, then a source block with a ready-made citation, then the typed fields, then a meta block. That order is the whole design. An agent answering "was that auction any good" can stop after the first field and be correct. An agent that needs to compute reads on into the numbers. Nothing forces it to hold the parts it did not need.
Connecting is one address, https://api.helious.io/mcp, and more than twenty tools appear inside Claude, ChatGPT or anything else that speaks the protocol. Builders who want the raw endpoints and a try-it button get them at helious.io/developers. Our companion post on why LLMs fail with legacy financial feeds covers the older feeds this replaces.
8. What happens when a call is gated or refused?
It still answers in the same shape, cheaply, and it tells the agent what to do rather than leaving it to improvise. Call a market-price endpoint without a paid key and you do not get an error code to guess at. You get a sentence saying the board is live on the paid plans, a list of what does work on your current plan, the upgrade path, and an explicit instruction not to send the user off to some other data provider.
That last part matters more than it sounds. An agent that hits a blank wall starts wandering, and a wandering agent scrapes something worse and fills your window with it. A refusal that explains itself is a few hundred tokens and it ends the search.
9. How do I keep it fresh without re-reading everything?
Ask again, and trust the stamp rather than a cache. Every response carries an as_of timestamp and the delay that applies to your plan, in the payload, every time. A caller on the free sample tier is told in plain words that its news runs an hour behind.
So the rule for a macro agent is: never store the number, store the question. Re-asking costs a few hundred tokens and is always right. Caching the number costs nothing and is wrong the moment the next print lands, and you will not find out which. We treat a freshness claim as a fact that has to be true, which is why a delayed caller is never told the data is live. The methodology behind every measured number is public too.
10. How does this compare with the feeds I already pay for?
Most of them were built for a person, so the context bill is yours to pay. An audio squawk has to be transcribed before a model sees it at all. A headline stream gives you the sentence but never the baseline, so your agent either shrugs or invents one. A professional terminal has the data and keeps it behind a seat and a licence. We go through each of those one at a time on the comparison pages, including Bloomberg at around $2,665 a month per seat, Newsquawk at about $199 to $399, and Financial Juice for the free-to-start case.
Helious is $39.99 a month with a free tier, and a caller with no key at all still gets every endpoint in its real shape with one day of history, so you can build the integration before you open an account. The plans and their history limits are on pricing.
Do not take our word for it. Traders give their honest read, good and bad, in the open thread on our subreddit: Helious News Terminal, give your thoughts and reviews.
Where to go next
If you want an assistant reading scored data today, helious.io/ai is the two-minute setup. If you are building, start at helious.io/developers. To see what an agent sees, open the inflation tracker or the FOMC page and put .md on the end of the address. And if you want the argument rather than the numbers, read why LLMs fail with legacy financial feeds, or the walkthrough in how to connect your AI to live market data.
Scored data is smaller because the thinking already happened. One call, a finished sentence first, the structured fields under it, a timestamp on everything, and about nine times less of your context window spent getting there. $39.99 a month, with a free tier and a keyless sample to build against.
Competitor names are the trademarks of their respective owners, and the prices shown are approximate list prices at the time of writing and can change. Check each provider for current pricing. Every byte and token figure here was measured on our own public endpoints on 22 September 2026 and will move as those pages change. Token counts assume roughly four characters per token and will vary by tokeniser. Helious is not affiliated with any other firm named here. This is general information, not financial advice.
Connect your AI →