# TurboSeek: an AI search engine small enough to read in one sitting, and honest enough to admit what it has not built yet > A Next.js app that takes a question, pulls the top search results, scrapes them for context and streams an answer from gpt-oss. Its own README lists eleven unfinished tasks, which is the most useful thing in the repository. **Nutlope/turboseek** — An AI search engine inspired by Perplexity - Repository: https://github.com/Nutlope/turboseek - Website: https://www.turboseek.io/ - Stars: 1,657 · Forks: 261 - Language: TypeScript - License: not declared - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/nutlope-turboseek ## The five-step request flow, exactly as the README lists it The README describes the pipeline in five numbered steps, and that list is the most useful documentation in the repository because it names each external call. Step one takes the user's question. Step two looks up the top 6 results through a search API and shows them. Step three scrapes the text from those 6 links and stores it as context. Step four sends the question plus that context to gpt-oss and streams the response back. Step five makes a second request, this time to Llama 3.1 8B, to produce 3 related questions the user can follow up with. Two details in that sequence are worth pausing on. The result count is fixed at 6, which is a small context budget and explains the missing citation feature in the roadmap: with six sources, the model frequently blends them and does not attribute cleanly. And step five is a separate model call rather than a prompt continuation of step four, so follow-up generation runs even when the answer was thin. The scraping step is the fragile one. Six arbitrary web pages get fetched and their text handed to a model, with no description of how HTML is reduced to text or what happens when a page blocks the request. That is where a project like this usually breaks first, and the README does not discuss it. ## The tech stack list and where it disagrees with the flow description The README's tech stack section lists six things: Next.js app router with Tailwind, Together AI for LLM inference, OpenAI gpt-oss models and Llama 3.1 8B for the LLMs, Exa.ai for the search API, Helicone for observability, and Plausible for website analytics. Here is the contradiction worth your attention. The stack list names Exa.ai as the search API. The how-it-works section, two headings earlier, says the app makes a request to the bing search API and that bing is what sends back the 6 links. Those are different providers with different APIs and different rate limits, so you cannot follow both descriptions. The rest of the documentation offers a third possibility. The cloning instructions tell you to create an account at SERP API, specifically serper.dev, or with Azure's Bing Search API. So the README describes Bing as a SerpAPI or Azure endpoint in one place and Exa in another. The `exa-js` package at version 2.x does appear in the package manifest, which suggests Exa is what the code actually calls and the bing wording is older text that survived a rewrite. Check the API route in `app/` before you trust either sentence. Plausible and Helicone are a sensible pair for a demo project. Plausible is cookie-light visitor analytics, Helicone is request-level LLM observability. Both are one environment variable away, and both are removable if you deploy this for yourself. ## Running it locally takes four accounts and one env file The README's cloning section lists six steps, and the practical part is that four of them are account creation. Fork or clone the repository. Create an account at Together AI for the LLM. Create an account at SERP API, or at Azure for Bing Search. Create an account at Helicone for observability. Create a `.env` file using `.example.env` as the reference and replace the API keys. Then install and run. ```bash npm install npm run dev ``` Those two commands come straight from the README's final step. The scripts exist in the package manifest: `dev` maps to `next dev`, `build` to `next build`, `start` to `next start` and `lint` to `next lint`. The Next.js version pinned is 16.0.10 with React 19, and Tailwind is at 3.4.1. Note that a lockfile named `pnpm-lock.yaml` is present in the tree while the README tells you to use npm. Both work, since pnpm can read a package.json that npm also reads, but the two flows produce different node_modules layouts and pnpm's symlinked store behaves differently for some transitive dependencies. Pick one and stay with it. The `.example.env` file is in the repository root, so the four credentials you need are discoverable without guessing key names. That is more than many small demos provide. ## Eleven unfinished tasks that read as a design document The README has a Future tasks section with eleven unchecked boxes. It is unusual to find one, and it functions as a better statement of the project's direction than the feature description does. The first item is to move back to the Together SDK with simpler streaming, which confirms what the package manifest shows. `package.json` depends on `@ai-sdk/togetherai` at 1.0.29 and also on the older `together-ai` package pinned at exactly 0.32.0. Two SDKs for the same provider in one dependency list means the streaming implementation was migrated and the old call path was never removed. Anyone copying this project should finish that migration rather than inherit it. The next two are about context budget: add a tokenizer to count tokens per source so the app knows before it goes over, and add a regenerate option. Two more address output quality and distribution, namely making sure the answer correctly cites and numbers all sources, and adding sharability. Two are UI details, auto-scroll during streaming on mobile especially, and fixing a hard refresh in the header and footer by moving answers to their own page. The final three are infrastructure: Upstash Redis for caching and rate limiting, advanced RAG techniques such as keyword search and question rephrasing, and authentication with Clerk backed by Postgres and Prisma for user sessions. Read as a group, they say the author built the demo path and knows exactly which production concerns are missing. Redis for caching and rate limiting is the first one to matter if this faces real traffic, since without it every anonymous visitor costs you a gpt-oss call. ## What the repository tree reveals about the scope The tree is small enough to be worth listing. Alongside the root config files there are `app/`, `components/`, `utils/` and `public/`, plus `.eslintrc.json`, `.prettierrc`, `.example.env`, `next.config.mjs`, `postcss.config.mjs`, `tailwind.config.ts` and `tsconfig.json`. Fifteen entries, one of them a directory per layer. That is the whole application, and the consequence is that TurboSeek is best understood as a reference implementation rather than a product you can fork into production and extend. There is no test directory, no database layer, no authentication code, no error boundary strategy and no rate limiting, because the roadmap lists all of those as not yet built. The dependency list tells the same story from a different angle. The runtime dependencies are `@ai-sdk/togetherai`, `ai`, `exa-js`, `next-plausible`, `react-hot-toast`, plus the two Together packages. No scraping library appears there, which is worth noticing given step three of the flow is scraping six pages. That suggests the scraping happens through fetch plus some parsing in the route handler rather than a dedicated library, or that the route handler does something simpler than a full fetch-and-extract cycle. There are no releases on this repository. There is a banner image and a link to a tutorial on the Together AI documentation site, which the README recommends as the way to learn how this was built. That tutorial is arguably the more complete explanation, since the README is written to get you running rather than to teach the design. ## Where this sits against Perplexity and the open clones The README credits its inspiration directly: Perplexity, You.com and Lepton search. All three are hosted products that answer questions with citations over live web results, and all three run closed models over their own crawl rather than over a third-party search API. That last point is the structural difference. A hosted answer engine owns its index. TurboSeek calls an external search API for six results and then scrapes whatever those results point to, which means it depends on two services it does not control and inherits both their rate limits and their page structures. For a demo that is a reasonable trade. For anything load-bearing it is the first thing that will fail, and the reason Redis caching appears so high on the roadmap. The open clones named in search results, such as Perplexica, Scira and NoteGPT, take different approaches. Several maintain their own crawler or index rather than leaning on a commercial search API, which costs more infrastructure but removes the scraping fragility. Others keep the search API and focus on the answer layer instead. The practical takeaway is that TurboSeek is most useful as a reading exercise. It shows the shape of a search-augmented answer engine in a codebase small enough to hold in your head, with the expensive parts left to someone else's API. If you want to run one in production, the roadmap in its own README is the honest list of what still has to be built. ## Conclusion TurboSeek is worth reading rather than deploying. At roughly fifteen files in the tree and one page component, it is a complete, runnable sketch of how answer engines are put together: search for context, scrape it, stream a model response, then generate follow-up questions from the same corpus. Anyone building a search-augmented product will get more from an afternoon with this code than from a product tour. Two things to settle before you copy the approach. The README names Bing as the search provider while the tech stack list names Exa, so the code is the only reliable answer on which one is wired up. And the package manifest carries both the modern Together AI SDK and a legacy `together-ai` package at a fixed version, which means the streaming code is halfway through a migration. The last push was on 2026-07-12. ## FAQ ### How can I create my own AI search engine? TurboSeek is built around that pattern and the README documents all of it. The flow is: take the user's question, call a search API for the top results, scrape text from those links as context, send question plus context to an LLM and stream the answer, then make a second model call for related follow-up questions. The repo is small enough to read as a template for building your own. ### Which search provider does TurboSeek actually use? The README contradicts itself. The tech stack list names Exa.ai for the search API, while the how-it-works section describes requests to the bing search API, and the setup instructions point to serper.dev or Azure Bing. The `exa-js` dependency in package.json suggests Exa is wired up in the code and the Bing wording is older text. ### What API keys do I need to run TurboSeek? Four accounts, per the README's cloning section: Together AI for the LLM, SERP API at serper.dev or Azure Bing Search, Helicone for observability, and optionally Plausible for analytics. Copy `.example.env` to `.env` and fill in the keys before running `npm install` and `npm run dev`. ### Why does the project depend on two Together AI packages? The package manifest lists `@ai-sdk/togetherai` at 1.0.29 alongside the older `together-ai` package pinned at 0.32.0. The README's roadmap confirms the cause, with a first task to move back to the Together SDK with simpler streaming, so the migration is half finished and both call paths remain. ### Can I use TurboSeek in a commercial product? Not on the current terms. There is no LICENSE file in the repository, the license field in the metadata is empty, and the README does not state licensing terms. If you intend to build on this code, contact the author or wait for a license to be added before shipping anything. ## Sources - [Issues](https://github.com/Nutlope/turboseek/issues) - [Nutlope/turboseek on GitHub](https://github.com/Nutlope/turboseek) - [Project website](https://www.turboseek.io/) - [README](https://github.com/Nutlope/turboseek/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nutlope-turboseek