Vector-First Generation: What Actually Changes When the Model Returns SVG

A client asks for a logo. You generate one, it looks good, and then the follow-up arrives: they want it on a 40mm embroidered patch, cut in vinyl for a shop window, and screen printed at two meters wide. Your 1024-pixel PNG survives exactly one of those.

That gap is old and boring. Raster generation gives you pixels, production wants paths, and the bridge between them has always been a trace. Auto-trace a generated logo and you inherit its soft edges, its gradients, and its noise, so the "vector" you deliver is a few thousand wobbly nodes pretending to be a shape.

Ideogram Vector skips the bridge. It returns an SVG file as the primary output, either from a text description or from an existing image, and the accompanying write-up from the Japanese AI newsletter Ai-Hakase treats that format change as the headline rather than the artwork. That framing is right, and it is worth pulling apart, because a vector output does not make design easier. It moves the difficulty somewhere else.

Two modes, two very different jobs

The model exposes two endpoints, and they should not be confused with each other.

Text to vector takes a prompt and optional image references and produces one SVG. Pricing runs $0.13 at low quality, $0.16 at medium, $0.20 at high, and a high-quality job with references costs $0.32.

Image to vector takes exactly one raster image, no prompt, and returns the traced result for $0.10. Framing is preserved, which is the honest signal about what this mode does: it is a replacement for the trace step, not a design tool.

The first mode is the new capability. The second mode is the one most teams will use first, because everyone already has a folder of logos that exist only as PNG.

The Japanese coverage quotes roughly five seconds for a single SVG. Treat that as model latency, not your round trip. In our own run through the provider queue, a text-to-SVG job finished in about 30 seconds end to end, and the returned file was 7.5 KB. The queue, the storage hop, and the signed URL fetch are most of the wall clock, and that matters when you are deciding whether to put this behind a button or a batch script.

What "editable" means once the text is outlines

The Ideogram model page demonstrates the promise with a hover interaction: point at a shape and its outline appears, then recolor it, move it, resize it. The artwork is not one flattened rectangle pretending to be a picture. It is geometry, and geometry can be manipulated.

Two constraints follow from that, and both are easy to miss in a demo.

Lettering arrives as outlines, not live text. You can recolor the letters and rearrange the composition. You cannot swap the typeface, retype a word in a brand font, or fix a kerning mistake by editing a text box. If the design is going to be reused across a product line with changing copy, plan for the lettering to be redrawn or replaced in a real vector editor. This is the same gap that shows up in every AI design tool that outputs outlines, and those of us building on top of these models should say it out loud rather than let a demo imply otherwise.

Group structure is not a design system. Editable shapes are not the same as named layers, sensible groups, or anything that maps to how a designer organizes a file. The earlier beta test of Illustrator's chat assistant made this concrete: the difference between a pretty image and a usable file was a prompt line demanding seven named layer groups, and the assistant only produced structure because it was asked. A model that emits SVG does not know your naming conventions unless the brief tells it.

Where the vector output breaks

Flat graphic shapes are the model's home turf. Anything photographic is not.

Soft shadows, glows, gradients, and grain are the failure zone. A gradient has to become bands or a mesh, a soft shadow becomes a stack of shapes, and a photo becomes thousands of small paths approximating a blur. You get a file that renders correctly and is miserable to edit.

Thin strokes and small type are the second failure zone, for the same reasons that raster text rendering struggles: below a certain physical size, the geometry has nowhere to go. If the target is a label or a patch, set a minimum stroke width in the brief and check it at final size, not in the preview window.

Third, path bloat. Illustrative subjects with organic detail can come back as enormous node counts. That is not a correctness problem, it is a production problem, and it shows up later when someone tries to plot, cut, or embroider the file. Merely looking right on screen tells you nothing about whether a cutter can follow it.

A practical rule that has held up across tools: the more the source looks like a poster or a sticker, the better a generated SVG behaves. The more it looks like a photograph, the more you are paying a model to do a trace with extra steps.

The failure mode that lives outside the model

When we wired this into Phosphene, the first real conversion failed, and it had nothing to do with artwork.

The provider rejected the request with a 422 and the message "Could not download the image, or it exceeds 50MB." The source was valid. The problem was transport: the image had been sent inline, as a base64 payload, and the endpoint expects something it can fetch over HTTP. Switching to a short-lived signed URL fixed it immediately, and the second attempt returned a clean SVG in 37 seconds.

That detail generalizes to anyone integrating a vector endpoint. These services fetch your input at queue time, not at request time, so a URL that expires in five minutes can go stale on a retry, and a URL that points at a private bucket has to be signed per attempt. Inline base64 is the convenient path and the one that silently breaks.

The other integration decision worth copying: keep the SVG as the artifact and a raster preview as the thumbnail. Browsers render SVG fine, but a gallery grid needs consistent dimensions and the file itself should never be re-encoded. Our implementation renders an at-most-2048px PNG preview for display and stores the provider's SVG bytes untouched alongside it, so the thing that gets downloaded is exactly what the model produced.

The cost math is not where you expect it

At $0.16 a shot, generation is cheap. Burn through twelve attempts to find a mark you like and you have spent under two dollars.

The expensive part is downstream. Someone still has to open that SVG, inspect the paths, merge junk shapes, delete off-canvas fragments, and confirm the thing survives at production size. That is ten minutes per asset for someone who knows what they are doing, and it does not disappear because the file arrived editable.

Compare it against the old path: a designer spends forty minutes redrawing a raster logo by hand, or auto-traces it in thirty seconds and spends twenty minutes cleaning the mess. Vector generation lands somewhere in between, and where exactly it lands depends on the source. For a new flat mark, it is closer to a win. For a photographic conversion, the trace you were trying to avoid is still the reasonable fallback.

A workflow that matches the tool

None of this argues against vector-first generation. It argues for treating it as a step in a production pipeline rather than a one-click deliverable.

Write the brief for production, not for taste. "Single-color vinyl cut, three colors maximum, strokes thicker than 2mm at 100mm wide" gives the model constraints it can act on, and gives you a checklist for the output.

Then generate at medium quality and throw away freely. Cheapest decisions first. Once a direction survives, redraw the lettering, or at minimum verify every letterform at the final physical size.

Open the result in a vector editor before it goes anywhere near a client. Count nodes on the most complex shape, merge overlapping paths, delete fragments outside the artboard, and export whatever format the print shop asked for. A generated SVG that nobody cleaned is just a raster file with more steps.

Keep the raster preview for approval loops and the SVG for delivery. Mixing those up is how a marketing team ends up pasting a 7 KB file into a slide deck and complaining that it looks wrong.

If you want to try it without a local toolchain, Phosphene's vector tool runs both modes and exports the provider's original SVG. It intentionally does not try to be a vector editor: path editing happens in Illustrator, Affinity, or Inkscape after export. That boundary is worth keeping honest, because a half-capable path editor inside an image app is worse than a clean handoff.

The interesting shift here is not that a model can draw a logo. It is that the output now arrives in a format production can consume, which means the bottleneck has moved from drawing to checking. That is a real change, and it is a smaller one than the demos suggest. For more on how text rendering behaves in these models, see our notes on Ideogram 4 text rendering, and for the layer-contract lesson from Illustrator's assistant, the beta workflow write-up is worth reading next.