Credit Consumption and Refunds
Automations are billed in credits. Credits abstract the underlying AI token and runtime costs into simple dollar amounts: today, 1 credit corresponds to $0.10 of usage. That conversion is set by StackJack and may be adjusted; your portal always shows authoritative balances and per-run costs.
If your tenant uses BYOK (your own Anthropic API key), runs are billed by Anthropic directly and consume no credits — see BYOK and automations.
What consumes credits
| Activity | Billed? | How |
|---|---|---|
| Automation runs (on-demand, scheduled, webhook) | Yes | Reservation up front, reconciled to actual usage when the run ends |
| Builder test-chat turns | Yes | Each test message is its own run, billed like any run |
| Automation wizard chat turns | Yes | Small per-turn reservation, reconciled to the actual cost of the turn |
| AI-assist suggestions (name, description, system prompt) | Yes | Small flat reservation, reconciled to actual |
| Token counting in the builder | No | Free for everyone |
| URL preview when adding a knowledge source | No | Free (no AI call is made) |
| Runs started by StackJack staff on your behalf | No | Credits consumed = 0 |
| Any of the above on a BYOK tenant | No credits | Runs bill your Anthropic account; builder features are absorbed by StackJack |
What drives the cost of a run
A run's credit cost is computed from two components:
- Tokens — input, output, cache-read, and cache-write tokens, at rates that depend on the model the automation uses. Larger models cost more per token; cache reads are heavily discounted relative to fresh input.
- Active compute time — a small charge proportional to the model's actual working time (active seconds), not wall-clock time.
Final usage figures are fetched authoritatively from Anthropic when the run ends, so what you're billed matches what actually ran. The per-run cost breakdown is visible on each run's detail page.
The reservation model
StackJack never lets a run silently overdraw your balance. Every metered run follows a reserve-then-reconcile cycle:
- Reserve. Before the run starts, credits are reserved atomically: the lesser of a runtime-based estimate (derived from the automation's model and runtime cap) and the automation's max credits per run setting.
- Refuse cleanly if short. If your balance can't cover the reservation, the run is recorded as
CreditExhaustedwith the required and available amounts in its error message. Nothing is charged. - Meter during the run. Usage is tracked live. If it reaches the per-run cap, the agent gets a "wrap up and summarize" message and the run ends as
CreditExhausted. - Reconcile at the end. The actual cost is compared to the reservation:
- Used less than reserved → the difference is refunded (you'll see a Refund transaction).
- Used more than reserved → the difference is deducted as an additional finalize transaction.
Every reservation, refund, and finalize appears as a separate line in your credit transaction history, linked to the run.
The per-run cap is a hard ceiling
The max credits per run guardrail (settable per automation, 0.01–500 credits, default 50) is strict:
- Mid-run, reaching the cap ends the run as
CreditExhaustedafter the wrap-up message. - At reconciliation, any raw usage above the cap is clamped — the excess is absorbed by StackJack, never billed to you.
The runtime guardrail works the same way for time: max runtime is settable per automation between 30 and 3,600 seconds (default 300). See Guardrails and safety controls.
Refund policy by failure type
| Situation | What happens to your credits |
|---|---|
| Insufficient balance at start | Nothing charged; run recorded as CreditExhausted for visibility |
| Run fails during startup (before the agent does any work) | Full reservation refunded |
| Platform outage prevents the run from starting | Full refund, and the run row is removed entirely so your history isn't polluted with failures you couldn't cause |
| You stop (interrupt) a run | Billed for actual usage up to the stop; the unused remainder of the reservation is refunded |
| Run fails, times out, or hits the credit cap mid-flight | Billed for actual (clamped) usage; unused remainder refunded |
| Service crash strands a run | The run is automatically recovered — marked Failed and its reservation refunded, typically within minutes |
| A refund itself is lost to a crash | Retried automatically (refunds are idempotent — you can never be refunded twice for one run) |
| Wizard turn's AI call fails | Full refund of that turn's reservation |
Negative balances (credit debt)
Reconciliation records the true cost even when a run under-reserved — which can push a balance slightly negative in rare cases. A negative balance blocks all further metered runs until it is resolved. If you see this, contact StackJack support; the block clears as soon as the balance is adjusted or topped up.
Where to see balances and history
Your credit balance, full transaction history, and available credit packs are shown on the Credits tab of the Automations area in the portal. Only the tenant owner can purchase credit packs. Every automation-related transaction carries the run it belongs to, so costs are always attributable.