Your first relay payment should buy useful model access, not a billing puzzle. A relay sits between your tool and a model provider, so you need to understand both the advertised rate and the rules used to calculate your final charge.
Before adding money, run through this checklist. You do not need to master every technical detail. You need clear answers, a small test budget, and a way to check what happened after each request.
Ask what the displayed token price includes
A token is a small piece of text, not necessarily a whole word. Input tokens cover material sent to the model; output tokens cover what it generates. Their rates can differ, so a single headline price may not describe your actual workload.
- Are prices listed per thousand tokens or per million?
- Are input and output charged separately?
- Are cached input, cache creation, reasoning, images, or tool use billed differently?
- Does a longer conversation trigger a different rate?
Ask for a worked example using your intended model. If you plan to use Claude Sonnet 5.5, check that exact model's rate rather than assuming another model's price applies.
Check how a displayed rate becomes a charge
Ask whether the price shown is the final relay price, an upstream provider price, or a base figure with a multiplier. Also check the billing currency, payment fees, taxes, and any minimum charge or rounding rule.
For simple text billing, the estimate is input tokens multiplied by the input rate, plus output tokens multiplied by the output rate. Match the units first. A rate per million tokens must be divided by one million before multiplying it by a token count. Add any separately billed items afterward.
Find out what happens when requests fail
A failed request does not always mean no model work occurred. A connection might break after generation has started, or your application might retry automatically. Ask which failures are chargeable and how interrupted streaming responses are handled.
- Can an automatic retry create another billable request?
- Are charges based on generated output or only output received?
- Does the relay reserve credit before a request, and when is unused credit released?
- What evidence is needed to dispute a charge?
Check your coding tool's retry settings too. Repeated attempts can explain a balance drop that looks larger than one prompt should cost.
Confirm what your top-up actually buys
Before paying, ask about minimum top-ups, credit expiration, refund eligibility, and withdrawal rules. Find out whether promotional credit follows different rules from money you deposit. A displayed balance is only useful if you understand when and where it can be spent.
SwiftRelay is a pay-as-you-go relay with per-token billing, and new accounts receive a small gift credit. Sign up for SwiftRelay and use that starter credit to inspect your first few charges before committing a larger amount. Confirm the current credit terms rather than treating promotional credit as refundable cash.
Inspect the usage record before increasing your budget
A useful billing record should let you connect a request to its model, token counts, rate, and charge. Ask whether usage details are available in the dashboard or through an export, and whether balances update immediately or after a delay.
Run one small request, then compare its usage record with the published pricing. If the numbers do not reconcile, ask support before continuing. Keep the request identifier, timestamp, and model name; avoid sharing API keys or sensitive prompt content.
Set a spending boundary for your first run
Ask whether the relay offers spending limits, low-balance alerts, and separate keys for different projects. Check whether a limit stops requests or merely sends a notification. In your application, cap output length and avoid unattended retry loops.
Start with an amount you are comfortable spending entirely on testing. Once you can explain a charge from prompt to receipt, increasing your balance becomes a deliberate decision rather than a guess.