Sunburst now calls OpenAI directly — generate and edit, on both surfaces.

What was tested

Galleria and the workflow canvas are separate code paths to the same backend, with their own configs and defaults, so each was exercised independently. Every run was confirmed three ways: the outgoing request body, the database row reaching a terminal state, and the provider path in the service log.

• Every call went to OpenAI. Confirmed in the service log for each of the four runs, matched to its generation by timestamp — the provider column in the database and the endpoint actually called agree.
• Nothing lingered in queued. 8 of 8 Sunburst runs and 23 of 23 overall reached completed. This mattered because a brand-new asynq task type was introduced, and a missing handler registration would have hung every generation silently — the gateway still returning 201 and the enqueue still returning 200.
• 15 credits charged per run, with quoted_credits matching credits_amount.

The parameter surface

Every value below was confirmed by sending it to the live API, not read from documentation. size takes literal pixel dimensions rather than preset names, which is what lets the interface quote real output dimensions on the generate button.

POST /api/generations → 201        (from a real Galleria run)
"config":{"size":"1024x1024","quality":"low","background":"opaque","output_format":"png","n":1}

• The keys on the wire are the ones OpenAI expects. Read from the stored generation config rather than the source, so this reflects what the interface actually sent, not what it was written to send.
• The documentation was wrong, and so were the API's own error messages. OpenAI rejects an invalid quality with "Supported values are: 'low', 'medium', 'high', and 'auto'" — yet xhigh and max are both accepted and echoed back, and size: auto works despite the error insisting on WIDTHxHEIGHT. Trusting those messages would have stripped two quality tiers and the Auto size out of the interface for no reason. Each value was confirmed by using it.

The edit path

This was the one genuinely novel piece of code. Every other provider client in the repository posts JSON; OpenAI's edit endpoint takes multipart/form-data with binary file parts, so the reference images must be fetched to bytes and assembled into a form.

[OpenAI Image] model=gpt-image-2.5-sunburst edit=true images_in=1
[OpenAI] POST /images/edits model=gpt-image-2.5-sunburst images=1

• Three parameters are dropped on this path. OpenAI's edit endpoint rejects quality, background and n, so the service filters them out. The interface still shows those controls when references are attached; they are silently ignored.

Transparency, counted rather than assumed

background: transparent is the capability most likely to look right and be wrong, because an alpha channel can exist while being opaque everywhere. So the stored asset was decoded and its pixels counted, rather than trusting file to report RGBA.

fully clear (a<16)     1,200,953  of 1,572,864   76.4%
fully opaque (a>239)     364,119
partial (anti-aliased)     7,792
corner alpha          [0, 0, 0, 0]

• The 7,792 partial-alpha pixels are the decisive number. A faked or uniformly-opaque alpha channel has exactly zero of them. Anti-aliased boundary pixels only exist where a real cutout was rendered — which is precisely what a channel-presence check cannot tell you.
• Requested from the interface, not just the service. "The provider can emit alpha" and "the interface can ask for alpha" are two claims; this evidences the second, which is the one that matters for a user.

Base64, decoded and checked

Unlike every other provider here, OpenAI returns no URL — only base64. That makes the decode the highest-risk part of the change, and a failure would be close to invisible: a wrong decode stores base64 text labelled image/png, and the response, the byte count and the metadata all still look healthy.

$ curl <generation_assets.public_url> -o stored.png
$ file stored.png
stored.png: PNG image data, 1024 x 1024, 8-bit/color RGB, non-interlaced
$ xxd -l 8 stored.png
00000000: 8950 4e47 0d0a 1a0a   .PNG....

• Real PNG magic bytes, on both the generate and the edit path. Verified by fetching the stored object back out of GCS, not by trusting the API response.
• This repository contains that exact bug. The ByteDance service casts []byte(*b64Json) without decoding. It is dead code there because that provider defaults to URLs, but it was the obvious thing to copy. The OpenAI client decodes properly, with a RawStdEncoding fallback and an empty-result guard.

Both surfaces, and the neighbour that had to keep working

Open findings

• Credits are a placeholder. 15, marked as such in the seed. The production figure is unconfirmed.
• No production rollout SQL in the branch. seed.sql is development only, so production needs its own insert — a single row, since no other model moves.

Two things fixed after first being written up here

• One check nearly went wrong and is worth recording. The two GPT predicates are evaluated with gpt-image-2 first. Had that predicate used a prefix or substring match rather than strict equality, it would have swallowed gpt-image-2.5-sunburst and made the entire Sunburst branch dead code — silently, and in a way the node settings would still have appeared to survive. It uses strict equality, so both branches are live, but that was the one route by which this could have been quietly wrong.

Not covered

Stated plainly, because a verification report that implies more coverage than it has is worth less than one that names its own edges.

• Quality tiers beyond low and high in the running system. All six were confirmed against the live API directly, not through the app.
• JPEG and WebP output, and n > 1.
• The 2:3 portrait size.
• Transparency on the edit path. Attaching a reference resets the control to auto, and OpenAI drops background on edits regardless — so this is arguably interface behaviour to document rather than a gap, but it is not evidenced either way.
• A caveat for anyone auditing this later. Joining a generation to its model row reports the model's current provider, not the one that served it. Only the stored config keys record which provider actually ran a given generation, so any per-provider count taken from the join will be wrong after a provider change.
• The failure path. This database has never held a non-completed row, so error handling is unexercised.