Skip to main content
Automations

Credit Consumption and Refunds

Written By Christopher Scaminaci

Last updated 8 days ago

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

ActivityBilled?How
Automation runs (on-demand, scheduled, webhook)YesReservation up front, reconciled to actual usage when the run ends
Builder test-chat turnsYesEach test message is its own run, billed like any run
Automation wizard chat turnsYesSmall per-turn reservation, reconciled to the actual cost of the turn
AI-assist suggestions (name, description, system prompt)YesSmall flat reservation, reconciled to actual
Token counting in the builderNoFree for everyone
URL preview when adding a knowledge sourceNoFree (no AI call is made)
Runs started by StackJack staff on your behalfNoCredits consumed = 0
Any of the above with your own Anthropic key on fileNo creditsRuns, builder turns and AI Assist suggestions all bill your Anthropic account
Fast decisions — a decision step inside a run, or a smart filter on a webhook triggerNot todayThese call a different AI service from the one that runs your automations. StackJack currently covers every one of them, while recording each call. See below.
Smart tool search and tool suggestionsNo, everA platform cost by decision. They never draw your credits and never use your own key.

Fast decisions are a separate lane, deliberately

A decision step and a smart filter ask TypeSafe AI for a short typed judgement. That is a different vendor from the one that runs your automations, so it is billed separately from everything in the table above and never folds into a run's own credit total.

  • Today StackJack pays for them. Every call is recorded from the day the feature shipped, and nothing recorded before charging is switched on is ever billed to you.
  • If charging is switched on later, a decision call costs a small flat number of credits per call — not per token — and it appears in credit history on its own line naming how many calls it covers. A run's own credit total, its per-run ceiling and its refund rules are unchanged by it.
  • A decision call made on your own TypeSafe key is never billed by StackJack, and your key is never used for anything else. See Fast Decisions and Your Own TypeSafe Key.
  • Your own Anthropic key does not cover fast decisions. Different vendor, different key. Having one on file changes nothing here.
  • A refused decision costs you nothing. If the feature is off, your organization has not turned it on, the request was malformed or no key was usable, the step is recorded as skipped and no charge can arise from it.

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.

On the ordinary monitor path, StackJack attempts a final Anthropic usage read when the run ends and settles that result against the reservation. Interruption and recovery paths can have to reconcile from the best persisted counters when the final provider read is unavailable. While a run is active, the Portal's usage and credit figures are partial; a just-terminalized or recovered run can briefly await the idempotent final settlement. The per-run detail page identifies the final StackJack ledger charge once settlement completes and separately re-prices token anatomy using the automation's current model and today's rates.

The reservation model

Every metered run follows a reserve-then-reconcile cycle. The reservation must fit the current balance before work begins, while final reconciliation still settles the best final usage StackJack can obtain if the estimate was low:

  1. 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.
  2. Refuse cleanly if short. If your balance can't cover the reservation, the run is recorded as CreditExhausted with the required and available amounts in its error message. Nothing is charged.
  3. Meter during the run. Usage is tracked live. If it reaches the per-run cap, the run is stopped at once and ends as CreditExhausted; the agent is not asked to wrap up first, and its session is shut down.
  4. 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 and reconciliation appears as a separate line in your credit transaction history. The ledger retains the run id for agent-run entries, although the current Recent transactions table shows the transaction description rather than a clickable run link.

The per-run cap is a hard ceiling

For StackJack-managed execution, the max credits per run guardrail (settable per automation, 0.01–500 credits, default 50) is strict. BYOK runs skip StackJack credit metering and this guardrail entirely:

  • Mid-run, reaching the cap stops the run at once as CreditExhausted, with no wrap-up turn.
  • 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

SituationWhat happens to your credits
Insufficient balance at startNothing charged; run recorded as CreditExhausted for visibility
Run fails during startup (before the agent does any work)Full reservation refunded
Missing platform Anthropic configuration prevents the run from startingStackJack attempts to refund the full reservation and remove the synthetic run row so the outage does not look like a customer-caused execution. If either cleanup step fails, operators receive the original service error plus cleanup diagnostics; use the credit ledger as the billing authority.
You stop (interrupt) a runBilled 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-flightBilled for actual (clamped) usage; unused remainder refunded
Service crash strands a tenant run for the first timeStackJack stops and confirms the old session, then gives the same run id one fresh execution attempt. A StackJack-managed run reuses its original reservation instead of placing a second hold. If the old session cannot be confirmed stopped, the run remains parked and cleanup retries later; uncertain stop confirmation does not make it Failed.
The accepted recovery attempt is stranded again, or the automation is no longer runnableThe run ends as Failed; actual usage is settled and the unused StackJack-managed reservation is refunded. Staff diagnostic runs are not replayed and go directly to terminal cleanup.
A run pauses for approval and nobody answersAfter 60 minutes cleanup stop-confirms the provider session. A confirmed stop ends the run as Failed; actual usage is billed and the rest of the reservation is refunded. If confirmation is uncertain, the run stays AwaitingInput and settlement waits while cleanup retries.
Terminal settlement is revisited after a crashFinalization is keyed to the run and is idempotent, so recovery can safely retry without applying the same settlement twice.
Wizard turn's AI call failsFull refund of that turn's reservation
Wizard turn answers, but settling it is interruptedThe turn is settled later for what it actually cost, not refunded — the answer was produced and paid for. A turn whose answer never arrived is still refunded in full.
You close the builder tab mid-answerThe answer finishes and is charged at its real cost. You will not see that answer, because the tab is gone, and no further message or tool test is started for it. Reloading the page within about fifteen minutes collects that answer instead of charging for a new one.
Three StackJack-billed builder requests are already running for your organizationThe fourth wizard message or AI Assist suggestion on StackJack credits is not started and nothing is reserved or charged. Send it again when one of the three finishes. Requests on your own Anthropic key are not counted and not limited.

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. New StackJack-managed runs are refused whenever the available balance cannot cover their full reservation. BYOK execution has no StackJack reservation and is not blocked by the StackJack credit balance.

You can clear this yourself — no support ticket needed. The tenant owner can buy a credit pack from the Credits tab exactly as normal; the purchase settles the outstanding debt first. New StackJack-managed runs become eligible only when the remaining balance covers the full reservation that the next run requests—not merely when the balance becomes positive. A run already refused as CreditExhausted is terminal and does not resume after a purchase; trigger a new run when the balance is sufficient.

Where to see balances and history

Your credit balance, your most recent transactions (the latest 20), 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. Agent-run entries are keyed to their run in the ledger; wizard turns and field suggestions use their own turn identifiers. For a customer-visible run total, use Billed on the run detail page.

On a recovered run, the run detail page reports the automatic-restart count and says that the original hold was reused. Read that note together with the run's reservation/refund/finalize entries: for StackJack-managed credits, recovery creates no second reservation and finalization is idempotent per run id.

That single-StackJack-bill guarantee does not apply to BYOK. BYOK bypasses the StackJack credit ledger, and the stranded attempt and replacement attempt may both have generated usage billed directly by Anthropic. Recovery is also a fresh execution, not a continuation: connector-side effects completed before the interruption can be repeated. Operations that must happen only once need vendor-side idempotency or deduplication, and you should inspect vendor state before manually running the payload again.

Still need help? Ask the team