searchGPT: a grounded search engine built on OpenAI and Bing, now archived
Grounded search engine (i.e. with source reference) based on LLM / ChatGPT / OpenAI API. It supports web search, file content search etc.
At a glance
- What is it?
- searchGPT is a small Python project that chains an OpenAI language model to Bing web search and local document files so answers carry numbered citations. The README marks it archived, so the interesting question is what its design teaches and what you inherit if you still run it.
- Who is it for?
- Adopt searchGPT only as a reading reference or a self-hosted demo, not as a maintained dependency. The repository is archived, so pull requests may not be reviewed, and the setup pins Python 3.10.8 plus paid OpenAI and Azure Bing keys.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 113 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem searchGPT was built to fix: hallucination on facts the model never learned
The README states the motivation directly: an LLM cannot learn everything during training, so real-time factual information is needed for reference. That is the whole thesis. The project exists to attach retrieved text to a generated answer and mark where each claim came from.
The README illustrates the failure mode with two comparisons using the text-curie-001 model. Asked what a ghost kitchen is, the ungrounded answer invents a kitchen staffed by departed spirits. Asked about the meaning of wwww in Japanese, the ungrounded answer treats it as a URL placeholder. In both cases the grounded variant returns a factual answer with bracketed citation numbers such as [1] and [2] pointing back at sources. The README also notes the project can be read as a minimal implementation of new Bing, scoped to search and question answering.
Who is this for? Developers who want to see the smallest complete loop of retrieval plus generation plus citation, and who are comfortable reading Python rather than installing a framework. It is not aimed at teams that need an SLA, a plugin ecosystem, or a hosted endpoint. The repository is explicit about its own status: a warning block at the top of the README states the project is archived and the developer is no longer actively maintaining or updating it.
What actually runs: retrieval from Bing and files, embeddings, then a cited answer
The README lists the sources the system can draw on. One is web search with real-time results. Another is file content search covering formats such as PPT, DOC, DOCX and PPTX. Between retrieval and generation sits semantic search over the retrieved source using OpenAI embeddings, and the README adds a parenthetical that matters: FAISS and pyterrier code is currently commented out. So the vector-index story is not the default path in the shipped code. If you are evaluating the project for its retrieval quality, that sentence tells you the retrieval layer you would be reviewing is not the one the README describes in its feature list.
Generation is delegated to an LLM provider, with OpenAI and GooseAI named as integrations. The README does not document prompt templates, chunk sizes, ranking rules, or how many sources are fed into a single answer. Those details would have to come from reading src/ directly, and the README does not walk through them. The architecture and roadmap are presented as an image rather than text, so the repository's own description of data flow is a diagram you have to open.
What is documented is the output shape: bracketed numeric citations attached to sentences, and a separate explainability screenshot showing sources alongside the answer. That citation discipline is the part worth copying. It forces the generator to commit to a source per claim, and it gives a reader a way to check the claim without trusting the model.
Setup: one config file, three entry points, and two paid API keys
Prerequisites are narrow. The README specifies Python 3.10.8, an OpenAI API key or a GooseAI API key, and an Azure Bing Search subscription key. Both key types are paid services, so a working install has a running cost before you write a line of code.
Installation is two commands. For a native environment: pip install -r requirements.txt. For Anaconda: conda create --name searchgpt python=3.10.8, then conda activate searchgpt, then the same pip install. The version pin is not decorative. Python 3.10.8 is named in both paths, and the README does not claim support for 3.11 or 3.12.
Configuration goes in src/config/config.yaml, where the OpenAI or GooseAI key and the Azure Bing Search key are entered. The README notes the keys can also be supplied through the UI, which is convenient for a local demo and a poor idea for anything shared, since it moves secrets into browser input rather than a file you control.
There are three entry points and they behave differently. app.py or src/flask_app.py launches the frontend web app. src/main.py produces stdout output only, which is the one to use if you want to script the pipeline or run it headless. The README does not document command-line flags for src/main.py, so treat the stdout path as a starting point you will extend rather than a finished CLI.
The retrieval layer is the weak point, and the README says so in a parenthesis
The most consequential sentence in the README is the note that FAISS and pyterrier code is currently commented out. Semantic search over sources is listed as a feature, and OpenAI embeddings are named as the mechanism, but the two vector-search backends most readers would associate with that mechanism are disabled in the shipped code. That leaves an open question the README does not answer: what performs the semantic matching by default, and how does it scale past a handful of documents? Without that answer, any assumption about recall on a large file set is unverified.
A second limitation is scope. The retrieval sources are web search and local files. There is no database connector, no API source, no streaming ingestion described. If your grounding corpus lives in a warehouse or behind an internal service, this project does not reach it without new code.
A third is the archived status. The README states plainly that new features, fixes, and pull requests may not be reviewed or merged promptly. Combine that with a hard pin on Python 3.10.8 and dependencies pulled from requirements.txt at install time, and you have a project whose environment will drift away from it. The last release listed is v20230312, dated March 2023, while the repository's last push is dated 2026. That gap is the shape of an archive, not a maintained tool.
Finally, grounded does not mean correct. Citations show where a sentence came from, not whether the source was accurate or whether the model summarised it faithfully. The README's own examples are persuasive, but they are two prompts chosen by the author.
How this differs from a retrieval framework such as LangChain or LlamaIndex
The obvious alternative category is a retrieval framework: LangChain or LlamaIndex. The difference is one of packaging, not of idea. Those projects give you a library of interchangeable retrievers, vector stores, splitters and chains, and you assemble the pipeline yourself. searchGPT gives you one assembled pipeline with a web UI attached, plus the citation formatting already wired into the answer. If you want to ship a small grounded question-answering demo this week and you are happy with Bing plus local files, the pre-built path is shorter. If you need to swap the retriever, add a reranker, or point at a different corpus, the framework is the better starting point, because with searchGPT you would be editing its internals rather than composing its parts.
The second alternative is simply the provider's own grounded search offering. A hosted grounded search endpoint handles retrieval, freshness and citation formatting for you, and you pay per query instead of operating a Python service. The trade is control and data locality. searchGPT runs on your machine, which matters when the documents you want to search cannot leave it. The hosted route also removes the Bing key and the Python 3.10.8 pin from your problem entirely.
Neither comparison is a verdict on code quality. It is a statement about what you are buying: a worked example with a UI, or a toolkit with a maintenance burden you choose.
Licence, maintenance cost, and what the MIT terms do not cover
searchGPT is licensed under the MIT License, per the README and the LICENSE file in the repository. MIT is permissive: you can use, modify and redistribute the code, including in commercial products, provided the copyright notice and licence text are preserved. That is the standard reading, and it is not legal advice. What MIT does not do is grant you anything on the services the project depends on. Your OpenAI or GooseAI usage is governed by that provider's terms, your Bing Search key by Microsoft's, and the content you retrieve from the web by whatever rights apply to it. A permissive code licence does not make the retrieved text yours to redistribute.
Maintenance cost is the real number here. The project is archived, so upstream fixes are not coming. You own the dependency graph in requirements.txt, the Python 3.10.8 pin, and any breakage in the OpenAI or Bing client libraries the code uses. The README also mentions GooseAI as an alternative provider, which softens provider lock-in somewhat, but does not change the fact that you are maintaining a frozen codebase.
If the goal is to learn the pattern, the cost is an afternoon and two API keys. If the goal is to run it in production, the honest framing is that you are forking it. Budget accordingly, and read src/config/config.yaml and the retrieval code before you commit, because that is where the README stops explaining.
Editorial conclusion
Adopt searchGPT only as a reading reference or a self-hosted demo, not as a maintained dependency. The repository is archived, so pull requests may not be reviewed, and the setup pins Python 3.10.8 plus paid OpenAI and Azure Bing keys. Before running anything, check whether your Bing Search tier still returns web results through the key you hold, and confirm which embedding path is active, because the README states the FAISS and pyterrier code is commented out. If you need a maintained grounded retrieval stack, budget for replacing the retrieval layer rather than patching this one.
Community notes