---
title: "Billing and plans for pipeline runs"
description: "How TIR bills a pipeline run by the minute on its CPU or GPU plan, what is free, and how to keep the cost down."
content_type: "concept"
product: "pipelines"
platform: "TIR"
url: "/tir/pipelines/concepts/billing-and-plans/"
---

# Billing and plans for pipeline runs

A pipeline run is billed for the time its steps run, on the plan you chose for the run. For the
price of each plan, see [E2E's pricing page](https://www.e2enetworks.com/pricing).

## What is billed

- Each step is billed by the minute at the plan's hourly price, from when its container starts until
  it ends. Time a step spends waiting to start is free. The start and the end each round up to the
  next full minute.
- A run has one plan. You choose a single plan when you create the run, and every step is billed at
  that plan's price, even when a step needs only a CPU. Steps that run at the same time are each
  billed, and the run's charge is their total.
- Each run a schedule starts is billed on its own, from its own duration and the plan you chose.
- Data you keep in object storage is billed under object storage pricing, separately from the run.

Pipelines, versions, and experiments themselves are free. You pay
for a schedule only through the runs it starts.

## Plans

A plan is a CPU configuration, shown as vCPUs and RAM, or a GPU configuration, shown as GPU count,
vCPUs, and RAM. The run form lists them under **Select Computing Resource** on the **GPU** and
**CPU** tabs, and you can pick any plan that has free capacity. When you create a run on an
hourly plan from a prepaid account, you need credit for about 24 hours of the plan's hourly price. A
postpaid account skips this credit check.

## Keeping the cost down

- Use a CPU plan for data preparation, file transfers, evaluation, and steps that only coordinate
  other steps, and a GPU plan for training and fine-tuning. Because a run has one plan, you can
  split work into separate runs when the steps need different plans.
- Retry a failed run instead of starting a new one, so the steps that already finished are skipped.
- Break a large pipeline into smaller steps, so that only a failed step needs to run again.
- Store intermediate results in an object storage bucket, so a retry after a later failure can
  reuse them.
- Turn off or delete schedules you have finished with.
- Delete runs, versions, and pipelines once their work is done.