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

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

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   One message for the app, Postgres, and the ground rules

   The Agent can create the app and provision the database beside it in the same breath. Spend the rest of the message on the rules the build leans on.

   PromptSet up the projectCopy

   Create a new React 18 + Vite + TypeScript app with Tailwind and its own server, and add a Postgres database to this workspace. Keep the database connection string in Secrets, never in anything the browser downloads. Then write a short PROJECT_NOTES.md fixing the vocabulary for a chat app (conversation, message, model, provider, stream, attachment, call log, limit) and recording two standing rules. One: my model provider key stays in Secrets, so every call to a model runs on my own server, which establishes who is asking before it does anything at all. Second: every model call is logged and checked against a limit I configure before it is made, because each one charges my card, the whole conversation is sent again on every turn, and a signed-in user is not a spending cap. Also note that because this workspace has no hosted identity service, my own server is what declares who is asking before any request touches a table. Start the app so I can see it boot.

   That last sentence carries more weight here than on the other tools. Nothing is going to hand the database an account on your behalf, and a policy reading a declaration nobody made does not complain. It admits everybody, and on this app what it admits everybody to is a text box that spends your money.

2. 02

   Schema, sign-in and the boundary, at a checkpoint

   One idea rather than three on this app. Take a checkpoint once it is right, because everything after reads this shape.

   PromptModel it and draw the boundaryCopy

   Write the data model against the workspace Postgres. 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 on my own server, with sessions, and have the server set the database session variable that identifies the account on every request before any query runs. Then row-level security on every table, written against that variable: 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 prove it: two accounts, and show me the second cannot read or move the first one’s messages.

   Watch for the declaration being set on every request rather than once when the server starts. A connection reused between two people with the identity of the first one is the failure mode here, it is silent, and the proof above is what catches it.

3. 03

   The first streaming reply, capped in the same message

   Your own server holds the key and enforces the limit. Ask for both together so there is never a checkpoint where one exists without the other.

   PromptStream one reply, with a ceilingCopy

   Build the chat call as a route on my own server, with my provider key in 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: 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. Count both in the database rather than in memory, because a deployment can run more than one copy of this server and a limit held in one process is not a limit. Over either, return a clear "you have reached your limit for today" and do not call the provider. Then the chat screen, and prove the limit refuses an eleventh call when I set the limit to ten.

   The line about counting in the database rather than in memory is the one to insist on here specifically. An autoscaling deployment starts more copies of your server under load, and a counter held in one of them resets every time another starts, which is exactly when you are least watching.

4. 04

   The sidebar, the titles, and what you resend

   The conversation list people live in, and the decision that stops a long thread getting more expensive every turn. Take a checkpoint after it.

   PromptBuild the thread and the sidebarCopy

   Build the conversation sidebar: 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 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 Postgres. While I am testing, show the token count for the next request on screen.

   Check the summary is written when messages fall out of the window rather than on every send. A summary regenerated each turn is itself a model call, so the change that was meant to reduce your bill quietly adds to it.

5. 05

   Make the picker tell the truth

   The step this template needs more than most. A dropdown with five names in it is one screen, and whether five vendors sit behind it is a different question.

   PromptMake the picker honestCopy

   Define the list of models in one place on my 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 server 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 route and the same ceiling, with its own key in Secrets. Tell me plainly which models are actually reachable and which are only names, and do not add a name I cannot reach.

   Because everything sits on your own server here, the model list, the prices and the ceiling can genuinely live in one file. Ask for that explicitly, because three copies of the same list in three places is how a picker and a function drift apart in the first place.

6. 06
   Destination

   Markdown, attachments, and one real conversation on the published copy

   The rendering, the composer’s extras, your own name on it, and then a rehearsal on the published address rather than the workspace preview.

   PromptFinish it, then rehearseCopy

   Finish the app. Render replies as Markdown with headings, lists and code in a monospace block with a copy button. 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 putting it in this workspace’s object storage and serving it through my server. 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 publish it, and walk me through one real conversation on the published 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.

   Check who the published app is visible to before you invite anybody. Publishing is what sets that, and on this application the setting decides who can spend against your provider key.

One rule outranks the rest here: the model provider key belongs in Secrets only: never in anything the browser downloads, and never in a repository. A key that gets out is burned, and this is the one somebody will actually spend: replace it the same day and check your usage page for what was done with it.

All of these are Replit rather than a third party, so the choice is shape rather than vendor. Review who the app is visible to before the first release, since Publishing is what sets it, and on this application that setting decides who can spend against your provider key.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.