How BtcForecaster works
Last updated 9 November 2026
· Current model: v2 (HAR-RV-J) (v2-har)
In short
BtcForecaster forecasts how far Bitcoin's price is likely to move over the next 1, 4 and 24 hours, as a 50% range and a 90% range, refreshed every 5 minutes. It doesn't forecast whether the price will go up or down. It publishes how often the price actually lands inside its ranges, misses included.
What the ranges mean
A 90% range is a price band the price should finish inside about 9 times out of 10. A 50% range is a narrower band it should finish inside about half the time.
Example: the current 1-hour forecast
At 10 Nov 2026, 17:00 UTC the price was $72,881. The 90% range for 10 Nov 2026, 18:00 UTC is $72,269 – $73,497, about ±0.84% of the price. The 50% range is $72,665 – $73,097 (about ±0.30%).
So the forecast is: there's roughly a 9-in-10 chance the price is between $72,269 and $73,497 at 18:00 UTC, and roughly an even chance it's inside the narrower band.
- 4 hours: $71,571 – $74,214 (90%) by 10 Nov 2026, 21:00 UTC
- 24 hours: $68,987 – $76,994 (90%) by 11 Nov 2026, 17:00 UTC
A 90% range should miss about 1 time in 10. That's by design. A range that never misses is too wide to be useful: "Bitcoin will be between $1 and $1 million tomorrow" is always right and tells you nothing. The aim is ranges that are as narrow as possible while still holding about as often as they claim.
Where the data comes from
- Source: Binance's free public market data for the BTC/USDT pair. The site stores the closing price of every 1-minute candle, fetched about once a minute, and the models work on 5-minute steps built from them.
- Quoted in USDT: the price is Bitcoin in USDT, a stablecoin that usually trades very close to US$1, so it's shown in dollars. It can differ slightly from Bitcoin's price in actual US dollars.
- Fallback: if Binance doesn't answer after 3 attempts, the site fetches CoinGecko's Bitcoin price in US dollars instead. Its history is coarser (roughly every 5 minutes, or hourly further back). If both fail, the site keeps showing the stored prices and marks them as delayed.
- Sources are never mixed: every price is stored with its source. A forecast only uses prices from the source of the price at that moment, so volatility is never measured across a switch, and it's only scored against a price from that same source; forecasts whose outcome price came from the other source are left out of the scores and counted separately. While the fallback is in use there's too little of its history to forecast from, so new forecasts pause until Binance is back. Any fallback periods are listed in /api/live-stats, noted on the track record page and shaded on the home page chart.
- No look-ahead: each forecast only uses prices available at the moment it's made. Forecasts recreated from history (backtests) follow the same rule and use the same code.
- Scoring: once a forecast's time arrives, it's checked against the stored price nearest to that time, within 3 minutes.
Why it doesn't predict direction
Three models were built to predict which way the price would move in the next hour: singular spectrum analysis (a method that extracts repeating patterns from a price series), gradient-boosted trees (a machine-learning method) trained on returns, volatility, volume and calendar features, and a "flow" model trained on order-flow data such as buying pressure, futures open interest and funding rates. Each was compared with the simplest possible forecast: the price stays where it is.
None beat it on data it hadn't been tuned on. Used as they were, the tree models' typical error was 4% and 21% larger than "no change" on the two halves of the test, and the flow model's 17% and 8.5% larger; the flow model called the direction right 47–49% of the time, which is chance. Scaled down to a fraction of their predicted move, they came out about level with "no change": no edge. (Source: README, "Retired models"; a 7-day backtest split into halves.)
In plain terms: the direction of Bitcoin's next few hours looks unpredictable, but the size of the move is partly predictable, because busy periods tend to stay busy for a while and quiet ones stay quiet. So every range is centred on the current price and extends equally far up and down in percentage terms. (Strictly, it's symmetric on a log scale, so in dollars the upper edge sits very slightly further away.)
How the forecast is made
The current model, v2 (HAR-RV-J), makes each forecast in five steps.
- Measure recent volatility, meaning how much the price has been moving. It looks at four windows at once: the last 15 minutes, the last hour, the last day and the last week. The short windows react to a shock straight away; the long ones keep the bigger picture. For the hour, day and week it uses a measure that a single sudden jump barely moves, and it records separately how much of the last day's movement came from jumps. (This is known as HAR-RV-J: a "heterogeneous autoregressive" model of realised volatility, with jumps.)
- Combine them and scale to the horizon. A regression (a weighted sum whose weights are learned from data) combines those inputs into the expected volatility over the forecast window. It's fitted separately for each horizon on the last 90 days, and refitted every day at midnight UTC; if a refit looks wrong, the previous day's weights are kept. The expected volatility per 5-minute step is then added up over the window (12 steps for 1 hour, 48 for 4 hours, 288 for 24 hours): typical move = √(steps × expected 5-minute variance).
- Allow for the time of day. Bitcoin is busier at some hours (around the US market open, for example) and quieter at weekends. The regression is told how active the hours the forecast covers usually are, how active the last hour usually is, and how much of the window falls on a weekend, all learned from the same 90 days. The README doesn't record this part's effect separately for this model; the improvement below is for the model as a whole.
- Add room for scheduled releases. When a US economic release falls inside a forecast's window, the
model adds extra variance, measured in units of one normal hour. This applies to every forecast whose window contains
the release time, so it's there from up to 24 hours before (for the 24-hour range) until the release itself. The
allowances, estimated on releases from January to May 2026:
"Extra room" is the added variance in normal hours; the other columns are how much wider that makes each range. Fed decisions are at 14:00 and CPI and jobs reports at 08:30 New York time. A release type with (almost) no extra room moved Bitcoin no more than a usual hour at that time of day. The estimates rest on only 3–5 releases of each type, so they're pulled towards the average over all types.Release Extra room 1 h 4 h 24 h Fed rate decision 0.40 h +18% +5% <1% US inflation (CPI) 0.00 h ≈0 ≈0 ≈0 US jobs report 0.41 h +19% +5% <1% - Set the 50% and 90% edges from real outcomes, not bell-curve assumptions. The model looks back at its own forecasts over the last 7 days (14 days for 4 and 24 hours) and, for each one whose outcome is known, divides the move that happened by the typical move it had predicted. The 90% edge is set where 90% of those past ratios fell, the 50% edge where half did. Bitcoin has more quiet stretches and more sudden jumps than a bell curve allows, and this captures both. With less than a day of past outcomes (288 forecasts), it falls back to bell-curve multipliers (±1.645 and ±0.674 typical moves).
How accuracy is measured
- Hit rate (coverage): the share of forecasts whose actual price landed inside the range, edges included, for each range and horizon. The target is 90% for the 90% range and 50% for the 50% range. Too low means the ranges are too narrow; too high means they're wider than they need to be.
- Overlap and effective sample size: a forecast every 5 minutes for the next hour means 12 consecutive forecasts share most of the same hour, so they aren't independent. The "effective sample size" is the number of forecasts divided by that overlap (12 for 1 hour, 48 for 4 hours, 288 for 24 hours): roughly how many truly separate outcomes there have been.
- Margin of error: how far the hit rate can drift from its target by chance alone, with 95% confidence, based on the effective sample size. A range counts as calibrated when its hit rate is within that margin of its target.
- Interval score: the width of the range plus a penalty for each miss in proportion to how far outside the price landed. Lower is better, so it rewards ranges that are narrow and still right.
- Rolling 7-day windows, not single days: forecasts overlap, so a single day is close to one independent observation at 24 hours (and about six at 4 hours). Day-by-day hit rates therefore swing wildly by chance; coverage over the trailing 7 days, with its margin, is the meaningful view, and it's the one shown here and on the track record page.
- Every horizon from 10 minutes to 24 hours was checked (on June–October 2026, unseen when the model was
tuned) for confidence that drifts with horizon, such as ranges too wide at 10 minutes and too narrow at 24 hours. The
published ranges held 88.6–90.1% of the time at every horizon from 15 minutes to 24 hours, all within their margins (89.0%
at 10 minutes, just under), so no drift. The model's raw volatility estimate does drift, too small at 10 minutes, but
the calibration step, done separately for each horizon, corrects it.
(Source:
tools/VolStudy/horizon-diagnostics-report.md.) - Live means live: the live statistics count only forecasts made in real time, never forecasts recreated from history.
- Raw data: the live statistics are public as JSON at /api/live-stats, per model and horizon.
Live results
v2 (HAR-RV-J), live since 28 Oct 2026. Figures as of 10 Nov 2026, 17:02 UTC.
Last 7 days (rolling window ending 10 Nov)
| In | Scored | 90% range held | 50% range held |
|---|---|---|---|
| 1 hour | 1,932 | 88.9% ±4.6 Calibrated | 51.8% ±7.7 Calibrated |
| 4 hours | 1,932 | 88.3% ±9.3 Calibrated | 56.4% ±15.4 Calibrated |
| 24 hours | 1,932 | 76.3% ±22.7 Calibrated | 50.2% ±37.8 Calibrated |
± is the 95% margin of error for the window. "Calibrated" means the hit rate is within that margin of its target (90% or 50%). Since live forecasting began: 1 hour 90.4% ±3.3 of 3,781; 4 hours 87.9% ±6.7 of 3,745; 24 hours 79.4% ±16.9 of 3,505 (90% range).
24 hours: the 7-day margin is still wide (±22.7 points, from 1,932 forecasts, about 7 independent outcomes), so more live data is needed before this hit rate means much.
The home page waits for 14 days of live forecasts before quoting a live hit rate. These figures are shown here early, with their margins, so you can follow along.
Every forecast and miss over time is on the track record page; the raw numbers are at /api/live-stats.
How the model is chosen and changed
- Tune every setting on one period of history (January–May 2026 for the current model).
- Test once on a later period the model never saw (June–October 2026), recreating each forecast with only the prices available at the time.
- Run it live alongside the current model. Every model keeps forecasting and is scored on its own live record; switching which one the site shows is a single setting, and the other keeps running, so the two can be compared and the switch reversed.
- v1 (baseline) (
v1-baseline): sizes the range from one fast-reacting average of recent price moves, with the same calibration step. It still runs as the baseline and fallback. Live record since 28 Oct 2026. - v2 (HAR-RV-J) (
v2-har): the multi-window volatility model described above, with time-of-day and scheduled-release terms. Live record since 28 Oct 2026. - v3 candidate (shadow) (
v3-har-cal90): v2 with one change: the 24-hour range is calibrated on the last 90 days of outcomes instead of 14. It runs in shadow: it is scored live like the others, but its ranges are never shown as the forecast (see the pre-registered test below). Live record since 9 Nov 2026.
Pre-registered test: v3 candidate (shadow)
What changes: the 24-hour range learns its width from the last 90 days of outcomes instead of the last 14; everything else, including the 1- and 4-hour ranges, is exactly v2.
Why a live test: on June–October 2026 this scored about 6% better at 24 hours and held 90% of the time, but most of that gain came from a single fortnight in August, so it failed our rule that a gain mustn't depend on one month. Rather than loosen the rule after the fact, the decision is made on new, live data, with the rule fixed now.
The rule, fixed before the test starts (start: 2026/11/09). After at least 14 days of live forecasts, the candidate becomes the main model only if all of these hold:
- its 24-hour interval score is at least 2% better than v2's, and the difference is statistically significant (p < 0.05);
- it is not more than 1% worse at 1 or 4 hours;
- its hit rate is within the margin of error of its target at every horizon;
- it passes the independence test at 24 hours (its misses don't bunch together or depend on the range's width) where v2 fails it.
If it fails, it is retired and listed with the rejected ideas. Its live record is on the track record page and in /api/live-stats as v3-har-cal90.
Out-of-sample test: v1 and v2 on Jun–Oct 2026
Backtest, not live: forecasts recreated every 15 minutes from 30 May
to 27 Oct 2026. Source: Data/backtest-stats.json,
written by tools/VolStudy --report (README, "HAR model").
| In | 90% range held v1 → v2 |
Average width v1 → v2 |
Interval score |
|---|---|---|---|
| 1 hour | 89.7% → 89.7% ±1.0 |
1.30% → 1.14% | −4.9% |
| 4 hours | 89.8% → 89.9% ±2.0 |
2.44% → 2.32% | −1.5% |
| 24 hours | 88.9% → 88.6% ±4.8 |
7.15% → 6.53% | −2.3% |
Interval score change: v2 against v1, negative is better. Same hit rate with narrower ranges means the width is spent where it's needed. The 4- and 24-hour gains are small next to their uncertainty: a 24-hour window overlaps the next 95 forecasts, so five months hold only about 150 independent 24-hour outcomes.
In 1-hour windows containing a scheduled release, v2's 90% range held 57.7% of the time (v1: 55.8%), well below the 90% target, from only 13 releases (3 of them Fed decisions).
Ideas tested and rejected
Each was tested the same way (tuned on January–May 2026, checked on June–October) and left out. Source: README, "HAR model".
- Implied volatility as an input (Deribit's DVOL, what options traders expect): a tiny gain at 1 hour, slightly worse at 24 hours. Not worth depending on another data source.
- Recency-weighted calibration (counting the last hours or days more when setting the edges): mixed results, none better than the current model, and one version let the 24-hour hit rate fall to 83%.
- Shorter training (30 or 60 days): similar at 1 and 4 hours, worse at 24 hours.
- Live feedback correction (widening after each miss and narrowing after each hit): it forced the hit rate to 90%, but by over-widening after unlucky streaks, and scored worse at every horizon.
- Outside data (implied volatility scaled to the horizon, futures funding rates, open interest): nothing came close to a 2% improvement fixed in advance. Recent price volatility already carries what these know about the next few hours.
- Extra room for the 48 hours after a release: the Fed-only version looked good on January–May but was worse on unseen data (based on three Fed decisions); the version pooling all releases made almost no difference.
- Lopsided ranges (more room on one side, because recent misses fell below the range more often): mostly worse. One mild version helped at 24 hours but wasn't statistically convincing; it may be re-tested after more months of data.
Limitations
- Surprise news isn't in the data. Scheduled US releases are allowed for; unscheduled events (hacks, regulatory news, sudden liquidations) aren't, and the first minutes of a sudden jump will usually be a miss.
- After big announcements the market can keep moving for longer than the model allows. Extra room is added only up to the release, not after it, and release hours are still under-covered.
- The 24-hour horizon needs weeks of live data before its results mean much: a week holds only about 7 separate 24-hour outcomes.
- Past volatility doesn't guarantee future volatility. The model reacts after conditions change, not before.
- One exchange's price. Forecasts and scoring use Binance's BTC/USDT price (CoinGecko only as a fallback), which can differ slightly from other exchanges and from Bitcoin in US dollars.
Not financial advice
BtcForecaster is an experimental, informational tool. Its ranges are statistical estimates that will sometimes be wrong. It is not investment advice, it doesn't recommend buying or selling anything, and it says nothing about whether you'd make or lose money. See the terms of use.
Frequently asked questions
- Does it predict whether Bitcoin will go up or down?
- No. Every range is centred on the current price. Models built to predict direction did no better than assuming the price stays the same, so the site only forecasts how far the price is likely to move, in either direction.
- Why is the range sometimes wider?
- The range follows recent volatility, meaning how much the price has been moving. It widens after big moves, at busier times of day and ahead of scheduled US economic releases that have moved Bitcoin before, and narrows when the market is quiet.
- Why was the forecast wrong yesterday?
- A 90% range is meant to miss about 1 time in 10, so some misses are expected. Misses also bunch up around sudden news, which no forecast built from past prices can see coming. Every miss is shown on the track record page.
- How often is it updated?
- A new forecast for the next 1, 4 and 24 hours is made every 5 minutes, using only prices up to that moment.
- Can I use the data?
- The live results are public: /api/live-stats returns them as JSON, refreshed about once a minute. Please read the terms of use before republishing them. Nothing on the site is financial advice.
Contact
BtcForecaster is built by Massimiliano Peluso (about). Questions, corrections or ideas: send feedback by email, or find him onLinkedIn, X or Bluesky. Journalists: see the press page.