KASPR Predict for Snowflake · beta · private preview
Timing verdicts inside your Snowflake account.
A Snowflake Native App with the same timing planner as the KASPR Predict MCP, computed where your data and pipelines already are. Call it from SQL, from a task before a heavy job, or from Cortex agents and MCP clients through a Snowflake-managed MCP server. It answers one question — given a task at a proposed time and place, is there a materially better time? — in fixed wording, in every participant’s local time, and says nothing when nothing is better. Nothing you send leaves your account.
Snowflake Native App · schemas TIMING and PREDICT · managed MCP servers KASPR_TIMING and KASPR_PREDICT
Beta version
- KASPR Predict is in beta. Answers, wording and features may change, and the model’s parameters are still being calibrated.
- Predictions are not based on the most recent data. They come from KASPR’s typical week for each place, built from measurements up to 16 July 2026, so they describe how a place usually behaves, not today’s conditions, outages or recent changes to a network.
- Treat every answer as a tendency to weigh, not as advice to rely on. Each answer names the data vintage it was computed from.
Three ways to ask
The same procedures answer a SQL worksheet, the chat in Snowsight and an AI coding agent. Each panel shows a real question to the app in our test account and the real answer.
A pipeline gate: run an embedding batch at 3 PM on Monday in Vienna?
CALL KASPR_PREDICT.TIMING.CHECK_TIMING('agent_batch',
'[{"label": "me", "query": "Vienna, AT"}]',
'2026-10-05T15:00:00+02:00', NULL,
'{"local_hours": [0, 24]}', 'Europe/Vienna');{
"verdict": "suggest_alternative",
"text": "Deferring to 6 PM Vienna (Mon): current window congested, alternative mixed, confidence high.",
"candidate": { "band": "congested", "confidence": "high" },
"alternative": { "band": "mixed", "time": "2026-10-05T18:00+02:00" }
}The steadiest hour for your call is 6:00 PM Tuesday in Nairobi (Africa/Nairobi time).
Just so it’s on your radar: that lands at 2:00 AM Wednesday for you in Melbourne (Australia/Melbourne). The whole Tuesday-evening Nairobi window falls in the small hours Melbourne-side, so there’s no overlap that’s comfortable on both ends. If a middle-of-the-night call doesn’t work for you, you may want to look at a different window (e.g., Nairobi morning / Melbourne afternoon).
Real questions and answers from the app in our Snowflake test account on 4 October 2026, shown in KASPR’s own styling rather than as screenshots of Snowsight or Claude Code. The SQL result is an excerpt; the chat and Claude Code answers are quoted in full.
One call, one verdict
A video call between Melbourne and Nairobi, proposed for 9 PM Nairobi time. The procedure names the hour in both places, says it is usually a congested hour on Nairobi networks, and proposes the nearest steadier hour inside the window. When nothing is materially better, the verdict is no_recommendation and there is nothing to show.
SQL
CALL KASPR_PREDICT.TIMING.CHECK_TIMING(
'live_call',
'[{"label": "me", "query": "Melbourne"},
{"label": "Tim", "query": "Nairobi, KE"}]',
'2026-10-06T21:00:00+03:00',
'{"start": "2026-10-06T18:00:00+03:00", "end": "2026-10-07T00:00:00+03:00"}',
'{"local_hours": [0, 24]}',
'Australia/Melbourne');Result (excerpt)
{
"verdict": "suggest_alternative",
"reason_code": "endpoint_congested_hour",
"candidate": {
"band": "congested", "confidence": "high",
"time_local": [
{"label": "Tim", "time": "2026-10-06T21:00+03:00"},
{"label": "me", "time": "2026-10-07T05:00+11:00"}]},
"alternative": {
"band": "mixed", "confidence": "high",
"limiting_endpoint": "Tim",
"time_local": [
{"label": "Tim", "time": "2026-10-06T19:00+03:00"},
{"label": "me", "time": "2026-10-07T03:00+11:00"}]},
"text": "9 PM Nairobi (5 AM Melbourne (Wed)) is usually a congested hour on Nairobi networks; 7 PM Nairobi (3 AM Melbourne (Wed)) is typically steadier for a video call. Propose 7 PM Nairobi instead, or keep 9 PM Nairobi?",
"data_vintage": "2026-07-16"
}Captured from the app on 3 October 2026; the explanation field, kept for when someone asks why, is left out here. The app and the hosted MCP server run the same decision code and agree field for field on a shared set of test inputs.
What you can do with it
Gate a pipeline before a heavy job
A task asks CHECK_TIMING with task class agent_batch before bulk model calls, re-embedding or a large transfer. On suggest_alternative it defers once to the suggested hour; on anything else, an error included, it runs now. It never skips a run.
Plan calls and live sessions from your own tables
BEST_WINDOW takes the people’s places and a window of up to twelve hours and returns the steadiest feasible hour in every participant’s local time, so a scheduling job or a dashboard can propose times without leaving Snowflake.
Give Cortex agents and MCP clients a timing tool
The app ships a Snowflake-managed MCP server with check_timing, best_window and explain_last_verdict, with the same descriptions as the hosted MCP server, behind your account’s own OAuth and roles.
What the app installs
Two schemas of stored procedures, each with its own managed MCP server. Every answer is a verdict or a decision a caller can act on; a timing verdict never blocks, and every scheduling error carries a fallback of run now.
| Schema | Procedure | What it does |
|---|---|---|
| TIMING | CHECK_TIMING | Is a proposed time a usually rough hour on the networks involved, and is there a materially steadier hour nearby? For calls, live streams, uploads, agent batches and fixed live events. |
| TIMING | BEST_WINDOW | The steadiest feasible hour inside a window of up to twelve hours, when no time has been proposed yet. |
| TIMING | EXPLAIN_LAST_VERDICT | The reasoning behind your last verdict, for when someone asks why. |
| TIMING | TIMING_WINDOWS | A table of hours with a band (steady, mixed or congested) and a confidence for one place: bands only, at most 48 hours. |
| TIMING | GET_ENTITLEMENT | Your account, tier and caps. |
| PREDICT | BEST_WINDOW | For batch jobs and agent loops with a deadline: run now with timeout, retry and cache tuning for the hour, wait, or no good window. |
| PREDICT | EXPOSURE_CLASS · LATENCY_FORECAST · SCHEDULE_HOLD · REPORT_OUTCOME | Classify a task, read the hourly curve for a place, hold a window and re-score it, record how a job went. |
How to get it
During the private preview we share the app with your Snowflake account as a private listing. Tell us your account locator and region when you ask; installation then takes a few minutes in Snowsight.
1. Ask for access
Through the contact page, with your Snowflake account locator and cloud region.
2. Install from the private listing
Snowsight → Data Products → Apps. The app needs no external access integration and reads no tables of yours.
3. Grant it to the roles that call it
One application role for the procedures and the MCP servers. Optionally, open the app in Snowsight and grant its two task privileges on the Permissions tab, so it can re-score held windows on a schedule.
GRANT APPLICATION ROLE KASPR_PREDICT.APP_PUBLIC TO ROLE ANALYST;4. Ask
Call a procedure from a worksheet, a task or a notebook, or point an MCP client at the app’s managed MCP server.
CALL KASPR_PREDICT.TIMING.BEST_WINDOW('live_call',
'[{"label": "me", "query": "Vienna"}]',
'{"start": "2026-10-09T06:00:00+02:00", "end": "2026-10-09T18:00:00+02:00"}');Full documentation: every procedure, parameter, verdict and limit →
How it decides
- —Verdicts come from KASPR’s typical week for each country, region and district: every hour of the week is steady, mixed or congested relative to that place’s own week. A two-party call is judged by its worse side, and that side is named.
- —A steadier time is suggested only when it is at least one band better and materially so, inside the window and the local hours you allow at every participant; otherwise the verdict is silent. A fixed event gets advice, never a different time.
- —The timing verdicts come from the same decision code the hosted MCP server runs, and both pass the same shared test cases, so a verdict reads the same in Snowflake, Claude or any other client.
- —Nothing here is a live measurement of the network. The model knows how a place usually behaves, hour by hour, from a frozen data vintage named in every answer.
What stays in your account
- —The app reads only its own forecast data, shared from KASPR inside the package. It never reads your tables.
- —Every computation runs in your account on your warehouse. The app makes no outbound network calls and requests no external access integration.
- —The places and times you send, and the verdicts, are kept only in the app’s own state tables in your account, for the per-user limits and the last explanation. KASPR does not see them.
- —Answers carry bands, times and a sentence: no measurements, no area identifiers, no observation counts.
During the private preview
There is no charge and no cap on the number of timing calls during the preview; each user can look up to 50 distinct places a day. Usage is recorded per user in your account from day one, so you can see what a usage-based plan would mean before one exists.
All procedures and both MCP servers · timing calls uncapped · 50 distinct places per user per day · installed by private listing
Through Snowflake Marketplace, billed by Snowflake · pricing to be announced before the preview ends
Questions
- How is this different from the MCP?
- Same verdicts, same wording, same decision code. The Native App runs inside your Snowflake account, so you can call it from SQL and tasks, and nothing you send leaves your account. The hosted MCP suits agents and clients outside Snowflake.
- Does any of my data leave my account?
- No. The app has no outbound network access. What you send and the verdicts it returns stay in the app’s own tables in your account.
- Which warehouse does it use?
- The caller’s. An X-Small warehouse is enough; a timing call takes a few seconds of it.
- Is this live network conditions?
- No. Verdicts come from KASPR’s typical week for each place, projected onto the hours ahead, and say so in their own words (“usually”, “typically”).
- Why did it say nothing?
- Because nothing was materially better. The timing procedures speak only when a steadier hour exists inside your window and the hours you allow, and never block the time you proposed.
- When will it be on Snowflake Marketplace?
- After the private preview. Until then we share it with your account directly; ask through the contact page.