Usage and caps
What counts, where to see it, and what happens at the ceiling.
Where to look
Billing shows the current period's published-post count against your plan cap, and Activity lists the individual actions behind it. If a number looks wrong, Activity is where you find out why — every action is there with its outcome.
What counts
| Action | Counts? |
|---|---|
| A post that published | Yes |
| A scheduled post, once it publishes | Yes |
| An update to an existing post | No — the cap is on published posts |
| An action waiting in the approval queue | No |
| A rejected action | No |
| A failed action | No |
| A duplicate call collapsed by idempotency_key | No — it returns the original action |
Reaching the cap
Publishing stops for the rest of the billing period and the agent gets an explicit error rather than silence. Nothing already published is affected. Upgrading raises the cap immediately; otherwise it resets at the start of the next period.
Per-key caps
You can also set a monthly cap on an individual agent key. That is independent of the plan cap and is the way to stop one automation consuming the whole allowance. A key that hits its own cap stops; the rest of the workspace keeps working.
Keeping usage sane
- Pass idempotency_key on every publish, so a retrying workflow does not spend the cap twice.
- Give scheduled bulk jobs their own key with its own cap.
- Use update_post to fix a post instead of publishing a second copy.