Here's how it works

The Stack

Here's what's under the hood, for those who want to know.

The phone apps are the real thing - native on both iPhone and Android, built separately for each with React Native and Expo, and when the phone's own frameworks are needed we write Swift and Kotlin. The fitness app, for example, does its pose detection right on the phone using Google's MediaPipe pose model - the same model on both phones. The web app is Next.js and its own codebase; nobody squeezed a phone app into a browser. All three share one TypeScript core with strict schemas, so a rule written once holds everywhere. By default, each phone app does everything that the web version does, but we can and do segment by use case. For instance, the fitness app is phone-first, with the web version offering different, complementary capabilities.

Data and server logic live in Supabase - Postgres plus functions on Deno - and every change to a job's state has to go through a small set of guarded doors in the database. No sneaking around the back. The longer-running work - each Designosaur's own worker and the model gateway - runs on Google Cloud Run, where a job can run past a Supabase function's 150-second limit. Web releases go out on Vercel through previews, staging and production, GitHub Actions runs the tests, and pnpm holds the packages together.

A theme engine and a thirty-six-theme library (and growing weekly) give every app three switchable themes; you're looking at that on this page. Email gets pulled from the accounts by a Supabase function and sorted with routed models; texts come off the Mac. And a Hetzner box, run with Coolify, hosts the browser stack we use for harvesting and measuring. The database already runs on AWS, and the rest is built from portable parts - Postgres, Deno functions, Next.js and containers - so the entire system could be migrated to AWS if needed.

Where it all runs:

It also talks to Google Workspace (mail in, approved replies out, Calendar and Tasks), HubSpot (read only), Resend for alerts, and Serper for search.

Tomorrow: Store builds, payments and phone test flows - each one started, none switched on yet.

How We Choose Which AI Model Does Which Job

Almost every request we send to an AI model goes out through one door - a LiteLLM gateway on Google Cloud Run - so a request reaches a model only by a route we chose. The door is set up from one list we keep: the registry. Each model on it has an entry that says what it can do, what it costs, who makes it and where that company is based, what license its weights carry, how long the maker keeps what we send, and whether the maker trains on it. A model that isn't on the list can't be called through the door.

One kind of request doesn't use the door yet: turning text into numbers so it can be searched by meaning. The email sorter does that every five minutes by calling the maker directly. Moving those calls behind the door is on the list.

Models are grouped by the job, not by the brand. Each group has a first choice and backups, so if one maker has a bad day the request moves to the next:

Each role also has a set effort level - how long a model may think and how much it may write. It's extra-high for Cleo, Ada, Trully's design review and Dromeo's long passes; high for Val, Trully, Dromeo's core work and Tycho's extraction; medium for Sun-sin, Tycho and Wolfgang; and low for Penny and the email sorter. A test runs on every change to the list, so a role can't quietly move to a model or an effort the list doesn't allow.

We track how every model performs, wherever it's made, so we know our costs stay competitive with the rest of the world. We use only models made in democratic countries, and a test fails the build if a route ever points anywhere else.

Keeping it current. A probe runs every morning. It reads the makers' model lists and what's trending, and files each new model as work for review. A research pass then reads the model's own pages and the independent scoreboards and fills in its entry - what it can do, its prices, the company's country, the weights' license, how long the maker keeps data and whether it trains on it - with a date and a link for each. A score we couldn't read from an independent source goes in as unknown, not guessed.

Getting on the list isn't getting a route. Before a model carries real work:

• It answers live through the door, using the same code our roles use, so we know its replies come back in the shape our code expects.
• It's tested on the job it would do, with tests that don't ask another model's opinion. The builder's test is 63 matched tries against a frozen baseline, scored by fixed tests; a newcomer has to come within three points of the baseline or beat it. A review model has to find the real faults in a set of known cases. A sorting model is judged side by side against the one it would replace.
• Its price and terms are set against the one it would replace, and its country and data terms compared with our rules.
• The change goes out first on a copy of the gateway that carries no traffic. It gets probed there, and only then takes over - with the old copy kept to roll back to.
• After that, every group is probed every thirty minutes. Each model change sets off a re-read of the scaffolding around it, so we drop workarounds the new model no longer needs.

How a change gets made. A newer model from the same maker - no more expensive, with an independent score at least as good and the same country and data terms - may take a backup slot, or first place on the quick jobs, on its own, with me told. Anything bigger, like a different maker or a new first choice for reasoning, is laid out as a case and waits for my yes. Anything without an independent score, or outside our rules, never switches on its own. For now all of these are made by hand, each with a written record.

Two changes from September 2026. Claude Sonnet 5.5 came out on September 28th, 2026. The next day it was on the list and in a backup slot for reasoning; on the 30th it beat the builder's frozen baseline by six points, I said yes, and it became the first choice for standard work - eight of eight probes answered. GPT-6 Astra became the second reader on reasoning in early September. On September 29th, three of six probes failed - our gateway's version was too old to talk to it properly - so it came off that evening. We upgraded the gateway, tested it on a copy with no traffic, and the next day it went back on, six for six.

For the mail sorter below, we require no retention or training on our mail, test on masked email, and leave every contact to me. Jev, a new decision model from TypeSafe AI, sorts at a small fraction of what our current sorter costs and answers in well under a second. In September we held off, because by default it kept what we send. It can now run with nothing kept and no training on our mail, through a gateway we already pay for. Its trial is on masked email, judged against my own labels, and if it beats our current sorter, it takes over sorting.

Today: 83 entries on the list - 82 models from 15 makers (one is listed twice, because we can reach it two ways); 11 on routes, 2 on trial, 62 tracked and 7 retired; the door is rebuilt only from the list. Jev is under evaluation, and three image and video tools made this site's pictures.

On a Route (11)

On Trial (2)

Being Evaluated (1)

Pictures and Videos on This Site (3)

Built from our model list each time this page is published. Price bands are relative, by blended price per million tokens. An independent score is one we read from a third-party scoreboard, dated.

Tomorrow: The steward that makes the no-brainer changes on its own, with the case laid out for the rest - and the search calls moved behind the door.

Models That Have Carried the Routes

Models come and go on the routes as scores and prices move. Here is every model that has carried real work through the door since the meter began in April 2026, with the job it did and when:

The models on the routes today are listed above; their calls are metered under the route's name, so they join this table when they leave it.

The coding tools are a separate list: I pay for them by the seat, and which model each one runs is my call. Here is every model they have run since we started in February 2026:

A model that builds well isn't automatically a good reviewer, so when another lab's model is available, no file's review rests on one model alone.

Open Source, and When We Build Our Own

When Cleo and Dromeo's requirements point at a capability - reading a pose from a photo, drawing a chart, testing accessibility - the first question is whether someone has already built it well, in the open, under a license we can ship. Before anything gets built, a research pass fills in a short table: the candidates, each one's license, what we'd use as is, what we'd adapt, and one sentence for anything we'd build ourselves. It reads the sources it cites; nothing is decided from memory.

The license decides a lot. We take the permissive ones by default - MIT, Apache, BSD, ISC and MPL. GPL in anything that runs, AGPL anywhere and closed source are a no by default, and anything in between gets a written decision first. When we install something, we pin the exact version, keep its license and notice files beside it, and write down where it came from. Every outside skill our agents use is scanned when it's installed, and a skill is promoted only after it beats a baseline on at least ten test cases. We build our own when nothing open fits.

Take the fitness app. One requirement was to estimate a few body measurements from a single photo - on the phone, without the picture going anywhere. Any feature that uses the camera brings five privacy rules with it, and Cleo carries them as constraints: the photo stays on the phone, consent comes first, the feature is off by default, choosing the model gets its own review, and research comes before any vision work. (The app's requirements were written before it came into the factory, but the same rules applied.)

On September 16th a research pass compared the options, license first:

• Google's MediaPipe pose model (Apache 2.0) - chosen: one model on both phones, it runs on the device, and there's no per-use cost.
• MoveNet (Apache 2.0) - eligible, not chosen.
• Apple's vision framework on iPhone with MediaPipe on Android - turned down: two models means two sets of calibration.
• A popular YOLO pose model - ruled out: its AGPL license won't let a closed app ship it without buying a commercial license.
• Three ready-made React Native wrappers (MIT) - passed over: they lagged our versions of React Native and Expo, or only worked on live video.

We ship the model file exactly as published - pinned by its checksum, its license and notice beside it, nothing downloaded while it runs - inside our own small Swift and Kotlin module for still photos. Then our own accuracy test, run on synthetic mannequins rather than real people, said the estimate isn't good enough to stand on its own as a measurement. So it only fills in the boxes, you confirm with a tape measure, and it's switched on in preview builds only. The web version says plainly that the browser doesn't scan.

The rest of the app follows the same pattern: Expo's camera and photo picker with every permission it doesn't need removed; Apple Health through an MIT library, off until you turn it on; encryption on the phone with open libraries; and charts we drew ourselves on open SVG and animation libraries, after trying a charting library and dropping it the same day.

The Designosaurs work the same way. Their methods, and the themes on this page, are built on open work we can name and license:

The other 13 themes we drew ourselves. And sometimes the answer is no: a self-hosted web crawler was turned down for its AGPL license (we use Crawl4AI instead); GNU FreeFont was refused for its GPL license; and when we looked at open-source customer-records tools on October 1st, the AGPL ones were out and the one clean option would have moved our records into a second database - so we built on our own records.

Why We Vote - and When We Don't

A model makes mistakes at random, and a long job made of many steps multiplies them. A November 2025 paper, "Solving a Million-Step LLM Task with Zero Errors" (arXiv 2511.09030), showed a way through, which its authors call MAKER: break the job into tiny steps, let several model calls answer the same step on their own, throw out any answer that comes back malformed, and take the first answer that gets K votes ahead of the runner-up. That way they finished a puzzle of more than a million dependent steps without a single error.

We took it up in April 2026, after our first end-to-end run, when five of our eight role agents crashed on malformed answers.

Then we measured. What made the builder reliable wasn't the voting - it was the compiler and the tests, with a repair loop when they fail. Voting on taste was holding up good work, and the paper itself only claims its result for steps with one right answer. So since June each kind of question has its own decider:

• When a machine test can settle it, whether it tests the code or the shape of the data, that result decides and nobody votes.
• When an answer has to come back in a fixed shape, the model is held to that shape as it writes.
• When there's one right answer and no test for it, the models vote: whether a security finding is real (Sun-sin), the ethics questions (Val), and whether a message holds a real event for my calendar.
• When it's a matter of taste, a real, live human being decides what looks and feels right. The model's score is advice, and each of those calls is saved as an example the system can learn from.

How the count works: with three voters and K of two, the leader has to be two votes ahead. Three to nothing wins; two to one doesn't. A malformed answer is thrown out before counting, so two to nothing with one thrown out also wins - in practice, every answer that counts has to agree. When a vote can't settle it, the question is held for a person; nothing goes through on a split.

We also stopped voting where it wasn't paying. When every piece of generated code was voted on three times, the votes caught nothing the tests hadn't. Now one model writes each piece, and a failed test sends just that piece to a three-way vote.

Today the calendar reader votes every minute, asking models from different makers, and an event still waits for my OK before it lands on my calendar. The other votes run when an app is being built. We haven't measured our own error rate with and without voting, so we don't quote one.

How the Work Gets Done

Several AI coding agents work on the software in parallel, each on its own copy of the code, so a day's work is done in a day. Nothing they produce goes into the product until I have seen it work on real data in a real browser. Every release goes through three stages and leaves a record of what was tested and who approved it. When something is wrong it gets fixed the same day.

Numbers We Can Show

Real counts from our own systems, each dated. Nothing is rounded up.