Understand usage, allowances and payments
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#overview.
Use this recipe to take a trial agent into paid use without surprising the person responsible for the bill. Begin with the included allowance, choose what further spending the application may incur, and keep the usage and payment records needed to explain the first bill.
Have an account administrator, an authorized payer and the applicable account terms available. Project setup, service credentials, spending permission and payment are separate steps; completing one does not complete the others.
Negotiated prices, contracting parties and invoice review belong in Commercial agreements and invoicing. For a commercial change, review the standard-to-Enterprise conversion or downgrade path, including the effective date and treatment of existing usage and balances.
Available today: Use the billing channel and terms supplied for your account. Self-service billing, comprehensive spending controls and separate test/live billing are planned; confirm the controls currently enforced for your account before sending paid traffic. This page publishes no allowance amount, price or payment deadline.
1. Try the application within the included allowance
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#included-allowance.
Try the included allowance without entering payment details:
- Create the first project, including its permitted region.
- Review the configured allowance, which usage it covers, its scope and remaining balance.
- Issue a credential for the application. Key creation does not purchase additional capacity.
- Make a permitted first call. The same authorization and finite usage controls apply to that call and later calls.
- When the allowance requires more funding, review the applicable terms before authorizing paid capacity.
Project creation and key creation are separate steps. The allowance amount and eligible products remain account-specific, and free allowance does not authorize additional paid use. Self-service onboarding is not yet available.
2. Agree who pays before enabling paid use
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#paid-traffic.
Before connecting a model or external service, review your account’s billing setup with the person authorized to approve spending:
| Confirm | Why it matters |
|---|---|
| Account, application/project and payer | The person operating an application may differ from the organization responsible for its bill |
| Active agreement or price revision and currency | An example price, provider estimate or future proposal does not establish your charge |
| Included allowance, eligible usage and any expiry | Free use is finite; an allowance is separate from permission to incur additional charges |
| Spending permission and funding limit | Choose how much paid work the application may accept; a usage chart or request-rate setting serves a different purpose |
| Connected model, tool and payment accounts | External providers may charge separately; a test label does not make a connected live account free |
| Billing contact and a way to track a question or payment | You need to recover an outcome after a lost response without starting a second payment |
The current public API has no sandbox or separate test-key type. Use controlled fixtures, bounded concurrency and accounts you are authorized to exercise; see Test your integration. A missing rate-limit header or a zero displayed balance is not permission for unlimited use.
3. Fund and limit the work you authorize
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#spending-and-funding.
After the trial proves useful, agree the permitted application scope and spending amount with the authorized payer. Spending permission and funding are separate choices: review eligible work, currency, effective time and approval before enabling a limit, subscription or automatic top-up. For a top-up, also review the trigger, purchase terms and limits on further purchases. A saved payment method does not authorize every future purchase.
Send a controlled first request, then inspect the usage record and remaining funding before expanding traffic.
Spending controls account for concurrent, retried and delayed work before accepting another paid action. A displayed estimate, alert or per-minute request limit does not replace those controls. If required budget settings are missing, paid work stops with an explanation of what to configure.
Before increasing a limit after work stops, identify the reason:
| Reason to investigate | Next step |
|---|---|
| Allowance exhausted or spending permission insufficient | Review the applicable allowance or spending policy and obtain the required funding authorization |
| Payment pending, declined or requiring authentication | Recover that payment's existing status and follow the authorized payment flow |
| Security, membership or manual restriction | Resolve that restriction through the responsible administrator; paying alone does not clear it |
| Usage or account state unavailable | Ask for reconciliation; do not assume missing state means remaining capacity |
After funding is restored, confirm which work may resume. Previously skipped schedules should not be assumed to replay automatically.
4. Explain the first bill using the same usage period
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#usage-and-invoices.
At the end of the first billing period, compare the account’s invoice with usage for that same period and timezone. Start with the application and model that incurred the charge, apply the accepted rate revision and account for credits or adjustments. If a row is missing or late, keep the reconciliation incomplete rather than treating it as free usage.
Usage records explain consumption; an invoice applies your commercial terms. Model input/output tokens and generation counts can help explain a charge, but a usage report may omit other products or arrive late. Check its coverage and update time before treating it as a complete balance.
Within that period, review:
- The account and project that incurred the usage, with environment/customer attribution where the deployment supports it.
- Quantity and unit, model or other charged capability, currency and the applicable rate revision.
- The payer and billing period, including the effective date of any payer or price change.
- The report's freshness, missing coverage and later corrections.
The detailed usage view shows this attribution and identifies incomplete reporting. Until it is available, request a scoped explanation through your account's billing channel. See Evaluation traces for inspecting individual runs and invoice review for the commercial record.
Recover an interrupted top-up or payment
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#payment-recovery.
Use only the payment method and checkout route supplied for your account. Keep the original payment, purchase or top-up reference. If the browser closes or a request times out:
- Reopen the existing operation or ask the billing contact to locate it using that reference.
- Check whether the authoritative outcome is pending, requires action, failed or completed.
- Complete any required authentication through the approved payment provider.
- Reconcile an uncertain outcome before initiating a replacement payment.
- Match any receipt, credit allocation or refund to the original operation.
The account interface preserves payment status across retries. A successful redirect, submitted form or credit note alone does not prove money moved. Purchased credit becomes available only after the required payment confirmation. A granted credit, invoice adjustment and cash refund have different effects; request the applicable record.
For a billing question, send a compact record through the agreed channel:
Account and project:
Invoice / payment / operation reference:
Affected period and timezone:
Affected usage or invoice line:
Expected terms or approved revision:
Observed status and when it was observed:
Requested clarification or correction:
Do not include API keys, full card details or payment secrets. Keep the original invoice and any linked correction; changes to future terms preserve past charges and their history.
The recovered outcome is the original payment’s confirmed status and any linked credit, receipt or refund. If it remains unknown, keep that payment under investigation. A second payment is a new financial action, not a way to refresh the first one.
Variant: charge your own customers or approve a purchase
Status: Upcoming — not yet available.
Section: DOC-CP-billing-spend#customer-billing-and-purchases.
Manage catalogs, subscriptions, usage charges, invoices and exports for your application's customers separately from your own Travila bill. These customer-billing operations do not yet have a public API. Paying Travila does not authorize a charge to one of your customers.
For a conversational purchase, the shopper reviews the merchant, items, complete amount and currency, delivery details and quote expiry, then approves those exact terms. A changed quote requires renewed approval. Purchase and payment status remain available after an interruption, so the shopper can check whether an order completed before trying again.
For account ownership and credentials, continue with Workspaces and projects. For negotiated pricing, payer consent and invoice disputes, use Commercial agreements and invoicing.
Document ID: DOC-CP-billing-spend. Section identities and revisions.