> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kerne.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overrides

> When one customer needs different terms

Sooner or later someone negotiates something your catalog doesn't sell. A yearly contract with a limit nobody else gets. A loaner machine while theirs is repaired. A month of goodwill after an outage you caused.

The tempting move is to create a plan for them. Don't — you'd be adding a product line to solve a conversation, and you'd carry it forever.

An **override** is that deal, attached to one customer, outside your catalog. Every check that already exists in your code starts returning the right answer for them, and nothing changes for anyone else.

## Two different things, easy to confuse

Ask which one you mean before reaching for either:

|                      | What it changes                                     | How long                                                        |
| -------------------- | --------------------------------------------------- | --------------------------------------------------------------- |
| **Override**         | The **limit** — "this customer has a 1,000/mo deal" | Renews every period like the plan's own limit, until it expires |
| **Usage adjustment** | The **counter** — "credit them 500 units back"      | Once                                                            |

An override is a standing arrangement. An adjustment is a correction. Giving someone a one-time refund by raising their limit means quietly raising it every month forever.

```typescript theme={"system"}
// A standing deal
await kerne.admin.grant('api_calls', {
  customer: userId,
  value: '50000',
  reason: 'Annual contract - negotiated limit',
  expiresAt: '2027-01-01T00:00:00.000Z', // omit for permanent
});

// A one-time credit
await kerne.admin.adjustUsage('api_calls', { customer: userId, delta: -5000 });
```

## Whole customer, or one counter

Without a dimension, an override covers the customer: on a feature counted per machine or per project, every counter gets that limit of its own.

With one, only that counter moves. The two stack, **most specific first** — a counter uses its own override if it has one, the customer's otherwise, the plan's if neither exists.

So "every machine to 3h, except this one at 5h" is two overrides, not a list of every machine.

<Note>
  Naming a dimension only does something when the plan limits that feature per dimension. Under a
  shared pool the override still saves but never resolves — you can't carve a private allowance out of
  a pool by naming one machine.
</Note>

## What an override does not touch

* **What happens past the limit.** Block, tolerate, or charge for the excess is always read from the plan's own entitlement. An override moves the number, not the behavior.
* **Periods, resets and rollover.** Only the limit itself.

Expired overrides stay in the list rather than disappearing, so you keep the audit trail of what was promised to whom. A check result carries `has_override` when one applied.

## Next

<CardGroup cols={2}>
  <Card title="Handle customer exceptions" icon="user-pen" href="/guides/billing/customer-exceptions">
    The practical walkthrough, with the common cases.
  </Card>

  <Card title="Overrides reference" icon="code" href="/sdks/server/admin/overrides">
    `grant` / `listGrants` / `revokeGrant`, every option.
  </Card>
</CardGroup>