openhiggsfield calls itself open source with no licence file

Free means the studio is free, and the key is yours

Openness is the first thing the page claims, three times. The top line calls it the free, open-source alternative to a named commercial studio, with no closed ecosystem and no studio subscription. The reasons list leads with free and open-source, then self-hosted, then your key, then the model count. And the hosted section says the studio itself is free. The mechanics behind that are consistent: you paste a platform key as an id and a secret, and the studio is what you run. What the page never does is say what the generation provider charges, and it is careful to separate the two, calling the studio free and the key yours. So the honest reading of the pricing claim is that the interface is free and the images are not free unless the provider you hold a key with gives them away, and the page is structured so you have to notice that yourself.

It calls itself open source and the repository records no licence

There are three sources and they do not agree. The page says free and open-source in its opening paragraph and again in its reasons list. The repository's licence metadata records no value at all, described as unknown. And there is no licence file in the tree, which holds a gitignore, a readme, two environment files, a Next configuration, a TypeScript configuration, a lockfile, a workspace file and three source directories. The package manifest adds a fourth data point rather than settling it, because the package is marked private and never published. For a project whose entire argument against an alternative is that it has no closed ecosystem, having no licence text is the first thing a reader should ask about, and the page does not raise it.

The browser never talks to the generation API, so your server holds the key

The architecture section is specific about this. Server actions are the only caller: the browser never talks to the generation API. Submit is a post to a path built from the model name, status is a get against a request identifier, and authentication is a header carrying the key.

Submit is `POST /{model}`; status is
`GET /requests/{id}/status`. Auth is `Authorization: Key <api_key>`.

The key itself is entered in a modal and stored by a server action in an httpOnly cookie, so it never reaches browser JavaScript, and a lamp in the top bar says whether a key is held. That is a clean design for the person using the studio. It also means that anyone who self-hosts this is running a relay that holds other people's generation keys on their server and forwards them to a third-party API, and that is a deployment decision rather than an implementation detail.

Uploaded media become public URLs carried to the generation API

The media inputs are described as uploads to object storage that become public URLs the generate request can carry.

Files upload to Vercel Blob and become public URLs the generate request can carry.

The architecture section adds that uploads go client-direct to that storage through an endpoint which issues scoped tokens, and that URLs of the storage's own scheme are preview-only. So the flow is: a start frame, an end frame, reference images, video or audio go straight from the browser to object storage, come back as public addresses, and those addresses are sent to a third-party generation API as inputs. The scoped tokens limit what the browser can do; they do not make the resulting object private. For a tool whose inputs are the thing a user is most likely to be private about, that distinction is worth holding on to, and the page does not spell it out.

History is local, but the media lives on someone else's storage

Three consequences arrive in one bullet about state.

**History persists** in IndexedDB in this browser (60 records). Favorites are
a deliberate keep and never age out of the cap. Result URLs belong to the
generation platform, so old history can outlive its CDN lifetime and show gaps.

So the run list is local to one browser, capped at sixty records, with favourites exempt from the cap by design. The files behind those records are on the generation provider's storage, which means a six-month-old history can show a list of tiles whose media no longer resolves. The gallery accounts for it: bulk download is sequential, reports progress, and produces a report of any files the storage layer refused. A gap is therefore an expected state rather than a bug, and the design treats it as one.

Thirty-eight entries counts variants, not vendors

The count appears three times in the same form: 38 models, 8 image and 30 video. The named list in that same bullet is shorter than the count.

Soul 2, Soul Cinema, Seedance 2.5 (Edit / Extend), Seedance 2.0 (Fast / Mini),
Kling 3 (Turbo / Std / Pro / 4K / Motion), Wan, Flux, Ideogram, Recraft, LTX,
MiniMax, PixVerse, Grok, Qwen and more.

That is fourteen names before the list trails off, and several carry variant labels in brackets, so the thirty-eight is a count of catalogue entries rather than of distinct products from thirty-eight vendors. That is a reasonable way to count a picker, and it is not what the headline number suggests to a reader. The page is otherwise careful about the same distinction elsewhere, insisting that the catalogue is the source of truth and that each entry declares its own settings and media roles so the studio never keeps a parallel list.

A ten minute deadline and a six second undo

The lifecycle is documented as a poll and a ceiling.

Skeletons open in the grid on submit, the request is
polled every 4s until a terminal status (10-minute deadline)

So a video generation that has not reached a terminal state in ten minutes is treated as finished, one way or another. The other deadline is on deletion: reversible for six seconds, through a bar with a draining indicator, placed in the strip the composer already reserves. What the page does not say is whether that window applies to bulk deletion from selection mode, where the same actions run across a range. Undo that is generous for one tile and ambiguous for forty is the kind of gap that only shows up under a thumb.

Six runtime dependencies, and no test framework

The stack is named in one line: a React framework's app router on a hosting platform, React 19, plain CSS, a small state library and pnpm. The manifest agrees and the list is short: a virtualised list helper, the object storage client, the framework, React twice and the state library. Styling is hand-written CSS with no framework in that list. Four development dependencies, all type definitions plus TypeScript, and no test runner, no linter and no formatter, which is notable for a page that sets out six design principles including one about every control shipping all its states. A workspace file sits at the root of a single-package repository, and one of the four commands is a hand-written Node script that rebuilds the icons and the social card.

Editorial conclusion

openhiggsfield is worth a look if you want one interface across several generation providers rather than a separate tab for each, because the catalogue is data rather than code and adding a model needs no studio changes. Two things to check before you host it. The licence claim on the page and the licence metadata in the repository disagree, and there is no licence file, which matters for a project whose headline is openness. And uploaded reference images become public URLs sent to a third-party API, so anything private stops being private the moment you attach it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. wide-trace/open-higgsfield on GitHub