Skip to main content
Use this guide to understand what drives your Wherobots bill and how to keep costs low — particularly when you’re getting started, testing queries, or evaluating the platform.

How Wherobots billing works

Wherobots charges based on Spatial Units (SUs) consumed over time. The main factors in Spatial Unit consumption are:
  1. Runtime size — Larger runtimes consume more Spatial Units per hour.
  2. Runtime duration — The longer a runtime stays active, the more you pay.
  3. Runtime region — Some regions have different Spatial Unit rates.
Billing starts when a runtime is fully provisioned (shown as Status: Running with a green dot 🟢 icon in the UI) and stops when the runtime is destroyed. Charges are prorated to a fraction of a second.
Key takeawaySmaller runtime + shorter session = lower bill. You have direct control over both.Choose your runtime size intentionally and always destroy Notebook Runtimes when you’re done.
For more details on Spatial Units and how runtimes are priced, see How is runtime usage measured?.
If you use the Wherobots VS Code Extension with GitHub Copilot, AI-assisted features like notebook generation and MCP server queries may count toward your GitHub Copilot usage. Check your GitHub Copilot subscription for any usage limits or metering that may apply.

Cost management strategies

The following strategies will help you manage costs, especially during the early stages of exploration and development.

Start with a Tiny or Micro runtime

When you’re exploring Wherobots for the first time — writing queries, testing workflows, or confirming that your logic is correct — use the smallest runtime available: These runtimes are sufficient for developing and validating queries against sample data or smaller datasets. Only scale up to a larger runtime (Small, Medium, etc.) once you’ve confirmed that your query logic is correct and you need faster execution on larger datasets.
Every Organization Edition has access to the full range of runtime sizes, except during a Professional Edition trial without a payment method. In that case, you can use Tiny, Micro, and Small General Purpose runtimes, with a 100-CPU quota. Adding a payment method unlocks the full range and raises the quota to 500 CPUs. See Add a Payment Method.

Destroy Notebook Runtimes when you’re done

A running Notebook Runtime consumes Spatial Units even if you’re not actively using it. This is the most common source of unexpected charges. To avoid surprises, always destroy Notebook Runtimes when you’re done with them:
  1. Go to the Code page in Wherobots Cloud.
  2. In the Notebook Runtimes list, click Destroy (the trash icon) next to any Notebook Runtime you no longer need.
Idle Notebook Runtimes still cost moneyWhile Wherobots has an idle timeout (defaulting to 45 minutes), you are still charged for minimum resources while the Notebook Runtime is idle. Always destroy Notebook Runtimes you’re not using to fully stop billing.

Use idle timeout as a safety net, not a strategy

Wherobots lets you configure an idle timeout (15, 45, or 120 minutes) that reduces resource consumption when a Notebook Runtime sits unused. However:
  • Idle timeout does not destroy the Notebook Runtime — it reduces but does not eliminate charges.
  • Treat idle timeout as a safety net for those times when you forget to clean up, not as your primary cost-control measure.

Monitor your usage

Use the Usage History page to see the Spatial Units each Notebook Runtime, Job Run, and SQL Session consumed, find usage spikes and long-running sessions, and review each Job Run’s resource consumption. For the filters, columns, and Job Run details, see Usage History.

Scale up only when needed

Follow this progression as you move from testing to production:
If a Tiny runtime isn’t delivering results fast enough, move up one size at a time rather than jumping to a large runtime.

Quick-reference checklist

Use this checklist to keep costs under control:
  • Start small — Use Micro or Tiny runtimes during initial testing.
  • Validate first — Confirm your query logic on a small runtime before scaling up.
  • Destroy when done — Destroy Notebook Runtimes as soon as you’re finished.
  • Review usage — Check the Usage History page regularly.
  • Scale intentionally — Only increase runtime size when you have a clear performance need.
Don’t forget to clean up: Leaving a runtime idle will incur costs — even if you stop working after 15 minutes.To avoid unexpected charges, always destroy Notebook Runtimes when you’re done.