# Getting started > Ask TypeSafe Jev which link a visitor is about to click, then warm > exactly that navigation. Your framework already prefetches. Nuxt warms every link that enters the viewport, Next does the same, and Chrome guesses on hover. None of them knows which link you actually want. This warms three instead of thirty, and starts before the hover. ## Pick your framework A module. Add it, set a key, done. A route handler and a provider, for the App Router. ## What you get either way - **One request per prediction.** Three questions, answered in parallel, in about 400 ms. - **Two effectors.** Speculation rules for document navigations, the framework's own preloading for in-app ones. [Why two](/guide/how-it-works#the-two-effectors). - **An overlay.** A probability on every link and a HUD. Press Shift +P . - **Failing open.** Any error or timeout leaves the page exactly as it was. ## What it costs Predictions are not free. The [benchmark](/guide/benchmarks) measures about 15 calls and 10,000 tokens per session, with a sixth answered from the server's own cache. Tune `minIntervalMs`, the cache TTL and the budgets before pointing it at real traffic. ## Is it worth it for you? Sometimes not, and that is worth knowing early. - If your visitors hover a link for a second before clicking, the browser's own document rules at `eagerness: moderate` already cover you, for free and with no model. - The in-app win comes from warming a payload, which means prerendered or statically generated routes. On a purely server-rendered route there is much less to warm. - It improves the median navigation and does nothing for the tail.