How long does an AI presentation take? We timed 58.

The answer is four minutes forty. That is the median wall-clock time for 58 slide decks generated by our production pipeline, measured from the moment the job was created to the moment a finished file existed. Forty-six of the 58 landed inside six minutes. The slowest took 1,432 seconds — just under twenty-four minutes. Nothing at all arrived in under two.

Every figure on this page came out of a database rather than out of a marketing meeting, and the section at the bottom says where each one is stored and how it was calculated. The sections in between say what those minutes are actually spent on, what makes a slow deck slow, and — the part most of this category avoids — what we measured that we could not explain.

What the number measures, exactly

A timing is only checkable if somebody says where the stopwatch starts and where it stops, and that is the part usually left out. Ours starts when the job row is written — which happens the instant somebody submits, before any provider is called — and stops when the file exists and is openable. Two columns on one table, subtracted.

SELECT (delivered_at - created_at) / 1000 AS secs
  FROM studio_jobs
 WHERE kind = 'deck'
   AND state = 'delivered'
   AND delivered_at IS NOT NULL
   AND delivered_at > created_at
 ORDER BY secs ASC

One thing this number is not. delivered_at is stamped once, when the file is first written — and our pipeline delivers twice. The first delivery is a complete, branded, laid-out presentation built from the writing alone. The illustrations arrive afterwards and the same file is rebuilt in place, under the same link. So 4 minutes 40 seconds is the time to a finished file with the words in it, not the time to the fully illustrated one. We say more about that gap, and about why we cannot put a median on it, further down.

The whole distribution

A median on its own is a claim. Here are all 58, bucketed by minute.

The useful reading is not the median. It is that the distribution has a hard floor and a long tail, which is what you would expect from a process where the fast part is bounded by how quickly a language model can write several thousand words and the slow part is bounded by nothing you control. Any vendor quoting you a single number for this is quoting you the left-hand side of that shape.

What is actually happening in those minutes

A generated presentation is two jobs wearing one progress bar: writing it, and illustrating it. They have completely different clocks, and the one most people expect to dominate is not the one that does.

We timed the writing stage separately, on live infrastructure, through the same functions the product calls. These are the figures on record.

Set 254.9 seconds against a median of 279.5. On a typical deck, the writing is roughly nine tenths of the wait and the layout, the file assembly and the PDF conversion share what is left. Illustration is not in that number at all, because the file is delivered before the pictures start. Subtracting one from the other leaves roughly twenty-five seconds for everything else — laying the slides out, writing the .pptx, converting a PDF copy and storing both. That is an inference across two different runs rather than a measurement, and it is the only figure on this page arrived at by subtraction. What happens inside it is a separate piece of work: what PowerPoint accepts in a hand-built .pptx, and what silently breaks.

The reason a deck writes so much more slowly than a document is not that it has more pages. It is that a slide carries fragments and a presenter needs sentences, so every slide is written twice — once for the screen and once for the notes pane — on top of chart series, figures for the statistics pages and named steps for the process pages. A deck is not a document with the paragraphs cut short.

Why the pictures are on a separate clock

Painting original artwork for a deck is slow, expensive and outside our control, so the pipeline is built around not making anybody watch it. The file is assembled and handed over as soon as the writing is laid out; the illustrations then arrive over the following minutes and the same file is rebuilt behind the same link.

Individual image generations, measured on the last fully illustrated deck, took 46, 61, 69 and 136 seconds. That spread is the whole story: the same request, to the same provider, on the same day, varying by a factor of three depending on how busy the queue was.

Do the arithmetic on a deck that wants eight pictures: three at a time, at 46 to 136 seconds each, is three rounds — somewhere between two and seven minutes of illustration after the file has already been delivered. That is the part nobody's homepage mentions, and it is the part that decides whether the deck you present looks made for you or looks like a stock library.

What makes a slow one slow

Twelve of the 58 took longer than six minutes. From our own logs, four things put a deck in that group, in roughly descending order of how often we have seen them.

The brief was heavy

Writing time scales with what the model is asked to produce, and a brief with more to say produces more slides, each carrying speaker notes. Our slowest recorded write, 456.6 seconds, was a deliberately heavy brief. Our controlled runs on an ordinary one finished in 189 to 314 seconds. Same code, same day.

The writing provider had a slow hour

We have watched two live jobs time out at 601 seconds against a 600-second deadline in one morning, while a controlled six-run set on the same day completed six of six in 189 to 314 seconds. The tail belongs to the provider's hour, not to the pipeline's build. Our own deadline for the writing stage has been raised three times as a consequence — 90 seconds, then 240, then 600, and now 900 — and each raise was made against a measured figure rather than a guess.

The picture queue was full

A refused generation is deferred to the next tick rather than retried immediately, because the provider returns a refusal as a non-retryable error. That is correct behaviour and it costs minutes. Before we understood the account's concurrency limit, roughly a third of every picture the product had ever made was being lost to it.

Nobody was watching

The engine is advanced by whoever asks — usually the browser, polling. Close the tab and the job is advanced instead by a cron that runs every five minutes, so a job with nobody watching spends most of its wall time waiting rather than working. Our own measurement includes that waiting, deliberately: it is what a customer experiences, and the alternative is a number that flatters us.

Why "instant" is a different product, not a faster one

You will see decks advertised in seconds. Some of those claims are true and mean something other than what a buyer assumes. Here is the test, and it is arithmetic rather than opinion.

An original image takes tens of seconds to render — 46 seconds at the fast end of what we have measured, 136 at the slow end. On those figures, a deck carrying eight freshly generated pictures cannot be finished in ten seconds, because the constraint is the image model rather than the software wrapped around it, and nobody's software makes somebody else's model faster. So a presentation that appears instantly is doing one of four things:

• It is not generating pictures at all — the visuals are stock photography, icon sets, or coloured shapes from a template.
• The pictures were made earlier, for someone else, and are being reused. This is the most common one and it is why generated decks in the same tool look like each other.
• It is generating text into an existing template, which is genuinely fast and is a real product — just not the same product.
• The pictures arrive later, as ours do. That is honest if the vendor says so, and misleading if the headline number quietly excludes them.

There is a second reason to distrust a very fast result, and it is the strangest thing in our dataset. The fastest deck responses we have ever recorded were failures. Five deck jobs have failed outright; their durations were 0, 2, 2, 8 and 13 seconds. A refusal comes back in seconds and a real deck does not. If a tool answers you immediately, the first thing to check is that it answered with a deck.

What we could not determine

A page that only reports what worked is an advert. These are the things we went looking for and could not answer from this dataset.

What to ask a vendor

If you are comparing tools, or deciding whether to wait for a generated deck or brief a designer, these are the questions that separate a measured product from a confident one. Each of them exists because answering it about our own product was harder than we expected.

Where every number on this page comes from

So that this can be checked rather than believed.

If you want to reproduce this against your own tooling, the whole method is two columns and a sort: record a timestamp when the job is created, record another when a file first exists, subtract, sort, and publish the buckets rather than the average. It took us longer to decide what the number meant than to compute it.