How to build a multi-model AI chat app with Claude Code

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 and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Boot it, then write down the two rules that keep this build honest

   An app running against your own database, and a CLAUDE.md holding the two constraints everything after this leans on.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a chat app (conversation, message, model, provider, stream, attachment, call log, limit) and writing down the two rules that hold for the whole build. One: my model provider key stays on the server, so every call to a model runs inside a server-side function that establishes who is asking before it does anything at all. Second: every call is logged and counted against a limit before it is made, because each one is a charge on my card, the whole conversation is sent again on every turn, and a signed-in user is not a spending cap.

   Put both in the file rather than only in this message. The second is the rule an assistant will not infer: asking for a chat feature gets you a chat feature, and nothing in the request implies that holding a forty-message conversation during testing should cost more than the first one did.

2. 02

   Model it, sign in, and keep one account out of another’s history

   The schema, the accounts, and the rules that make a conversation private, together, because on this app they are one idea rather than three.

   PromptModel it and draw the boundaryCopy

   Write the data model as Supabase migrations. 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 Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a trigger that creates a profile row 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. The row you may edit is not the same question as what that row may become. Prove it before moving on: two accounts, and show me that the second cannot read or move the first one’s messages.

   Insist on that proof as a query you watch fail. Every mistake in a privacy boundary is invisible while there is only one account, and a second account with its own conversations in it is the cheapest test instrument in this whole build.

3. 03

   Stream one reply, and cap it in the same breath

   The feature this app exists for, and the limit that stops testing it becoming expensive. Ask for both in one prompt so there is never a version of this code without the ceiling.

   PromptStream one reply, with a ceilingCopy

   Build the chat call as a server-side function, with my provider key in the function’s secrets and nowhere else. 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. Do the streaming carefully, because this is the part I want done properly: read the response in chunks, keep a buffer for a fragment that arrives split across two chunks rather than dropping it, and write the finished message into the database once the stream ends, including when the connection drops halfway so a half-written answer is saved as a half-written answer rather than lost. Before it contacts the provider at all, write a row to the calls table and check two limits I can configure: how many calls one account may make 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 a screen with a text box and the reply appearing as it is written. Finally, show me three things: a reply streaming in, the finished message in the database, and the limit refusing an eleventh call when I set the limit to ten.

   That last check is the one to insist on, and to run yourself. Set the limit low, ten is plenty, and watch it stop you. A ceiling you have not seen refuse anything is a ceiling you are hoping is there.

4. 04

   The thread, the sidebar, and what you resend

   Somewhere for the conversation to live, a list you can scan, and the decision that keeps message sixty from costing sixty times message one.

   PromptBuild the thread and the sidebarCopy

   Build the conversation sidebar over the conversations table: a list 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 the part that decides the running cost: rather than sending 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, because this is about what gets sent rather than what gets stored. While I am testing, show me the token count for the next request somewhere on screen so I can watch the effect of the budget.

   Ask for the token count on screen even though you will remove it later. It is the only way to feel what the budget does, and the difference between a forty-message thread with a window and one without is the sort of thing you want to see once rather than read about.

5. 05

   Make the picker tell the truth

   The step this template needs more than most. A model list is a promise about what the function behind it can reach, and the two are easy to get out of step.

   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, because a substitution nobody can see is worse than an error. 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 secrets. Tell me plainly which of the models in my list you have actually implemented and which are only names, and do not add a name I cannot reach.

   The last sentence is the whole point. Ask for the honest answer explicitly, because a model list is exactly the kind of thing that gets padded out to look generous, and this template already ships with one name in it that the code behind cannot reach.

6. 06
   Destination

   Markdown, attachments, and one real conversation end to end

   The rendering, the composer, your own name on it, and then the part most builds skip: use it for something you actually needed.

   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 be explicit with me about the trade: either send the file to the model without keeping it, which needs no storage, or store it and link it from the message, which needs a bucket and access rules over it. 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 walk me through one real conversation end to end: sign in as a second account, hold a conversation long enough to matter, check that account cannot see the first one’s threads, and compare the spend my calls table reports against what my provider’s own usage page says.

   Check that figure against the provider’s own dashboard instead of trusting the one you built. An estimate that has drifted from the real bill is worse than having none, since you will price things off it, and week one is while the arithmetic is still small enough to follow.

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.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.