Courses vs. Cohorts

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.

Course "Intro to Special Relativity" (the recipe)
  ├─ Cohort "Fall 2025, Group A"   (Tuesday's meal)
  ├─ Cohort "Fall 2025, Group B"   (Tuesday's meal, different table)
  └─ Cohort "Spring 2026"          (next semester's meal)

What lives where

Lives on the Course	Lives on the Cohort
Name	Code (e.g. `MATH101-FA25-A`)
Description	Start / end dates
Language	Enrolled students
Target hours	Assigned teachers
AI instructions	Submissions
The syllabus tree	Per-student progress
Default rubrics	Per-cohort overrides

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:

const course = await hk.courses.create({ name: "Photography 101" });
const cohort = course.cohorts[0];   // a default cohort is auto-created

$course = $hk->courses->create(['name' => 'Photography 101']);
$cohort = $course->cohorts[0];   // a default cohort is auto-created

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:

for (const customer of customers) {
  await hk.cohorts.create({
    course_id: "crs_intro_to_security",
    name: `${customer.name} — security training`,
    code: customer.slug,
    starts_at: customer.kickoffDate,
  });
}

foreach ($customers as $customer) {
    $hk->cohorts->create([
        'course_id' => 'crs_intro_to_security',
        'name' => "{$customer->name} — security training",
        'code' => $customer->slug,
        'starts_at' => $customer->kickoffDate,
    ]);
}

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.

Get started

Core concepts

Guides

Courses vs. Cohorts

TL;DR

What lives where

When you have just one cohort

When you have many cohorts

Anti-patterns

​TL;DR

​What lives where

​When you have just one cohort

​When you have many cohorts

​Anti-patterns

TL;DR

What lives where

When you have just one cohort

When you have many cohorts

Anti-patterns