Limits are the least loved part of any AI product and the least explained. "3 apps a day" reads like stinginess until you know what a generation costs and what would happen without the cap. This guide explains the four limits a ContentForger generation passes through, what each one is protecting, and the working habits that make them invisible in practice.
Every generation costs real money
The root fact is simple. Each run sends your prompt plus a long system instruction to a model provider and pays per token in and per token out. ContentForger records the input tokens, output tokens and a cost figure for every generation; that is why your dashboard shows token counts against each run. A tool with no limits is a tool that has handed its credit card to the internet.
So limits are not a growth hack. They are how a $0 tier can exist at all, and how a $29 tier can promise a hundred runs a day without the price moving.
Limit one: the daily count
Free allows 3 new apps a day plus 10 change requests, Pro 100 apps and Agency 1,000. The count is taken from your history since 00:00 UTC, so it is a calendar day and resets at the same moment for everyone. It counts builds you started, not builds that finished, because the record is written at the start; a stopped or failed build still counts.
What it protects: the per-user cost of the tier. Why that design: counting at the start means a user cannot avoid the count by cancelling at ninety-nine percent.
How to live with it: plan a session as one clear prompt plus a few narrow change requests; on Free, changes have their own allowance of 10 a day.
Limit two: the output per batch
Until October 2026 each run had a fixed output budget, and a run that reached it stopped with the last file cut off. ContentForger now plans each app first and writes the files in batches of six, with a ceiling per batch, saving every file the moment it is finished.
What it protects: the cost of a single run, and the latency. A model left to run without a ceiling can produce an enormous answer to a small question.
How to live with it: you mostly do not have to. If a build stops part-way, open the same build link and it carries on from the last saved file.
Limit three: the hourly request limit
Independently of plan, the generate endpoint accepts twenty requests an hour from one network address on a sliding window, and the brief tool shares that allowance.
What it protects: the service from abuse by scripts, and the daily count from being gamed through many accounts on one connection.
How to live with it: you will rarely notice it alone. On a shared connection, a team can hit it collectively; the response is a plain "Rate limit exceeded", and waiting is the only remedy.
Limit four: the monthly spend ceiling
There is a single ceiling on total model spend across all users for the month. When it is reached, generations answer "Service temporarily at capacity" on every plan until the first of the next month, UTC. An alert goes to the operator when spend passes eighty percent of the ceiling, so in practice it is raised before it bites.
What it protects: the business. A bug, an attack or a very popular day should degrade the service, not end the company.
How to live with it: you cannot, and you should not have to. If you see this message, it is not about your account; try again later.
A fifth constraint: how much you can type
Separate from all four, each input has a maximum length. A Generate prompt is between 1 and 4,000 characters; a brief idea between 5 and 2,000; the anonymous demo between 10 and 500. These are not cost limits so much as sanity limits: a prompt past 4,000 characters is usually a specification that should be split into a first prompt and follow-ups anyway. The practical effect is that a very long pasted document is rejected before anything runs, with an "Invalid input" response rather than a model error, and nothing is counted against your day.
Why the limits fail closed
Here is the design choice that matters most and gets explained least. When ContentForger cannot read your usage, because the database did not answer, it refuses the generation rather than assuming the count is zero. You see "temporarily unable to verify your usage, please retry" with a sixty-second hint, and the status is 503, not the daily-limit 429.
The alternative, assuming zero on error, is how spend guards quietly stop guarding. A guard that treats "unknown" as "fine" is not a guard. Denying for sixty seconds is recoverable; an unmetered model bill is not. The brief tool and the Agency API apply the same rule.
Reading the messages
- "Daily generation limit reached" (429): you have used today's count. It resets at 00:00 UTC.
- "Rate limit exceeded": the hourly per-address limit. Wait a while.
- "Service temporarily at capacity" (503): the monthly ceiling. Not about you.
- "Temporarily unable to verify your usage" (503): a lookup failed. Retry in a minute.
- A generation that just stops mid-file: the output budget. Ask for the file again.
Choosing a tier by its limits
The three plan numbers are the whole pricing story once you understand them; How AI App Builder Pricing Works walks through that. For the exact behaviour of each limit, including the Agency API's shared daily counter and the scheduled-build runner's exceptions, see Plans, Limits and the Agency API Explained.
Limits well understood stop being limits. They become the grid you plan on.
