Models and usage

Where the model comes from

Buff Code works on your organisation’s models. The administrator decides which model answers — in the model choice, 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 to Buff and from there to the model according to the organisation’s plan: 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). 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: 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.
• 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: 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).
• 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.