Get It: a PDF study companion that scores mastery per concept

The gap Get It targets: the student already owns the PDF

The README opens with a blunt claim: the student already has the PDF and does not need another summary. What they need, in the project's framing, is a way to see the parts a textbook refuses to draw and a way to prove understanding concept by concept. That is the whole design brief.

The stated failure of existing tools is that they measure surface area. Flashcard ratings measure recall in the moment. Mind maps measure how much you drew. Summaries measure how patient the model was. None of them answer the question the README puts in italics: whether you would survive a question you have not seen before.

So the audience is narrow on purpose. This is for someone working through a digital, text-based document they intend to be examined on, who wants a per-concept readout rather than a completion percentage. It is not a note-taking app, not a PDF annotator, and not a course platform.

How the pipeline runs: tag, render, graph, score

Three processes start once a file clears the import gate.

First, a concept-detection agent walks every page and plants inline tag pills on words that benefit from a picture. Each tag carries a renderer choice: 3D scene, 2D animation, formula walkthrough, plotted graph, or cited source. Second, the right pane fills in when you click a tag. Three.js handles anatomy and molecules, Canvas handles physics and chemistry animation, KaTeX handles formulas, a plot engine handles functions and distributions, and quoted sources handle legal articles and named papers. Third, a knowledge graph builds itself with six to twenty-five concept nodes, typed edges, node size by mastery and colour by progress.

The scoring loop is the part worth scrutinising. Four tools feed one journal: multi-turn chat scoped to a single document, flashcards with Again / Hard / Good / Easy self-grading, forced-choice quizzes with one correct answer and three plausible distractors, and a Feynman mode where the agent plays a curious eight-year-old and you teach. After each completed session an evaluator agent reads the journal end to end and updates four scores per concept node, memory, comprehension, structure and application, each 0 to 100.

Those scores are monotone non-decreasing by a runtime clamp. The student can only progress, never regress. That is a real design decision and it cuts both ways: it protects morale, and it also means the graph cannot tell you that you have forgotten something. A concept scored 90 last month stays at 90 even if you blank on it today. Spaced repetition is listed as a topic on the repository, but the clamp sits in tension with the idea of decay.

Installing Get It and reading your first document

The repository is a Next.js 16 app wrapped in Electron 33, with React 19, TypeScript and Tailwind 4. The package.json scripts define the developer path rather than a packaged download, so this is a build-from-source workflow. The dev script runs cleanup, then a Next build, then an Electron prepare step, then launches.

npm install
npm run dev

The dev script chains `npm run cleanup && npm run build && npm run electron:prepare && node scripts/launch.mjs`, so the first run compiles the app before the Electron window appears. There are also platform-specific desktop builds: `npm run build:desktop:mac-arm`, `npm run build:desktop:mac-x64` and `npm run build:desktop:win-x64`.

Before launching, copy the environment template. The file itself says to copy `.env.example` to `.env` or `.env.local`, and both are gitignored.

cp .env.example .env.local

The provider setting is documented as `"codex"` (the default), `"gemini"`, `"claude"`, or `"pi"`. Codex runs through the bundled `@openai/codex-sdk` npm package. Gemini and Claude are invoked as subprocesses, so their CLIs must be installed globally: `npm i -g @google/gemini-cli` for Gemini, `npm i -g @anthropic-ai/claude-code` for Claude. Their keys go in the same file.

# GEMINI_API_KEY=your_gemini_key_here
# ANTHROPIC_API_KEY=your_anthropic_key_here

Two visualisation settings matter for cost. `NEXT_PUBLIC_AUTO_GENERATE_VIZ` defaults to `false`, which means the app waits for a click before spending tokens on a tag; the template notes this keeps Codex usage proportional to what the student actually opens on long documents. `NEXT_PUBLIC_MAX_VIZ_GEN_RETRIES` defaults to 3, capping additional generation calls per tag at 1 plus that value, so up to four attempts.

Then drop in a text-based PDF or a `.md` file. Markdown is rendered to a clean document on the way in. The app checks the file up front and refuses scans or image-only documents with an explicit message, because it reads text, not pictures. If your PDF was produced by a scanner, convert it with OCR before you start.

Where Get It breaks: scans, rate limits and the repair loop

The import gate is the first hard boundary. Image-only and scanned PDFs are turned away. There is no OCR step in the pipeline as described, so a photographed textbook chapter is simply not usable input.

The second boundary is your provider's rate limit. The README is explicit that when you hit one, the app shows a countdown banner, stops cleanly, and your work is saved. Nothing retries in a loop. Once the window clears you pick back up by re-clicking a concept or hitting Retry on a tool. That is honest behaviour, but it also means a long document on a free tier will be a stop-start experience. The README states that a paid tier gives comfortable session headroom while free tiers sign in but their allowance is intentionally small.

The third is the visualisation repair loop. When a sandbox crashes on generated Three.js or Canvas code, the agent reads its own error and re-emits a fix, and the student sees a repairing state instead of a stack trace. That is capped by `NEXT_PUBLIC_MAX_VIZ_GEN_RETRIES`. After the cap, the tag presumably stays unresolved; the README does not describe what the user sees at that point.

One more thing to weigh: the four scores are produced by an LLM evaluator reading a journal, not by a psychometric instrument. The README calls the four numbers the difference between a study app and a measurement instrument. That is the project's claim about its own design, and it is worth treating as a claim rather than a validated result.

Get It versus Anki and the flashcard-only approach

The obvious comparison is Anki, and the difference is in what gets scheduled and what gets measured.

Anki schedules review of items you author or import. Its unit is the card, its signal is your own Again / Hard / Good / Easy press, and it has no opinion about whether you understood the underlying concept, only whether you recalled the card. Get It uses the same four-button grading inside its flashcard tool, but that grade is one input into a journal that an evaluator reads alongside chat, quiz and Feynman sessions. The output is four scores per concept node on a graph rather than a due-date queue.

The other difference is where the content comes from. In Anki you build the deck. In Get It the tags, the visualizations and the graph are generated from the document, so the cost is token spend against your own AI account rather than authoring time. That trade favours long, diagram-heavy technical documents and penalises anything you would rather write cards for by hand. Anki also runs entirely offline with no model dependency; Get It needs a working provider session for every agent action, and the README notes that a local model through Ollama is possible through the bring-your-own OpenAI-compatible path, which is the only configuration that removes the network dependency.

Licence, local data and what an upgrade actually costs

The project is Apache-2.0, and package.json marks it `"private": true`. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you keep the licence and notice files and state significant changes. None of that is legal advice, and if you plan to redistribute a modified build you should read the licence text in LICENSE yourself.

The privacy story is unusually specific for a hackathon project. The README states that documents and study journal never leave the computer: no accounts, no cloud sync, no document upload, no model traffic through the project's servers. Model calls go to whichever provider you configured. The only telemetry described is an anonymous open and update ping carrying a random install id, the app version and your OS, and `GETIT_DISABLE_ANALYTICS=1` turns it off. The journal is a single JSON file on disk, downloadable in one click from the right-pane menu.

Upgrade cost is where a build-from-source project bites. There is no auto-update mechanism described. Keeping current means pulling the repository and rerunning the build, and the release history shows three releases inside June 2026, v1.3.0, v1.4.0-preview and v1.4.0, so the cadence was fast at that point. The last push was on 2026-06-29, and the repository is not archived. Anyone running this should expect to rebuild rather than click an update button, and should watch for changes to `.env.example` keys between versions.

Editorial conclusion

Adopt Get It if you already hold a Codex, Claude or Gemini account, study from digital text PDFs, and want per-concept scores rather than a page counter. Skip it if your material is scanned, if you need a hosted web app with sync, or if you want a vendor to supply the model. Before installing, confirm your PDFs have a text layer, check that the CLI or key for your chosen provider works from a terminal, and open README.md and .env.example to see the current provider list.

Frequently asked questions

Official sources

1. beltromatti/get-it on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases