Should I vibe code
Multi-model AI chat that compares answers side by side across providers
Six columns means six bills. And the model list you shipped on Sunday is already wrong by the end of the month.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Fanning one prompt out to four providers and rendering four columns is a satisfying weekend, and for a fortnight it beats the paid thing because it is yours. Then the treadmill starts. Every provider ships a new streaming shape, a new reasoning block and a deprecation notice on its own calendar, and the thing you actually built was not a chat UI — it was a standing promise to keep a model list current. Nothing here can hurt anyone but your own invoice, which is the good news and also exactly why this is a v0 rather than a product.
What actually breaks
not "if". the specific failures.
- Provider APIs drifting apart — streaming shapes, tool-call formats, reasoning blocks — so every new model is a new adapter rather than a config line
- Token spend multiplying by the number of columns, quietly, because asking everything at once is the entire premise
- Deprecations on the provider's schedule rather than yours, so a saved comparison stops being reproducible and you cannot say what changed
- Keys in a .env on a box you exposed "just to try it from my phone", which is a paid API proxy with no front door
- Context handling tuned against one provider and silently truncating on another, which makes the side-by-side comparison a lie
- Partial failures, where one slow provider stalls the grid and you discover that four streams need four independent lifecycles
Is that you?
the verdict is a default, not a law
- It runs on your machine, with your own keys, and never gets a public URL
- You are comparing outputs to make a decision, not building a product on top of the comparison
- You are content to hand-write an adapter each time a provider ships something new
- Anyone else can send prompts through your keys
- You need the model list to stay current without you being the person who updates it
- Spend has no cap and no per-request accounting
- You are pasting things into it your employer would call confidential
If you build it anyway
the checklist, then the prompt that enforces it
- Keys come from the environment or the OS keychain. Never a file in the repo, never a value that reaches a client bundle.
- Put a hard spend cap and a per-request token ceiling in before the second provider, not after the first surprise invoice.
- Record cost per request per provider from the first commit. Fan-out makes spend invisible unless you measure it per column.
- If it ever gets a public URL it needs authentication. An open proxy sitting in front of paid API keys is among the most-scanned things on the internet.
- Pin exact model identifiers and store which one produced each answer. A moving alias makes yesterday's comparison unreproducible.
- Isolate each provider's stream so one hanging does not blank the grid, and render the failure in its own column instead of swallowing it.
I am building a multi-model chat that fans one prompt out to several
providers and shows the answers side by side. Apply these constraints and push
back if I ask you to skip one.
1. Before any UI work, tell me what this costs. Fan-out multiplies spend by the
number of columns, so cost accounting is a feature here, not telemetry.
2. Implement a hard server-side spend cap and a per-request token ceiling first.
It refuses the request; it is not a warning banner.
3. Log provider, pinned model id, token counts and cost for every request, so
"what did last week cost me, per model" is one query.
4. Read keys from the environment or the OS keychain only — never a file in the
repo, and never anything a browser can see.
5. Do not give this a public URL without auth. If I ask you to deploy it so I
can use it from my phone, stop and tell me it has become an open proxy to my
paid accounts, then add auth and rate limits before anything else.
6. Pin exact model identifiers, never a moving alias, and store the resolved id
next to every answer, or yesterday's comparison is unreproducible.
7. Give each provider its own adapter, error handling and stream lifecycle. One
provider hanging must not blank the grid — render the failure in place.
8. Normalise history per provider and warn me when a thread will be truncated
differently across them, because a truncated comparison is not a comparison.
9. Redact obvious secrets before anything is written to disk, and give me one
command that deletes every stored conversation.
10. In the README list the wired-up providers, the date each adapter was
written, and what to check when one starts returning 400s. That list is the
maintenance this project actually is.
11. Out of scope, and say so: shared accounts, billing anyone else, and any
claim that the comparison is fair across different context windows.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
At the second deprecation email. $10/month is roughly one evening of debugging a streaming parser, and it includes model access without you holding four sets of keys — for casual use the subscription is genuinely cheaper than your own API spend, which is an unusual thing to be able to say on this site.
$10/mo is cheaper than your weekend.
Store conversations as plain JSON or markdown, in a directory, with the resolved model id and the cost attached to each turn — not as rows in a schema only your UI understands. Then leaving is not a migration: Open WebUI and LibreChat are both maintained and both already do this properly, and a folder of files is what you carry across on the day writing adapters stops being fun.
Open-source self-hosted chat interface for local and hosted models.
Open-source multi-model AI chat platform for self-hosting API-based assistants.
Questions
Why isn't this SHIP IT? Nothing dangerous happens.
Almost nothing does, which is why it lands at DEMO ONLY rather than anywhere worse — the blast radius is your own invoice. The verdict is about the gap between the demo and the product. The demo is four columns of streaming text on a Sunday afternoon. The product is somebody keeping a dozen adapters current indefinitely, and that somebody is you.
Is deploying it so I can use it on my phone really that bad?
It is the one genuinely sharp edge here. A URL with no auth in front of your provider keys is an open proxy, and scanners find those in hours, not weeks. The bill is the visible part. The part you find out about later is that your key was used for whatever the finder wanted it used for. Put a password on it before it leaves localhost.
Do I need to build it at all? Open WebUI exists.
For most people that is the honest answer. Open WebUI and LibreChat are both actively maintained, both support multiple providers, and both have already absorbed the adapter churn you are about to sign up for. Build your own if the comparison grid itself is the thing you want to design; self-host theirs if you just want the outcome.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice