What spends a credit
Three kinds of action spend credits, whether you start them in the app or over MCP:- Chats. A conversation with the Attensira agent. Each turn is agent work.
- Automation runs. Every execution of an automation, whether you trigger it by hand or it runs on its schedule.
- Ask calls. The
asktool, which puts a question to the agent and returns an answer or a running session.
add_prompts, run_automation and ask, plus add_context when called with run: true, answer_inbox_question when the run that asked has already finished, and the agent run that answers a steer_project post. The read-only tools — search, get_analytics, get_prompt, get_page, query_evidence, get_session, list_sessions, get_account, get_ai_traffic_install, list_inbox, get_inbox_item, list_automations, get_automation, deciding_sources, win_plan, get_brief, list_wins, get_costs, get_loop_health, get_goals, list_projects, list_deliverables, get_report, get_markets, preview_markets, get_brand_family, and the deep reads answer_history, answer_slice, citation_timeline and page_history — do not, and neither do the writes that only change settings, memory, goals or sessions (approve_work_item, decline_work_item, approve_ask, decline_ask, resolve_inbox_task, update_automation, update_settings, record_observation, write_skill, set_goal, connect_github, cancel_session, delete_session, add_context without run). start_workspace and confirm_setup charge nothing: payment happens in the person’s browser.
Within a run, reading the open web (web_fetch, each page find_contact reads) is metered by the work the read actually took, up to a fixed ceiling per read. Reddit threads read through web_fetch are free.
Google Ads
Credits pay for the agent’s work on your Google Ads, never for the ads.- Researching keywords in a chat or automation is metered by the keywords looked up.
- Drafting a campaign is metered by the work it took: reading the landing page, writing the campaign (and its one repair pass, when one is needed), and the images it generated.
- Filing a campaign for approval, approving it, the daily sync, the hourly spend guard and the optimizer’s daily pass spend no credits.
How a credit is consumed
Consumption is per action, not per second and not per seat. Two people in the same workspace draw from one shared balance, so a busy automation schedule and a busy chat habit compete for the same pool. Cost scales with how much work the action actually does. A short chat turn costs less than an automation that fans out across many prompts and pages. This is why an automation you run by hand can feel cheap while the same automation on an hourly schedule is not.Plan credits and bought credits
Your balance holds two kinds of credit, and they follow different rules. Plan credits come with your plan every month (see Plans). Credits you do not use roll over: up to 100% of one month’s grant carries into the next, so a balance of plan credits can reach two months’ worth and no more. Rolled-over credits expire 2 months after they roll over. Rollover is the only expiry in the product. Bought credits are the ones you top up, by hand from Buy credits or automatically with auto top-up. They never expire. The smallest purchase is 5,000 credits, and the more you buy at once, the less each credit costs. The discount is by volume, not graduated: the whole purchase is priced at the band it lands in.
So 5,000 credits cost 800 and 500,000 cost $3,000.
No plan counts seats. Invite as many people as you need; they all draw from the workspace’s one balance. Every plan, Starter included, gets the same support from a person, at team@attensira.com.
What happens as the balance falls
Nothing degrades quietly. Your balance is in the top bar on every screen, in credits, and the agent surfaces remain fully functional right up to the point where a request cannot be covered. The usage chip turns amber when the balance is low, and when your plan’s prompt slots or this month’s responses are used up. Open it for the balance with Buy credits, and for prompt slots and responses against your plan’s limits. It shows nothing until the balance has been read, rather than a 0 it has not confirmed. As the balance gets low, the practical effect is that long-running agent work becomes the first thing at risk: an automation that fans out widely needs more headroom than a single chat turn, so it is the kind of action most likely to be the one that cannot start.What a workspace sees at zero
At zero, credit-consuming actions stop. Starting a chat, running an automation, callingask, or adding prompts through the agent will be refused rather than partially performed. You are told the workspace is out of credits; you do not get a half-finished automation run. In the dashboard, the box you start a chat from says You’re out of budget · Top up, links to Billing, and keeps what you typed so you can send it after topping up.
Everything that does not consume credits keeps working. You can still open the workspace, read every metric already collected, filter and compare, and use the read-only MCP tools. Readings keep running: the daily answers to your prompts use your plan’s monthly response budget, not credits.
When the balance is spent
When the credit balance is spent, scheduled automations do not run. Nothing is charged for runs that did not start. Instead of disappearing quietly:- The workspace gets one row in Work, Scheduled work is paused: the credit balance is spent. It names the automations that are paused and has a Top up credits button.
- It also gets one email when the pause starts. A pause that lasts a week is one row and one email, not seven.
- Each skipped run is recorded in loop health with the reason
no_credits.
What stops new work
The balance is the first of four checks every new piece of work passes before it starts. A monthly budget and the caps below it sit on top of the balance: work needs both a balance to pay for it and room under the budget and caps.
The first check that fails is the answer. Topping up lifts only the first: a budget or a cap is a limit you set, and more balance does not move it.
Each check happens before the work starts, never during it. A run already under way always finishes and is charged in full, so a month can pass the budget or a cap by at most one run, and runs that start at the same moment can each pass on the same reading.
What you see. A refused request answers
402 (payment required), and its message names the check: the balance is spent, this month’s budget is spent, the project has spent its monthly cap, or the workspace has spent its monthly cap. Nothing is half-done. In the dashboard, a chat refused at the budget shows the budget banner with Raise budget; see Costs.
Scheduled work that is stopped files one row per workspace and wall in Work, and sends one email, as the balance does. The budget’s row and a project’s row carry a Raise cap button; the workspace cap’s row says where the setting is. Each closes itself when the work runs again. In loop health each skipped run carries the reason in the table above.
If this month’s spend cannot be read when a scheduled run is due, the run is skipped rather than started against a cap it could not check. Nothing is paused and nothing is filed in Work; loop health records spend_unreadable, and the next scheduled check reads again. A chat or ask started at that moment is refused with a 503 rather than a 402; nothing was charged, and it can be sent again.
Monthly credit cap
Each workspace has an optional Monthly credit cap (monthly_credit_cap, in credits; 0 means no cap). It caps what that workspace may spend in a calendar month, counted in UTC. One credit is one cent, so a cap of 20,000 credits is $200; Costs shows it in dollars.
- It counts everything charged to the workspace in the month: agent work, and the reads of your own pages that monitoring makes. Daily prompt readings use your plan’s response budget, not credits, so they are not in it.
- It is checked before a run starts, never during one. A month’s spend can therefore go over the cap by at most one run’s cost.
- It holds the workspace’s automation runs, scheduled or started by hand. Chats and
askare held by the budget and by a project’s cap, not by the workspace cap. - When the cap is reached, scheduled runs pause with a row in Work and an email that name the cap. They resume on the 1st of the next month, or when you raise the cap, and the row closes itself when they do.
Project monthly cap
A project can have a monthly cap of its own, shown and set in dollars, to the cent. Empty means the project has no cap of its own and only the workspace’s limits apply. Only an org admin can change it, in the project’s settings or in billing settings; both edit the same cap, and the project’s settings show what it has spent this month against it. Everything the project’s crew does counts toward it: its scheduled and event runs, tests, and the Chief of staff’s replies to posts in the project. Like the workspace cap, it is checked before a run starts and never during one, so a month can go over it by at most one run’s spend. Months are calendar months in UTC. When the project reaches its cap, its new work stops and the rest of the workspace carries on:- The project’s scheduled and event runs do not start, and each skipped run is recorded in loop health with the reason
work_area_cap. A test of one of its automations is refused too. - The Chief of staff does not start on new posts in the project. The post is saved, the feed says the reply could not start, and a steer is still kept as the project’s direction.
- The workspace gets one row in the Inbox per capped project, Scheduled work is paused: this project reached its monthly cap, naming the scheduled automations that did not run, with a Raise cap button, and one email when the pause starts.
- The project’s feed gets one line for the month saying the cap was reached and when work resumes.