Features
A request goes in, a conventional project comes out, and every step between is something you can read.
01The composer
Under the message box is a row of options, each opening its panel in place. Getting started walks through them.
Write what the thing is, who uses it and what it has to do. Specifics help more than adjectives.
For each message the agent either replies in words and changes nothing, or builds. Before the first build it may ask a question or two, and a “yes” becomes the full brief you agreed.
A visual direction from the catalog, narrowed by mood. Styles whose moods your message names are marked as suggestions; nothing is picked for you.
One of 400+ complete styles: its colors, typefaces, type scale, corners and shadows are written into the site as tokens. Its colors can be edited, and an edit that breaks a contrast pair is not applied.
A design from the template catalog as a starting point, by category and subcategory, the gallery styles among them. Its brief is added to your message, to edit or send.
A page to start from. vibld reads its text, colors, fonts and spacing and adapts them rather than copying. It goes with one message.
Your images and video, placed where the request calls for them. One library per account, shared by every project.
Project instructions and a few visual preferences, applied to every message, so you only say them once.
Which models are offered depends on the deployment and your plan; Free builds with GPT-6 Luna. Beside Send, what a build on it is expected to cost, from the last 30 days of builds, or the most a build can cost until there are enough of them, plus the draft on a project's first build. The settings menu reports which one actually served the last run.
02Directions
Pick a style and the build starts from its direction, including how it moves.
Show me three directions: three quick sketches that differ in look, for about a tenth of a build. Offered before the first build only.
Ask for an animated background, or name one (aurora, particles, grain, flowing lines), and the build can use one of four that vibld writes itself: drawn in code from the project’s colors, paused off screen, and a still frame under reduced motion.
03Checkpoints
There is no accept step. A build’s code is shown as soon as it exists, badged “Checking the build” while vibld installs and builds it, and “Fixing a problem” while a repair runs. Until the check ends, export, push and publish act on the last finished checkpoint. Iterating is another turn in the same conversation, and a follow-up changes only the files it needs.
While a first build runs, a draft of the page, labeled as one. Then Run live preview, and the frame is the running app.
The generated files, as files, badged while a build is being checked. Export, Publish and Push are under Ship, in the top bar.
What the run is doing, when it started and finished, and what it cost.
Where it stops: Not the sandbox’s process output, which is not piped in yet.
What vibld’s own checks found, including a build that did not pass its check.
Where it stops: Not the sandbox’s install, build or type errors, which are not reported here yet.
The newest 100 checkpoints, any one restored in a single step. Nothing is deleted, so a restore can be undone too.
Every run on the project: the model, the tokens, the cost and why it ended.
04Sandbox and sharing
Run live preview installs the dependencies and starts a dev server. It reports each state (queued, installing, starting, ready, failed) instead of a spinner, and it expires (ten idle minutes, thirty at most, one at a time), because it is for looking at a project rather than hosting one.
Share mints a link to the running sandbox. Several can be live at once, each with its own expiry and each revoked on its own, and none is affected by restarting or stopping the sandbox.
Anyone with the link can view the running app and everything it shows, until it is revoked or expires. The builder says so next to the button.
A running preview takes each new version in place and says “Updating preview…” while it does. A change to the dependencies is installed first; one it cannot take in place restarts the preview, and the tab says why.
05Projects
The code, the whole conversation and the settings. Open, rename, duplicate, archive or delete from the Projects list. Free keeps three active projects; Build and Ship have no limit.
Close the tab or lock the phone and the build carries on; reopening the project picks up the result. Only Cancel stops one, and it is charged for what it used.
Turn on a link and anyone with it sees the project’s code and live preview. Somebody signed in can remix it into a project of their own. Your conversation, name and email stay yours.
06Design checks
The chosen direction is written into the project as DESIGN.md: its colors, type, breakpoints and motion. When the build finishes, static checks read the files against it, and against the few rules every page must keep: a page language, alt text on images, a reduced-motion rule. Checks read files; they do not render them, so they cannot see computed contrast or an overflowing layout.
An error is something the checker is confident about, such as a color the spec named that appears nowhere. Only errors buy a repair, because a repair is another paid call. A repair is a patch to the files at fault, not a rewrite, and a warning rides along with one that is happening anyway.
07Taking your code
All three are under Ship, in the top bar. The output is a conventional project with no proprietary runtime, and it keeps building the day you stop paying.
Downloads the checkpoint as a .zip: the files as they are, ready to open in an editor and run with the package manager the project declares. Nothing rewritten, nothing that phones home.
A branch named vibld/<revision>, one commit and a pull request against the default branch, in the project’s own repository: a new one vibld creates, or one you pick. The grant expires after 90 days, and a push is safe to retry.
Builds the checkpoint and serves it at the project’s own vibld-preview.dev address, in two presses. Take it down the same way: the address stops working immediately and the name stays yours.
Where it stops: Rolling back to a previous published checkpoint is not built yet.
08What you get
Plan and usage in the settings menu reads the same spend figures the builder enforces. Pricing has the plans.
It installs and builds with the package manager it declares. There is no vibld package in its dependencies and nothing that checks an account when it runs.
Static checks read the files. Only an error the checker is sure of buys a repair, because a repair is another paid call. It patches the files at fault rather than rewriting the project.
In the project’s own repository, created or picked on its first push, on a vibld/ branch, against your default branch. Review it like any other change.
vibld: <revision>
your-org/clay-saturdays, from vibld/<revision>
Nothing automated can publish: no scheduled run, no webhook, no text in a commit. Take it down and the address stops working immediately, and the name stays yours.
clay-saturdays.vibld-preview.dev
Name itPublish
The source is public. Self-hosted, vibld is three Cloudflare Workers with deliberately different blast radii, so the code a model wrote never runs next to your provider keys.
09Before you join
Yes. Export downloads it as an archive: package.json, index.html, a src directory and a README. Push to GitHub opens a pull request in a repository you connect. From there it goes wherever you put it.
No. It installs and builds with the package manager it declares, npm install and npm run build. There is no vibld package in its dependencies and nothing that checks an account when it runs.
It writes React, TypeScript and Vite, styled with Tailwind and shadcn/ui components, with Lucide icons and Motion for animation. A frontend developer can review it without learning a new format first.
Projects you have exported or pushed keep working, because none of them call home. The core is licensed Apache-2.0, so anyone with a copy of the source can keep reading, running and forking it.