Skip to main content

TL;DR

A Course is the recipe. A Cohort is the meal you cooked yesterday. You author the recipe once. You can cook it many times.

What lives where

When you create a cohort, the syllabus tree is cloned into it. From that moment, edits to the cohort don’t propagate back to the course, and edits to the course don’t reach existing cohorts. (You can still re-clone with cohorts.create({ course_id, copy_overrides: false }).)

When you have just one cohort

Plenty of products only ever need one cohort per course — for example, a self-paced consumer learning app. The SDK supports that with sugar:
You can ignore cohorts entirely until you need them. The day a customer asks for “the same course but for the new intake,” you already have the model.

When you have many cohorts

This is where the split pays off. Say you sell a corporate training course; each customer is a cohort:
Now each customer’s enrollments, submissions, and grades are isolated. The syllabus stays in one place.

Anti-patterns

Don’t model “this year” and “last year” as edits to the same Course. You’ll lose history and break analytics. Create a new Cohort instead.
Don’t model “track A” and “track B” of the same course as separate Courses. They share a syllabus, share rubrics, share generated content. Use one Course with two Cohorts and per-cohort overrides.
Don’t create a Course per student. Courses are syllabi. A 1:1 tutoring product is one Course with one Cohort per learner — or a single Cohort and the right rubric. Talk to us if you’re not sure.