Every AgenticWebTeam plan comes with a monthly pool of credits, and almost every question we get about pricing comes down to the same two things: what exactly is a credit, and how many do we actually need? This guide answers both, so you can pick a tier with confidence rather than guesswork.
One unit for everything the assistant does
A credit is a fixed unit of assistant usage. Rather than juggling separate meters for AI model calls, web research, stock photography, image generation and document rendering, everything the assistant does is priced from a single rate card and drawn from one pool. Ask for a paragraph rewrite and a handful of credits are consumed; ask for a researched, illustrated, thousand-word article and it will draw proportionally more.
The advantage of a single unit is that you never have to think about which underlying service was involved. A run that searches the web, imports a photo and updates three documents shows up as one line of usage with one credit figure attached — visible to your admins in Usage & Billing, per run and per service, alongside the running balance.
How the pool works
Your workspace's monthly pool is simply seats multiplied by your tier's per-seat allowance — each tier includes a different monthly credit allowance per seat, and every seat's allowance joins one shared pool. Five seats therefore share five times the allowance, with no per-person rationing: a heavy month for your editor and a quiet one for your developer balance out naturally.
Included credits refresh on the first of each month and don't roll over. That's deliberate: it keeps the mental model simple — size your tier to a typical month — and it's why we also sell top-ups for the atypical ones. Top-up packs are bought in the portal, charged to your card on file, applied instantly, and never expire.
What happens at zero
Nothing silently overspends. When the pool reaches zero, new assistant runs pause until you top up or the monthly refresh lands. Admins can see the balance trending down long before that happens, so in practice the pause is a safety net rather than a surprise. It also means your bill is genuinely predictable: seats are the only recurring charge, and credits only ever cost what you've explicitly bought.
Sizing your plan in practice
Start from what your team actually ships. A content-led team publishing a handful of researched articles a week, with routine edits and the odd image, sits comfortably in Growth. A team that leans on the assistant daily — long-form content, code changes, document generation, lots of research — grows into Scale, where the per-credit economics are best. Solo operators and early-stage sites almost always start on Starter and move up when the pool starts feeling tight.
The honest answer, though, is that the live demo is the best sizing tool we have. Before subscribing, you can book a demo and try the assistant on a real demonstration site — creating pages, editing content, changing layouts — and get a feel for how much work a task really involves. Once you subscribe, the usage screen shows your actual consumption from day one, so resizing after the first month is an informed decision rather than a guess.
Where credits actually go
It helps to know which tasks are light and which are heavy. Reading and writing your own CMS is the light end: querying documents, applying edits and creating drafts consume modest amounts, because the underlying work is mostly your own content moving through official APIs. A morning of routine content maintenance barely dents the pool.
The heavier end is anything that reaches outside your systems or generates something new. Web research reads real pages on the live internet; image generation renders original artwork; PDF rendering produces finished documents; long-form writing leans on more model time. None of these are extravagant individually, but a workflow built around daily deep research will consume noticeably more than one built around editing and publishing.
Code changes sit in the middle. Reading files, making targeted edits and committing costs about as much as comparable content work — it's the size and number of files involved that moves the needle, not the fact that it's code.
Invoices, VAT and the paper trail
Whatever the plan, the money side stays boring by design. Card payments run through Stripe — we never see card details — with VAT calculated automatically at checkout where it applies, and every invoice, payment and any refund visible under Usage & Billing. Enterprise customers skip cards entirely and receive monthly invoices generated from actual metered usage, which their finance teams tend to prefer.
Questions we hear at this point
Do unused seats waste credits? No — a seat's allowance joins the shared pool whether or not that person was busy this month, so quiet team members effectively subsidise busy ones. Can we see who's consuming what? Yes — usage is recorded per user and per run, so an admin can see at a glance where the month's credits went. Do failed runs cost credits? Work that was actually performed is metered; a run blocked before it starts — by permissions or an empty pool — costs nothing.
A few sizing rules of thumb
Draft-heavy workflows cost less than you'd expect, because reading and writing your own CMS is cheap relative to research and generation. Web research and image generation are the credit-hungry skills — factor them in if your workflow leans on either. And remember the pool is shared: adding a seat adds its allowance to the pool, so growing the team grows the budget in the same motion.
If you're still unsure, start a tier lower than you think you need and buy one top-up if you run short — top-ups never expire, so nothing is wasted. And if your organisation prefers invoicing and custom terms over card billing, the Enterprise plan swaps the card for monthly invoices generated from actual usage. Either way, the meter works the same — one credit, one unit of real work done.
