Llama Tutor: a Next.js study partner built on Llama 3.1 and Exa search

Six setup steps and four vendor accounts

The README is short enough to read in under a minute, and the whole running procedure fits in six numbered steps. Fork or clone the repository, create accounts at Together AI and Exa, create an account at Helicone for observability, write a `.env` using the `.example.env` at the root as a reference, then run the install and dev commands.

npm install
npm run dev

That is the entire path to a running app. What makes it interesting is what sits behind those steps: this is not a project you can run offline or for free. The model call goes to a hosted inference provider, the search call goes to a hosted search API, the request trace goes to a third hosted service, and the analytics go to a fourth. A reader who forks this expecting a local tutor finds four API keys and a metered bill.

The README does not name the individual environment variables. It says to copy `.example.env` and replace the keys, which means the authoritative list of what the app needs lives in a file rather than in the documentation. That is a reasonable choice for a small project and a mildly annoying one for a reader who wants to know before signing up what they are agreeing to pay for.

Why a tokenizer and a readability parser are in the dependency list

The most informative part of this repository is `package.json`, because it names the pieces that make grounded answers possible and a few of them are not obvious.

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "next lint"
}

Three entries in that dependency list explain the shape of the app. `llama3-tokenizer-js` exists because counting tokens for the Llama family needs the model's actual tokenizer rather than an approximation, which is what you need before truncating a fetched page to fit a context window. `@mozilla/readability` paired with `jsdom` is how the app turns a URL into clean article text on the server, stripping navigation and advertising so the model is not billed for a page's furniture. `exa-js` is the search provider that finds those URLs in the first place.

Read together, those three packages describe a specific pipeline: search for sources, fetch each page, extract the readable portion, count tokens against the model's vocabulary, trim, then answer with the extracted text as grounding. Nothing in the README explains this sequence, which is why the manifest is the more instructive document of the two.

Llama 3 and Llama 3.1 in the same README

The project description reads "An AI personal tutor built with Llama 3.1", and the repository topics list uses the same version. The README's own banner line says the project is powered by Llama 3 70B and Together.ai, without the point one. The tech stack section then goes back to Llama 3.1 70B from Meta.

So the repository states two different model generations for the same application. Both lines are worth taking seriously, because 70B is a size that changes the hosting story: Llama 3 70B and Llama 3.1 70B are different weights with different quality on reasoning and instruction following, and the hosted provider serves each separately. Since the code and not the README decides which checkpoint the app actually calls, the dependency on `together-ai` version `0.32.0` is where the real answer lives.

This is a small thing, and it is exactly the kind of small thing that survives in a project whose author wrote the banner before the implementation settled. It matters to a reader choosing between local and hosted inference, because the practical constraint is not the model name but whether the hosted endpoint for that exact checkpoint is available on the plan you signed up for.

An open source label with no license file

The README calls this an open source AI personal tutor, and the hosted site exists at llamatutor.com. GitHub reports no license for the repository, `package.json` has no license field, and the file listing at the root contains no LICENSE file of any kind.

Those three facts do not agree with the word open source in the banner, and the practical consequence is specific: without a license, the default copyright rules apply, which means nobody outside the author has been given permission to copy, modify or redistribute the code. The fork button on GitHub does not change this. A fork you cannot legally ship is a reading exercise.

This is a contradiction to surface rather than resolve, because a reader can act on it. If you want to run it, the license question does not matter. If you want to base a product on it, or contribute a change you expect to be merged, the absence of a file is the first thing to raise with the author, and adding a LICENSE would be the smallest useful contribution anyone could make here.

A pnpm lockfile in a repository that tells you to use npm

The file listing at the root includes `pnpm-lock.yaml`, `next.config.mjs`, `postcss.config.mjs`, `tailwind.config.ts`, `tsconfig.json`, `.eslintrc.json` and `.prettierrc`. That is the standard shape of a Next.js app wired up with Tailwind and a formatter, and it matches the README's claim of a Next.js app router project with Tailwind.

The lockfile is the odd one out. A pnpm lockfile means the project was installed with pnpm, yet the setup instructions say `npm install` and the README never mentions pnpm. Anyone who follows the instructions with npm gets a resolution tree that no maintainer has tested, and the version ranges in `package.json` are caret ranges throughout, so a fresh npm install will pick up newer minor versions than the ones pnpm recorded.

There is a second detail worth noting in the same list: a `proxy.ts` file sits at the repository root rather than inside `app/`, and `package.json` pins Next to `16.0.10` while React stays on `^18`. Both are choices a reader should verify against the Next.js version in use rather than assume.

The task list is the real status report

With no published releases and a package version of `0.1.0`, the only forward-looking information in the repository is a checklist titled Future Tasks. It has eight open boxes, and they describe a project mid-construction: share and copy buttons after a conversation, suggested follow-up questions and a new chat action at the end of the chat page, splitting the page in two and restoring the footer, moving icons into a typescript file, a more detailed landing page with a GitHub link, a hamburger menu on mobile, an experiment with the generative UI work from Vercel, and a nicer dropdown.

Two of those entries are worth pausing on. Adding generative UI from Vercel means the interface would start assembling components at runtime rather than rendering fixed ones, which is a much larger design commitment than the rest of the list implies. And the follow-up question item points at the real weakness of a retrieval tutor: today a conversation ends and the next step is manual.

The last push was on 2026-07-12, roughly three months before this writing, so the repository is not dormant. But with an empty release history and an unfilled checklist, the fair reading is that this is a reference implementation released for people to learn from rather than a project on a published cadence. The homepage at llamatutor.com is the version to judge for polish; the code is where the pipeline explanation lives.

Editorial conclusion

Llama Tutor is worth reading if you want a compact reference for how a Next.js app grounds model output in live search, because the two dependencies that do the real work, llama3-tokenizer-js and Exa, sit next to a token counter and a URL fetcher rather than hidden behind an abstraction. Copy it as a starting point rather than a dependency: the absence of a license file means there is no grant to build on, the inference and search calls land on paid accounts you supply yourself, and the setup path lists four of them. If you want a maintained product rather than a reference implementation, the missing licensing and the open checklist of unfinished tasks are the two facts to settle first.

Frequently asked questions

Official sources

1. Issues
2. Nutlope/llamatutor on GitHub
3. Project website
4. README