Pregame betting asks whether your view beats a market before the event starts. Live betting asks that question while the event, the data feed, the model, and the price are all moving. The second problem is not automatically richer. It is simply less forgiving.
Pregame gives you time to be correct
Before the game, you can verify participants, injuries, weather, market rules, and the price across books. You can rerun the model, inspect a suspicious feature, and decline the wager without watching the quote disappear between clicks.
That slower environment favors repeatable process. The market may already be sharp, but the bettor has a fair chance to know which state was modeled and which price was accepted. The odds translation in the betting-odds guide can be completed before execution rather than reconstructed afterward.
Pregame does not mean static. Lines move as information and money arrive. The advantage is that the inputs and timestamps can be archived cleanly enough to test whether the decision was sound.
Live betting is a synchronization problem
A live model needs the current score, clock, possession or game state, participant availability, market definition, and an executable quote. Those inputs must refer to the same moment. A fast model paired with a delayed feed is still pricing the past.
The screen can create false confidence. A bettor sees a play, sees a number, and assumes the number has not reacted. The sportsbook may have a newer feed, may suspend the market, or may reject the order after repricing. An apparent gap is not an edge until the price fills.
Log the state used for the forecast and the state acknowledged by the ticket. Without both, a later review cannot distinguish good prediction from a latency accident.
A pregame model is only the prior
The pregame probability remains useful as a starting point, but the game supplies evidence. Score, time remaining, field position, foul or penalty state, substitutions, and injuries can alter the distribution. The correct update depends on the sport and market.
Do not bolt the current score onto a pregame projection and call it live. The model must have been designed and validated for state updates. It also needs leakage controls so training features come from information available at the decision timestamp.
A model that cannot represent the live state should return an error value: unsupported state; cure is no live price. That is better than silently reusing the opening forecast.
Stale is a claim that needs evidence
A live line is stale when the executable market has not incorporated information that materially changes fair value. That definition contains two traps. First, the information may already be reflected through inputs you did not see. Second, the displayed quote may no longer be executable.
Before calling a line stale, compare feed timestamps, confirm market status, record the accepted price, and identify the specific state change your model handles differently. “The touchdown looked important” is not enough. The market knows the score changed. The question is whether it mispriced the consequences.
Track these entries through the closing-line-value framework, but preserve live timestamps and state. A pregame close and a live execution are not directly comparable.
Execution cost is part of the model
Live markets can reprice between submission and acceptance. Orders can be delayed, rejected, partially accepted, or filled at a different quote depending on venue rules. A backtest that assumes every displayed price was available is not an execution test.
Record attempted orders as well as accepted tickets when diagnosing live strategy. Rejection patterns can reveal that the apparent edge existed only on stale display data. The model may be predicting correctly while the trading path cannot capture the price.
The current board on the picks page and exposure on the desk are useful only when their timestamps and market states remain visible. Green styling is not a substitute for an executable quote.
Cashout is a fresh transaction
Cashout should be evaluated as an offer to close a position now. Compare the offer with the position’s current fair value, the cost and availability of an opposite market, and the reason your risk policy allows an exit.
There is no honest universal answer. A cashout can be expensive, useful, unavailable, or mispriced. The right analysis starts from the current state and contract rules, not from the emotional comfort of locking a result.
Do not call a cashout a hedge unless the resulting exposure has been calculated. Closing one ticket may leave related positions untouched.
Choose the mode your evidence supports
Pregame is the default when your data updates on a schedule, your model was trained on pregame features, or your execution path cannot measure latency. Live belongs to systems built for event-state ingestion, rapid recalculation, and accepted-price logging.
Neither mode grants an edge. Each creates a different burden of proof. Pregame asks whether your forecast beats a mature price. Live asks whether your synchronized forecast beats a moving price you can actually obtain.
The sharpest live decision is often refusal. When the state, price, or timing cannot be verified, passing is not hesitation. It is the only result the evidence supports.
Line movement versus recorded public ticket share
This chart remains empty until a verified source table binds public ticket share and line movement for the same market observations.
Model calibration from graded predictions
Calibration points render only when a verified source binds prediction probabilities to settled outcomes for the same observations.
