AI Tutor: a study chat that has actually read your course

What the tutor is handed before it answers

Every message you send triggers a fresh context build on the server. Nothing is precomputed from last week. The tutor sees your course as it stands the moment you press send, assembled into three labeled blocks.

The first is the syllabus and course block. It carries the course name, the instructor if you recorded one, then your class meetings rendered as lines like "lecture: Mon/Wed 10:00-11:15 @ Room 214" — labs and discussion sections included, since those are stored as their own meeting kinds. If you have customized your grading scale, the cutoffs go in as plain text: A at 93 percent and up, B at 83 and up, whatever your school actually uses. Last come the structured items from your most recent syllabus scan of that course, each with its weight, due date, and type, drawn from the same six categories the scanner uses: assignment, quiz, exam, project, reading, or other.

The second block is deadlines, built from the tasks you are actually tracking on that course, sorted by due date, with completed items marked done and weights and due times riding along.

The third is lecture notes: the extracted text of the files attached to the course, each headed by its filename so the tutor can tell you which document a point came from.

• The syllabus block is capped at 8,000 characters and carries up to 60 items from your latest scan.
• The deadlines block is capped at 8,000 characters and up to 60 tasks.
• Notes are read newest first: the 10 most recent files for that course, sharing a 24,000-character budget of extracted text.
• A syllabus or deadlines block that has to be cut is explicitly marked as truncated, so the model knows it is working from an abridged source. Note text that runs past the shared 24,000-character budget is simply cut at the budget.
• The last 12 messages of your conversation are replayed each turn for continuity.
• When there is no course material at all, the model is told so directly and asked to invite you to add a syllabus or notes.

How one message actually travels

The screen is a plain chat. You type, you press the arrow, your message appears as a bubble immediately while the request is in flight, usually three to ten seconds. Underneath that spinner, a fixed sequence runs.

The model call goes to OpenAI GPT-5.6 Luna with low reasoning and an output ceiling of 2,048 tokens: enough for a worked explanation without inviting an essay. If OpenAI returns a retryable error, the function backs off and retries up to three times. You see one spinner; the retry policy runs beneath it.

• The request has to declare its size, and the body has to be under 256 KB. A chunked stream that tries to slip past the size check is rejected before anything else happens.
• Your session is validated, then the database is asked whether you are Pro. This is a server-side check, not the app's local flag, so a stale or lapsed client cannot talk its way in, and a momentary database blip returns a temporary-unavailable error rather than quietly demoting a paying account.
• One message is reserved from your daily allowance, atomically, under a per-user lock. Reserving before the model call is what stops ten fast taps from all sneaking past the cap together.
• The conversation is confirmed to be yours, and the course to ground on is read from the conversation record itself. The course ID your app sends along is treated as a hint for a brand-new thread, never as permission to read a course.
• The three context blocks are built, the recent turns are replayed, your new message is appended, and the model is called.
• Both turns — your message and the reply — are written to the database on the server, so your history stays consistent even if the app is killed mid-answer.

Deadline answers come from your task list, not the model's memory

One line in the tutor's instructions is not a preference. If you ask about deadlines or dates, it must answer from the deadlines section, and it must never invent a date.

That matters more than it sounds. The deadlines block is built from your live task list, not from the raw text of the syllabus PDF. If your professor pushed the essay back a week and you moved it in Semora, the tutor says the new date. If a deadline arrived from a Canvas sync instead of a scan, it lands in the same task list and grounds the answer identically. The syllabus block and the deadlines block can disagree with each other, and when they do, the deadlines block is the one describing what is actually true now.

There is a matching limit worth stating plainly. The deadlines block carries titles, types, due dates, due times, weights, and whether you have checked something off. It does not carry your scores. The tutor knows the final is worth 30 percent and that you have not done it yet. It does not know you got a 74 on the midterm. Grade math lives in Semora's grade tracking and forecasting screens, not in the chat.

Uploading lecture notes

Tap Add notes in the bar above the conversation and pick a file. The picker accepts PDFs and images, so an exported slide deck, a scanned reading, or a photo of the whiteboard all count.

Your device does no parsing. It uploads the raw file to a private storage bucket under a path keyed to your account, then records a pointer to it. The first time the tutor needs that file, the server downloads it and has the model transcribe every readable line, preserving structure, and caches the result. Every later message reuses the cached text, so you pay the extraction cost once per file rather than once per question. The same cached text is what flashcard generation reads, so a review packet you attach here is transcribed once and used by both features.

Uploaded files appear as chips you can tap to remove. The confirmation says exactly what removal means: that file will no longer ground the tutor. Removing it deletes both the record and the stored file.

Two constraints are worth knowing up front. Notes attach to a course, so if you opened the tutor without one, the app tells you to open it from a course first instead of accepting an orphan file. And a file over roughly 6 MB is skipped at extraction time rather than sent to the model. That skip is quiet (the answer still arrives, just without that document behind it) so if a large scanned PDF does not seem to be landing, split it or export it smaller.

One thread per course, plus a general one

There is no thread list to manage. Open the tutor from a course and you land in that course's rolling conversation, the same thread you were in last week, history intact. The composer placeholder becomes a prompt to ask about that course specifically, and so does the empty state before your first message.

Open it from the Me tab instead and you get a general thread with no course attached. That still works, but the server tells the model outright that no course material is attached and asks it to invite you to add a syllabus or notes, and the empty state on screen says the same thing. It is an honest downgrade rather than a silent one.

Scoping is also what keeps courses from bleeding into each other. Your organic chemistry thread is grounded on organic chemistry's syllabus, tasks, and notes, and nothing else. Ask it about your statistics midterm and it will tell you that is outside what it has.

The limits, in real numbers

The daily cap applies even though the tutor is a Pro feature. It exists to bound what the model costs to run, and it lives on the server so it can be adjusted without shipping an app update. One honest caveat: the slot is reserved before the model is called, so on the rare occasion a request fails upstream, it still spends one of the fifty. That is the trade for a cap a burst of taps cannot blow past.

• 50 tutor messages per rolling 24 hours per account. Rolling, not a midnight reset.
• 4,000 characters per message, enforced in the composer and checked again on the server.
• 256 KB maximum request size.
• 60 syllabus items and 60 tasks per context build.
• 10 note files per course in the grounding pass, sharing 24,000 characters of extracted text.
• 12 previous messages replayed per turn — roughly six exchanges of working memory.
• 2,048 output tokens per reply.

How it connects to the rest of Semora

The tutor keeps no copy of anything. It reads the same records the rest of the app writes, which is why the order you do things in matters.

It is worth being equally clear about what it does not touch. It does not read your office hours entries, your entered scores, your Smart Plan, or your other courses. The view is deliberately narrow: one course, and the material you gave it.

• Your syllabus scan populates the structured items the tutor quotes back at you. A course with no scan and no notes gives it nothing course-specific to work from.
• Edits you make to a deadline anywhere in the app change what the tutor says the next time you ask.
• Notes uploaded here are the same notes flashcard generation reads, sharing one transcription.
• Class meeting times and your custom grade scale, both set on the course, land in the tutor's context automatically.
• Pro is bought in the iOS app and the entitlement applies account-wide, so the tutor is available on iPhone, iPad, and the web app under the same login. There is no separate web checkout.

Who this is genuinely for

This is for the student who has already put a course into Semora and now wants to interrogate it. With a scanned syllabus, a tracked deadline list, and a few weeks of slides uploaded, the tutor is unusually good at questions like what is actually on the midterm, explain the difference between these two terms the way my notes framed it, or I have four things due next week and I need to know which one is worth the most.

It is a poor fit in four situations, and it is better to say so than to let you find out after paying.

• You want graded work done for you. The tutor is instructed to explain reasoning and guide you toward an answer rather than produce it, and that is deliberate.
• You have nothing in the app yet. An empty course gives you a general chatbot, which you can get for free elsewhere.
• You want long formatted documents. Replies are plain text by instruction (short paragraphs and bullets, no markdown headers) and capped at 2,048 tokens.
• You are on the free tier. The tutor is Pro. Free accounts see a description of what it does and a route to the paywall, not a reduced version of the chat.

What happens when things go wrong

Chat features fail in boring ways, and knowing which failure you are looking at saves you from retyping.

The failure mode to watch for yourself is the quiet one. If a note file was too large to extract, or a syllabus block was truncated, the tutor does not print a warning in the chat. It answers with what it has. So when a reply seems to be missing something you know is in your material, checking that the file actually uploaded is the first thing to do.

• The send fails: your bubble is rolled back and the text you typed is restored to the composer. You do not lose a message you already wrote.
• The model returns nothing, or a safety filter blocks the completion: you get a message asking you to rephrase, not an empty bubble.
• Google is overloaded: after the retries and the fallback model, you are told the tutor is busy and to try again in a minute.
• Your Pro status lapsed, or the app's cached flag is stale: the server flags it and the app routes you to the paywall rather than a dead-end error.
• A note file cannot be downloaded or transcribed: that failure is non-fatal. The answer still comes back, just without that document in context.
• You hit the daily cap: the error names the number and tells you to try again in 24 hours.