A page that explores the GitHub repo it's deployed from — live, entirely in the browser, no backend.
Ask it a question about its own source, current or historical ("what does this file do", "what changed in the last commit"), and it fetches the real repo via GitHub's API, retrieves the relevant files/commits locally, and reasons over just that shortlist. No server, no API key, no signup.
- Resolve context — when served from
<user>.github.io/<repo>/, the page infers its own owner/repo from the URL. No hardcoded config needed once deployed. - Fetch structure — one call to the recursive git-tree endpoint gets the whole file listing.
- Fetch content — file bytes (current or at any historical commit SHA) come from
raw.githubusercontent.com, which has its own CORS-open, effectively-unlimited-for-this-use pool, separate from the 60/hourapi.github.combudget. - Retrieve — a local heuristic (keyword/path/tag scoring, no LLM) narrows the tree down to a shortlist of a handful of relevant files or commits, so the model never has to see the whole repo.
- Reason — the shortlist goes to an in-browser model, which answers the question and shows which files/commits it used.
- Model: Chrome's built-in Gemini Nano via the Prompt API (
LanguageModelglobal) for v1 — zero download, but Chrome-only and experimental. Open-weight/WebLLM (portable, multi-hundred-MB-to-GB first-load download) deliberately deferred past v1. - Multiple files, not one HTML file: split into
src/github.js/retrieve.js/model.json purpose, for searchability, despite every other demo in this workspace being a single standalone file. The real cost of that choice is quieter cross-file interface bugs (aref/branchmismatch betweenfetchRawContentand its callers shipped once already, looked like CDN flakiness before it was isolated). Mitigated with// @ts-check+ JSDoc types ongithub.js/retrieve.js— zero added files, just comments, and VS Code's built-in TS language service catches shape mismatches live (model.jsis exempt —LanguageModelisn't a type TS's DOM lib knows about, so checking it would just be false-positive noise). Deliberately did not keep a checked-in test file for this — no other repo in this workspace has one either, and a standalone test file is process, not functionality.
- Rate-limit resilience:
api.github.comis capped at 60 req/hour per IP (raw content fetches don't count against this). For anything beyond casual browsing traffic, add a build-time snapshot fallback so a live demo (e.g. a talk audience on shared wifi) can't fail from quota exhaustion. Not yet built.
Portfolio/demo piece, not a product — see the project's own reasoning for why "on-device AI beats a cloud agent" doesn't hold as a broad pitch. The value here is the demo itself: proof of retrieval-under-a-tight-context-budget, live third-party API orchestration, zero-backend architecture.