How to Create a Chatbot With ChatGPT

The three routes, defined

Read all three before starting any of them. The expensive mistake here is spending a week on route one and then discovering it cannot do what you wanted.

Route 1: a custom GPT inside ChatGPT

A custom GPT is a configured version of ChatGPT with your own instructions and uploaded files, built through a form in the ChatGPT interface and used inside ChatGPT itself.

No code, no key, no hosting. Building one requires a paid ChatGPT plan, Plus or above, and takes about an hour if your content is already tidy.

The hard limit is where it lives. A GPT runs on chatgpt.com, behind a ChatGPT account. OpenAI's help documentation states directly that GPTs are not a way to embed ChatGPT in an external website or application, and points you at the API for that. You can share a link, share it inside your workspace, or publish it to the GPT Store, but you cannot put it in the corner of your pricing page. Knowledge is capped at 20 uploaded files of up to 512 MB each, against a shared 25 GB per-user storage allowance, and it is only as current as your last upload.

Examples: An internal onboarding assistant, A GPT that drafts replies in your brand voice, A sales-enablement GPT over your own decks

Route 2: the OpenAI API

The API route means calling OpenAI's Responses API from your own backend, with your own chat interface on your own domain, and retrieval either from OpenAI's file_search tool or from a vector database you run.

This is the only route that puts a chatbot on your website if you are building it yourself. You get complete control: which model, what the instructions say, what content it can see, what happens when it does not know, where the conversation goes afterwards.

It is also where the tutorial and the product diverge sharply. The model call is roughly fifteen lines. Everything that turns it into something a paying customer can use is yours, permanently. Two things have got easier since 2024: the Responses API is an agentic loop rather than a single completion, so tool calls happen inside one request, and the built-in file_search tool over managed vector stores means you need no embedding or vector infrastructure of your own for a first version.

Examples: A docs assistant on a developer site, An in-app support panel, A chatbot that has to hit your own order database

Route 3: a chatbot platform

A chatbot platform is route two already built, where you point a hosted product at your website or documents and it handles indexing, the widget, citations, lead capture, escalation and analytics.

There is no architectural mystery here. Platforms in this category call the same frontier models over the same kind of retrieval. That includes matram.ai, which runs on Claude for generation with an in-house intent classifier and retrieval over your content. Nobody in this market is training a foundation model, and any vendor implying otherwise is describing prompt configuration in more impressive language.

You are buying the surrounding engineering, and the fact that somebody else maintains it when a model is deprecated or your site structure changes. You give up control over the internals and anything the vendor did not anticipate.

Examples: matram.ai, Intercom Fin, Tidio Lyro, Zendesk AI agents

Route 1: building a custom GPT, step by step

Worth doing even if you intend to build properly later, because it is the cheapest way to find out whether an AI can answer from your content at all.

The steps

• Open ChatGPT on a paid plan, go to the GPT editor and start a new GPT.
• Write the instructions yourself rather than accepting the generated ones. Say what it is for, who it talks to, what tone to use, and above all what to do when the answer is not in the uploaded material. Without that last sentence it will guess.
• Upload knowledge files. Clean text beats volume: an exported help centre as markdown will outperform twenty scanned PDFs. You have 20 file slots, so consolidate rather than uploading every page separately.
• Turn off any capability you do not need. Browsing on a GPT meant to answer only from your documents is a common cause of it confidently quoting a competitor.
• Test with the questions your customers actually ask, in the words they actually use, not the words on your website. The gap between those two vocabularies predicts whether a chatbot works better than anything else does.
• Share by link or to your workspace, or publish to the GPT Store.

Where this route stops

At your website boundary, and it stops hard. A visitor reading your pricing page cannot use a custom GPT without leaving, signing into ChatGPT and finding it. That rules it out for customer support, for lead capture and for anything you would call a website chatbot.

You also learn nothing operationally. There is no record of what visitors asked, no list of questions that went unanswered, no handover when the bot is stuck, and those are what improve a support experience over months. It is an excellent internal tool and a poor external one. If your goal is a widget on your own domain, treat the GPT as a prototype and read the no-code chatbot builder comparison for tools that do put a bot on your site without code.

When none of this is the answer yet

Before route two, a check worth running. There are four stages below, and writing the surrounding product yourself only starts to make sense at the far end of them.

Stage one: answering them yourself still works

Enquiries arrive slowly, you know the answers, and replying takes less thought than configuring anything would. Nothing on this page beats that. A custom GPT for your own team is still worth the afternoon, because it costs almost nothing and it tells you whether your content is good enough to answer from at all. Putting a public bot on your site is a different commitment, and at this stage it buys you nothing you do not already have.

Stage two: friction starts, and the fix is content

The same questions keep landing. Now the temptation is to open the API reference. Try the cheaper experiment first: write the questions down in the words customers use, find the page that answers each one, and write the ones that are missing. Do that and a fair amount of the friction goes on its own. Skip it and no route here rescues you, because file_search returns only what you uploaded, and a model instructed to answer strictly from retrieved passages will correctly refuse to answer from documentation nobody has written.

Stage three: the build nobody is maintaining

An API build is easy to start and quiet to abandon. The widget goes up. It works. Then attention moves elsewhere, uploads stop, and the vector store slowly comes to describe a version of your product that no longer exists. Nobody watches the daily spend on an endpoint that is public and costs money per request. Nobody reads transcripts, so the questions it failed on are never collected, and that list was the most useful thing it produced. And when a model is deprecated the migration is yours to run, on a date somebody else picked.

Stage four: the question that breaks the design

Then a visitor asks about their own account. Where the order is, whether the plan renewed, what the last invoice covered, why the card was declined. Retrieval over your marketing pages reaches none of it, and neither a custom GPT nor a first-pass API build is shaped for it. What it needs is identity for an anonymous visitor, an authenticated call into your own systems, a permission model, and a clear view of what a confidently wrong answer about somebody's money costs you. That is not a chatbot project any more. It is a product feature, and it belongs with whoever owns your account systems rather than with whoever volunteered to try the API.

Route 2: building on the OpenAI API

Use the Responses API, not Chat Completions, and not the Assistants API. This is the part of the internet's advice that has gone most stale.

OpenAI's text generation guide now says that if you are building any text generation application, it recommends the Responses API over the older Chat Completions API. Chat Completions still works and OpenAI has committed to keeping it, so an existing integration is not in danger, but there is no reason to start a new build on it. The Assistants API is a different matter: it is deprecated with a sunset date of 26 August 2026, so anything you build on it today has a shelf life measured in weeks.

The smallest thing that works

Two calls. Once to put your content into a vector store, then one per question to answer from it. The second call is the whole chatbot, minus everything that makes it a product.

// One time: create a knowledge base and upload your content.
const store = await openai.vectorStores.create({ name: "acme-docs" });
await openai.vectorStores.files.uploadAndPoll(store.id, fs.createReadStream("help-centre.md"));

// Per question: retrieve and answer in a single request.
const reply = await openai.responses.create({
  model: "gpt-5.6-luna",
  instructions: [
    "You answer questions about Acme for visitors on acme.com.",
    "Answer only from the retrieved passages. If they do not contain",
    "the answer, say so plainly and offer to pass the visitor to a human.",
    "Never invent prices, policies or delivery times.",
  ].join(" "),
  input: userMessage,
  tools: [{ type: "file_search", vector_store_ids: [store.id] }],
});

That instruction block is not decoration. The sentence telling it what to do when the passages do not contain the answer is the difference between a chatbot that says "I do not have that, let me get someone" and one that invents a returns policy. Write it before you write the UI.

Choosing a model

The current lineup is the gpt-5.6 family, in descending capability and price: sol, terra and luna, plus the smaller gpt-5.4-mini and gpt-5.4-nano. For a grounded support chatbot the smaller models are usually right, because retrieval has already done the hard part. Once the correct passage is in front of the model, the remaining job is reading comprehension and tone, and you are paying a premium for reasoning you are not using. Start on luna, measure against real questions, and move up only if you can point at answers that got worse.

You are also not locked to OpenAI. The same architecture runs on Claude or Gemini with a different client: Anthropic lists Claude Haiku 4.5 at $1 in and $5 out per million tokens and Google lists Gemini 2.5 Flash-Lite at $0.10 in and $0.40 out, both as at 20 July 2026. Token counts for identical text differ between vendors, so a lower headline rate does not reliably produce a lower bill.

The three routes side by side

The row that decides most of these is the first one. If the answer to "does it need to live on my website" is yes, route one is out no matter how appealing its effort column looks.

The API column is the only one whose maintenance row points back at you, and that is the real trade. It is invisible in month one. For the build-versus-buy arithmetic in detail, the chatbot development cost breakdown goes through it line by line.

What the API route actually costs: a worked example

Assumptions stated first, because every cost estimate in this category is really an argument about assumptions. Take 1,000 conversations a month at an average of three questions each, so 3,000 model calls. Each call carries roughly 3,500 input tokens (a 400-token system instruction, about 2,500 tokens of retrieved passages, and 600 tokens of conversation history) and produces about 250 output tokens. One file_search call per question. Under 1 GB of stored content, which is inside the free storage allowance. All rates are OpenAI list prices read on 20 July 2026.

Two things to take from that table, and the first is inconvenient for us. At this volume the token bill on the small model is about $22.50, which is genuinely less than a matram.ai subscription. If your only cost is tokens, DIY wins. We would rather say that here than have you discover it in month two.

The second is that tokens are the part of the bill you will spend least time thinking about. Everything else moves the total: hosting, a database for conversations, prompt caching (worth a lot here, since the same instruction block and often the same passages recur), and the engineering hours. At developer rates, one week of build time costs more than several years of the token line above, and the build is not one week. Scaling on the model side stays gentle: ten times the volume on luna is roughly $225 a month, which still is not the number that decides anything. The number that decides it is whose week gets spent on the widget. Run your own volume through the chatbot ROI calculator rather than these illustrative figures.

What the tutorials leave out

Everything between a working API call and something you can point a paying customer at. This list is the honest content of "weeks, not days". The built-in file_search tool removes a real chunk of it, since you no longer have to stand up a vector database or write a chunking strategy. What it does not remove is everything that is not retrieval.

You build and own

• The widget. An embeddable, responsive, accessible chat interface that loads fast inside someone else's page, survives their CSS and works on mobile Safari. Reliably the most underestimated item on this list.
• Content freshness. file_search indexes what you upload. Crawling your site, noticing what changed and re-uploading it is your cron job, and a stale index is the most common cause of a chatbot quoting last quarter's price.
• Citations. The tool tells you which chunks it used. Turning that into a link a visitor can click, tied to the right sentence, is your code.
• Session state, identity for anonymous visitors, and history that survives a page reload.
• Rate limiting and abuse protection. Your endpoint is public and spends money per request, which makes it a target in a way an ordinary form is not.
• Lead capture, and wherever those leads have to land afterwards.
• Escalation. Detecting that the bot is stuck, routing to a person, and handing that person the transcript.
• Analytics, and the weekly habit of reading real transcripts, because nobody can enumerate a generative system's outputs in advance.
• Model migrations. The model names on this page will be superseded, and something has to be re-tested when they are.

None of this is exotic or beyond a competent engineer, which is exactly why it is dangerous: every item looks like an afternoon, there are nine of them, and then they need maintaining. The build a chatbot from scratch walkthrough goes deeper on the engineering if that is the road you are taking, and the API integration page covers the middle path where a platform handles the chatbot and you call it from your own code.

The costs that never reach the invoice

The worked example above is the part of this decision you can put in a spreadsheet, which is precisely why it attracts more attention than it deserves. The costs that hurt are second order.

The first is the weekend that turned into a quarter. An API call that works on day one sets an expectation for everything after it. Then the widget has to survive somebody else's CSS and somebody else's mobile browser, the follow-up question needs rewriting before it retrieves anything sensible, and someone asks for a way to correct a bad answer without a deploy. Each of those is reasonable. Together they are a roadmap item you never wrote down, paid for out of whatever your engineers were going to build instead.

The second is ownership. Prototypes reach production because they demo well, and a demo carries no maintenance plan. So the bot answers visitors from a vector store drifting out of date, and nobody is accountable for it because it was never really anybody's project. Then a model is deprecated and you are re-testing prompts and refusals to somebody else's timetable. The Assistants API, deprecated with a sunset date of 26 August 2026, is the visible version of that. The invisible version is every quieter change that lands the same way and does not make the news.

And the mistake runs the other way too. Buy when you should have built and the one behaviour your product depends on turns out to be the one the vendor never exposed, which you find out after your content has already moved across. Neither error is loud in month one. So the question that actually separates these routes is not what the tokens cost. It is which parts of this you still want to be maintaining once the model names on this page have been replaced. Whose name is against that work?

Which route you should actually take

Route one is settled by a single question: does it need to be on your website? If yes, it is out. The genuine decision is between the other two.

A sensible sequence: build a custom GPT this afternoon and test it against fifty real customer questions. For the price of an hour that tells you whether your content is good enough to answer from at all. If it is not, no route works and the actual job is writing documentation. If it is, pick between building and buying on the criteria above rather than on the token price, because the token price is not what separates them. SaaS teams usually start from an existing docs site, and small businesses usually start from a handful of pages plus an FAQ. If you have already decided to buy, the Intercom alternatives comparison is a fairer starting point than a feature list.

Frequently asked questions

Sources

• OpenAI text generation guide (accessed 20 July 2026) - OpenAI's recommendation to use the Responses API over Chat Completions for new text generation applications, and gpt-5.6 as the model in current examples.
• OpenAI API pricing (accessed 20 July 2026) - List prices per 1M tokens for gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.4-mini and gpt-5.4-nano, plus file search at $2.50 per 1,000 calls and $0.10 per GB per day of storage with 1 GB free.
• OpenAI file search tool documentation (accessed 20 July 2026) - The built-in file_search tool and vector stores as OpenAI's managed retrieval capability in the Responses API.
• OpenAI API deprecations (accessed 20 July 2026) - The Assistants API deprecation with a sunset date of 26 August 2026.
• OpenAI help centre: GPTs in ChatGPT (accessed 20 July 2026) - That GPTs are not a way to embed ChatGPT in an external website or application, and that the API is the route for building an assistant into a product.
• OpenAI help centre: creating and editing GPTs (accessed 20 July 2026) - Knowledge file limits of up to 20 files per GPT at up to 512 MB each, and that building a GPT requires a paid ChatGPT plan.
• Anthropic pricing (accessed 20 July 2026) - Claude Haiku 4.5 list price of $1 per 1M input tokens and $5 per 1M output tokens.
• Google Gemini API pricing (accessed 20 July 2026) - Gemini 2.5 Flash-Lite list price of $0.10 per 1M input tokens and $0.40 per 1M output tokens.