The New Composer: Up to 10x Cheaper, 2x Faster

The first Composer was one very capable agent doing everything. You described a product, and a single session asked the questions, decided the architecture, built the agents, the backend and every screen, tested it and fixed what broke, one step at a time. It worked. It was also the most expensive way to do it: our most powerful model was reading your whole project even while asking which features you wanted, and nothing could start until the previous step had finished.

We rebuilt it. The new Composer costs up to 10x less per project and gets you to a working preview about twice as fast. None of that came from a cheaper model doing the same job worse. It came from splitting the job, running the parts at the same time, and giving each part exactly what it needs. This post is the list of what changed.

The architect does not build

The Composer you talk to now has one job: understand what you want and write the plan. It asks a few sharp questions about the product, never about names or technicalities, proposes an architecture, and hands over a brief. It never opens your project, so the conversation is fast and costs a fraction of what it used to.

The plan lands as a proposal you approve, tweak or reject. Feedback simply produces a new proposal. Nothing is built until you say yes, so a wrong direction costs you a sentence, not a build.

Once approved, the brief goes to builders: the agents that actually write the code. You choose how much power each build gets, from Presto for quick iterations to Virtuoso for the genuinely hard ones. Legato is the default and carries most projects. You pay for the top tier only where it matters.

Multitasking

One request can now start several builders at once, and they keep working after you have moved on to the next thing. The agents, the backend and the interface get built side by side instead of one after another. That is where most of the speed comes from.

You see every builder in its own row: what it is doing, how long it has been at it, and whether it finished cleanly, finished with caveats, or got stuck. You can reply to one without disturbing the others, and you can stop one for real, the moment you click.

New harnesses

A harness is the machinery a builder runs in: its workspace, the tools it may use, how it checks its own work, how its usage is metered. The old Composer had one, fixed. Builders now run on several, and the platform picks the right one for each build. That is what makes a quick build and a deep build genuinely different things, not the same loop with a different label.

• Builders that know Timbal. They arrive with a compact playbook for agents, interfaces and backends instead of rediscovering the framework on every project.

• Check before you finish. Every batch of changes is verified before a builder reports back, so mistakes are caught early, when they are cheap.

• Plan first, if you want. A build can be asked to only read and plan. You review, then spend.

• Nothing wasted. Context that repeats is reused rather than paid for again, and every run shows what it actually cost.

• A gate in front. Every brief is checked before a builder sees it, so the machinery with real access only ever runs requests that are about building something.

The UI generator

The most expensive part of the old Composer was screens. Every dashboard, table and settings page was written from scratch, one at a time, and no two projects looked alike.

The new generator composes instead of writing. Every project ships with its own design system and a library of ready-made screens: dashboards, records, metrics, calendars, media, profiles. The builder picks the closest one, adapts it to your product, and applies your look. A screen is a decision and a theme, not thousands of lines of fresh code, and it comes out consistent with the rest of the app.

And the architect is honest about whether you need an interface at all. The default is no. Every agent already comes with a place to chat with it in the Studio, so “people will talk to it” is not a reason to build a web app. An interface has to earn its place, and when it does not, the most expensive part of the build is simply not there.

Voice agents, from the same conversation

Say “it should take calls” and your agent can. The builder turns voice on, and a minute later you are in the Studio talking to it. No plumbing is written, because voice is native to the agent. You can attach a phone number, place outbound calls under your own rules, and see the speed and cost of every call next to its transcript.

The Composer itself also listens. Describe the product out loud from the home screen and the proposal arrives in chat, ready to approve.

Where the 10x comes from

No single trick. Planning on a small, fast model that never reads your project. Builders on the power each task needs, not the maximum by default. A playbook instead of rediscovery, and checks that catch mistakes early. Screens composed from a design system, and no screens when the product does not need them. Context reused instead of paid for twice. And nothing built before you approve. Each one takes a slice; together, on the projects we build every day, they take up to an order of magnitude.

The 2x is simpler: builders work in parallel, the thread streams as it thinks, and the preview refreshes the moment a build changes it.

Try it

Open the Studio, start a Composer thread and describe the product. Pick a tier, watch the builds come in, reply to the one that needs you. The framework underneath is open source, the docs are at docs.timbal.ai, and if you want us to walk you through a build, talk to us.