How to build a multi-model AI chat app with v0

Rule of thumb, and it splits on what you want to own. If you want a better chat client for yourself or a small team, do not build this: TypingMind is $99 once on your own keys, and LibreChat is free, self-hosted and genuinely multi-vendor under an MIT licence. Both beat a from-scratch build on effort and on model breadth, and saying otherwise would be selling you something. What none of them gives you is a product with your name on it that your own customers sign in to and pay for. That is the case for building, and it is a real one: the moment other people are the users, a per-seat plan stops being a tool you buy and becomes a cost that grows with your success. Work out which of the two you are, because the answer is not close in either direction.

* On this template the free-tier line to watch is the pause rather than storage. No files are kept, because attachments go to the model and are never saved, and a conversation is a few kilobytes of text. What does bite is that a free project sleeps after a week of inactivity, and an app people open when they happen to have a question is exactly the sort that goes quiet. Pro, from $25/mo, ends the pause and keeps a daily backup for 7 days.

Prices and rates from supabase.com, developex.com, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   The chat screen, before anything is behind it

   Start where this tool is strongest. A thread, a composer and a sidebar that look right, with sample messages in them and nothing real underneath yet.

   PromptSet up the projectCopy

   Build the chat screen for an AI chat app in React with Tailwind, with sample data and no backend yet: a scrolling thread of messages with the person’s and the model’s messages styled differently, a composer at the bottom that grows as I type, a collapsible sidebar of past conversations, and a model name at the top. Make it work properly on a phone as well as a wide screen, and add a light and a dark theme. Then write down in the project notes that this app’s vocabulary is conversation, message, model, provider, stream, attachment, call log and limit, and that two rules apply to everything built after this: my provider key lives on the server and never reaches the browser, and every model call is logged and counted against a limit before it is made.

   Spend a little longer here than feels necessary. This screen is the entire product from the outside, and it is much easier to get the composer and the message spacing right while there is nothing real behind them to break.

2. 02

   A database, sign-in, and one account out of another’s history

   Now put something real underneath. The schema and the access rules together, because a conversation being private is the same idea as it having an owner.

   PromptModel it and draw the boundaryCopy

   Add Supabase and set up the data model. Conversations with an owner, a title and a last-updated time. Messages belonging to a conversation, with the text, whether a person or the model wrote it, the model that answered, and attachment metadata. A calls table logging every model request: who, which conversation, which model, tokens in and out, whether it succeeded and an estimated cost. Then add email and password sign-in with a persisted session and a profile row created for a new account. Then row-level security on every table: a row is reachable only by the account it traces back to, with explicit WITH CHECK on every insert and update, and the update rule on a message must forbid changing which conversation it belongs to. Then wire the screen from step 01 to real data rather than samples, and prove the boundary: a second test account that cannot read or move the first one’s messages.

   Ask for the proof as something you watch, not as a claim. It is the one part of this build with no visible symptom when it is wrong, and the screen will look exactly as correct either way.

3. 03

   The first streaming reply, and the ceiling with it

   The screen already looks like it works. This is the step that makes it, and the limit belongs in the same request so there is never a version without one.

   PromptStream one reply, with a ceilingCopy

   Build the chat call as a server-side function, with my provider key in the server environment and nowhere the browser can read it. It requires a signed-in user and refuses with a 401 otherwise, sends the conversation to the model, and streams the answer back to the browser as it arrives, rendering into the thread from step 01 as it comes. Do the streaming carefully: read the response in chunks, keep a buffer for a fragment split across two chunks rather than dropping it, and save the finished message when the stream ends, including when the connection drops halfway. Before it contacts the provider at all, write a row to the calls table and check two limits I can configure: calls per account in a rolling window, and a total across the app. Over either, return a clear "you have reached your limit for today" and do not call the provider. Read the limit and the cost on the server, never from the client. Then prove the limit refuses an eleventh call when I set the limit to ten.

   The streaming and the ceiling are the two things on this page you cannot judge by looking at the result. Run the eleven-message test yourself, and watch a long reply arrive rather than trusting that it did.

4. 04

   Real conversations in the sidebar, and what you resend

   The sidebar from step 01 gets its data, and the request gets a budget so a long thread does not cost more every turn.

   PromptBuild the thread and the sidebarCopy

   Wire the sidebar to real conversations: ordered by what I touched last, opening one loads its messages in order, plus renaming, deleting and a new-conversation button. Give a conversation a title from the first exchange rather than from the first fifty characters of what I typed, and never overwrite a title I have renamed by hand. Then change what gets sent to the model: rather than the whole thread every turn, send the most recent messages up to a token budget I can configure and a short running summary of anything older, stored on the conversation and updated as messages fall out of the window. Keep the full history in the database. While I am testing, show the token count for the next request on screen.

   The summary is the part to watch. A summary regenerated on every turn is itself a model call, which quietly undoes the saving, so check it is written when messages fall out of the window rather than each time you press send.

5. 05

   Make the picker tell the truth

   The step this template needs more than most, and the one furthest from what a screen can tell you. A dropdown with five names is a visual component and a claim about five implementations.

   PromptMake the picker honestCopy

   Define the list of models in one place on the server, with the vendor, the id and the per-token prices for each, and have the picker read that list rather than a separate one in the frontend. The function must refuse a model that is not in it with a clear message rather than silently substituting a default. Record on every message which model actually answered it and show that under the reply. Then, if I want a second vendor, add exactly one: a separate adapter for its request shape and its streaming format, behind the same function and the same ceiling, with its own key in the server environment. Tell me plainly which models are actually reachable and which are only names, and do not add a name I cannot reach.

   This is the request where a good-looking answer is the risk. A dropdown is easy to render and a second provider adapter is a week of real work, so ask which of the two you have been given and expect the honest answer to be shorter than the list.

6. 06
   Destination

   Markdown, attachments, and one real conversation

   The rendering the screen has been faking, the composer’s extras, your own name on it, and a rehearsal on the deployed copy.

   PromptFinish it, then rehearseCopy

   Finish the app. Render replies as Markdown with headings, lists and code in a monospace block with a copy button, since copying code out is most of what people do with a chat app. Add attachments to the composer, and tell me which trade you have taken: sending the file to the model without keeping it, which needs no storage, or storing it in a bucket with access rules and linking it from the message. Add dictation using the browser’s own speech recognition, with a sensible message in browsers that do not offer it rather than a dead button. Put my own name, colours and copy on the header and the sign-in page. Then deploy, and walk me through one real conversation on the deployed address: sign in as a second account, hold a conversation long enough to matter, confirm that account cannot see the first one’s threads, and compare what my calls table reports against my provider’s own usage page.

   Do the rehearsal on the deployed address rather than the preview. This is the one build in the series where a limit that only works locally costs money rather than time to discover.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks everything else on this page: your database service key and your model provider key live on the server and nowhere else, which means never inside the app people download and never inside a repository. A key that escapes is burned whichever of the two it is, and the provider key is the one somebody will actually spend. Read your usage page first to see what was done with it, then replace it the same day.

Speed is not what separates these eight, because all of them serve a built folder quickly enough. Three other questions do. Does the plan you are on allow commercial use, which Vercel’s Hobby tier does not. Can it publish from a private repository, given the function secrets sitting beside this code. And does a deep link resolve for a browser that has never seen your site, because a link to one conversation is exactly what somebody will paste to a colleague.

Do the arithmetic before you choose, because the fee is smaller than it looks. Take the conversations you expect in a month, multiply by the tokens a typical one sends, and remember that a thread resends itself on every turn. At gpt-4o-mini rates a thousand medium conversations a month is a bill in single-figure dollars, and 5.5% of that is cents. At that size the decision is about your own time rather than the fee, so the answer is usually the aggregator or nothing at all. The fee starts to matter at a volume where you would be negotiating with providers directly anyway. Figures read on each vendor’s own page in August 2026.

Add a calls table that records every model call (who made it, which conversation, which model, how many tokens went in and came back, whether it succeeded, and a cost estimate) and write to it from the chat function on every call, successful or not. Then add a ceiling: a limit per account per rolling window and a total across the whole app, both settings I can change, checked inside the function before it contacts the provider and returning a clear "you have reached your limit for today" rather than an error. Apply a tighter limit to demo accounts than to real ones. Do not let the client send the limit or the cost, because both are read on the server. Then add a small usage panel showing calls and estimated spend for the current period, by account.

Change what gets sent to the model. Keep the most recent messages in full up to a token budget I can set, and for anything older send a running summary instead, stored on the conversation and updated when messages fall out of the window. Show me the token count for the next request in the interface while I am testing, so I can watch the effect. Keep the full history in the database untouched, because this is about what is sent rather than what is stored, and make the budget a setting rather than a number in the code.

After the first exchange in a conversation, make one cheap model call to write a short title of at most six words describing what the conversation is about, and save it on the conversation. Do it once rather than on every message, let me rename it by hand afterwards and never overwrite a title I have edited myself, and count that call against the same log and ceiling as everything else. If the call fails, keep the current title rather than showing an error.

Replace the keyword test that decides whether a message is an image request. Give me an explicit control in the composer for asking for an image, so the choice is mine and the app never guesses. Where you keep any automatic detection at all, make it a separate cheap classification call rather than a substring match, show me which mode a message was sent in, and let me resend the same message in the other mode without retyping it. Count image calls against the ceiling at their own higher cost rather than as one call.

Add search across my own conversations. Do the finding with database queries over the message text rather than with a model, show the matching messages with their conversation and date, and let me open one at the right place. Then add an optional panel that answers a question from my own history, sending only the messages the query actually matched and quoting which conversation each part of the answer came from. Never send my whole history in one request, and where the search finds nothing, say so instead of answering from general knowledge.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.