The obvious fix is to put them behind one text box. That sounds like a UI decision. It is not. Once a single prompt field has to serve image, video, voice and 3D, three genuinely hard problems show up, and none of them are about layout.

Problem 1: the modalities disagree about what a prompt is

A good image prompt is a dense noun phrase. Adjectives, materials, lighting, lens. Nothing about time, because there is no time.

a worn brass desk lamp, single hard key light from the left, dusty highlights

A good video prompt is a verb phrase with a camera in it. The same noun phrase produces a static shot that technically moves.

a worn brass desk lamp; camera pushes in slowly as the filament flickers on

A good 3D prompt is neither. It is a set of geometric constraints, and half the adjectives that improve an image actively hurt it — "dusty highlights" is a texture instruction with no geometry behind it, and "hard key light" is meaningless in a mesh.

a desk lamp, hollow base, flat bottom, thick shade walls, no thin wires

A voice prompt is a performance direction: pace, register, emphasis.

So a single prompt box is lying a little. The same sentence cannot be optimal in four places at once. The design question is what to do about that, and there are three honest answers:

1. Make the user rewrite it per modality. Correct, and nobody does it.

2. Rewrite it silently. Fast, and it hides why a result was bad.

3. Rewrite it and show your work. Slower, and the only option where the user learns anything.

The third is what "agent" should mean in practice: the thing plans, tells you what it is about to do, and lets you disagree before spending the compute.

Problem 2: each modality fails in an unrelated way

The failure modes have almost nothing in common, which means one generic error state is useless:

That last row is the one people underestimate. A 3D render can look flawless while the underlying mesh is unusable — hundreds of thousands of triangles, disconnected shells, no consistent scale. The render is not evidence about the geometry. Any tool that shows you only the pretty picture is answering a different question from the one you asked.

Problem 3: chaining is where the value is, and where the state lives

The single-modality workflow is: prompt, generate, download, done.

The interesting workflow is: generate an image, keep that exact subject, put it in a scene, animate it, add a voice over it, and separately turn the subject into a mesh.

Each arrow in that chain is a place where identity has to survive. That is a state problem. The system has to carry a persistent handle on "this specific thing" across model boundaries that were never designed to agree with each other. Tool-hopping loses that handle at every step, which is why the manual version of this workflow produces four assets that do not quite look like the same object.

Keeping the chain inside one project is not a convenience feature. It is the only place the continuity can live.

What this implies for exports

If the chain is the point, the exports have to be ordinary files — MP4, PNG, WAV, OBJ, GLB — and they have to be downloadable without ceremony.

A generation tool that will not hand over the file is not a tool, it is a demo. This matters most for 3D, where the file is the entire deliverable: nobody wants a mesh they can only look at inside someone else's viewer.

The short version

Putting four modalities behind one prompt is not a consolidation exercise. It requires the system to translate intent per modality, surface modality-specific failure honestly, and keep subject identity alive across model boundaries. Get those three right and the single text box is genuinely simpler. Get them wrong and you have built four tools that happen to share a font.

If you want to see what the chained version feels like — including AI 3d creation that hands you a GLB rather than a viewer link — the first render is free, which is about the right amount of commitment for finding out whether the unified version is worth it.

That framing misses what the date actually means. An EOL date is not an expiry stamp on a carton. It is the moment a version stops receiving fixes while the rest of the world keeps finding reasons it needs them.

The number that reframes it

Across 477 tracked products and 8,754 versions, 78% are already past end of life. Another 179 versions cross the line within 90 days.

Taken alone that sounds like ordinary software entropy — old things are old. The number that changes the conversation is a different one: how many vulnerabilities were published against a version after its support ended and fixed only in newer branches.

MySQL 5.7 went EOL in October 2023. In the three years since, 127 CVEs have been published that it will never receive a fix for. Go 1.16, dead since March 2022, has missed 111. Go 1.17 has missed 106. MySQL 8.1 has missed 103 in under three years.

Those are not theoretical exposures accumulating slowly. That is a running total of known, published, named problems in software that a great many production systems are still running right now.

Why the count keeps climbing after death

This is the part that is easy to get backwards. A version does not become vulnerable the day it goes EOL. It becomes vulnerable at the same steady rate it always was — researchers keep finding things, the upstream project keeps fixing them in current branches, and the dead version simply stops being on the list of places the fix gets applied.

So the risk of running an EOL version is not flat. It grows, monotonically, for as long as you keep running it. A version that was two CVEs behind at EOL is a hundred behind three years later. Nothing about your deployment changed; the gap widened underneath it.

That is why "we will upgrade when we have a reason" is such an expensive posture. The reason accumulates silently and only becomes visible when one of those hundred-odd CVEs turns out to be reachable from your edge.

Ranking by missed CVEs beats ranking by age

The instinct when you inventory EOL software is to sort by how long it has been dead. Oldest first, work down the list.

That ordering is wrong more often than it is right. Age tells you how long something has been unsupported. It says nothing about how much attention the world has paid to it since. A niche library that went EOL in 2019 and attracted three CVEs is a smaller problem than a database that went EOL in 2023 and attracted 127.

Sorting by missed CVEs — vulnerabilities published after EOL and fixed only in newer branches — puts the list in the order you would actually want to work through it. It also tends to surprise people, because the top of that list is usually popular software that went EOL recently, not the ancient thing everyone already feels guilty about.

The maintenance version of the same idea

There is a planning use for this that is less obvious than the audit use.

If you know which of your dependencies cross their EOL date in the next quarter, upgrade scheduling stops being reactive. 179 versions reaching EOL within 90 days is, from the other side of the telescope, 179 upgrade windows that can be planned while nothing is on fire — rather than 179 future incidents discovered by a scanner at an inconvenient moment.

The difference between those two experiences is entirely a matter of whether anyone looked the dates up in advance.

end of life dates and support status for 477 products, including which CVEs each dead version has missed, are tracked at end-of-life.org — refreshed daily, with an API if you would rather wire it into your own inventory than check it by hand.