# When AI Pauses

When Insulin refuses a request for a billing reason, it says which of four reasons applies,
because each has a different fix. A generic "billing problem" would send everyone to support.

The reason appears as a banner at the top of **Settings → Billing**, and in the conversation
itself if you were chatting when it happened.

![The billing banner reading "AI features are paused — your credit has run out", with the line "Add credit to resume. Stored files and running sandboxes are unaffected."](images/billing-paused-banner.png)

---

## The four reasons

| Banner | Why | How it resolves |
|---|---|---|
| **This organization is suspended** | An administrative hold placed by Suger | Contact [support@suger.io](mailto:support@suger.io) |
| **Monthly spending limit reached** | The month's spend hit the limit **you** set | Raise or remove the limit on the same page |
| **AI features are paused — your credit has run out** | Pay as you go, and the balance reached zero | Add credit |
| **All billable features are paused — your account has reached its debt limit** | The balance fell past the negative floor set for the account | Add credit; contact support if you need the floor changed |

They are evaluated in that order, and you are told about the first that applies. Telling
someone their credit ran out when they are actually suspended would send them to top up an
account that will still refuse them.

```d2
direction: down
classes: {
  q: { shape: diamond; width: 250 }
  stop: { width: 230; style.border-radius: 8 }
  ok: { width: 230; style.border-radius: 8 }
}
susp: "Suspended by Suger?" { class: q }
limit: "Month's spend at\nyour own limit?" { class: q }
model: "Monthly billing?" { class: q }
floor: "Balance past the\ndebt limit?" { class: q }
zero: "Balance at or\nbelow zero?" { class: q }

s1: "AI, new sandboxes and\nuploads paused\nContact support" { class: stop }
s2: "AI paused\nRaise or remove the limit" { class: stop }
s3: "AI, new sandboxes and\nuploads paused\nAdd credit" { class: stop }
s4: "AI paused\nAdd credit" { class: stop }
run: "Requests run" { class: ok }

susp -> s1: yes
susp -> limit: no
limit -> s2: yes
limit -> model: no
model -> run: "yes — never blocked\nfor balance"
model -> floor: no
floor -> s3: yes
floor -> zero: no
zero -> s4: yes
zero -> run: no
```

**Monthly billing is never stopped for a balance.** The invoice comes after the usage, so a
negative balance is the normal state of an invoiced account between invoices. It can still be
stopped by a suspension or by your own spending limit.

## What keeps working

This is the part people ask about first, and the answer is deliberate: **losing access to your
own work over a few cents is not an acceptable billing outcome, and paying afterwards would
not give back the hours you could not work.**

| | Credit exhausted / limit reached | Past the debt limit |
|---|---|---|
| Reading, listing and searching your stored files | Works | Works |
| Running sandboxes | Keep running | Keep running |
| Starting, stopping, connecting to an existing sandbox | Works | Works |
| **AI requests** | Paused | Paused |
| **Creating a new sandbox** | Works | Paused |
| **Uploading new files** | Works | Paused |

**No data is deleted in any of these states.** A running sandbox is never killed to collect a
debt.

The difference between the two columns is the whole point of having two states: an exhausted
balance is a soft stop that leaves you able to keep working with what you already have, and
the debt limit is the hard stop that also prevents new capacity being reserved.

## What happens to a request in flight

- **A request that has not started** is refused before the model is called, and answered in
  the conversation with the reason and what to do about it.
- **A long response already streaming** is checked every ten seconds and cut off where the
  text stops, with the same explanation, once the balance is known to have run out. A deep
  research run or a multi-tool agent loop can otherwise spend far more than the balance it was
  allowed against. The check reads a decision that is held for up to a minute, so a response
  can run briefly past zero before it stops.
- **If the check itself cannot be answered**, the response is allowed to finish rather than
  truncated. Consumption is metered either way, and losing an answer someone is waiting on is
  the worse failure.

## Resuming

Service resumes **automatically** — there is nothing to switch back on and no operator to
wait for.

| Cause | Fix | Back within |
|---|---|---|
| Credit exhausted | Add credit | About a minute of the credit landing |
| Debt limit | Add credit | About a minute of the credit landing |
| Your monthly limit | Raise or remove it on **Settings → Billing** | About a minute |
| Suspension | Suger lifts it — a successful payment does not clear it on its own | Immediately after |

If you are relying on **automatic top-up** to add that credit, allow a little longer: the
top-up itself runs every five minutes, and the minute above starts once it has been charged.

The short delay is the spend check re-reading your account; it holds its answer for up to a
minute so that a busy conversation is not re-checked on every message.

:::warning
**Adding credit does not clear your own spending limit.** If the banner names the *monthly
spending limit*, topping up changes nothing — the limit is compared against what you have
spent this month, not against your balance. Raise or remove the limit instead.
:::

## Being told before it happens

The **Credit balance** card is the reliable early warning, and the in-app assistant can take
you straight to **Settings → Billing** if you ask it about spend.

If you would rather not watch it, turn on
[automatic top-up](/insulin/billing/spend-controls/#turn-on-automatic-top-up): it charges a
saved payment method once the balance is at or below a trigger you choose, so the balance
never reaches zero in the first place.