Rhumb's discovery surface covers 999 scored services and 435 capability definitions, but current callable execution is narrower at 18 callable providers strongest for research, extraction, generation, and narrow enrichment. Price the workflow that can actually run today, not the whole catalog.
Start with the repeat job, not the platform idea
"How much will agent execution cost?" is too broad to answer honestly. The useful unit is one repeated, observable job: search for ten fresh sources, extract one vendor page, send one approved email, generate one image, verify one lead, or classify one document.
Once that job is concrete, the price model becomes operational: resolve the supported capability, estimate the route, choose the credential rail, cap repeat volume, test the denied neighbor, and keep receipt evidence that survives retries.
The six fields to price before launch
What exact job will the agent repeat?
Use a concrete capability id such as search.query, email.send, image.generate, scrape.extract, or the current supported equivalent — not a broad product idea.
Should Resolve choose the best supported provider, or should the agent pin one provider?
A pinned provider is a constraint, not a price shortcut. Estimate, credential mode, denial, and receipt checks still apply.
How many times can the agent call before a human reviews the result?
Name per-run, per-hour, and per-day ceilings so the first loop cannot turn a good demo into a quiet spend spiral.
What is the maximum acceptable cost for one completed action?
The ceiling should include retries, fallbacks, enrichment calls, and output expansion — not just the happy-path provider price.
Whose account, key, wallet, or quota pool pays when the workflow repeats?
Governed key, wallet-prefund, x402, BYOK, Agent Vault, and provider pinning create different budget evidence.
What adjacent action must fail closed before the loop is trusted?
If you cannot name the denied domain, tenant, amount, row, account, path, or side effect, the price is not production-real yet.
Choose the rail after the workflow is priced
Best when
Default for repeat managed execution when the workflow fits Rhumb's current callable surface.
Pricing shape
Upstream execution cost plus 20% margin under Rhumb-managed billing.
Evidence to keep
Run resolve and execute estimate before the first paid call, then keep the estimate id, capability id, credential mode, and cost ceiling in trace context.
Best when
Wallet-native agents that will call repeatedly but should not authorize every request separately.
Pricing shape
Wallet funds reusable balance, then repeat traffic executes on the stable X-Rhumb-Key rail.
Evidence to keep
Price the workflow like governed execution, but preserve wallet identity, top-up id, amount, and balance drawdown in the receipt trail.
Best when
Zero-signup or strict per-request payment flows where payment proof is part of the product experience.
Pricing shape
USDC on Base; upstream execution cost plus 15% margin on the x402 rail.
Evidence to keep
Expect payment instructions per request and prove payment_request_id, X-Payment proof, amount, wallet identity, and verification outcome before execution state changes.
Best when
Workflows that must run through your provider account, contract, workspace, or compliance boundary.
Pricing shape
Rhumb adds no markup in BYOK or Agent Vault mode. Provider charges bill directly to your provider account. You still pay the provider directly.
Evidence to keep
Estimate Rhumb-side routing and execution shape, then separately cap the provider account's quota, rate limits, and per-action cost exposure.
The estimate call is the budget checkpoint
The pricing page exposes the canonical estimate shape at https://api.rhumb.dev/v1/capabilities/{capability_id}/execute/estimate. Use it before promotion, with the same capability id, provider constraint, credential mode, and budget ceiling the agent will use in production.
The estimate is not just a number. It is the checkpoint where route, availability, credential mode, cost ceiling, policy constraint, and denial expectations become explicit enough to compare against the eventual receipt.
Loop math: price the completed action
Ready-to-loop checklist
Anti-patterns
Ask for proof around one priced workflow
The best request is narrow: one capability, one repeat volume, one credential rail, one denied neighbor, and one receipt shape you would trust after a retry. That is enough to test whether the first paid call can be boring.