How Credits and Operation Costs Work

Geobble uses credits to pay for operations that consume platform compute, AI, data processing, generated artefacts, exports, and stored data.

Your available balance is shown in Billing.

Some operations have a fixed or predictable cost. Others depend on the amount of data, the requested analysis, or AI usage. Where an operation supports estimation, Geobble can calculate the expected credit cost before you run it.

The basic model is:

Credit balance
      ↓
Operation requested
      ↓
Estimate or preflight
      ↓
Credits reserved where required
      ↓
Operation runs
      ↓
Actual cost settled

Credits and storage are related, but they are not the same thing: credits are the unit of account; storage is one of the things that consumes them.

What uses credits?

Geobble currently uses credits for categories including:

• AI-assisted work;

• spatial analysis;

• mobility analysis;

• file ingestion;

• persistent data artefact generation;

• interactive map-tile generation;

• Source exports;

• storage rental.

Not every interaction in Geobble has a separate visible credit charge.

For example, ordinary navigation or viewing a resource is not the same as running a paid data operation.

The relevant question is:

Is Geobble performing billable compute, AI, data generation, or storage on behalf of this account?

Where to see your credit balance

Open your account's Billing settings.

The Billing page shows information including:

• current credit balance;

• monthly plan allowance;

• current plan;

• which account is responsible for credit charges;

• stored data;

• current estimated daily storage cost;

• storage runway.

This is the main place to answer:

How many credits do I currently have?

and:

How quickly is my stored data consuming them?

Credits can come from different grants

Your displayed balance can contain credits from several sources.

Depending on the account and plan, these can include:

• monthly plan credits;

• signup credits;

• promotional credits;

• purchased credit packs;

• administratively granted credits.

The displayed balance combines the spendable credits that are currently valid.

You normally do not need to decide which grant an operation should consume.

Geobble manages that automatically.

Some credits expire

Different credit grants can have different validity periods.

Under the current credit model:

• monthly plan credits expire after three calendar months;

• signup and promotional credits expire after three calendar months;

• purchased credit packs expire after twelve calendar months;

• recurring administrative grants have their own validity period;

• ordinary administrative credits do not expire by default.

Geobble consumes valid credits starting with those that expire soonest.

Conceptually:

Credits expiring sooner
        ↓ used first

Credits expiring later
        ↓

Non-expiring credits
        ↓ used later

You therefore do not need to manually choose which credits to spend first.

One displayed credit is the user-facing unit

Internally, Geobble calculates costs at finer precision than one whole displayed credit.

This allows proportional pricing for workloads such as:

• storage;

• feature-based spatial computation;

• AI usage.

A non-zero amount below one full credit can therefore appear as:

<1 credit

rather than being treated as free.

The internal precision is an implementation detail; the user-facing unit remains the credit.

Fixed, usage-based, and workload-based costs

Not all operations are priced the same way.

A useful distinction is:

Fixed-cost operation
Usage-based operation
Workload-based operation
Ongoing storage cost

Fixed or configured operation costs

Some operations use a configured fixed credit cost.

Examples in the current cost model include:

• file ingestion;

• map-tile generation;

• persistent data artefact generation;

• Source export.

The exact current values are platform pricing settings rather than something you should infer from the size of the button or the duration of the operation.

Use the current Pricing/Billing information when you need the current tariff.

AI is usage based

AI-assisted work does not have one universal cost per message.

Its credit usage depends on the AI usage associated with the operation, including the applicable model and usage category.

That means:

short request

and:

large multi-step AI-assisted workflow

should not necessarily be expected to consume the same amount.

Credits pay for the measured AI usage rather than a flat “one prompt = one credit” rule.

Spatial analysis is workload based

Ordinary spatial analysis can depend on:

• whether the operation is analytical or produces persistent data;

• how many features are involved;

• the geometry family involved.

For example, an operation over:

1,000 points

can have a different workload from an operation over:

100,000 complex polygons

even if both are described conversationally as:

Intersect these datasets.

Geobble therefore uses workload information rather than treating every spatial operation as identical.

Saving data can cost more than inspecting a result

There is an important distinction between:

analysis / preview

and:

persistent output

A temporary analytical result may require computation without creating a durable data artefact.

A materialised result may require:

• computation;

• persistent Source data;

• generated artefacts;

• ongoing storage.

So:

Show me the result.

and:

Save this result as reusable data.

can have different cost implications.

How an operation estimate works

For operations that support estimation, Geobble calculates the expected cost from the current request before execution.

For example, Studio mobility analysis provides an explicit:

Estimate

action.

After estimation, the interface shows the expected credit amount before Run becomes available.

The sequence is:

Configure analysis
      ↓
Estimate
      ↓
Review credit cost
      ↓
Run

This gives you an opportunity to change the workload before starting it.

An estimate depends on the current request

If you change the analysis after calculating its estimate, the old estimate should not be treated as the cost of the new request.

For example, changing:

15-minute contour

to:

15, 30, 45 and 60-minute contours

changes the workload.

Likewise, changing:

100 origins

to:

500 origins

can change the expected cost.

Review the estimate for the actual operation you intend to run.

Estimated cost is not always identical to final settlement

For prepaid or estimated work, Geobble uses a reservation model.

Conceptually:

Balance: 100 credits

Operation estimate: 12
        ↓
12 credits reserved
        ↓
operation executes
        ↓
reservation settled

The reservation protects both sides of the operation:

• Geobble knows that the expected workload can be paid for;

• your account does not accidentally spend the same credits on another simultaneous operation.

A reservation is not necessarily the same thing as the final charge.

What happens after execution?

Depending on the operation, Geobble can:

• settle the reserved amount;

• settle a measured amount;

• refund unused reserved credits;

• settle zero when work is cancelled or fails before the paid execution stage;

• require additional credits when measured work legitimately exceeds the original reservation and the workflow supports increasing it.

The exact behaviour depends on the operation.

The practical rule is:

Treat the displayed estimate as the expected cost of the configured operation, not as a promise that every failure mode will have identical settlement behaviour.

What happens if you do not have enough credits?

Before billable work begins, Geobble checks whether the responsible billing account can cover the required amount.

If not, the operation can be blocked with an insufficient-credits error.

Conceptually:

Available: 8 credits
Required: 12 credits
        ↓
Operation cannot proceed

This is preferable to starting expensive work that cannot be completed.

Go to Billing to review the balance and, where available, add credits or change the relevant plan.

Mobility analysis costs

Provider-backed mobility analysis uses workload estimates before execution.

Current durable mobility operations include:

• route;

• reachability;

• nearest destination;

• travel metrics;

• map matching.

The workload varies by operation.

Route

A route has a comparatively simple declared tariff.

The current customer tariff is:

1 credit

for a route operation.

Map matching

Map matching currently uses the same:

1 credit

customer tariff.

Reachability contours

Contour reachability depends on:

• number of requested contours;

• number of origins.

The current pricing rule is:

1
+ number of contours
+ ceil(number of origins / 5)

credits.

For example:

1 origin
2 contours

would have a workload calculation of:

1 + 2 + ceil(1 / 5)
= 4 credits

Nearest and travel metrics

These operations depend substantially on the number of source-to-target pairs.

Their current rule is:

1 + ceil(source-target pairs / 1,000)

credits.

Suppose you compare:

100 origins
×
20 destinations

That creates:

2,000 pairs

and therefore a declared workload tariff of:

1 + ceil(2,000 / 1,000)
= 3 credits

This is why adding many origins and destinations can change an estimate significantly.

H3 reachability

H3 travel-time surfaces depend on:

• contour count;

• grid workload;

• reference-point workload.

The current tariff uses:

2
+ contour count
+ ceil(cell-reference pairs / 1,000)

credits.

Increasing the map extent or requested grid detail can increase the number of cells and therefore the estimated workload.

Use Estimate rather than trying to predict a complex H3 analysis from visual map size alone.

Preview does not universally mean free

Do not interpret:

Preview

as:

Free

Provider-backed mobility previews can still require paid computation.

Preview describes the lifecycle of the output—temporary rather than durable—not necessarily whether compute was required.

This distinction matters.

Spatial analysis costs outside mobility

Geobble's ordinary spatial-analysis tariff is designed around workload rather than provider request count.

The cost contains:

• a base amount;

• an additional feature-based amount.

The current platform model distinguishes:

• analytical work;

• persisted/materialised work.

And the per-feature workload varies by geometry family:

points
lines
polygons
unknown/mixed geometry

Polygon workloads have a higher configured feature rate than points because their processing cost can be greater.

For persisted operations, settlement can consider the greater of the relevant input and output feature workloads.

The implication is practical:

A spatial operation that creates a very large derived dataset can cost more than an operation over a small result, even when the operation name is the same.

File ingestion uses credits

Uploading a supported GIS file involves more than transferring bytes.

Geobble can need to:

• inspect the geographic dataset;

• ingest its layers;

• normalise data;

• generate a managed representation;

• create supporting persistent artefacts.

File ingestion therefore participates in the credit model.

For multi-layer datasets, the workload can involve more than one layer.

See How to Create a Source from a Supported GIS File.

Failed processing is not automatically charged as successful processing

The ingestion workflow uses reservations and settlement.

When file ingestion fails after a reservation has been established, the current processing path can settle that unsuccessful reservation at zero rather than charging it as a successfully completed ingestion.

PostGIS imports use similar reservation behaviour: failed imports release the reserved processing cost rather than treating the failed import as successful work.

See Why a Source Failed to Process.

Exports can consume credits

Generating a Source export can involve platform processing and creation of an export artefact.

Export is therefore part of the configured operation-cost model.

For example, exporting a Source as:

GeoJSON
GeoPackage
Shapefile
CSV

can require a billable export-generation operation.

Downloading an already available object and generating a new export are not necessarily the same workload.

Generated map and data artefacts can consume credits

Geobble creates optimised artefacts to support operations such as:

• persistent geographic data;

• interactive map delivery.

The current pricing model includes configured costs for:

• persistent data artefact generation;

• PMTiles/map-tile generation.

These costs are separate from the ongoing storage consumed by those artefacts after they exist.

Think of:

Generation cost
       +
Storage over time

rather than assuming a one-time generation cost permanently covers storage.

How storage consumes credits

Stored data has an ongoing rental cost.

The current storage model is based on:

amount of stored data
×
storage rate per GB-day

Storage is billed daily.

That means two accounts holding different amounts of data can have different ongoing credit consumption even if neither runs a new analysis that day.

Billing shows your daily storage cost

The Billing page displays:

Stored

the amount of data currently attributed to the account;

Daily cost

the current calculated storage-credit cost per day;

Runway

approximately how many full days the current credit balance can sustain the current storage usage.

For example:

Balance
÷
current daily storage cost
≈
storage runway

Runway is an estimate based on the current balance and current storage usage.

If either changes, the runway changes.

More stored data can reduce your runway

Suppose:

Current balance: 100 credits
Storage: 2 GB

and later you:

• upload several large Sources;

• materialise analytical outputs;

• create derived data;

• generate additional persistent artefacts.

Your storage usage can increase.

Even if your credit balance has not yet changed significantly from operations, the daily storage burn can increase and reduce the displayed runway.

References do not necessarily duplicate storage

Adding an existing Source to Project context is conceptually different from creating a deep copy of its data.

Metadata-only references that continue to point to an existing resource do not create another billable storage copy merely because you referenced the resource from another Project.

By contrast, operations such as:

• uploads;

• imports;

• materialised results;

• deep copies;

• generated exports;

• stored derived Sources;

can create additional stored data.

That distinction is useful when deciding whether a result really needs to become another persistent dataset.

What happens when credits cannot cover storage?

Storage has its own account lifecycle.

The normal state is:

ACTIVE

If the account cannot cover the required storage rental, it can move to:

READONLY

In read-only mode:

• existing data remains readable;

• uploads and storage-changing modifications are blocked.

This protects existing data while preventing the unpaid storage footprint from continuing to grow through new writes.

The Billing page displays a warning when storage is not active.

Restoring a read-only account

A read-only storage account can return to active status when its balance is sufficient to cover at least one day of its current storage usage.

In practice:

1. open Billing;

2. inspect the balance and daily storage cost;

3. add sufficient credits where available;

4. recheck the storage status.

Reducing unnecessary stored data can also improve future runway where deletion is appropriate and permitted.

Direct and inherited credit billing

A resource can belong to one account while its credit costs are charged to another account under an inherited billing configuration.

The Billing page therefore shows:

• the account's credit billing mode;

• the billing account that is actually charged.

The two modes are:

DIRECT

and:

INHERITED

Direct billing

With Direct billing:

Resource-owning account
        ↓
its own credit balance is charged

This is the straightforward case.

Inherited billing

With Inherited billing, the resource-owning account can use the credit balance of its configured owning account.

Conceptually:

Resource belongs to Account B
        ↓
billing mode = INHERITED
        ↓
Account A is the charge account

This is particularly important when working across account or organisation structures.

Do not assume that the handle in the current browser URL is necessarily the balance that will be charged.

Check Billing account on the Billing page.

Your plan and your credit balance are related but different

A subscription plan can provide a monthly credit allowance.

The plan describes the account's subscription entitlement.

The credit balance is the amount currently available for credit-consuming work.

For example:

Plan:
Pro

Monthly allowance:
X credits

Current balance:
Y credits

Y can differ from the monthly allowance because:

• credits were already spent;

• valid credits from previous periods remain;

• credits were purchased;

• a promotion or administrative grant was added;

• some grants expired.

Do not interpret:

My plan includes 100 credits per month.

as:

My current balance must always equal 100.

The Billing page displays the actual balance.

Monthly allowance is not the same as monthly reset

Credits are issued as grants rather than simply overwriting the balance with a fixed number every month.

A new monthly allowance can therefore coexist with still-valid earlier grants.

At the same time, those grants have their own expiry rules.

Conceptually:

Month 1 grant
    +
unused valid amount
    +
Month 2 grant
    +
purchased credits
    -
operations
    -
expired credits
    =
current balance

This ledger approach is why your balance can be higher or lower than one month's included allowance.

Buying credits

Where the current account and subscription permit it, Billing includes a Buy Credits section.

Purchased credit packs are added to the spendable balance.

Purchased credits currently expire after twelve calendar months.

The checkout/payment layer and the Geobble credit ledger perform different jobs:

Purchase completed
      ↓
credit grant added
      ↓
Geobble balance becomes spendable

The Geobble credit ledger remains the source used to determine whether an operation is allowed to run.

Why a cost can change when the request changes

Suppose you estimate:

Nearest hospital

50 settlements
10 hospitals

and then change the input to:

500 settlements
100 hospitals

You have changed the pair workload from:

50 × 10 = 500

to:

500 × 100 = 50,000

The operation label is still:

Nearest destination.

But the workload is radically different.

This is why operation names alone are not enough to predict every cost.

Reducing unnecessary credit usage

Optimise the work, not merely the number of clicks.

Useful approaches include:

Use appropriate input data

Do not run a national-scale operation when you only need one region.

Filter before expensive analysis when appropriate

If only operational facilities are relevant, avoid computing over closed and irrelevant records merely to filter them afterwards.

Preview before materialising when the workflow supports it

Use temporary output to verify:

• inputs;

• scope;

• thresholds;

• settings;

before creating durable data.

Remember that a provider-backed preview can itself have a compute cost.

Avoid unnecessary persistent copies

If a Source can simply be referenced from another Project, do not create a deep copy merely for organisational convenience.

Delete genuinely obsolete stored artefacts when appropriate

Persistent data continues to contribute to storage usage until it is removed according to the relevant storage lifecycle.

Do not delete resources that remain needed for reproducibility simply to minimise costs. Data governance should still come first.

Estimate before expensive work

When the interface provides an estimate, use it.

A good sequence is:

Choose inputs
      ↓
set parameters
      ↓
estimate
      ↓
review cost
      ↓
review analytical assumptions
      ↓
run

A cost estimate is useful not only for budgeting.

A surprisingly large estimate can also reveal a configuration problem.

For example:

Why does this nearest-destination analysis contain millions of pairs?

may reveal that you selected a national Source instead of the intended regional subset.

Credits do not replace analytical review

A paid operation can still be wrong.

Paying for:

• a buffer;

• an accessibility analysis;

• an AI-assisted operation;

• a data import;

does not make the result authoritative.

Always review the result according to its intended use.

See What to Do When an AI-Assisted Result Looks Wrong.

Example: mobility analysis

Suppose you want travel times from:

100 settlements

to:

20 hospitals

The workflow is:

Configure

Choose:

• Travel metrics;

• settlement Source;

• hospital Source;

• transport profile;

• Preview or Save as data.

Estimate

Geobble determines the relevant workload:

100 × 20
=
2,000 source-target pairs

Review

Check both:

• whether 2,000 pairs are genuinely intended;

• the displayed credit estimate.

Run

Credits are reserved and the analysis executes.

Save if appropriate

If you choose durable output, the result can become persistent data and contribute to storage.

This shows how:

analysis cost

and:

storage cost

can both apply to one workflow at different stages.

Example: uploading a Source

Suppose you upload a GeoPackage.

The workflow can involve:

Upload transfer
      ↓
file ingestion
      ↓
managed Source
      ↓
persistent artefacts
      ↓
ongoing storage

The ingestion operation and ongoing storage are separate cost concepts.

If the file contains multiple layers, ingestion may need to process those layers separately.

If processing fails, consult Why a Source Failed to Process rather than repeatedly paying attention only to the upload progress indicator.

Example: current storage runway

Suppose Billing shows:

Credit balance:
250 credits

Daily storage cost:
5 credits

Runway:
50 days

This does not mean your balance will definitely last exactly 50 days.

Additional operations can consume credits.

New uploads can increase the daily storage cost.

Deleting stored data can reduce it.

New credit grants can increase the balance.

Runway answers:

At the current balance and current storage usage, approximately how many full days of storage can this balance sustain?

Quick checklist

Before a billable operation

• I selected the intended data.

• The geographic scope is appropriate.

• I understand whether the output is temporary or persistent.

• I checked the displayed estimate where one is available.

• I know which account will be charged.

• The available balance is sufficient.

When reviewing an estimate

• The feature count or pair count makes sense.

• I did not accidentally select a much larger Source.

• Distances, contours, resolution, or other workload parameters are intentional.

• I understand that changing the request can invalidate the estimate.

• I understand that an estimate and final settlement are related but not universally identical.

For storage

• I know how much data is currently stored.

• I checked the daily storage cost.

• I checked the current runway.

• I understand that persistent Sources and derived results can increase storage.

• I understand that simple references do not necessarily create duplicate billable storage.

• I will respond to a low balance before storage becomes read-only.

For account billing

• I checked whether billing is Direct or Inherited.

• I know which account's balance is actually being charged.

• I distinguish my current balance from my plan's monthly allowance.

• I understand that different credit grants can expire at different times.