# Models and usage

> Which model Buff Code gets, who chooses it, how usage is counted and where the organisation’s billing shows it — per developer device.

## Where the model comes from

Buff Code works on **your organisation’s models**. The administrator decides which model answers —
in the [model choice](/en/docs/tariffs#openrouter-own-choice-of-model), in the
**“Task development”** row, and on dedicated capacity — on its card: this is the same model the
platform uses to formulate, develop and check tasks. If nothing is chosen — our default model for
the plan.

For the organisation’s models there are no provider keys on the developer’s machine. The request goes through
the [connector gateway](/en/docs/buff-code/gateway) to Buff and from there to the model according to the
[organisation’s plan](/en/docs/tariffs): on OpenRouter plans — to a third-party provider; on
dedicated capacity and in a custom setup — to a dedicated machine, and nothing goes to third-party
providers; the connector neither reads nor stores the request.

In Buff Code the models are shown under the **Buff** provider: the `/models` command in the interface, `buff models`
in the console. The name they appear under depends on the plan: a model the organisation chose itself is shown
under its own name, and a model we picked — under the plan name, for example
“OpenRouter (balanced models)”. With an old connector (before v0.16.0) you see just
`buff` instead of the name. Alongside, you can connect your own provider or a local model (see
[Own providers and local models](/en/docs/buff-code/own-providers)). Turns on them bypass Buff
and do not count towards the organisation’s usage.

## How usage is counted

Every model turn — one Buff Code request and the answer — is charged to the organisation’s plan, like
the platform’s work: by the tokens the model itself reported — at the provider on OpenRouter plans or on the dedicated
machine (input, output, reasoning, cache).
The project is the one chosen in the [working context](/en/docs/buff-code/sign-in): usage is charged to it.

A failed turn (a model refusal, a dropped connection, a refusal due to the balance) is recorded but not charged.

If the balance runs short, Buff Code gets a clear refusal rather than silence from the model;
an answer already started can take the balance slightly below zero — the difference is covered by the next top-up.

## Where usage is shown

- **In Buff Code itself**: the organisation’s balance — in the line under the input field (in the console — on the main
  screen); “Balance and spending” (`/balance` in the console) — the runway in days, the plan and prices per million
  tokens, the estimate for this session in roubles and your usage by day. When funds are low or have
  run out, a bar with an action appears above the input field. The session estimate is computed from the plan’s
  prices; the exact charge is in the workspace. Requires company connector v0.18.0 or newer. See
  [Balance and usage](/en/docs/buff-code/work/session#balance-and-usage).
- **The organisation’s billing history**: the row is labelled **“Buff Code · device name”**, next to it —
  the project. The **“Source”** filter picks only Buff Code or only the platform’s work.
- **[Development sessions](/en/docs/buff-code/sessions/view)**: for each session — tokens by type,
  model working time and how much was charged; totals for the chosen period, project and developer.
- **In Buff Code itself** — `buff stats` shows the local statistics of this machine; it is
  computed from Buff Code’s data and has nothing to do with billing.

## Limitations

- The organisation’s model is one for all developers: you cannot switch it for a single person.
  A developer connects their own provider themselves (see [Own providers](/en/docs/buff-code/own-providers)).
- The developer chooses the reasoning level (`/variants`) — within what the model supports.
- Turns on a developer’s own providers do not reach Buff: they are absent from billing and development sessions,
  and in a mixed session only the Buff turns are counted.