HKU's HKUDS Open-Sources AI Tutor DeepTutor, Hits 20K Stars in 111 Days
- DeepTutor, a personalized learning tool open-sourced by the University of Hong Kong's Data Intelligence Lab (HKUDS), launched on 2025-12-29 under Apache 2.0 — fully open source. The authors state there is currently no paid online product of any kind.
- Within 111 days of launch (as of 2026-04-19), it passed 20,000 GitHub stars and hit both the daily and weekly Trendshift trending charts.
- Chat, Partners, Co-Writer, Book, Knowledge, Memory — every module shares the same agent loop and interconnected context. Switching modes just changes what this turn is trying to accomplish; the underlying engine is always the same one.
- The companion paper proposes a hybrid personalization engine (static knowledge grounding + dynamic personal memory), lifting personalization metrics by 10.8% on average across TutorBench, a benchmark spanning five disciplines and 270 tasks.
- With the entire personalization engine disabled, the same "investigate, solve, write" scaffolding still lifts general agentic reasoning ability by 29.4% on average across five backbone models on public benchmarks.
HKU's team open-sourced an AI tutor, and people are actually using it
HKU's Data Intelligence Lab (HKUDS) released the open-source learning tool DeepTutor on December 29, 2025, and published a companion research paper on its underlying mechanism in the first half of 2026.
Why this isn't just another routine open-source drop: it passed 20,000 GitHub stars within 111 days of launch, hitting both the daily and weekly Trendshift trending charts; the project is fully open source under Apache 2.0 with no paid product whatsoever; and it's backed by an arXiv paper with verifiable numbers from a benchmark spanning five disciplines and 270 tasks.
The project is led by Bingxi Zhao at HKUDS (advisor Chao Huang, director of HKU's Data Intelligence Lab), with community contributions. The ecosystem also reuses several of the lab's own open-source projects: LightRAG (retrieval engine), nanobot (an earlier ultra-lightweight agent engine), AutoAgent, and AI-Researcher.
One brain, eight learning modes — what you're switching is just the goal
DeepTutor's core design: chat, problem-solving, quiz generation, research, visualization, mastery practice — all run on the same agent loop. What you switch is what you want to do this turn; the underlying engine and context are always the same.
How a chat becomes full tutoring: it thinks for itself, and asks you back when unsure
Chat is the default entry point — most work starts here. A single conversation thread can chat normally, call tools, "ground" answers against a selected knowledge base, read attachments, generate images, consult other agents, write to a notebook, and carry the same context across multiple turns.
The loop is deliberately simple: the model reasons turn by turn, calls tools when needed, observes the results, then produces a final answer with no further tool calls. The key is a special tool called ask_user: when unsure, instead of guessing, the agent can pause this turn, surface a structured clarifying question, and wait for your answer before continuing.
search/reason/draw…
ask_user asks you back
Toggleable tools include brainstorm, web_search, paper_search, reason (deep reasoning), and geogebra_analysis (math plotting analysis); once a generation model is configured, imagegen and videogen become available too. Chat is also the launch point for deeper capabilities: Quiz (question generation), Research (cited reports), Visualize (chart animation), Solve (detailed reasoning), and Mastery Path (study plans) all branch off from here.
What it remembers and what it forgets: two clearly separated contexts
Persists across turns
Sub-agents, knowledge base, persona, model, and voice — pinned to the input toolbar, staying active for the entire conversation.
Applies to this turn only
Files, chat history, books, notebooks, question banks, and imported agents — pulled in temporarily via the "+" menu, serving only the current question.
How does it know you so well? A memory you can click open, layer by layer
DeepTutor's personalization doesn't rely on a vector store hidden in the backend — it's a file-backed, three-layer memory you can read, edit, and audit. Because every conclusion in an upper layer cites evidence from the layer below, any line in your profile can be traced all the way back to the original event. The diagram below is clickable — click a layer to see exactly what it stores and where it came from.
Quiz surface: 3 out of 5 related practice questions wrong, all on "differentiate the outer or inner function first."
The official docs split this memory into three layers: L1 is a workspace mirror plus an append-only event trace, L2 is the curated facts each surface distills, and L3 is the cross-surface synthesis. Because L2 cites L1 and L3 cites L2, anything in your profile can be traced back to its source along the chain. The product's Memory Graph visualizes the whole pyramid: L3 synthesis at the center, L2 in the middle ring, L1 traces on the outer ring.
Both images above are from the official HKUDS repo.
Companion, writing, book-making, research: the rest of the modules in one pass
The modules below are somewhat secondary but still practical. They all run on the same brain — here they're covered briefly, each with an official screenshot.
Partners: a persistent companion with a personality and a phone number
Partners are persistent companions with their own persona, model strategy, resource library, memory, and channels. Every message coming in from the web or an IM app becomes a normal conversation turn inside that partner's dedicated workspace. The channel layer is configuration-driven and supports 15 entry points, including Feishu, Telegram, Slack, Discord, DingTalk, WeCom, WhatsApp, and Teams. A partner can also be consulted as a sub-agent from regular chat — that's "My Agents": it can connect to local Claude Code or Codex for live consultation, and can also import your existing conversation history into a searchable, continuable named agent.
Click to view the Partners architecture diagram
Co-Writer: select a passage and let it rewrite — nothing lands until you approve it
A split-pane Markdown writing surface with live rendered preview (including math and charts). Its core feature is "surgical editing": select a passage and have it rewritten, expanded, or condensed. The editing agent can back up changes with knowledge-base or web evidence, shows every edit as an accept/reject diff, and writes nothing to the document until you click approve.
Book: turn your material into a "living book"
Book turns selected sources into an interactive living book — a reading environment built from typed blocks. On creation, it gives you a chapter outline to review first, rather than dropping a black-box finished product on you. Each chapter compiles into blocks — text, callout, quiz, flashcard, timeline, code, chart, interactive component, animation, concept map — and every page has its own Page Chat. Blocks can be individually inserted, moved, regenerated, or switched to a different type without rewriting the whole chapter.
Knowledge Center: you get to pick the retrieval engine
A knowledge base is the document collection behind RAG (retrieve then answer), providing grounding for chat, writing, book-making, and Partner conversations. What's distinctive is that you can choose the retrieval engine: LlamaIndex (default, local vector plus keyword), PageIndex (with page-level citations), GraphRAG, and LightRAG (knowledge-graph retrieval) — or link directly to an Obsidian vault and let the tutor read and write it in place. Each knowledge base is bound to one engine, and re-indexing preserves old versions instead of breaking the one currently in use.
Learning Space: skills, personas, and reusable context
The resource library and personalization layer. It holds chat history, notebooks, question banks (every saved question keeps your answer, the reference answer, and the explanation), plus mastery paths, personas (behavior presets like "companion," "research assistant," or "teacher"), and skills (SKILL.md scripts the model reads on demand). Skills don't have to be written from scratch — you can download one directly from the EduHub community directory.
Up and running in three commands — and callable as a tool by other AI
The smoothest path is a PyPI install: it sets up a full local web app plus a CLI without cloning any code. Requires Python 3.11+ and Node.js 20+.
pip install -U deeptutor deeptutor init deeptutor start # open 127.0.0.1:3782
docker run --rm --name deeptutor \ -p 127.0.0.1:3782:3782 \ -v deeptutor-data:/app/data \ ghcr.io/hkuds/deeptutor:latest
There are four install paths in total: PyPI (above), source (for modifying code), Docker (single container running the full app), and CLI-only (for headless servers, agent harnesses, and scenarios like Claude Code / Codex with no web UI). Auth is off by default, running single-user by default; once multi-user is enabled, the first person to register becomes admin, and everyone else gets an isolated workspace and a redacted settings page that never exposes raw API keys. Configuration is plain JSON/YAML throughout.
It's not just built for humans — it's built for other agents too
The DeepTutor CLI has two modes: an interactive REPL (deeptutor chat), and structured JSON output for other agents (add --format json, streamed as NDJSON turn by turn). It runs "headless-safe": when there's no terminal, an ask_user pause resolves automatically with an empty reply instead of hanging. The repo root ships a roughly 150-line SKILL.md handoff document that Claude Code, Codex, and OpenCode recognize automatically — reading it once is enough to understand the whole system, and it also lets you wrap deeptutor run as a tool inside a LangChain or AutoGen loop.
deeptutor skill search "socratic tutor" deeptutor skill install socratic-tutor
Every skill imported from EduHub goes through the same security gate: registry security vetting, defensive archive extraction, stripping the "always" field from the skill (a downloaded skill can't be forced into every system prompt), and its provenance is logged to .hub-lock.json for auditing.
How these features tie together: a paper spells out the mechanism behind it
The modules above read like a list of features. What actually keeps them from being disjointed — what makes this a system that gets better the more you use it — is a paper released alongside the product by the HKUDS team, "DeepTutor: Towards Agentic Personalized Tutoring." It answers a concrete question: why does a weakness spotted during tutoring directly determine what question gets generated next, and why does performance on those questions feed back into improving the next explanation?
The paper couples two things into a closed loop: static knowledge grounding (SKG) handles "is what's being taught correct, and grounded in the curriculum," and dynamic personal memory (DPM) handles "is this way of teaching, and this question, right for this specific student." The two are complementary — neither can replace the other.
SKG and DPM are the most abstract pair of concepts in this paper — here's a comparison card to tell them apart first:
Is the curriculum content correct
Breaks textbooks and papers into atomic knowledge units, uses a knowledge graph to capture relationships between them and a vector index to capture their semantics, merging and deduplicating results from both paths at query time.
Responsible for making sure what the tutor teaches is grounded and factually correct.
Is it right for this student
Its core is the "trace forest": each complete tutoring session is recorded as a tree, with nodes split into three layers (session summary, mid-level planning, execution detail); three dedicated memory agents actively retrieve and compare against it to continuously update the learner profile.
Responsible for making sure the depth and style of explanation fit this particular person.
Like a tutor who flips through the textbook to make sure the concept was taught correctly (SKG), while also flipping through this student's error log to decide how to explain it and what to assign next (DPM).
Trace forest: a layered chart opened for every tutoring session
The trace forest is DPM's ledger. Every complete tutoring conversation is recorded as a tree: Level 1 stores session-level input and a global summary, Level 2 stores the mid-level plan the task was broken into, and Level 3 stores the finest-grained execution record, including tool outputs, evidence, and verification results. Every node carries a vector encoding, so it can be retrieved by semantic similarity across the whole forest. The system browses it with a toolkit called TraceToolkit, which has only three actions: find similar by semantics (SearchTrace), filter and enumerate by time or topic (ListTraces), and read a node in full along with its ancestor path (ReadNodes).
It's like opening a detailed chart for every tutoring session, organized by layer — "chief complaint → diagnostic reasoning → specific exam records." On the next visit, you can pull up detail from any layer of an old chart, instead of seeing just one line like "this student is average at math."
The profile isn't generated by passively summarizing the latest conversation. Every time a new trace comes in, three dedicated memory agents actively query TraceToolkit, compare the latest behavior against older cross-session patterns, and update three parts of the profile: a summary of session history, an evidence-backed list of recurring confusions, and teaching reflections that guide the future. Personalization is thus built on retrievable trace evidence, not a crude "mastery score."
Putting it together: how the loop runs
Connecting the two pieces: static knowledge and personal memory are first synthesized into a "personalized context" inside the hybrid personalization engine, which feeds both pipelines at once — tutoring goes through three steps ("investigate, guide step by step, then write an explanation calibrated to the student's level," where beginners get a scaffolded step-by-step derivation and advanced students get a concise summary of just the key insight), while quiz generation goes through two steps (map concepts from this student's perspective to pick a question, then have an independent verifier check correctness). After the student finishes this round, the results are written back into the trace forest and refresh the profile.
investigate · guide · explain
select · independently verify
Paper authors: Bingxi Zhao, Jiahao Zhang, Xubin Ren, Zirui Guo, Tianzhe Chu, Yi Ma, Chao Huang (The University of Hong Kong, HKUDS). v1 submitted 2026-04-10, v2 on 2026-05-08.
Does it actually work: results from 270 tasks
To test personalized tutoring, the paper built its own student-centered benchmark, TutorBench: it first indexes university textbooks and papers into knowledge bases, then generates 3 student profiles at different levels for each knowledge base, each profile attached with source-grounded knowledge gaps (categorized as "misconception," "incomplete understanding," or "missing knowledge"), and finally keeps exactly 3 passing interactive tasks per profile.
How it's scored: putting an AI student through the class
The benchmark uses an AI-based student simulator to interact with each tested system: the simulator turns knowledge gaps into first-person "I thought…" statements, requests a custom exercise after several rounds of tutoring, and the resulting full conversation transcript is scored against a personalization rubric. The rubric has two groups of five items each, 1 to 5 points apiece. Tutoring side: source faithfulness, personalization, applicability, engagement, logical depth. Exercise side: match quality, grounding adequacy, diversity, answer quality, cross-concept coverage. The evaluation covers all 270 tasks, uses Gemini-3-Flash to drive both the student simulator and each system's backbone, and uses Claude Sonnet 4.6 as the judge.
The three dimensions with the biggest gains
Bars are scaled against a maximum score of 5.
Five systems, side by side
The four baselines all share the same retrieval tools and backbone model, differing only by adding chain-of-thought, self-refine, or ReAct-style tool calling. Their scores cluster tightly, which shows that adding these alone isn't enough to catch up with a system that genuinely adapts to the learner.
| System | Tutoring avg. | Exercise avg. | Overall quality | Relative gain |
|---|---|---|---|---|
| Naive Tutor | 3.96 | 3.10 | 3.53 | — |
| CoT Tutor (chain-of-thought) | 3.97 | 3.06 | 3.52 | -0.28% |
| Self-Refine Tutor | 4.05 | 3.08 | 3.57 | +1.13% |
| ReAct Tutor (tool loop) | 3.96 | 3.08 | 3.52 | -0.28% |
| DeepTutor | 4.39 | 3.42 | 3.91 | +10.76% |
Alignment with human preference: from 45 sessions stratified-sampled across five domains for blind pairwise comparison, both human reviewers and the AI judge gave DeepTutor the top preference across all ten metrics, and the two win rates correlate strongly (Pearson r=0.82, p=0.0038) — meaning the AI judge isn't blindly favoring it, but ranking similarly to humans under the same rubric.
Stable across domains: overall quality differs by only 0.16 points across the five disciplines, so the gain isn't being carried by just one subject.
Taking it apart: SKG and DPM each do their own job, neither is dispensable
The ablation study removes each component separately to see which metrics collapse:
The biggest drop is in "grounding adequacy," followed by "source faithfulness" and "cross-concept coverage."
In other words, the tutor starts "teaching without grounding."
The biggest drop is in "personalization" and "match quality."
In other words, the explanations and questions stop fitting this particular student.
Removing both together causes the largest overall drop. This confirms SKG and DPM are complementary mechanisms: SKG anchors "what the tutor says," DPM shapes "how it adapts to you" — neither substitutes for or eliminates the need for the other.
An unexpected finding: turn off personalization entirely, and the scaffolding alone still holds up
The paper also tested something else: is DeepTutor's "investigate, solve, write" scaffolding only useful for personalized tutoring, or does it also help general problem-solving? So they disabled the entire hybrid personalization engine (both SKG and DPM turned off), kept only the bare solver, and measured the improvement in first-try accuracy (Pass@1) across five public benchmarks (HLE, GPQA-Diamond, the LiveBench reasoning subset, GAIA, and AA-LCR).
All five backbone models improved, with average relative gains ranging from 25.69% to 32.03%. Personalization, SKG, and DPM were all switched off in this run, so the gain points to the general-purpose value of the "investigate, solve, write" scaffolding itself.
Click to see the per-benchmark breakdown across all five test sets
| Backbone model | HLE | GPQA-D | LiveBench | GAIA | AA-LCR |
|---|---|---|---|---|---|
| Gemini-3-Flash | 19.40→30.80 | 81.31→84.85 | 70.00→96.00 | 37.58→47.88 | 63.00→74.67 |
| Sonnet-4.5 | 8.40→14.60 | 72.22→73.23 | 64.33→82.00 | 29.09→45.45 | 53.33→54.00 |
| Qwen-3.5-Plus | 16.80→24.20 | 88.38→87.88 | 69.00→93.00 | 33.94→49.09 | 66.00→69.67 |
| GPT-5-Mini | 16.46→21.20 | 80.81→80.30 | 71.00→93.00 | 27.27→49.09 | 68.67→71.00 |
| Minimax-M2.5 | 14.00→19.40 | 82.83→83.33 | 59.30→73.00 | 23.64→42.42 | 66.00→76.40 |
HLE uses a fixed 500-question subset; GPQA is the Diamond tier; LiveBench takes the reasoning subset. Numbers are first-try accuracy percentages (baseline → with DeepTutor scaffolding).
Where the paper draws its own boundaries, and what you can actually use today
The paper doesn't overclaim. It's explicit about what's been validated and what hasn't.
The paper explicitly states that system extensions like Book Engine and TutorBot (now Partners in the product) are "architectural instances" — deployment mechanisms for long-term personalized tutoring, not interventions validated by this evaluation. Their effect on retention, engagement, and real learning outcomes would require longitudinal human studies. Chat, Book, and Memory are features you can install and use right now, but whether sustained use actually helps people learn better is something the paper itself hasn't measured, leaving that for future work. The interactive evaluation relies on an AI student simulator and rubric-based judging, which inherently carries a gap between "controlled simulation" and "real learners"; the multi-stage pipeline also trades higher reasoning cost for stronger controllability. The paper's recommendation: in real use, treat generated tutoring content as an aid rather than an authority, and verify important claims against trusted course materials or a human teacher.
What an ordinary person can do with it right now
Weaknesses diagnosed during tutoring propagate to the learner profile and directly determine what question gets generated next; in turn, the student's performance on generated questions refines the profile and improves future explanations. "DeepTutor: Towards Agentic Personalized Tutoring," the paper's description of the "closed tutoring cycle"