The real-time wall

Three walls so far: your list could not stay fresh, your screen could not see the whole market, your backtest could not reach the regime that would test it. This one is different in kind, because it breaks a feature you built rather than limiting one you wanted.

The two numbers that meet

From the previous lesson, your cockpit costs a measured number of calls per refresh. From /user, you have a daily limit — on the free plan, documented as 20 API calls per day.

Put them together for the worked cockpit at 18 calls per refresh: the free allowance buys one refresh a day, and not quite a second one.

That is the whole wall, and it is arithmetic rather than a policy. Twelve live quotes cost twelve calls because /real-time is priced per symbol, and no amount of batching changes it — course 1's correction is what makes this number honest.

What breaks, precisely

The cockpit stales. Not blank, not broken — stale, which is worse, because it renders perfectly. This is why unit 2 insisted on labelling age and unit 3 insisted on showing the oldest timestamp. Without those, a person reads a confident, wrong screen.

The alert is mute. Unit 3 priced a real alert loop at 936 calls a day for 12 symbols at five-minute intervals. Against 20 calls, the alerting feature you designed cannot run at all — not degraded, not delayed. Off.

Those are the two sentences that make this wall real rather than rhetorical: your cockpit stales and your alert is mute.

Degrade honestly

A tool that hits its limit and says nothing is the failure. Three behaviours, and none of them is hard:

1. Stop refreshing before the limit, not at it. Keep a reserve so a deliberate manual refresh still works.
2. Say what happened. "Refresh paused — 20 of 20 calls used today, resets at 00:00 UTC." A 429 rendered as "something went wrong" is the worst version of this moment.
3. Keep showing the data, labelled. Every panel goes to its stale state with a real age. The person can still work; they just know what they are looking at.

This is unit 2's degrade-rather-than-disappear rule, and the wall is the reason it existed.

Write down what your tool cannot do

In PLAN.md:

Calls per refresh:        ___
Daily allowance:          ___
Refreshes it buys:        ___
Alert loop needs:         ___ calls/day
Therefore alerts:         ___

Fill it in with your own measured numbers. That last line usually reads "cannot run", and writing it is the point — an honest limitation you know about beats a feature you believe in that does not work.

What upgrading changes, precisely

Nothing in your code. The same cockpit, the same panels, the same layouts, the same alert evaluator you already wrote and tested — refreshing at the interval it was designed for, with the alert loop actually running.

And the same honesty as the previous three walls: if you open your cockpit twice a day and read it, it fits, and you should not pay for anything. The wall matters when the tool becomes something you rely on, and the previous lesson's projection is what tells you when that happened. Live pricing is on the pricing page and deliberately not quoted here, because a number written into a lesson goes stale and then lies to whoever reads it next.

Try it now

Fill in the five lines with measured numbers, then set your refresh interval to what your allowance actually supports and use the cockpit for a day. That experience — a tool you built, running honestly inside a real limit — is the point of the whole exercise, and it is a different feeling from being told about it.