Before buying a credit-based AI tool, ask the vendor to define the exact event that triggers a charge, show the effective cost per action, model realistic usage, explain the useful outcome you receive, and demonstrate controls that limit spend.
A credit balance alone is not a cost model. Rates may vary by model, task, duration, output size, quality, workspace, or outcome. The practical buying sequence is to define the billable event, calculate effective cost, test realistic volume, compare the charge with operational value, and verify monitoring and stop controls.
For example, a hypothetical workflow of 2,000 actions per month at four credits each uses 8,000 credits before retries. With an assumed 8% retry rate, the planning estimate becomes 8,640 credits. That is usage arithmetic, not a dollar forecast, until you confirm the plan price, included allowance, and billing rules.
A credit balance is not a cost model. You need the billable event, effective unit price, and a practical way to constrain consumption.
1. What event creates a charge, and what does one action really cost?
Ask whether billing occurs at request, execution, completion, or a defined outcome. Get the minimum billable unit, credit conversion, rates by model and task, and treatment of retries, partial failures, abandoned work, duplicates, reversals, and disputes in writing.
Also request the fields available for reconciliation, such as event identity, workspace, user, model, feature, timestamp, credit quantity, and outcome status. Do not assume that a usage export, API, or invoice-level event record exists unless the vendor documents it for your plan.
Build a per-action worksheet before comparing plans. Record the task, model, billing unit, credits per unit, expected monthly quantity, retry assumption, included credits, expiration or rollover, overage rate, fixed fees, and estimated dollar cost. Calculate the dollar amount from the vendor-confirmed package price rather than inferring it from the credit count.
Runway’s current model-credit table, checked October 12, 2026, lists Google Veo 3.1 with audio at 40 credits per second. It lists Google Nano Banana Pro 2 at 16 credits per 4K image and distinguishes Pro 2 from Nano Banana Pro, which has a different listed rate. Duration, quality, resolution, and output quantity can also change consumption. Treat the table as a rate reference, not a complete quote for a configured generation. Review Runway’s current model-credit table and confirm the configuration before purchase.
A buyer-side worksheet can use this arithmetic:
estimated_credits = unit_credits * monthly_actions * (1 + retry_rate)
estimated_overage_credits = max(0, estimated_credits - included_credits)
estimated_cost = base_fees + package_cost + (estimated_overage_credits * overage_price_per_credit)Use that formula only when the package and overage terms support it. If credits expire, are pooled across teams, or are sold in bundles, include those rules instead of assuming a simple per-credit price.
2. How will the bill change at realistic usage levels?
Model low, expected, and high usage across the commitment period. Separate fixed seat or subscription fees from consumption. Include shared pools, workspace allocation, minimum commitments, expiration, rollover, and overages where they apply.
| Scenario | Monthly actions | Credits before retries | Credits with assumed 8% retries |
|---|---|---|---|
| Low | 1,000 | 4,000 | 4,320 |
| Base | 2,000 | 8,000 | 8,640 |
| High | 3,000 | 12,000 | 12,960 |
These figures are hypothetical arithmetic using four credits per action and an assumed 8% retry rate. They are not a vendor forecast or usage benchmark. Convert each scenario to dollars only after entering verified plan rates, included capacity, fixed fees, and overage terms. Run the same assumptions through the vendor’s published pricing and written quote, then investigate any difference.
Runway documents annual Enterprise credits as a shared pool for eligible workspace members and says unused annual contract credits do not roll over annually. Confirm how your contract allocates credits and handles expiry. HubSpot’s Customer Agent ROI calculator is a scenario tool that discloses a 260-working-days-per-year assumption and says its results are not guaranteed. Use it to inspect assumptions, not as independent evidence of savings. Inspect HubSpot’s calculator assumptions.
3. What outcome is the vendor charging for, and what value does it add?
Separate model activity from useful business work. A generated response is not automatically a resolved support issue, a qualified lead, or a safe CRM update. Ask what the product adds beyond model access, such as business context, proprietary data, integrations, workflow execution, governance, or a measurable outcome.
HubSpot provides a bounded example of outcome-based pricing. Its April 2026 announcement says Breeze Customer Agent is priced at $0.50 per resolved conversation, or 50 HubSpot Credits, and Breeze Prospecting Agent at $1 per lead recommended for outreach, or 100 credits. HubSpot says these offers are available to Pro and Enterprise customers and include a free 28-day trial. Confirm eligibility and activation terms in the account. These are vendor-defined events, not a general pricing rule or a complete billing schema. Read HubSpot’s pricing announcement.
Ask what counts as a resolved conversation or recommended lead, and how duplicates, abandoned tasks, reversals, failed actions, and disputed outcomes affect billing. If the charge is for a recommendation, define how your team will measure whether it was accepted, acted on, and valuable.
For a workflow that can update customer records, specify which fields the system may propose or change, who approves exceptions, and which application is the system of record. A AI agent implementation should fit a defined workflow rather than simply add model calls.
Use deterministic rules when the condition is exact, structured, and consequential, such as checking a required field or blocking an invalid status transition. Use AI when meaning must be interpreted from unstructured text. A practical hybrid pattern is a deterministic pre-filter, AI classification into an allowed value, schema and evidence checks, and human review for low-confidence or high-impact cases before a CRM write. CRM systems should retain a clear owner for the final customer record.
| Trigger | AI job | Validation | Action or fallback |
|---|---|---|---|
| New support conversation | Propose a resolution category from approved knowledge sources | Check the category against an allowed list and require supporting evidence | Route uncertain cases to a person; record the final disposition in the CRM |
| New prospect signal | Recommend a lead for outreach | Check source freshness, duplicate status, account ownership, and required fields | Send for review before outreach; reject stale or duplicate recommendations |
| CRM status change | Interpret unstructured notes only when needed | Apply deterministic transition rules and permission checks | Block invalid writes and send exceptions to the record owner |
4. Which controls stop a test from becoming production spend?
Ask to see usage visibility, alert timing, hard spending caps, pause behavior, and permissions by user, team, workspace, or project. Confirm whether queued or scheduled activity continues after a limit is reached. A preview, sandbox, dry run, approval gate, and hard cap address different risks.
Clay documents Sandbox mode for testing table configurations on a subset of up to 50 rows. It disables outbound actions while active and supports reviewing changes before publishing. Clay also says recurring sources, webhooks, and scheduled runs continue during Sandbox mode, and individual cells or columns may still be run manually. Test those background paths separately before publishing. Read Clay’s Sandbox mode documentation.
Runway documents workspace credit caps for relevant Enterprise configurations. A hard cap stops further generation at the configured maximum. A workspace with no cap may continue drawing from the shared organization pool, and usage beyond purchased credits may be billed. Confirm availability, permissions, and scope. Anthropic describes organization- and individual-level spending limits for Claude Code premium-seat usage on Team and Enterprise plans. Do not assume that control applies to every Claude product or plan.
A sandbox protects the test environment, while a hard cap limits eligible spend. Neither validates business quality, and Clay documents that recurring sources, webhooks, and scheduled runs continue while Sandbox mode is active. Before testing, identify every path that can still run and assign an owner for the resulting spend.
5. How should you reconcile usage and choose a pilot?
Ask whether the vendor can provide usage details that reconcile to a workspace, user, model, feature, event, timestamp, credit quantity, and outcome status. Do not claim an export or API exists unless current vendor documentation confirms it.
Keep records at the correct grain. A per-billable-event record represents one resolved conversation, recommended lead, or generation. A per-run record represents one execution. A citation record represents one evidence item. A daily aggregate represents one organization, product, model, date, and declared aggregation grain. Do not use one broad key such as customer ID plus date for every record type.
The following is an illustrative buyer-side record for one billable event, not a vendor schema:
{
"event_id": "illustrative-local-uuid",
"vendor": "example-vendor",
"workspace_id": "workspace-12",
"event_type": "lead_recommended",
"model_or_feature": "prospecting-agent",
"occurred_at": "2026-10-12T10:30:00Z",
"credits": 100,
"outcome_status": "review_required"
}Use a vendor event ID when the vendor guarantees its uniqueness. If none exists, generate a local UUID at ingestion and store a separate source-record reference. Enforce uniqueness with a database constraint or transactional upsert on the actual natural key. A lookup-then-create check is not safe for concurrent workers because two workers can observe no record and insert duplicates.
Set the pilot’s representative workload, baseline cost, success measure, acceptable error rate, spend ceiling, and named exception owner before the first paid run. Include review time, retries, integration work, and human handling of exceptions in the full cost. Expand only when usage can be reconciled, the outcome is measurable, and the spend owner can constrain or stop the workflow.
Vendor decision checklist
Use these as purchase gates. If a billing definition or control remains unclear, request written clarification or keep the deployment at a narrower pilot.
- The charge-triggering event and minimum billable unit are defined in writing.
- Low, base, and high estimates can be reproduced from disclosed rates and your own volume assumptions.
- Retries, partial failures, duplicates, reversals, expiration, rollover, overages, and fixed fees are addressed.
- Usage reporting and administrative limits have been demonstrated on the exact plan, not assumed.
- A pilot owner, success measure, budget ceiling, exception route, and stop condition are recorded.
Vendor rates, model names, eligibility, credit rules, and controls can change. Recheck current documentation and contract terms before purchase. Keep modeled consumption and ROI separate from observed pilot results, and record the assumptions, measurement grain, and period behind each conclusion.