The cheapest credit problem is the one you configure away before it happens. This is the setup checklist — what to turn on, and in what order, when you stand up a tenant or take over an account.

Most credit surprises are not caused by AI being expensive. They are caused by a tenant running for weeks with no model policy, no per-user ceiling, and nobody watching the dashboard — until the 100% email arrives. Every control described below is available today and takes minutes to set. The work is doing it up front rather than after the first spike.

This guide is written for MSP admins who log in through admin.hatz.ai. Tenant and workspace admins can apply most of the same controls inside their own organization.

The short version

Work through these in order. Steps 1–3 take a single sitting; steps 4–7 are what keep the tenant predictable after go-live.

Know the number. Confirm the tenant's monthly credit allowance, when it resets, and whether Extra Usage should be on.
Turn on visibility. Take a usage baseline in the first two weeks, and set a review cadence.
Set the model policy. Default model, disabled models, Auto on with the modes you want allowed.
Set the limits. Role credit limits for the groups that need a ceiling, and an Extra Usage cap for the tenant.
Know which alerts reach you — and which ones only reach the end user.
Publish a usage policy so users build efficient habits from day one.
Bake it into a tenant template so the next tenant starts configured instead of getting configured after the first surprise.

Step 1: Start with the number

Each tenant has a monthly credit allowance that is shared across all of its users and AI features. It resets at the start of each calendar month, and unused credits generally do not roll over unless your agreement says otherwise.

Monthly usage is measured on a calendar-month boundary in UTC. When you reconcile end-of-month usage, compare it using UTC dates so the boundary lines up with what the platform counted.

Before a rollout, confirm two things for every tenant:

The package allotment. Open Admin > Tenants, select the tenant, and review the Overview page. To review package options, use the 3-dot actions menu and select Upgrade Package. If you do not see that menu, your admin role does not include billing permissions — ask your primary admin. Partners billed through a distributor arrange upgrades through that distributor.
Whether Extra Usage should be enabled, and at what cap. This is a deliberate choice per tenant, not a default. A tenant without Extra Usage hits a hard stop at its allowance. A tenant with Extra Usage keeps working past it and bills for the difference. Decide which behavior each client should get before they get it by accident.

Step 2: Turn on visibility before you need it

The most common cause of a credit surprise is that nobody looked until the email arrived. Know where the numbers live before you need them in a hurry.

Where to look

MSP Admin Dashboard (admin.hatz.ai > Dashboard) — all of your tenants at once, filtered by date range and tenant. Includes the credit usage trend (Usage, Credit In and Out, Breakdown, and Phone tabs), Power Users and Power Builders, active users and workflow runs, an hourly usage heat map, Top Models, and the Workshop leaderboard.
Tenant Overview (Admin > Tenants > select tenant > Overview) — that tenant's total credit usage for the current billing period, its usage trends, and its top five users by consumption.
Tenant Users page (Admin > Tenants > select tenant > Users) — credits used by each individual user, in the Credits used column.
Workspace Usage page (Workspace > Usage, inside the tenant) — the view a tenant admin sees for their own organization: usage by source, top models, top users and builders, top apps, workflows, and agents, a heat map, and run counts.
CSV export — from the Download menu on the Admin Dashboard, with selectable fields, for anything you want to track outside the platform.
Usage API — for programmatic reporting into your own dashboard or PSA. See the Hatz API documentation.

Take a baseline in the first two weeks

A number is only useful if you know what normal looks like. In the first two weeks after a rollout, record:

Typical weekly credit consumption for the tenant
Who the top five users are, and roughly how far ahead of the median they sit
Which models actually appear in Top Models
Which apps, workflows, and agents are running, and how often

Then watch for the three patterns that precede almost every spike: one user pulling far ahead of the rest, an automation running more often than anyone intended, and a high-multiplier model showing up in Top Models for work that does not need it.

Set a recurring reminder to review — weekly during a rollout, monthly once usage settles.

On reading the numbers: current-period usage figures are near-live, while charts and leaderboards refresh periodically and can trail by up to about an hour. Recent activity typically appears within about 15 minutes. If two views disagree, confirm they are using the same tenant, billing period, date range, time zone, and feature scope before treating it as a billing issue.

Step 3: Set the model policy

Model choice drives per-message cost more than any other single factor. Every model carries a multiplier that tells you how credit-intensive it is relative to the industry flagship model at 1x — a model at 0.5x uses roughly half the credits per message, one at 2x roughly double. Setting policy is more reliable than hoping every user checks the multiplier before they pick.

There are three controls, and they work together.

Default LLM. The model that opens first in Chat and defaults into each Workshop step. Set it for all tenants at Admin > Settings > Global Settings, or for one tenant at Admin > Tenants > select tenant > Organization Settings. Tenant admins set their own at Workspace > Org Settings.
Disabled LLMs. Remove models your users do not need. You can disable a single model, every model from one developer, or any mix. Same two locations as the default model.
Auto model selection and allowed modes. Turn Auto on and choose which modes are permitted: Lite (fast and lightweight), Performance (balanced, the usual default), and Turbo (maximum capability for hard work). Auto evaluates every message and routes it to a model suited to that specific request, so users stop paying premium rates for simple questions. There is no extra credit charge for using Auto.

How the layers stack

Policy flows MSP global → tenant → custom role, and each layer can only narrow the one above it. A role can remove access to a model, but it can never re-enable a model that the MSP, tenant, package, or provider policy has disabled. Auto respects all of it — if a model is disabled, Auto will never route to it and silently picks the next best available option instead.

A reasonable starting policy

Enable Auto and allow Lite and Performance for general staff. Add Turbo for the specific roles whose work genuinely needs it.
Disable high-multiplier models for tenants and roles with no use for them. A team running on Lite by policy costs a fraction of an unrestricted deployment.
Check the multiplier before you whitelist anything expensive. Hover a model in the picker for its multiplier, or open View all models and switch to the Multipliers tab for a sortable table. Watch for the Promo badge — Hatz occasionally runs promotional pricing, and the displayed number always reflects the current rate.

Step 4: Put the limits in before you need them

There are two independent ceilings: one on each user, and one on the tenant. They do not know about each other. A user can be stopped by their role limit while the tenant still has credits, and a tenant can be limited even though no individual user reached their own cap.

Per-user ceilings: custom role credit limits

A custom role can carry an optional monthly credit limit that caps how many credits each assigned user can consume during the calendar month. Limits are configured on custom roles only — if you need a ceiling for a group on a built-in role, create a custom role for them.
What happens at the limit depends on the tenant. Where credit-limit enforcement is active — today the default for tenants on a credit-limited package or an active trial — a user who reaches their role limit is not cut off. They are moved onto Auto Lite and keep working against a tenant-shared reserve of efficient-model capacity. Only once that reserve is used up for the month are their credit-consuming requests refused. On tenants without that enforcement, reaching the limit blocks new credit-consuming actions outright.
Either way, the user sees an in-product message telling them to contact an administrator, and long-running operations may stop if they hit the limit mid-run.
That reserve is shared across the whole tenant, not held per user. If several users reach their caps in the same month they all draw on the same pool, so the first to arrive degrades gracefully and later ones can be refused sooner. Treat it as a grace window, not as headroom you can plan against.
Setting a role limit to zero prevents users on that role from using credit-consuming actions at all.
Every user on a role shares that role's limit. Split groups into separate roles when they need different ceilings.
Roles without a credit limit are not capped by the role. Those users are still subject to the tenant's allowance and any other applicable limits.
After you change a limit, review current usage in the users and roles views so you know whether assigned users are already close to the new number.

Pair the cap with a mode restriction. A cap is a backstop, not a brake — it does nothing about what a user spends on the way to it. Restricting the Auto modes available to that role — keeping a high-volume team on lower-credit modes — and disabling higher-multiplier models they do not need is what actually lowers everyday burn. Use both together.

In beta: weekly caps and configurable limit actions. An expanded version of role limits is being tested with a small group of partners. It adds a separate weekly cap alongside the monthly one, resetting every Wednesday at 12:00 PM Eastern, and lets you choose what happens when a cap is reached — Block (new requests do not start until reset; work already running finishes) or Auto only (the user is switched to the lower-cost Auto modes you allow rather than being cut off; usage still bills normally, since this is a model restriction and not a discount). It also adds a Request more path so a user who has used 80% or more of a cap can ask an admin for an increase, and a panel in the account menu where users can see their standing and exact reset time. Weekly Credit Usage Limits covers the tester experience in full.

This is not yet available to customer tenants generally — betas run with a limited group of partners before shipping broadly. If you want to be considered, read What is the Hatz Beta Testing Program and How to get into a beta, or talk to your Hatz account team. Until it reaches you, the monthly role limit described above is the control that is live.

Per-tenant ceiling: the Extra Usage cap

Extra Usage lets an eligible organization keep working beyond its monthly allowance, up to a monthly cap you set. Usage stops automatically when the cap is reached, and the cap resets alongside the regular allowance at the start of each calendar month.
To enable it: log in to admin.hatz.ai, open the Tenants tab, find the tenant, select the Not enabled button to its right, enter the dollar amount or number of credits you want as the ceiling, and select Confirm.
To view consumption or change the cap later, use the gear icon on the Tenants tab. Changes take effect immediately.
If you do not see an Extra Usage column for your tenants, it is not available to your organization — contact your Hatz account team.
For eligible usage-based billing accounts, Extra Usage is billed at the end of the billing period and charged automatically to the MSP's default payment method. Keep that payment method current.

Set the cap at a number you would approve without needing a conversation. That is the entire point of setting one.

Step 5: Know which alerts actually reach you

Alerting is not uniform across the three controls. Know which ones email you and which ones only ever appear in front of the end user.

Tenant monthly allowance — email to admins. At 75%, a heads-up with no restrictions yet. At 100%, the allowance is reached and limited overage behavior may apply depending on plan and configuration. Once any overage capacity is exhausted, AI usage may be limited or suspended until access is restored.
Extra Usage cap — email to admins. At 80% and 95% of the cap, usage warnings. At 100%, the cap is reached, extra credits are no longer available for the rest of the month, and the tenant is rate limited unless you raise the cap.
Role credit limits — in-app for the user, email for admins on most tenants. The user is notified in-product at 80%, 95%, and 100% of their limit, as a percentage rather than a credit count. Where credit-limit enforcement is active — again, the default for tenants on a credit-limited package or an active trial — MSP admins and the tenant's client admins are also emailed at those thresholds. That email names the specific user who crossed, so one person reaching their cap does not read as the whole tenant being at its limit. On older tenants without that enforcement, the notification is in-app only and no email is sent.

Do not treat alerting as coverage on its own. Which of these you actually receive depends on how the tenant is configured, and a per-user email identifies one person rather than describing the tenant's overall position. The dashboard review from step 2 is what shows you a pattern building across a tenant — several users trending toward their caps, or one automation driving the trend. A single cap notice will not tell you that.

Users on a role with a limit policy can check their own standing — credits used, their limit, percentage, and reset time — from the account menu at the top right. Users on a role with no policy set will not see that panel.

Step 6: Publish a usage policy for your users

Controls cap the damage. Habits prevent it. The goal is not to have people use AI less — it is to make sure that when credits are spent, they are earning their keep. These five behaviors do most of the work:

Default to Auto on Lite. Escalate to Performance or Turbo for the task that genuinely warrants it, then drop back down. Auto routes per message, so there is no need to start a new chat to change tiers.
Start a new chat for a new topic. Every message in a thread carries the full history as input, so a long conversation pays for irrelevant context on every turn.
Keep files and context tight. Upload the relevant pages, not the whole document. Paste the relevant excerpt, not the whole thread.
Enable subagents so specialized work is delegated to lighter, purpose-built models instead of loading everything onto the primary model.
Turn recurring prompts into Apps, Agents, or Workflows. Anything a person retypes every week is automation waiting to happen — cheaper, more consistent, and faster than rebuilding context each time.

Rather than writing your own version of this, hand users the end-user guide — it covers the same ground in their language, with troubleshooting for unexpected burn.

Step 7: Make it the default for the next tenant

Once a tenant is configured the way you want it, use Tenant Templates to reuse those roles and settings when you provision the next one. That way each new tenant starts with your model policy and role limits already in place, instead of being configured after its first surprise.

If you do nothing: the reactive path

It is worth knowing what the unmanaged outcome looks like, because it is recoverable but disruptive.

The tenant reaches 100% of its monthly allowance. Hatz may provide limited additional capacity for efficient AI usage, depending on plan and configuration. Requests route to lower-credit models, and users may notice that more credit-intensive models become unavailable in the model selector.
That additional capacity is exhausted. AI usage may be limited or suspended for the organization until access is restored. Platform login and the Admin Dashboard generally remain accessible while AI features are limited.
To restore access: upgrade the package (increases the allowance and takes effect immediately), enable or raise Extra Usage if it is available for the organization, or wait for the monthly reset on the 1st.

For the client, that period is an outage of their AI. It also arrives with no warning for anyone who was not watching — which is the case the steps above are designed to prevent.

Quick reference: where each control lives

Package allotment and upgrades — Admin > Tenants > select tenant > Overview > 3-dot menu > Upgrade Package (requires billing permissions)
All tenants' usage, plus CSV export — admin.hatz.ai > Dashboard
One tenant's usage and top users — Admin > Tenants > select tenant > Overview
Credits used per individual user — Admin > Tenants > select tenant > Users
A tenant admin's own usage view — Workspace > Usage
Default model and disabled models, all tenants — Admin > Settings > Global Settings
Default model and disabled models, one tenant — Admin > Tenants > select tenant > Organization Settings
Auto policy and allowed Auto modes — set by admins at MSP and tenant level; see Auto Model Selection for what each mode does
Role credit limits and role model restrictions — custom role settings, under Users, Roles & Permissions
Extra Usage on/off and monthly cap — admin.hatz.ai > Tenants tab (gear icon on the tenant row)
Model multipliers — model picker tooltip, or View all models > Multipliers tab

When to contact support

Most high-usage questions can be narrowed down from the usage views first. Contact support when the reports do not match a specific request or workflow run, when a user or tenant appears limited despite available credits, or when you cannot reconcile a spike after checking users, models, workflows, files, tools, API activity, and date ranges.

Include the tenant name, the affected user, the date, time, and time zone, the model and Auto mode in use, and any workflow, run, file, or API detail that helps identify the request.

Credit usage support covers usage, limits, resets, unexpected consumption, and blocked-by-limit questions. Invoices, payment, refunds, downgrades, package changes, and commercial terms go to your account owner or the Billing team.

Controlling Credit Consumption: An Admin Setup Guide