---
title: "Generated images"
description: "How images are generated for articles, how many an article may carry, the style and reference controls, and how text inside a picture is handled."
updated: "2026-08-29"
verifiedAgainst:
  - packages/shared/src/post-images.ts
  - packages/shared/src/free-grant.ts
  - packages/shared/src/assets.ts
  - workers/lib/image-fact-grounding.ts
  - apps/web/app/api/posts/[postId]/suggest-images/route.ts
---

When no approved asset fits a section, an image can be generated for it.

## How many an article can carry

<PropertyList>
  <Property name="Four images per article" type="maximum">
    The ceiling on section images attached to one article. It is a per article
    limit and it is not raised by your plan: a plan buys you more images across
    the Project, not more images inside one piece.
  </Property>
  <Property name="One image per article" type="minimum on a generated draft">
    A drafting run asks for at least one useful visual rather than treating
    images as optional decoration.
  </Property>
  <Property name="Three reference assets per image" type="maximum">
    How many of your own approved assets can be handed to the model as visual
    reference for a single image. This is a separate constraint from the four
    above.
  </Property>
</PropertyList>

## Style

<PropertyList>
  <Property name="ai_recommended">
    Let the pipeline choose per image.
  </Property>
  <Property name="vector">
    Flat, graphic, diagrammatic.
  </Property>
  <Property name="illustration">
    Drawn, editorial.
  </Property>
  <Property name="photorealistic">
    Photographic.
  </Property>
</PropertyList>

Style is a Project setting, so a blog does not alternate between three visual
languages by accident.

## References

Generation can be guided by your own approved assets, so generated visuals
resemble your product rather than a generic dashboard. This is the setting that
makes the difference between illustrations that look like your software and
illustrations that look like everyone's.

## Budget

Image generation is metered per Project, alongside posts and topics. On a paid
plan the budget refills with the billing period; a Free Project's 15 images are a
one-time lifetime total that never refills.

When the image allowance is spent, articles are produced without generated images
rather than failing. See [usage and limits](/billing/usage).

## Replacing a generated image

Replacing one in the editor queues the work on the same durable queue automatic
generation uses, so a manual replacement is paced with everything else rather
than jumping the queue or timing out in the browser.

### Replacing one on a post that is already live

You can regenerate a section image on a post that is already scheduled or
published, and the replacement is checked like any other: it gets a real quality
verdict rather than being left permanently marked in progress.

<PropertyList>
  <Property name="The post stays where it is">
    Checking a replacement never unschedules or unpublishes the post. Whatever
    state the post was in, it stays in.
  </Property>
  <Property name="The current image keeps serving">
    Readers continue to see the image that is there until a replacement is
    actually ready, so a live article is never left with a gap while work runs.
  </Property>
  <Property name="One bounded retry">
    If the check is not satisfied, one replacement attempt may follow. It is
    bounded on purpose rather than looping.
  </Property>
</PropertyList>

<Callout variant="note" title="This applies to images you regenerate by hand">
  Automatic image work still stops at scheduling or publication, and so does
  anything to do with an image you uploaded. The exception is deliberately
  narrow: it covers exactly the image a person asked to be regenerated on a post
  that is already out, which is the one case where an unchecked picture would
  otherwise go live and stay marked as pending forever.
</Callout>

## Words inside a picture

Text baked into an image cannot be corrected later the way a sentence can, so
how much readable copy an image carries is decided per image rather than left
open.

This is not a setting you choose. The pipeline picks one of three modes for each
image as it plans it, and the default is no readable copy at all.

| Mode | What it means |
| --- | --- |
| **None** | The visual carries no readable copy. This is the default and the most common answer. |
| **Minimal** | A few short conceptual labels, capped in both count and length. Labels only, and nothing that asserts a fact. |
| **Verified caption** | The image is allowed to state something checkable. |

<Callout variant="note" title="What verified means here">
  It means grounded, not proofread. An image whose copy states a hard fact is
  treated as fact bearing, and its wording has to be supported by the article's
  own authoritative text rather than invented by the model to fill the space.
  The same treatment is triggered by a brief that asks the pixels to communicate
  checkable data, even when the mode itself is more modest.

  You will also meet an older mode named verified overlay on images generated
  before this was reorganised. It is kept so existing posts keep rendering;
  nothing new is written with it.
</Callout>

Where an image does carry required copy, the editor shows you the exact strings
alongside the image card, so what the picture is supposed to say is reviewable
next to the article rather than only visible in the rendered image.