Credits
ShapeDiver provides an infrastructure service for anyone working with Grasshopper, from individual computational designers to large organizations. As such, it's important to us to provide you with a fair and transparent pricing system that scales with your usage and needs.
We use a combination of subscription plans and usage-based credits to achieve this. Each plan unlocks
a certain set of features,
a number of seats,
a number of credits that can be used within each calendar month
This guide will first introduce our credit system and how you can manage your usage and cost, and then provide detailed insights into the different actions that consume your account's credits.
This page describes the method for credit counting we introduced in early 2025. If you first subscribed to your plan earlier than that, your credits might be counted using our legacy counting method. You can find out which method applied to you on your billing dashboard.
Overview of Credits and Credit Accounts
When you or others work with your ShapeDiver account, credits are consumed for actions like computing the solution of a Grasshopper model for a set of parameters, generating a file export, or downloading an AR scene.
You can review and manage your credit consumption on the billing page in your dashboard on the ShapeDiver platform. This page includes information about the credits available to you and how many have already been used.
Prepaid Credits
Every ShapeDiver plan includes a number of credits that are available for consumption within a given calendar month. If you are researching which plan to purchase, you can find this number in the description of the different plans on our pricing page. If you are already a user, you can find the number of prepaid credits available to you on your billing page.
The available credits are reset at the beginning of every month, and unused credits are not carried over to subsequent months.
Excess Credits
If your prepaid credits are used up before the end of a given month, you can continue using your account by allowing us to charge you for any credits in excess of the amount included in your plan. These credits are called excess credits, and we'll send you an invoice for the amount you have used at the end of each month.
To avoid costly surprises, you can limit the amount of excess monthly credits your account consumes. You can set this limit on your billing page to
zero (no excess credits)
any positive number, or
unlimited.
Account Blocking
Once your account reaches the limit of available credits and no further credits can be consumed in the current month, we will pause access to your parametric models until new credits become available.
This can happen
when you have used up your prepaid credits and have set your excess credit limit to zero or
when you have reached the excess credit limit you configured.
When you have run out of credits, you will not be able to access your models, but you will retain access to your account. You can perform various management tasks like downloading your Grasshopper models, deleting models, or managing account settings. But you won't be able to view or compute any solutions for your models on the platform, in any embedded solution, or through our APIs.
To reactivate all of your models, you can choose to
increase your excess credit limit on your billing page
upgrade to a plan with a higher number of prepaid credits or
wait for the end of the current calendar month.
If you are a member of an organization's account on ShapeDiver, only the organization's owners or administrators can make these changes.
Credit Usage Notifications
We know that many of our customers run critical applications based on our services, and we will always strive to help you avoid negative surprises regarding finances or availability.
To do so, we will send you email and in-platform notifications when your credit use reaches certain thresholds in any given month.
These include at the moment:
Notifications when 50%, 90% and 100% of your prepaid credits have been used up. These include detailed information on what happens if your prepaid credits run out.
Notifications when 50%, 90% and 100% of your excess credits have been used up, should you have configured a limit.
Consuming Credits
Counting Modes
We designed the consumption of credits on our platform to scale with resource usage as well as possible. To adjust to our customers' diverse usage patterns, we've created two basic modes:
Browser Mode and General Mode
Both will be explained in detail later, but let's start with the motivation and fundamentals for each of them:
Browser Mode is primarily designed for end-user applications running in a browser, though it can also be used in other situations. Its goal is to allow customers to release public-facing applications without the concern of unexpected costs caused by malicious actors or bots.
In Browser Mode, credits are mainly charged for 10-minute intervals during which a user interacts with a model. Short computations within this period are not charged individually unless they produce file exports. Usage in Browser Mode is rate-limited in a way that ensures a seamless experience for human users while discouraging batch computing or similar tasks that require numerous Output Requests in rapid succession.
General Mode is designed to provide maximum flexibility and performance for applications of any kind. In General Mode, we charge credits for every request sent to our servers. The amount of credits charged for a request depends mainly on the time our servers require to compute the result. In this mode, our servers will aim to answer all requests as quickly as possible without applying rate limiting, except to safeguard the stability and performance of our systems.
Terminology
Credit charges are triggered by various actions on our servers. Some are treated differently depending on the modes we just covered in the previous section. Before we look at the individual modes in detail, here's a list of actions that can trigger credit charges:
Output Requests: This type of request asks our servers to return the outputs of a ShapeDiver model for a specific set of parameters. Outputs are typically either geometry or materials used to display geometric objects in a viewer and attributes and meta-data of a limited size. Output Requests will be answered from our cache if the particular result has already been computed before, and they will trigger a computation on our geometry workers if this is not the case.
Export Requests: These requests call for the return of a specific export defined in a ShapeDiver model. Exports can be everything from CAD files to images, PDFs, or binary data. As for Output Requests, a computation will be triggered if the requested content is not available in our cache.
Combined Requests: In some situations, requesting outputs and exports for a set of parameters is more efficient through a single call. A Combined Request is an Output Request that also identifies one or several exports that should be computed and returned.
Computations: Whenever data unavailable in our cache is requested, the necessary parameters are dispatched to one of our geometry workers to compute it. This worker will then run this computation and store all requested data in our cache. Once this is done, we answer the request as quickly as possible. The amount of time our workers require to complete this task is called computation time. It includes the time used by Grasshopper’s solver and the time to read the results from Grasshopper and serialize them into files.
Opening a session using an "Embedding Ticket": This is done with a specific request to our API, which creates a session with a unique ID. Sessions have a lifetime of a maximum of one hour but can be closed earlier on request. When you use our ShapeDiver Viewer on its own, as part of App Builder, or one of our SDKs, these API requests are handled for you.
Sessions are charged in 10-minute chunks. Opening a new session always starts one 10-minute chunk. If the session continues after the first chunk, our servers look for additional requests coming in. Once the first request outside the initial 10-minute chunk comes in, another chunk is started. This means that a browser tab that remains idle for hours because a user did not close it will not create additional credit charges until the user engages with it again.
AR Requests: The ShapeDiver platform and APIs allow you to download the 3D outputs of a ShapeDiver model as an asset for use in the native AR viewers of various mobile devices.
Model Loading: To deliver fast responses to your requests, we keep ShapeDiver models loaded on a number of geometry workers in parallel. We decide the number of workers on which a particular model remains loaded based on demand patterns, your type of plan, and several other considerations. This means that we have to open and load models from time to time on workers when we expect increased traffic for those particular models. Loading time includes opening the Grasshopper model, parsing it as far as this is necessary, and precompiling scripts. For some models, especially when they contain large numbers of components or many scripts, this process takes longer than to compute a solution.
Credit Counting
Event | Browser Mode | General Mode | Notes |
|---|---|---|---|
Creating a session | 1 | 0 | |
Output Request | 0 | 1 | |
Export or Combined Request | 1 | 1 | |
Computation < 10 seconds | 0 | 0 | |
Computation >= 10 seconds | 1 per complete 10-second chunk | 1 per complete 10-second chunk | Examples: 22 seconds: 2 credits 44 seconds: 4 credits |
Download of cached results for an Output- Export of Combined Request | 0 | 0 | |
AR Request | 1 | 1 | |
Model Loading | 1 per begun 10-second chunk | 1 per begun 10-second chunk | Examples: 8 seconds: 1 credit |
Examples
Let’s look at some realistic examples of using the ShapeDiver infrastructure.
Case 1: A user opens a website with an embedded ShapeDiver viewer
Activity | Credit Cost |
|---|---|
User opens the website, the ShapeDiver viewer is loaded and initalizes a session | 1 credit |
25 Output Requests that trigger computations below 10 seconds (for example, parameter changes in a viewer) | 0 credits for the requests |
One Output Request that triggers a computation of 22 seconds | 0 credits for the request
|
Five Output Requests for which the results are cached and delivered without a computation | 0 credits |
1 export of a PDF file that triggers a computation of 7 seconds | 1 credit for the export request |
After 5 minutes, the user stops working with the model but leaves the browser window open | 0 credits |
One hour later the user comes back and sends five more Output Requests that trigger computations below 10 seconds | 1 credit for beginning a new 10-minute chunk |
User closes the browser tab | 0 credits |
Total Credit Consumption | 5 credits |
Case 2: Batch Computing
Activity | Credit Cost |
|---|---|
| 500 credits for the requests |
Based on the results of the Output Requests, the script chooses 75 parameter sets. For these parameters, 75 export requests are made to compute one PDF file per request. | 75 credits for the export requests |
Total Credit Consumption | 1445 credits |
Three hours later, a colleague mistakenly calls the exact same script again. Now, all results are already cached. | 500 credits for the compute requests |
Total Credit Consumption | 575 credits |
Credit Analytics
Check out the documentation of our analytics dashboard to learn how to track your use of credits throughout each month.