openai-fm: an MIT demo with no releases and a last push dated March 2026

The last push is dated 2026-03-03 and there are no releases

Two facts about the state of the repository are worth putting first, because neither appears in the readme. The last push on the default branch main is dated 2026-03-03, which is over seven months before the present. And the repository has no GitHub releases at all, so there is no tag to pin, no changelog entry to read and no artefact to download. What that combination means in practice is narrow but real: there is exactly one thing to fetch, the head of the default branch, and no way to ask what changed in it or when. The readme itself makes no claim about maintenance state either way. It describes what the demo is, links to the OpenAI text-to-speech documentation for anything beyond the demo, and then stops. For a reference implementation that is a defensible position, and for anything you intend to depend on, it means the dependency set below is the whole contract.

The deployment note is one sentence about who pays for the API key

Step six runs the app with npm run dev and says it will be available at http://localhost:3000. Immediately after that comes the only note in the document, and it is a cost warning rather than a security one: be aware that if you deploy this app to a public server, you are responsible for any usage it may incur using your OpenAI API key. The mechanism behind that warning is structural. The key is supplied as an OPENAI_API_KEY environment variable, and the app is a Next.js application, so the key is read on the server and every text-to-speech request a visitor triggers is billed to whoever supplied it. Nothing in the readme describes authentication, rate limiting, quotas or any other control between a public visitor and that key. There is one server-side guard mentioned anywhere, and it is not a guard: the optional Postgres step is only needed for the sharing feature, so a deployment without a database simply has no sharing and nothing else changes.

The example environment file lists eight variables and the steps name one

Step five is the one marked optional, and it is where the documentation and the repository disagree most visibly. The instructions say to set the environment variables in a .env file at the root of the project to connect to a hosted postgres database, as shown in .env.example, and they print a single line:

POSTGRES_URL="postgresql://username:password@host:port/database_name"

The .env.example file in the tree is considerably wider than that. It defines eight variables: POSTGRES_URL, POSTGRES_PRISMA_URL, POSTGRES_URL_NO_SSL, POSTGRES_URL_NON_POOLING, POSTGRES_USER, POSTGRES_HOST, POSTGRES_PASSWORD and POSTGRES_DATABASE. Four of them are connection strings for the same database under different pooling and TLS settings, and four are the broken-up components of one. The step does say this only affects the sharing feature and is not needed to run the application, which is the useful part, but a reader copying from the example file rather than from the step ends up with a .env containing variables the application may never read.

POSTGRES_PRISMA_URL is in the example file with no Prisma in the tree

One entry in that list does not belong to this project as it stands. POSTGRES_PRISMA_URL carries a connection string with pgbouncer=true and a connect_timeout, which is the shape a pooled Prisma client expects. There is no Prisma in the tree: the top level holds .env.example, .gitignore, LICENSE, README.md, eslint.config.mjs, global.d.ts, next.config.ts, package-lock.json, package.json, postcss.config.mjs, public/, src/, tailwind.config.mjs and tsconfig.json, with no schema file and no Prisma directory. package.json does not list Prisma as a dependency either. What it does list for the database is @vercel/postgres, which is the client the POSTGRES_URL family of variables is shaped for. So the example file carries a leftover from a template that had an ORM, alongside the Vercel client that the code actually depends on. It is harmless to leave in place and misleading to follow literally, since a reader who wires Prisma up to it would be adding a data layer the demo does not have.

eslint-config-next is pinned to 15.2.2 while next floats on 15.3.6

The dependency table has one version that does not match its neighbour. next is declared as ^15.3.6 and react and react-dom as ^19.0.0, both floating ranges, while eslint-config-next is pinned to the exact string 15.2.2 with no caret. So a fresh npm install resolves the framework to whatever 15.x is current while holding the lint configuration to a specific older minor. The lint script is next lint, and the repository carries a flat eslint.config.mjs alongside eslint ^9, which is the configuration style that version expects. Two smaller signals point the same way: tailwindcss and @tailwindcss/postcss are both at ^4 while a tailwind.config.mjs is still present, and package-lock.json is committed, which fixes the install to npm rather than leaving it to whichever package manager a contributor prefers. None of this stops the demo from running. It does mean that a fork which changes the Next.js version is also changing the lint baseline, and that the lockfile is the thing worth reading before an upgrade rather than the range in package.json.

The dependency list describes an audio editor with a code editor in it

Reading package.json tells you more about what the demo does than the readme does. wavesurfer.js is there, which is waveform rendering and playback for the generated audio. Three CodeMirror packages are there, @uiw/react-codemirror with @codemirror/lang-javascript, @codemirror/lang-python and @codemirror/legacy-modes, plus a duotone theme, so the input is a syntax highlighted code editor rather than a plain textarea. lz-string is there, which is the usual way to squeeze a payload into a shareable URL, and that is consistent with the optional database being described as needed for the sharing feature. State is handled by zustand with immer for immutable updates, and the interface primitives are radix-ui with a switch, a toast and the icon set. So the shape is: type text in a highlighted editor, generate speech, look at a waveform, optionally share the result. None of that is written down in prose anywhere in the repository.

The contribution policy says pull requests may go unreviewed

The Contributing section is two sentences and the second one is the operative one. You are welcome to open issues or submit PRs to improve this app, and the text then adds that they may not review all suggestions. The contributor list above it is headed OpenAI team and contains eleven names, all of them firstname lastname pairs with profile links, several of them pointing at github.com accounts under an openai organisation and one to an x.com account. There is no external contributor section, no list of community authors, and no indication of who reviews incoming changes or on what timescale. Alongside the absence of releases, that is the second thing a prospective contributor should know before opening a pull request: the project is MIT licensed and open to changes, and it does not promise a response.

Editorial conclusion

openai-fm is worth reading if you want a compact, MIT licensed example of a text-to-speech front end with waveform playback and a syntax highlighted text editor, and worth running if you already have an API key and a tolerance for a project whose last commit is dated 2026-03-03. It is not a foundation to build on: there are no releases to pin, no changelog, and the contribution policy says outright that not every suggestion may be reviewed. Before deploying anything derived from it, read the deployment note about API key usage, decide whether you need the sharing feature at all since it is the only thing that pulls in a hosted Postgres database, and check that the dependency versions in package.json still resolve against the Next.js release you intend to run.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. openai/openai-fm on GitHub
4. Project website
5. README