Skip to main content
Hexel bills for active compute. Understanding your usage helps you optimize cost and catch unexpected spend early — for example, spotting a runaway sandbox that’s been executing in a loop. Hexel Studio bills based on the compute your workloads consume. Usage is recorded per environment and available through the API, the CLI, and the Console.

​
Billing units

​
Reading a usage record

If your usage summary shows:
This means: one standard sandbox ran for 1 hour (3600 compute_cpu_second). The default sandbox TTL is 3600 seconds — an unreleased sandbox bills for its full TTL even if idle. Idle agents cost very little (capacity is throttled rather than torn down), so you primarily pay for active processing.

​
Check your usage

For current pricing, see the Console billing section and the pricing page. Rates are not duplicated here so the docs stay accurate over time.

​
Cost optimization

Billing follows active compute, so the levers are the work you run and the capacity you hold:
  • Release sandboxes promptly. A sandbox bills until it’s released or its TTL expires; don’t hold idle sandboxes.
  • Right-size tiers. Run on the smallest tier (metrics confirm headroom) rather than over-provisioning.
  • Prefer serverless/fluid fleets for spiky traffic. Reserve always_on capacity only for latency-critical workloads.
  • Attribute by environment. Separate environments make it clear which workloads drive spend.

​
Common mistakes

  • Leaving sandboxes allocated. Release sandboxes when done; renewing keeps them billable.
  • Not attributing usage per environment. Use separate environments to see where cost comes from.

​
Best practices

  • Review usage regularly in the Console or with the usage API.
  • Release sandboxes promptly and right-size instance tiers.
  • Separate environments to attribute and forecast cost.

Tiers & Limits

Tier capacities and account limits.

Scaling

How capacity affects cost.

Metrics

Relate performance to usage.

Sandboxes

Release to stop billing.