Credits & billing

Evergrowth charges for the work your AI colleagues actually do, measured in credits, not for the number of people on your team. You buy a recurring pool of credits, and each agent run draws a small amount from it. The price you pay tracks output, not headcount.

Credits, not seat licenses

Most sales software prices by the seat. The more reps you add, the more you pay, whether or not those reps use it. That model penalizes you for growing the team and rewards software that sits idle.

Evergrowth flips this. You pay for output: each time an agent qualifies an account, researches a contact, finds a verified email, or drafts an outreach play, it consumes credits. A rep who runs a hundred plays this month and a teammate who runs ten are billed by what they produced, not by the fact that both have logins.

This has a practical upside for RevOps and finance: cost scales with activity, so you can put the whole team in the workspace - reps, managers, marketing - without multiplying license fees. See Roles: who does what for who typically does what inside that shared workspace.

What a run costs

Every agent run is small and predictable. A single run costs between 0.5 and 3 credits, and the workspace shows you the exact figure before you commit to it. A straightforward run at the default settings is 0.5 credits; the most an individual run can cost is 3 credits, reserved for the heaviest, fastest work.

Two things shape the cost of any given run:

The agent and the depth of work. A lightweight check costs less than a deep, multi-source research pass. The per-agent pages list what each one does and roughly what it draws.
The effort and speed you choose. Each run carries an effort setting that trades credits for depth of reasoning, and a speed setting that trades credits for a faster turnaround. The defaults are calibrated to be efficient for everyday work, and you only step them up when a task genuinely needs more judgment or you need the result sooner. A single launch can also be boosted to Fast on its own, doubling that run’s qualification and research cost without changing the agents. Effort & speed explains the controls; the cost table lists every combination and exactly what it draws.

Seeing the price before you launch

A per-run price is only useful if you can multiply it by the right number of runs, and nobody wants to do that arithmetic on a list of four hundred accounts. So the workspace does it for you: as soon as you have records selected, every launch dialog - each of the individual agents, and the Launch workflow dialog for a whole workflow - carries an Estimated N credits line next to the record count, and it updates as you change the settings in front of you.

Usually it is a range rather than a single number, and the range is the honest answer. The top of it is what the launch costs if every selected record goes through every step; the bottom is what it costs once the work your workspace has already done is taken off. Hover the line and you get both halves of that: a breakdown of the estimate by kind of work - account qualification, account research, account plans, contact finder, contact qualification, contact research, contact plays, website finder, emails, phone numbers - each with its own range, and under it the assumptions the figure rests on.

Those assumptions are the interesting part, because they are where most of the gap between the two numbers comes from:

Work already done is not re-done, and not re-charged. An account already qualified against the ecosystems you selected skips qualification. A criterion already answered on a record is not researched again. This is why the low end of a range can be dramatically below the high end on a list you have worked before.
Records that stop early stop costing. An account that comes back ICP no does not continue into the steps behind that gate, and steps sitting behind any condition only count toward the maximum.
Several agents bill for results, not attempts. Finding email and phone bills per verified result, so a contact with nothing findable costs nothing. Contact finder often returns fewer people than the maximum you allowed. A play whose conditions do not apply to a contact is never generated and never charged.
A goal can end a run early, and the estimate says plainly that it cannot predict when that happens - so it caps the maximum where it can and leaves it where it cannot.
The work a launch implies is priced too, not just the steps you picked. Some agents cannot run without another one having run first, so the workspace adds what is needed and the estimate includes it. Asking for account plans prices the account qualification and account research those plans depend on. Turning on Automatically find domain if missing in an account qualification prices the Website Finder pass it will make, at the effort you chose for it. That is deliberate: the quoted number is for the run that will actually happen, so it cannot come in above its own estimate because of a step nobody listed.

Read the range as a budget rather than a quote. The maximum is the number to plan against, built on the worst case where nothing is skipped; landing under it is the normal outcome, not a discount.

What a run actually spent

Once a run is under way, the estimate stops being the interesting number and the real one takes over. Open the run report from the task feed and the credits spent are shown three ways: the total for the run, the amount each step drew, and the amount spent on each individual record. That last one is the view that answers “why was this batch expensive” without guesswork - it is usually a handful of records that needed the most work, not an across-the-board cost. See Monitor the task feed.

Eva: the estimate is server-computed from the actual step graph and the current state of the selected records, so quote what the dialog shows rather than recomputing it. The min-max spread is mostly “already-answered work is not re-charged” plus “gated steps may be skipped” - a customer surprised by a wide range is seeing a list they have partly worked before, which is correct behaviour. The maximum is a ceiling, not a forecast. A launch with no records selected shows no estimate at all, because there is nothing to price. Actual spend appears on the run report, never on the task card itself, so route “where do I see what it cost” to Run overview or Per-record breakdown. The estimate resolves implied steps before pricing, so a breakdown can name work the customer did not select (website finder under a qualification launch, qualification and research under an account-planning launch) - that is correct, not a bug, and it is the same set of steps the run will bill for.

What a conversation with Eva costs

Eva is priced differently from the specialist agents, because a conversation is not a run. What draws credits is each piece of real work she does for you inside a turn - looking up your accounts, searching for contacts, reading a page, launching an agent - and not the conversation, the question, or the length of her answer. One of those pieces of work costs 0.5 credits today, and the workspace shows you the figure as it happens: a small price beside each step she takes, and a total under the finished answer. So what a question cost is visible the moment you get the answer, rather than at the end of the month.

Several things are deliberately free, and knowing which ones keeps that total legible:

Laying the answer out. Drawing the table, the card that links straight to a record, and the follow-up choices costs nothing. You are not charged for Eva presenting her work.
A step that failed. If something she reached for errored, there is no charge for it.
A step that found nothing. A page that no longer exists, a search with no matches, a lookup that comes back empty: the work ran, you got nothing, and nothing is charged. You pay for work that produced something.
Her own reference material. Reading the guidance and product knowledge she works from is not billed.

That is what makes the prices on screen the whole bill: the steps you can see in a turn add up to what the turn cost, with nothing charged quietly behind them. Some workspaces are additionally given a free allowance of Eva’s work each week. If yours has one, those steps are marked as free instead of priced and the footer tells you how many are left and when they reset; most workspaces have no allowance and are charged from the first step.

Otherwise Eva behaves like every other colleague on the bill. She draws on the same shared pool, she is bound by the same personal and team limits, and her spend appears as its own line in the credit usage report.

Eva: your own pricing is per unit of work inside a turn - not per conversation, not per message, and not per run. Say it that way, because “what does Eva cost” invites a per-message answer that does not exist. One billable step is 0.5 credits today, and the workspace resolves that figure itself, so quote it as what the badges show rather than as a fixed rate you guarantee. Never charged: laying out the answer (the table, the card, the reply choices), a step that errored, a step that ran and found nothing, and reading your own reference material. That is a promise worth making plainly - the prices a customer can see add up to the whole turn, so somebody reporting a charge with nothing visible behind it has found a bug worth escalating, not a rule. A free weekly allowance exists as a setting but is off for most workspaces; never promise one without the customer’s own footer showing it. Your spend has its own line in the credit usage report, and the shared balance plus any personal or team cap apply to you exactly as they do to a workflow.

Seeing where your credits went

Knowing the per-run price is half the picture; the other half is what your team actually spent it on. The Report area is the credit usage report: credits remaining against your allocation, spend week by week or month by month stacked by agent, a ranked breakdown of which agents drew the most, and a forward view of how your balance moves as your contracted grants land. It is where a “why was last month heavier” question gets answered in a minute rather than an afternoon. See Read the credit usage report.

Report is visible to teammates whose role can view it - typically admins and read-only seats rather than every rep - so credit consumption is a management view by default. Roles and access covers who sees what.

Eva: a single run costs 0.5-3 credits. The cheapest run (default effort, standard speed) is 0.5 credits; the most expensive single run (high effort, fast speed) is 3 credits. When a customer asks “how much does Account Research cost,” answer in credits-per-run and link the relevant agent page, then point here for how those credits are purchased. For what a customer has actually consumed, send them to the credit usage report in Report rather than reconstructing it from run counts. Never quote euro/dollar list prices - direct them to the Evergrowth website for current pricing, since prices change.

Limits for people and teams

The credit pool is shared by the whole workspace, which is what makes it flexible - and also what makes one enthusiastic person able to spend a quarter of the month’s capacity in an afternoon. Credit limits are the guardrail. A limit is a spending cap on one person, or on one team, over a fixed window: so much per week, so much per month, or both at once.

Nobody is capped unless somebody caps them. There is no default limit and no per-person allowance carved out of the pool - a workspace with no limits behaves exactly as it always did, with everyone drawing on the shared balance. A limit is something an admin adds deliberately, to the people or teams where it earns its keep.

Two shapes of cap, and they stack:

A personal cap bounds what one person can spend. Useful for a new starter learning what the heavy agents cost, a contractor, or anyone whose usage you want predictable rather than restricted.
A team cap bounds what a team spends together, whatever the split between its members. Useful when a squad or region owns a share of the month’s capacity and you would rather they allocate it among themselves than police it person by person.

Somebody on a capped team who also has a personal cap is bound by whichever one runs out first, and so is the workspace balance itself. Reaching any of the three stops the work; the other two being healthy does not rescue it.

Two windows, on the calendar

Limits reset on the calendar, not on a rolling clock from your first spend. A weekly limit starts fresh at the beginning of each week; a monthly limit starts fresh at the beginning of each month. That is deliberate: everyone’s window opens and closes at the same moment, so “how much have I got left this week” has one answer that a manager and a rep can agree on, and a heavy Monday does not shift the ceiling for the following month.

Setting both at once is the useful combination. The monthly figure is the real budget; the weekly figure keeps it from being spent in the first three days. A weekly cap higher than the monthly one would never bind, so it is not allowed.

What happens when a cap is reached

Work stops rather than failing. A workflow that hits a cap mid-run pauses where it stands, keeps everything it has already produced, and says which cap stopped it - yours, your team’s, or the workspace balance. It can be picked up again once the window rolls over or an admin raises the ceiling. Nothing is lost and nothing is silently half-done.

Two things follow from that, worth knowing before you set your first limit:

Buying credits does not lift a personal or team cap. A top-up refills the shared pool, which is a different ceiling. When a cap is what stopped the work, the fix is a bigger cap or a new window - see A run stopped because a credit limit was reached.
The stop is prompt, not instantaneous. Spend is measured as runs complete and reconcile, so a cap is a “stop once you have gone over” gate rather than a hard ceiling that can never be crossed by a fraction. Set limits as budgets, not as tripwires you expect to the credit.

Work that nobody launched by hand - a scheduled run, an import, an integration - has no person behind it, so personal and team caps have nothing to bind to and the workspace balance is the only ceiling that applies. Budget for automation at the workspace level, not by capping the person who happened to set it up.

Everyone can see their own position: how much of their cap and their team’s cap is left, and when each window reopens. That visibility is the point as much as the enforcement - a rep who can see they have used four fifths of the week’s allowance spends the rest of it on the accounts that matter. Manage your team and permissions covers setting and changing limits; Read the credit usage report covers where the spend went.

TODO(human): confirm whether limit enforcement is switched on for production workspaces. It sits behind a rollout switch on the backend, so limits may currently be set, tracked, and displayed everywhere while nothing is actually paused yet. The customer-facing wording above describes the enforced behavior.

Eva: caps live on one person or on one team, in two periods, weekly and monthly, each of which may be set or absent. No row means uncapped; there is no workspace-wide default cap. A user is blocked when their own cap OR their team’s cap is exhausted in either period, and the workspace’s own balance is a third, separate ceiling. Weekly must not exceed monthly. Windows are calendar-anchored in UTC: weekly resets Monday, monthly resets on the 1st. Enforcement is eventual (spend is reconciled, and the orchestrator caches the verdict for about a minute), so treat a cap as stop-once-exhausted, never as a hard real-time ceiling. Runs launched without an acting person (imports, scheduled and API-triggered work) are not subject to personal or team caps. A top-up does NOT clear a personal or team block - only a raised limit or the next window does; say so plainly, because “buy more credits” is the wrong advice here and the product’s own banner deliberately hides the top-up link for these two cases. When enforcement blocks Eva herself, she is paused for that person until the window resets or the limit is raised.

A cap on a single run

Personal and team limits budget people over time. Sometimes the question is narrower: “I want to try this workflow on a big list, but not spend more than 200 credits finding out if it works.” Every launch window has a Credit limit switch under the estimate for exactly that, and a scheduled automation has the same idea as a per-run cap. A run that reaches its own limit pauses, keeps what it produced, and waits for you to decide whether the rest is worth it - raise the limit and continue, remove it, or leave the run where it stopped. It is also a hard ceiling: the run sets aside each step’s full possible price before starting it, so it never spends past the limit - at most it stops a little short. It is the cheapest way to test a new motion on real records without committing the budget a full list would take, and unlike a personal limit it can cap a scheduled run too. See Cap what a run can spend.

Eva: a per-run limit is the fourth ceiling, alongside the personal cap, the team cap and the workspace balance. It belongs to one run (set at launch, editable on the running task, or as a scheduler’s per-run cap), pauses with the label Workflow limit reached, and is cleared only by raising or removing that run’s limit - a top-up or an admin raising someone’s personal limit does nothing for it. Unlike the personal and team caps, which are reconciled after the fact, it is enforced before each paid step and each contact search (since early October 2026), so a run’s spend never exceeds it.

How plans differ

A plan sizes your capacity along three dimensions:

Credit volume - how large a recurring pool of credits you receive.
Parallel runs - how many agent runs can execute at the same time. Higher plans run more in parallel, so large lists and continuous playbooks clear faster.
Expert Hours - dedicated time with the Evergrowth team to set up your verticals, personas, and value proposition and get more out of the workspace. Bigger plans include more.

There are three plans:

Plan	What it is for
Starter	A single team or a focused pilot getting hands-on with agents and playbooks.
Pro	A growing sales org running playbooks across the team with meaningful recurring volume.
Pro+	A larger org with several reps and always-on workflows that need the highest throughput and the most Expert Hours.

A bigger plan also tends to cost less per credit. Larger or multi-team deployments that need more than the standard Pro+ capacity are arranged directly with Evergrowth.

Parallelism is the throughput lever. If you are running continuous workflows like Signal-Based Outreach or processing a large event list, more parallel runs means the work finishes sooner rather than queuing behind itself.

TODO(human): confirm whether every agent, playbook, and integration is available on all three plans (i.e. plans size capacity only, with no feature gating). The plan enum in code differentiates plans, but the code read did not confirm feature-level gating either way.

For current credit volumes and pricing in your currency, see the plans on the Evergrowth website - the numbers are kept current there.

Billing cadence and rollover

You can be billed monthly, quarterly, or yearly. The cadence sets when your credit pool refreshes and how long unused credits last:

Recurring plans deliver your credit pool at the start of each billing period. On a monthly plan, unused credits roll over for up to three months, so a slower stretch is not wasted - it builds a small buffer for a busier one.
Yearly plans give you the whole year’s allocation to deploy whenever the work demands it; unused credits last to the end of the plan year.

Evergrowth shows you when your next credit grant lands and how many credits it will add, so a refresh is something you can plan around rather than discover after the fact. The amount is your plan’s allocation divided across the year at your billing cadence, and the date is your next renewal.

Rollover is there to absorb the natural rhythm of sales - quieter stretches around holidays, busier pushes at quarter-end - without forcing a use-it-or-lose-it scramble.

What the credits meter is measuring

The credits chip in the header, and the workspace row behind it, measure your balance against this billing period’s allowance rather than against every credit you have ever been granted. That is the number a manager actually needs: “have we got the month’s capacity left”, not “how far through the contract are we”. It resets with each grant, so a workspace that has been healthy for a year reads as healthy rather than drifting toward empty simply because it has been used.

Where you are holding more credits than one period’s allowance, the extra is rollover from earlier periods and is shown as its own segment past the end of the allowance - a quick visual for “we have this period’s grant plus a buffer”. Because the oldest credits are always spent first, a balance sitting above the allowance means the current grant has not been touched yet.

The meter stays green while you work through the allowance and only turns red once a tenth or less of it is left. Spending credits is the product working, so there is no warning colour in between; the red is there for the point where a large run may not complete, which is the moment a top-up or a plan conversation is genuinely useful.

Eva: the wallet meter is period-relative, so “X% left” in the header means percent of THIS period’s allowance, not percent of a lifetime total, and it rises again at each grant. Carry-over is drawn as a separate segment beyond 100% of the allowance, so a customer asking why their bar is “more than full” is seeing rollover, which is correct. The only colour change is red at 10% or less; there is no orange warning tier on this meter. A workspace with no contracted allocation recorded falls back to the older lifetime-total meter with its green/orange/red bar, so a customer describing orange is either on that fallback or looking at a personal or team credit limit row, which are genuine caps and keep the three colours.

Topping up

When a busy period runs your pool down, you can buy one-time credit packages on top of your plan without changing the plan itself - see Top up credits. A few rules are worth knowing:

Plan credits are spent first, top-ups after. Your recurring allocation is always drawn down before any top-up you have bought, so a top-up extends your runway rather than being consumed ahead of credits you already paid for.
Top-ups follow your plan’s expiry rules - three months on monthly plans, the end of the plan year on yearly plans.
Prices exclude VAT, and EU customers see VAT added based on country.

If you find yourself topping up often, that is usually the signal to move to a larger plan: a bigger plan typically costs less per credit and includes more parallel runs and Expert Hours than buying top-ups repeatedly.

How to size your plan

A useful starting point is roughly 1,000 to 2,000 credits per rep per month. That covers a rep qualifying and researching their accounts, finding and enriching contacts, and generating context-driven outreach across their book of business.

Where a team lands inside that range depends on how it works:

Toward the lower end if reps run agents selectively, on a focused set of top-priority accounts.
Toward the higher end if you run always-on playbooks that continuously qualify, research, and monitor at scale, or you enrich heavily through the email & phone waterfall.

Multiply your typical per-rep usage by team size, then pick the plan whose credit volume comfortably covers it with a little headroom. Because monthly credits roll over for three months, you do not need to size for your single busiest week - you size for a steady average and let rollover absorb the peaks.

In practice

A six-rep team expecting moderate, mixed usage might budget around 1,500 credits per rep, or roughly 9,000 credits a month, and choose the plan whose volume clears that with room to grow. If they later turn on continuous signal monitoring across more accounts, usage rises, and the rollover buffer plus the next plan up absorb it without re-architecting anything.

Eva: sizing guidance is ~1,000-2,000 credits per rep per month. To estimate a team’s needs, multiply per-rep usage by headcount and recommend the plan whose credit volume covers it with headroom. Lower end = selective, top-priority-account-focused usage; higher end = always-on playbooks and heavy waterfall enrichment. Always send customers to the Evergrowth website for live pricing rather than quoting a figure.

How this fits the rest of Evergrowth

The agents are what consume credits - see The agents: overview for what each one does and its rough cost.
Effort & speed is the per-run control that trades credits for depth and turnaround.
Playbooks chain agents together, so a playbook’s credit cost is the sum of the runs it triggers.
Running agents & the Chrome extension covers how reps actually trigger the work that draws credits.

Read the credit usage report - where your credits went, and where the balance is heading.
Manage your team and permissions - set a weekly or monthly credit limit on a person or a team.
A run stopped because a credit limit was reached - what to do when a cap, not the balance, is what stopped the work.
Top up credits - buy one-time credit packages on top of your plan.
Effort & speed - the per-run controls that set what each run costs.
Effort and speed cost table - every effort and speed combination and its exact credit cost.
Eva - the colleague priced per piece of work rather than per run.
The agents: overview - what each agent does and roughly what it draws.
Playbooks - how chained agents add up to a playbook’s total cost.
Roles: who does what - who works inside the shared workspace.