---
title: "The Free grant"
description: "The one-time Free allowance on a first Project: how you become eligible, what a grant now costs, what it includes, and what running out starts."
updated: "2026-08-29"
verifiedAgainst:
  - packages/shared/src/free-grant.ts
  - packages/shared/src/x-post.ts
  - apps/web/lib/server/free-grant-lifecycle.ts
  - apps/web/lib/server/acquisition-runtime-control.ts
  - apps/web/lib/server/free-opt-in.ts
  - apps/web/lib/server/x-post-verification.ts
  - apps/web/lib/server/free-grant-abuse-control.ts
  - apps/web/lib/server/bootstrap-security.ts
  - apps/web/app/api/sites/[siteId]/plan/free-opt-in/route.ts
  - apps/web/lib/server/acquisition-benefit-exclusion.ts
  - packages/shared/src/project-plan-selection.ts
  - apps/web/lib/server/site-tiers.ts
---

The Free grant is one lifetime allowance on an account's first Project. There is
no card and no countdown: it is a fixed amount of work, and it lasts until you
spend it.

Getting one is two separate conditions, and it is worth keeping them apart.

<PropertyList>
  <Property name="Eligibility" type="decided at signup">
    Whether your account may take Free at all. Written onto the account the
    first time you sign in, alongside the offer it was assigned, and never
    recalculated afterwards.
  </Property>
  <Property name="The grant itself" type="claimed at the plan step">
    Eligibility is permission to take it, not the thing itself. You still have
    to choose it on your first Project, and claiming it now asks for something
    in return. See [what it costs](#what-a-grant-costs).
  </Property>
</PropertyList>

<Callout variant="note" title="Which offer a new account gets is a setting, not a rule">
  Signup assigns an offer and, separately, marks whether the account may swap it
  for Free. Both come from a runtime setting that has been changed more than
  once, so this page deliberately does not claim what a brand new account is
  offered today. Your own plan step shows what your account actually holds. See
  [the trial](/billing/trial) for the other offer.
</Callout>

## One grant, one Project, once

The grant is issued to the account, and it lands on the first Project that
account creates. It is not per Project and not per workspace: a second Project is
a paid purchase from the start, and a second account is not a way to get a second
grant on the same work.

## What a grant costs

Free is not automatic any more. Claiming it asks for one public post on X, and
the plan step verifies that post before the grant is written.

<Steps>
  <Step title="Post it">
    The dialog suggests the text and fills in your blog address and our handle.
    You can rewrite it completely, and rewriting it is fine: only two things are
    checked, and both are named on screen.
  </Step>
  <Step title="Paste the link">
    Bring the link to your post back into the second field. The grant is written
    when that post passes.
  </Step>
</Steps>

A post qualifies when all four of these hold:

<PropertyList>
  <Property name="It is a real X post link" type="required">
    A status URL on `x.com` or `twitter.com`. A profile link or a search result
    is not one.
  </Property>
  <Property name="It mentions your blog address" type="required">
    The Project's live `blogged.dev` hostname. This is what ties the post to
    your account rather than to anybody else's.
  </Property>
  <Property name="It mentions our handle" type="required">
    `@blogged_app`. The address alone is not enough, because the address already
    ends in our own domain and would prove nothing on its own.
  </Property>
  <Property name="It was posted in the last 24 hours" type="required">
    Checked before the wording is, so an old post is never reported as something
    you could fix by editing it.
  </Property>
</PropertyList>

A post that has already been used to start somebody's free project cannot be
used again. That check is what makes one post worth exactly one grant.

<Callout variant="note" title="Not being able to read the post is not a refusal">
  The post is read through a public endpoint, and that read can fail on its own.
  When it does, the answer says so and asks you to try again in a few seconds.
  It is separated from a genuine rejection deliberately: a post that does not
  qualify is worth editing, and one we could not read is worth re-pasting
  unchanged.
</Callout>

<Callout variant="warning" title="If you cannot post on X">
  The dialog is dismissible and it blocks nothing. The plan cards stay behind
  it, so an account that will not or cannot post publicly takes the trial or a
  paid plan in the ordinary way. Declining costs you nothing except the Free
  offer itself.
</Callout>

The post is verified once, at the moment you claim, and the grant is not
re-checked afterwards. Whether the requirement applies at all is a runtime
switch: when it is off, no post is asked for and the opt-in simply appears.

## Why a claim can still be refused

The grant is fenced against being handed out repeatedly to the same person. Two
of those limits are ones an ordinary customer can meet.

<PropertyList>
  <Property name="One per account, one per email address" type="lifetime">
    The durable half. These are the two that genuinely mean the benefit was
    already used, so a second account on the same email address does not produce
    a second grant.
  </Property>
  <Property name="A cap per browser" type="lifetime">
    A shared-environment signal rather than proof of anything. It is counted
    against an identifier your browser stores. The exact cap is an operator
    setting rather than a published number.
  </Property>
</PropertyList>

<Callout variant="warning" title="A browser that blocks site storage cannot claim">
  The per-browser check needs an identifier the browser keeps for us. A browser
  with site storage blocked, or a hardened private window, has none to send, and
  the claim is refused with a message saying this browser could not be verified.
  It is not a message about your account, and nothing has been spent: allow site
  storage for the dashboard, or claim from an ordinary window, and try again.
</Callout>

Every other refusal is reported the same way, as the grant simply not being
available for this account, with a paid plan offered instead. That is
deliberate, so the refusals cannot be used to probe how the limits are counted.

## The allowance

<PropertyList>
  <Property name="Posts" type="3">
    Articles this Project may produce in total.
  </Property>
  <Property name="Topics" type="40">
    Topics this Project may generate in total.
  </Property>
  <Property name="Images" type="15">
    Generated images in total.
  </Property>
  <Property name="Competitors" type="7">
    Competitors tracked at once. This one is a standing limit rather than a
    running total: stop tracking one and the slot is free again.
  </Property>
  <Property name="AI article regenerations" type="0">
    Not reduced. Off.
  </Property>
</PropertyList>

## It never resets

This is the difference that matters most, and it is the one thing about Free
worth reading twice.

A paid plan's allowance is an amount per billing period, and it refills when the
period rolls over. The Free grant is a lifetime total for that Project. It has no
period start and no period end, so there is nothing for it to roll over into.
Three posts is three posts, not three a month.

<Callout variant="note" title="Nothing is lost when it runs out">
  Spending the grant stops production. It does not touch anything the Project has
  already made: the posts, drafts, topics, knowledge and assets stay exactly where
  they are, and the blog keeps serving.

  Running out of the posts or the images does start a clock, though, and it ends
  with the Project archived and the blog unpublished. That is set out in
  [what happens when a Free Project runs out](/workspaces/lifecycle), and it is
  the part of this page worth reading before you need it.
</Callout>

## What is included

Free is meant to show the product working rather than a sample of it, so the
automation is not what is held back.

- **Both Autopilot modes.** Assisted and Full. A Free Project can run in Full
  mode and carry a post through to publication, subject to the same Content
  Direction gates as any paid Project. See [Assisted and Full](/autopilot/modes).
- **Competitor Blog Watch**, up to the seven tracked competitors above. See
  [Competitor Blog Watch](/growth/competitor-watch).
- **Newsletter lead capture**, including the subscriber list it builds. See
  [lead capture](/growth/lead-capture).
- **A live blog.** The Project's `blogged.dev` address is published from creation,
  not held back until you pay.

## What is not included

Five features are paid only. They are connection and convenience features rather
than the engine, and each one refuses in the same way.

| Feature | Where you meet it |
| --- | --- |
| Renaming the `blogged.dev` address | [Your Blogged address](/blog/subdomain) |
| Connecting a custom domain | [Custom domains](/blog/custom-domain) |
| Search Console | [Search Console](/analytics/search-console) |
| AI article regeneration | [Revisions](/content/revisions) |
| Scheduling a post by hand | [Scheduling](/autopilot/scheduling) |

<Callout variant="note" title="The refusal is an upgrade prompt, not a limit message">
  These are not metered down to zero. They are switched off, so the answer says
  the feature needs a paid plan rather than telling you that you have used
  something up. If you see a quota message instead, you are at an allowance, not
  at one of these.
</Callout>

Sending a team invitation is also unavailable while a workspace's only Project is
on the grant, for a different reason: invitations are gated on the workspace
holding a subscription, and a Free workspace has none. See
[roles and access](/workspaces/roles).

## Upgrading converts that Project

Putting a plan on a Free Project converts that exact Project, permanently. The
grant is marked converted and does not come back.

<Callout variant="warning" title="A grant is never reissued">
  Archiving the Project, deleting it, or cancelling the subscription afterwards
  does not return the grant to your account. The one lifetime benefit was spent
  on that Project when it converted. Nothing about a Free Project is worth
  discarding in the hope of starting the allowance again, because that is not
  what happens.
</Callout>

Upgrading is also what lifts the allowance. The charge is raised immediately and
the plan's own numbers, on the plan's own period cadence, arrive once that
payment is confirmed. Everything the Project already produced stays in it. See
[changing a plan](/billing/change-plan) and
[what checkout can refuse](/billing/checkout).

## An invited account gets no grant

If the first thing you ever do in Blogged is accept an invitation to somebody
else's workspace, your account is recorded as having arrived that way and no
signup benefit is issued to it, then or later.

This is deliberate: an invitation would otherwise be a second signup path that
also handed out a grant. It is worth knowing before you accept, because it cannot
be undone. If you want your own Free Project as well, sign up for your own
account first and accept the invitation afterwards.

## Free Projects and pricing

A Free Project has no price, so it holds no position in the multi Project
discount ladder and cannot deepen anyone else's rate. It also contributes nothing
to a workspace invoice. See [discounts](/billing/discounts) for how positions are
counted, and [creating a Project](/workspaces/projects) for adding a paid Project
beside a Free one.