Understanding execution credits
An execution credit represents one node-minute of execution on the Standard compute class: the amount of time a node takes to run. Each node execution consumes credits, whether you run it manually while building a workflow or when it runs automatically in production. Arranging and configuring nodes on the canvas without running them doesn't consume credits.
For example, a workflow with 11 nodes, each taking one minute to run on Standard, consumes 11 credits per execution.
Execution compute classes
Every workflow runs in a compute class. The compute class sets how much compute power and memory a workflow gets, and the multiplier applied to its execution time. Choose Light for orchestration and waiting on other systems, and Performance for heavy processing such as machine learning. More compute only speeds up workflows that can use it.
You set the compute class individually for each workflow. Standard is the default.
Available compute classes:
| Compute class | Multiplier | When to use it | Example |
|---|---|---|---|
| Light | 0.6x | Orchestration, API calls, small data, linear workflows, and workflows that mostly wait on external systems. | A workflow that pushes its transformations to a database such as Snowflake, or calls REST services. |
| Standard | 1x | Balanced compute for most workflows. This is the default. | A typical data preparation, blending, and reporting workflow. |
| Performance | 1.6x | Heavy processing, machine learning, large data, and workflows with many parallel branches. | Training a machine learning model, such as a random forest, on a large dataset. |
Sovereign environments use the same compute classes, but you set the class per environment. See Sovereign execution credits.
How parallelism is used
A higher compute class can run more nodes at the same time. Some nodes, such as multithreaded nodes, can also use more compute power at once and finish faster as a result.
- Light: Nodes run one at a time, in order. Parallel branches run one after the other.
- Standard and Performance: Knime first runs as many ready nodes in parallel as the class allows. It then gives any remaining compute power to nodes that can use it.
Nodes that wait, such as the Wait... node or nodes waiting for an external service, don't block other nodes. Other nodes can run in the meantime.
Many workflows don't benefit from more parallelism, for example workflows whose nodes run one after the other on a single thread, or workflows that mostly wait on external systems. For these workflows, Light runs about as fast at a lower price.
Memory limits
All nodes running at the same time share the memory of the compute class. In managed environments, this includes external processes, such as Python and R. In sovereign environments, the class limits only the Java heap of the executor. See Compute classes for sovereign execution.
A node that needs more memory than is available can slow down, or it can fail. If this happens, select a higher compute class.
How credits are calculated
Credits consumed = execution minutes × multiplier of the compute class
The following rules define execution time:
- Execution time is wall-clock time, measured in milliseconds, from the moment a node starts until it finishes or fails. For example, a node that runs for 10 seconds on Light consumes 0.1 credits.
- A node is billed once for its execution time, regardless of how much compute power it uses.
- Nodes that run in parallel are each billed for their own execution time.
The following examples show how credits add up:
| Example | Calculation | Credits consumed |
|---|---|---|
| One node runs for 1 minute on Light | 1 min × 0.6 | 0.6 |
| One multithreaded node runs for 1 minute on Standard | 1 min × 1.0 | 1 |
| Three nodes run in parallel on Performance, 1 minute each | 3 × 1 min × 1.6 | 4.8 |
What is and isn't billed
The following rules answer common billing questions:
- Queued nodes: A node isn't billed while it waits in the queue to start.
- Failed nodes: A node that fails is billed up to the moment it fails. If a node fails because it runs out of memory, select a higher compute class.
- Repeated runs: With the same input data and compute class, a workflow generally consumes a similar number of credits. Some variation is expected, for example because of database or API response times.
Waiting for data
- Waiting for external data (for example, a file from a third party) doesn't have to consume credits. Design the workflow to start only once the data has arrived. For example, trigger it when a file is dropped, have the external process call Knime directly, or schedule the run for when the data is ready. Avoid using a Wait node in production: it's intended for debugging and testing, not for production workflows.
- Waiting on in-database processing (for example, a step pushed to Snowflake or Databricks) does consume credits. The workflow is still orchestrating that step as part of your pipeline. If cost is a concern and the workflow isn't time-sensitive, run it in the Light compute class.
Exceptions to the multiplier
Some nodes in Knime are primarily used to delay workflow execution or delegate execution to another workflow. Here, an exception applies regarding execution time: A reduced multiplier of 0.1 is applied to their execution time, regardless of compute class.
This reduced multiplier applies to the following nodes:
All other nodes are billed for their full execution time. For example, a Wait... node that takes one minute to run consumes 0.1 credits per execution.
Execution bands
Execution bands are your annual credit allowance: You commit to an execution band with a fixed number of execution credits at a fixed price at the start of your subscription period. Choose the band that fits your team's needs. There are up to 10 predefined bands, plus custom bands for consumption beyond that — your Knime account team can help you estimate usage and choose the right one.
An execution band is an allowance, not a stockpile of credits you receive. You can use up to the band's limit, but unused credits don't roll over or get refunded, similar to a mobile data plan or a car rental's kilometer package.
You can upgrade your band at any time by contacting your Knime account team — not only at renewal.
Understanding AI credits
We measure AI consumption in AI credits which are measured from the number of tokens used by the underlying LLMs, plus a service fee. One AI credit refers to 10,000 input tokens or 1,667 output tokens. Token usage translates into AI credit bands, each with its own price.
Similar to execution bands, you choose an annual AI capacity band which is your annual credit allowance for AI usage.
If you bring your own model, you pay your AI provider for tokens directly, and pay Knime a reduced service fee (0.17 credits) instead of the standard AI credit rate.
What happens if you reach your band limit
Track your consumption on the Usage & billing page under Global administration. See Track your usage.
If your usage goes above your band, Knime doesn't stop your work right away. Knime reserves the right to slow down execution and limit AI requests, and eventually to suspend them.
To return to normal, upgrade to the next band by contacting your Knime account team. You can do this at any time, even while execution is suspended.
Sovereign execution credits
Sovereign environments use the same compute classes and multipliers as managed environments, and credits are calculated the same way. Two things differ:
- You set the compute class per environment, not per workflow. To run workflows in different classes, create one environment per class.
- Each sovereign environment has a yearly fee, in addition to credit consumption. The fee doesn't depend on how many executors are connected to the environment.
For the memory and threads of each class, and how to choose a class for an environment, see Compute classes for sovereign execution.