What happens when Jev's pick does not actually match the brief?

You hit the catalog ceiling, and the design is the README's own worked example of it. Early outside visitors asked for an x feed and a mobile podcast app when only dashboards existed, and Jev's review scored the results 0.8 out of 3. Adding a phone-app layout with a tab bar plus social and media blocks moved the same briefs to 2.3 and 3.0. Weaker matches are surfaced in the thread rather than hidden, which is the honest way to run this.

Do I get the same design if I send the same brief twice?

Jev has no memory, so every turn sends the whole thread, brief plus revisions, as state. Within a thread decisions are sticky, so a revision only changes what it is about, and try something else is classified as a remix that moves decisions of taste such as accent, typeface, headline and variants to Jev's runner-up options, while decisions of fact like layout and block set never remix. Across fresh threads there is no continuity beyond what you send.

Can I try the pipeline without an API key?

Yes, and the pipeline will even assemble. Without TYPESAFE_API_KEY the server uses a clearly labelled keyword mock so the code can be worked on offline, but the README states its decisions are meaningless, which makes it a development aid rather than a way to evaluate anything. For the real thing you need Node 24 or newer and a TypeSafe key; an OpenAI key is optional and only enables the writer.

What does one design cost, and what stops a runaway bill on a public demo?

The README measures about 250 questions and 11k input tokens per design, 0.8 to 1.6 s and roughly $0.0005; switching the writer on adds about three seconds and $0.0015. On a hosted demo the endpoint is rate limited per visitor and DAILY_USD_CAP, default 5 dollars, stops new Jev calls once that much has been spent in a UTC day. Usage is counted per day in a file, so mount a volume at /data to keep the counters across deploys.

What does Jev decide versus what Luna writes?

Jev decides every structural choice (layout, blocks, variants, colours, typeface) always on, while Luna optionally fills typed text slots against a strict schema; code owns ordering, limits, fallbacks and sanitising.

How many questions does one Forma design send?

About 250 typed Choice, Score and Noul questions sent with the thread in one fan-out request; Jev answers them in parallel and in isolation, and code ignores what it does not need.

What stops a runaway bill on the public Forma demo?

The public endpoint is rate-limited per visitor and DAILY_USD_CAP, default 5, stops new Jev calls for the day once that much has been spent.

CommunityJev Demos & Experiments

Forma System1 Experiment

An experimental design harness that splits the work: Jev picks layout, blocks, colours and typography from a prebuilt catalog in about a second, while an optional small LLM fills typed text slots a few seconds later.

See highlights

Open github.com

Stars: 0
Language: TypeScript
License: MIT
Published by: Community
Author: LamplighterPaul
Last verified: Oct 2026

LamplighterPaul/forma-system1-experiment

User repository on GitHub

View on GitHub

Experimental design harness: a small decision model (Jev) picks the design in about a second, a traditional LLM (Luna) only writes the words. With and without it.

Forks: 0
Last pushed: Updated Sep 2026

Repo stats from the GitHub API, cached Oct 2026.Homepage

About this project

Experimental. How fast and cheap can design get if a small, fast model makes the decisions and a traditional LLM is only allowed to write the words? Live at · by Paul Zammit. Describe a page, a screen, a form or a diagram and press Enter. A design appears in about a second and the words fill in a moment later. Keep typing to iterate: "make it dark", "remove the FAQ", "try something else". Switch Luna off to see what the decision model does alone.

Quoted from the project's README. Read the full README.

Tagscommunity jevbest catalog-import

Works forJev for Classification Jev for Routing

Used inJev for Software & DevTools

Languages: TypeScript

Highlights

One fan-out call turns the catalog into about 250 typed questions in a single request; a second small call then reviews the outline.
The ceiling is the catalog: five layouts, 40 prebuilt shadcn/ui blocks with typed parameters, meaning-named theme tokens and banks of pre-written copy.
Every word on the canvas was written in advance; the optional writer fills typed text slots against a strict JSON schema and emits no markup and no addresses.
Every call asks whether the brief is a design request and whether it is something that should not be built, so refusals are typed questions.

Watch out

The catalog is the hard ceiling, and the README treats match quality as the real bottleneck rather than the model: when a match is weak the thread says so, and the review pass's high something-is-missing probability is used as the backlog signal for what to add next. The project describes itself as an experiment, not a product, and not affiliated with either vendor. Jev has no memory, so every turn resends the whole thread as state, and coherence comes from sticky decisions plus that review pass rather than from the model reasoning across questions, which it explicitly does not do; it reads text only and never sees rendered pixels. Cost figures are the author's own measurement of about 250 questions, 11k input tokens, 0.8 to 1.6 s and roughly $0.0005 per design. Running it needs Node 24 and a TypeSafe key; without one the server falls back to a clearly labelled keyword mock whose decisions are meaningless. If you deploy the public endpoint, note that it is rate limited per visitor, that DAILY_USD_CAP defaults to 5, that visitors are counted by a salted hash that changes daily with no IP stored, and that the live event feed logs the latest message of each thread unless EVENT_LOG is set to off. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

Pi-Jev-Guide

Pi guard plugin that checks inputs and tool calls with local rules plus Jev semantic judgements, with redaction and verification reminders.