What a campaign pack contains
A single post is rarely the unit of work. A launch needs one strong opening post, a handful of supporting posts to keep the thread alive over the following days, several hook variants so you can test which opening line earns attention, and a set of calls to action worded differently for different placements. This workflow returns all four in one run, split into labeled sections rather than run together.
The inputs mirror how campaigns are actually briefed. There is a field for the product and campaign context, one for the offer and the campaign window, one for the audience, and one for tone. The offer field is the one people skip and then regret: a discount, a deadline, or a bundle changes the shape of every post in the pack, and a model that does not know about it writes generically.
Output format is selectable. The campaign pack layout keeps the sections as headed blocks, markdown is convenient if the copy is going into a document or a repository, and the split format returns posts, hooks, and calls to action as separate lists for pasting into a scheduler.
- Main post, supporting posts, hook variants, and CTA variants in one run
- Offer and campaign window are separate inputs, not an afterthought
- Pick campaign pack, markdown, or a split list format
Where your text goes, stated plainly
This page does not process anything locally. Everything you type, including the brief, the product context, the offer, the audience, and the tone, is sent over HTTPS to a Cleanor server, which builds a prompt, calls a language model provider, and returns the answer. There is no offline mode, and it would be untrue to say your text stays on your device here.
That changes what belongs in the form. Unannounced launch dates, embargoed pricing, partner terms, and anything covered by an NDA should not go in. Product facts you are about to publish anyway are exactly the right material.
Runs are recorded against your account: the inputs, the generated output, and a separate metering row with token counts and cost. That is what makes it possible to find a good run again later, and it is also a reason to be deliberate about what you submit.
Sign-in, credits, and the guardrails
The workflow requires a signed-in account on a plan that includes monthly AI credits, and each run deducts from that allowance. If credits run out, the request is refused with a message that says so rather than returning an empty result.
Rate limits sit on top of that. Each account is capped to a small burst of runs in a five minute window and a larger number per hour, which protects your own allowance from an accidental loop. Beyond individual accounts, the site as a whole has a daily ceiling on both run count and spend, so during a busy day a request can be deferred to the next.
None of this is hidden. An AI endpoint without a spend ceiling is a bill waiting to happen, and the caps are what keep this workflow usable without a per-run charge attached to it.
- Sign-in and a plan with AI credits are required
- Per-account burst and hourly limits protect your allowance
- Site-wide daily run and spend caps can defer a request