Plans, Limits and the Agency API Explained

Everything in this chapter is taken from the pricing page at /pricing. Where the product's behaviour adds detail, that is marked.

Free, $0 a month:

Pro, $29 a month:

Agency, $99 a month:

The pricing FAQ adds four facts. You can cancel at any time and the plan stays active through the current billing period. A full refund is available within 7 days of the first payment. Accounts are single-user; team seats are on the roadmap, not available today. And there is no fixed token cap per app: each app is planned first and written file by file.

Two clarifications from the product itself. "Claude Opus 5.5 (+ Sonnet 5.5 via API)" on Agency means the web app uses Opus for every Agency generation, while the REST API lets you choose sonnet or opus per call. And the watermark on Free is a "Built with ContentForger" comment the generator is asked to place in the footer of the code; it is a comment, not a visible badge, and Pro and Agency output is not asked to include it.

A single generation is subject to four independent limits. They reset on different schedules and they fail with different messages, so it pays to know all four.

The daily allowance. 3, 100 or 1,000 new apps by plan (Free also gets 10 change requests a day), counted from your history since 00:00 UTC. This is a calendar day in UTC, not a rolling 24 hours; wherever you live, the count returns to zero at 00:00 UTC, so work out once what that is in your local time. The count includes every generation you started, including ones you stopped or that failed, because the record is written when the run begins. When you are at the limit the response is a 429 with "Daily generation limit reached", and the Generate page shows a toast suggesting an upgrade. Your Settings page shows the live figure as "Generations today X / Y".

The hourly request limit. Twenty requests an hour per network address, sliding window, on the generate endpoint, shared with the brief tool. This applies before your plan is even looked up. On a shared office connection several people can exhaust it together. It shows as a bare "Rate limit exceeded".

The output per batch. Apps are written six files at a time with a ceiling per batch, and each file is saved as soon as it is complete. There is no fixed cap per app; if a build stops part-way, reopen its link and it resumes.

The monthly spend ceiling. A single, site-wide ceiling on model spend across all users, resetting on the first of the month UTC. When it is reached, generations answer 503 "Service temporarily at capacity" for everyone, on every plan, until the new month. This is rare by design and it is not about your account.

One more response is worth distinguishing from all four. If the service cannot read usage at all, it refuses and says "temporarily unable to verify your usage, please retry" with a sixty-second retry hint. That is a 503. A 429 means wait until tomorrow; this 503 means try again in a minute.

The AI Project Brief tool at /brief is Pro and Agency only and is not a generation: it does not write a history row and does not count toward the daily allowance. It does share the hourly request limit and the monthly ceiling.

Upgrades run through Stripe Checkout. The Go Pro and Upgrade buttons on /pricing, and the two buttons on /settings for Free accounts, link to a checkout route with the tier in the address. If you are signed out you are sent to sign in and then straight back to checkout. If you already hold a live subscription you are redirected to the billing portal instead of a second checkout, so you cannot accidentally pay for two plans.

After payment you land on /settings with an upgraded flag, and a welcome email follows. Your plan is set from the price you actually paid, not from the button you clicked; the webhook that grants access reads the subscription's price and maps it to Pro or Agency. If the price cannot be mapped, access is deliberately not granted and the failure is logged for a human to look at, rather than guessing a plan.

Changing or cancelling happens in the Stripe billing portal, reached from the Billing section on /settings. Cancelling keeps the plan active to the end of the paid period, as the pricing FAQ states. When a subscription ends, your plan returns to Free and you receive an email saying so. Your history and saved generations are not removed by a downgrade; only the daily allowance, model and features change.

Refunds: within 7 days of your first payment, per the pricing FAQ. After that you can cancel but there is no refund.

API access is at Agency, then API Access, which is the page /agency/api. It is available only on the Agency plan; any other plan receives "Agency plan required".

Press Generate key. The key is a string beginning with cf_ followed by 64 hexadecimal characters. It is shown once, on that screen, with a copy button. The product stores only a SHA-256 hash of it plus the first few characters as a preview, so nobody at ContentForger can read your key back, and neither can you. If you lose it you regenerate.

Regenerate creates a new key and invalidates the old one at the same moment; there is one key per account, not a list. Revoke removes the key entirely and the API refuses all calls until you generate a new one.

Treat the key as you would any secret: keep it in your own environment variables or secret store, never in a repository, and never in a prompt.

The REST API has one endpoint. It accepts a JSON body and returns JSON; it does not stream and it does not support conversation history. Authentication is a Bearer header carrying your key.

curl -X POST https://contentforger.com/api/v1/generate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Build a landing page with a pricing table", "style": "minimal", "model": "sonnet"}'

Body fields:

The response has three fields: code, which is the complete output as one string in the ---FILE: marker format the web viewer parses; model, the full model identifier that ran; and usage, with inputTokens, outputTokens and costCents. Splitting the code string into files is your responsibility; the format is one marker line per file followed by a fenced block.

Your white-label settings are applied to every API generation. Each API call writes a history row and counts against the same 1,000 a day as the web app; there is one daily counter per account, not one per channel. Prompts are run through the same content-policy check as the web app.

Status codes as the endpoint actually returns them:

Note that the docs page at /docs/api describes 401 as "missing or invalid API key"; in the current build an invalid key is a 403. Code your client to treat both as "re-check the key".

Scheduled builds live at Agency, then Scheduled, which is /agency/scheduled. A schedule has a name, a prompt of up to 4,000 characters, and a five-field cron expression in UTC. The form's default is 0 9 * * 1, every Monday at 09:00 UTC.

How it runs. The service checks all enabled schedules every fifteen minutes. A schedule is due when its most recent cron occurrence is later than its last run (or its creation time if it has never run), so a 09:00 schedule will run at the first check after 09:00, within the following quarter hour. At most ten due builds are run per check; any beyond that wait for the next check. An expression the parser cannot read is never run; it is logged on the server, but the page itself shows no error, so double-check the five fields when you create one.

What it produces. Every scheduled run uses Claude Opus 5.5 and your white-label settings, writes a normal row to your dashboard history with status completed, and sends you an email saying the build finished with a link to the dashboard. Open the row from /dashboard to read or copy the code.

Two honest limitations of the current build. The Scheduled page lets you create and delete schedules but not edit or pause one; to change a prompt, delete and recreate. And the scheduled runner does not pass through the daily-allowance or monthly-ceiling checks that the web app and API apply; its rows do appear in your history and therefore in your daily count, but a scheduled run itself is not refused when the count is high. Keep that in mind when choosing a cadence.

White-label is configured at Settings, then White-Label, which is /settings/white-label. There are three fields: brand name, logo URL and primary colour. Saving requires the Agency plan. Once saved, every Agency generation, whether from the web app, the API or a scheduled build, carries instructions to use your brand name in headers, footers and metadata instead of ContentForger, to use your logo URL and primary colour where given, and not to mention ContentForger or NorwegianSpark anywhere in the code.

Those are instructions to the model, so verify them. A quick search of the downloaded project for the word ContentForger before you hand anything to a client takes seconds and is the only real proof.

The client dashboard at /agency/clients records a name, optional email and company for each client and shows a count of projects attached to them. There is also a per-client white-label toggle in the Clients view under /dashboard. The journal tutorial White-Label Your ContentForger Output for Agency Clients walks through delivering a branded build end to end.