A twitter code generator app is a thirty-line tool around one public endpoint

What every other guide on this topic gets wrong

Open the pages that currently surface for this phrase. They mostly fall into one of two buckets. Some send the reader to Google Authenticator, which is a reasonable answer if the underlying task is two-factor login but has nothing to do with generating code. The rest send the reader to Twitter's own publish.twitter.com web form, which is a decent tool, but it is a form, not a generator. You paste one URL at a time, you copy the block, you never see the response shape, and you cannot script it.

What gets skipped is the most interesting sentence: the endpoint behind that web form is public, accepts GET, returns JSON, sends the right CORS header, and has kept the same contract for more than a decade. Once you know that, the "app" part shrinks to a textbox and a fetch call. The rest of this page walks through the endpoint, the response, the component, and the sandbox that lets you preview the output without leaving the preview iframe.

The endpoint, exactly as it responds today

The first thing worth doing is calling the endpoint yourself. It takes a tweet URL and returns a small JSON object. Every field in the response is stable across rebrands, including the provider_name string that still reads Twitter and the script tag src that still points at platform.twitter.com/widgets.js.

Three things to notice in the response. The html field is the entire embed, ready to paste. The cache_age field is advisory: you can hold a given response in memory for a very long time without re-fetching. The provider_name field still says Twitter, which is the small piece of evidence that the rebrand was a product decision, not an infrastructure one.

The generator component, in full

Below is the entire core of the generator. It is intentionally thin. One state for the input URL, one state for the result, one state for the error message, one async function that branches on HTTP status. Every case the endpoint can return has a distinct message so the reader knows whether the tweet is gone, protected, rate limited, or merely unreachable.

The 30-line count is not marketing. You can paste this into a fresh Vite project, wire it into App.tsx, and the output is a textarea containing the exact HTML you would have copied from publish.twitter.com's web form. The only reason to go longer is to add styling, a copy button, a preview, or the variations listed further down this page.

Why the sandbox matters for this app in particular

Most code-generator tools hand you a string and walk away. For a Twitter embed that string is useless on its own because the rendered card only appears once platform.twitter.com/widgets.js loads and scans the DOM for blockquote.twitter-tweet. You need a real browser to see whether the embed you just generated actually renders. The mk0r sandbox ships that browser. Chromium launches on a virtual display before the first prompt lands, with a persistent profile and remote debugging exposed over CDP, and Vite serves your app into the same machine.

Ports matter here. Chromium exposes CDP on 9222, Playwright MCP listens on 3001, the ACP bridge is on 3002, Vite binds 5173, x11vnc is on 5900, and websockify bridges that VNC stream to WebSocket on 5901. All of those are up before the agent writes its first file. When the generator fetches the embed and drops it into the DOM, the browser that evaluates the result is the one already running in the VM.

The preview component, in full

The second file the agent writes is a preview. It takes the HTML string, drops it in a div, loads widgets.js once per page, and asks the script to re-scan when the string changes. This is the part most hand-written generators skip. Without it, the user has to paste the blockquote into another site to see whether the tweet rendered, which ruins the point.

End to end, from prompt to rendered tweet

The chain below is the observable path a single prompt walks inside the sandbox. Every arrow is a real process boundary, not a metaphor. The final step is the same Chromium that listens on port 9222 rendering the final card, and you see it over the websockify stream that started booting before you opened the page.

The turn-by-turn sequence

Broken out so you can see which file lands when, and where each event surfaces. The HMR events come from the _mk0rBridge.ts file baked into every sandbox at /app/src/_mk0rBridge.ts. It posts five message types to the parent window so the preview iframe knows when to react.

Variations on the same app

The core is fixed: one endpoint, one fetch, one textarea. The interesting work is around the edges, and each variation below is a one-sentence follow-up prompt to the same running sandbox. None of them add more than about 40 lines to the project.

What the bridge logs during a normal session

Here is a trimmed trace from a real session where the agent built this generator for the first time. The bridge prints one line per HMR event and every event also posts to the parent iframe, which is how the preview knows when to re-mount.

Versus the status quo of copying from a web form

The publish.twitter.com web form is fine for one tweet, once, manually. Every other case is worse than it needs to be. The generator version of this app gives you control over every field in the response, lets you paste many URLs at once, and renders the result next to the code instead of making you paste the blockquote elsewhere to check.

What is worth taking from this

If you build code generators for anything, the lesson is not the specific endpoint. The lesson is that the "generator" category hides a lot of single-endpoint problems where the UI is the only interesting work. oembed is one. Gravatar is another. GitHub's raw file endpoint is a third. Each of them is a 0-line React component around one fetch. The value of a sandbox is not that it makes the component shorter, it is that it lets you render the output of the component in the same environment you wrote it, so you never have to leave the tab to verify the result.