Abuse and spend protection
Everything TrueTone generates has a real cost behind it. So generation is fenced in from several directions at once: a credit allowance you spend down, a size limit on any single request, an account-level spending cap, and automated screening that turns away bots and floods of requests. No mistake, runaway loop, or bad actor can quietly run up an open-ended bill.
What it is
When you create a blog post, an audiogram, or a video, TrueTone hands the work to outside services that actually produce it, and those services bill by the size of the job. Left unchecked, a single oversized or repeated request could cost far more than intended. This page explains, in plain terms, the layers that keep that from happening.
None of these layers depend on you remembering to turn anything on. They apply to every account by default and work together, so if any one of them were ever to miss a case, another still holds the line.
| Layer | What it protects against |
|---|---|
| Credit allowance | Spending more than your plan includes. Every action is paid for from your credits before it runs, and when they are gone, generation stops. |
| Bounded request size | One oversized request costing far more than a normal one. Generation requests carry a size limit, and a flat price per content type keeps what you pay fixed regardless. |
| Account spending cap | Total monthly generation spend running away, even across many small requests. |
| Per-seat limits | One loan officer on a company account draining the shared pool. |
| Rate limiting | A person or script hammering the generation tools too fast. |
| Bot protection | Automated, scripted, or non-human traffic reaching the tools at all. |
Who it is for
Loan officers
You want to know that a slip of the finger, a stuck browser tab, or someone else cannot burn through your credits. The credit allowance and the request-size limit are the two that touch you most directly.
How a request is protected
Here is what happens, in order, the moment you ask TrueTone to generate something. Most of it is invisible. You only notice a layer when it stops something that should be stopped.
Automated traffic is screened out
Before anything else, the request is checked to confirm it is coming from a real person using the product, not a script or bot. Traffic that fails this screen is turned away before it can reach the generation tools or cost anything.
The pace is held in check
The tools that generate content are rate-limited, so no single account or source can fire requests faster than a real person ever would. This blunts both accidental loops and deliberate floods.
Your allowance is checked and reserved
Generation is metered in credits. The credits for an action are set aside before the work is handed to the outside service, never after. If you do not have enough, the action does not run. This is the fundamental bound: you cannot spend past your allowance, by design.
The request size is capped
Generation carries a limit on how large a single request can be, and a request that runs past it is declined with a clear message rather than quietly trimmed or split into several smaller jobs behind your back. Together with a flat price per content type and your finite credit allowance, this keeps any one action from carrying a surprise cost.
The account spending cap has the final say
An organization can set a monthly spending cap. As total generation spend approaches it, an admin is warned, and once it is reached, further generation is held until the next period or the cap is raised. This is the backstop that catches spend building up across many ordinary requests.
Fixed, knowable prices
Every content type costs a fixed number of credits, and you see that number before you generate. The price does not float with the length of what you write or how long a video runs. A short piece and a long one of the same kind cost the same, so the cost is always known up front and never a surprise afterward.
This is a deliberate choice. A credit allowance is only useful if you can plan against it. A price you cannot predict until the work is done is not a budget you can reason about, so TrueTone does not have one.
The size limit on a request is not a limit on how much you can create overall. It caps a single generation so its cost stays predictable. If a piece is too large to process in one pass, you will be told plainly, rather than handed a quietly shortened result or an open-ended bill.
The same meter, whichever door the work comes through
Work does not have to come from the dashboard to be metered. Content created through the TrueTone API or by an AI assistant connected through the TrueTone Connector spends the same credits, from the same allowance, under the same spending caps and per-seat limits, as the same work done in the app. There is no headless side door around the meter. Your billing activity records which lane each action came through, so spend driven by a connected assistant is visible for exactly what it is. And before any of that, what a key or connection may do at all is bounded by the Capability Groups granted when it was created; see API keys and AI connections.
Good to know
A few honest notes:
- A refusal is sometimes the right answer. Capping request size means a small amount of legitimate, unusually large content can be declined. That is intentional. A clear “this is too large” beats a runaway cost or a degraded result stitched together from pieces.
- Spending caps and per-seat limits are configured, not automatic amounts. Your credit allowance always bounds spend on its own. The account spending cap and per-seat limits are additional ceilings an org admin sets. During onboarding, some of this is set up together with TrueTone while the self-serve admin panels roll out. The controls themselves are live and enforced.
- Numbers stay out of this page on purpose. Exact rate limits, thresholds, and internal cost figures are deliberately not published here, because they would help someone probe for the edges. What matters for a trust decision is that the limits exist, apply to everyone, and hold.