Two kinds of model, two kinds of relationship CORE
In Module 1 you learned that the model is one of the four parts of an agent. This lesson is about the first real choice you have to make as a director: which kind of model do I run, and where does it live?
There are two options. A local model is a model that runs on your own computer — weights on your disk, inference on your CPU or GPU, no internet required once it is downloaded. A cloud model is a model that runs on someone else’s servers; you reach it over the internet through an API, and you pay per request. Both options have been available for a few years now. Both will still be available in five. They solve different problems.
The beginner framing is local is free and cloud costs money, so pick local when you can. That is wrong in a way that will slow you down. The real tradeoff is richer, and this lesson is about seeing it clearly enough that you can pick the right model for each piece of work you do.
The four-axis tradeoff CORE
Every time you choose between local and cloud, you are trading off four things.
Capability. Cloud models are, on average, smarter. The frontier cloud models are trained on far more data and far more compute than anything that fits on a laptop. They reason better on long chains, write better code, and make fewer confident mistakes. Local models in the 7–13 B parameter range — the ones that will actually run on your machine — are impressive, but they are roughly one or two generations behind the frontier. For a hard task, capability gap matters.
Cost. Local is free at the margin once the model is downloaded. Run it a thousand times a day; the cost is the electricity. Cloud charges per request, measured in tokens. A single long research task with a frontier cloud model can cost pennies to a few dollars. A thousand such tasks costs real money. The crossover point — where local becomes cheaper than cloud — depends on how hard you run it.
Privacy. A local model sees your data and nothing leaves your machine. A cloud model ships your prompt — and anything you put in that prompt, like the text of a private email or a draft of a sensitive document — to someone else’s servers. Reputable providers have policies about what they store and how, but the policies are not the same as the physics. If “no copy of this leaves my machine” is the requirement, only local satisfies it.
Reliability. A cloud model is reliable as long as your internet is up and the provider has not had an outage. A local model is reliable as long as your laptop is on. Neither wins cleanly; they fail in different ways. If you are working on a plane or in a cabin with no signal, local wins. If your laptop is unplugged and dead, cloud wins.
| Axis | Local | Cloud |
|---|---|---|
| Capability | 1–2 generations behind | Frontier — wins |
| Cost | Free at the margin — wins at volume | Per-request pricing |
| Privacy | Nothing leaves the machine — wins | Prompt ships to provider |
| Reliability | Works offline; fails if machine is off | Works if internet & provider up |
How to pick for a specific task CORE
Good directors do not pick a model for their whole life. They pick a model for the task in front of them. The framing is: for this specific piece of work, which of the four axes dominates?
A few worked examples:
Draft a cover letter for a summer internship, using my résumé. Capability matters — you want this to read well — and the résumé is yours but not secret. Cloud wins. The cost per draft is a few cents; the better writing is what you are paying for.
Summarize the journal entries I have been keeping on a hard family issue. Privacy dominates. Even a well-intentioned cloud provider is not a place to ship this. Local wins, even if the summary is slightly rougher.
Triage my inbox every morning at 7am for the next month. Reliability, cost, and privacy all matter — this runs 30 times a month against real email. If your inbox is not sensitive work, cloud is fine and the per-run cost is small. If it is sensitive, you want local or a hybrid with redaction.
Help me condense a 30-page software user manual into a 2-page quick-reference card my mom can keep next to her computer. Capability dominates — this needs careful summarization that holds the meaning while cutting the bulk. Cloud wins.
Write a short bedtime story for my little brother, offline in a cabin with no Wi-Fi. Reliability dominates. Local wins.
Notice: the answer is not the same each time. That is the point. A student who always reaches for one type has a worse tool belt than a student who can pick.
Why serious practitioners run both CORE
You might expect the course to push one answer. It does not. The recommended posture is: install both and pick per task.
The reason is that the four axes point different ways for different tasks, and switching is cheap once both are set up. A student with only cloud has nothing to fall back on when the internet drops, when privacy matters, or when they want to run a model a thousand times a day for pennies. A student with only local has a ceiling on capability they will run into the first time they need real reasoning on a hard problem.
Running both has costs: more setup now, two workflows to keep in your head, two bills to understand (your electricity and your cloud spend). Those costs are real, but they pay back fast. Nearly every professional who does this for real has both. Lessons 2.2 and 2.3 will walk you through the installs.
If your hardware can't run a local model — older laptop, less than 8 GB of RAM, Chromebook-adjacent — that's fine. Lesson 2.3 (the local install) is the only place in the course where the hardware bar is higher; the rest of the course runs cloud-side and works on any modern laptop. You'll read Lesson 2.3 for the concept (it matters for Module 9's privacy work) and skip the install. You won't be locked out of anything.
The hybrid workstation and what “default model” means CORE
Once both are installed, you will write a short rule for yourself: which one do I reach for by default, and when do I switch? That rule — your default model plus your switching conditions — is the first real artifact of your workstation.
A reasonable default for most students is: cloud is the default; switch to local when privacy, offline, or high-volume-low-cost is the driver. A different reasonable default, for a privacy-first student, is: local is the default; switch to cloud only when I hit a capability wall. Either is defensible. What is not defensible is I just use whatever is open, because that means you are not choosing — you are drifting.
Your capstone design in my-first-loop.md has a Model section. By the end of this lesson you will fill it in with “local,” “cloud,” or “hybrid,” plus a one-line reason. That is your first workstation decision on paper.
Quick capability check for your machine RECIPE
| Tool | Any computer (macOS or Windows) |
| Version tested | macOS 14 Sonoma / Windows 11, April 2026 |
| Last verified | 2026-04-17 |
| Next review | 2026-07-17 |
Before Lesson 2.2 asks you to install a local-model runner, do a five-minute capability check:
- RAM. macOS: Apple menu → About This Mac. Windows: Settings → System → About → “Installed RAM.” Write the number down.
- Chip / GPU. macOS: About This Mac → “Chip” (e.g., “Apple M2”). Windows: Settings → System → Display → Advanced display → “Display adapter.” Note if you have a discrete GPU (NVIDIA / AMD) or integrated graphics only.
- Free disk space. A usable local-model install needs at least 10 GB free; Lesson 2.2 will assume 20 GB to leave room for multiple models.
Rule of thumb for local-model fit:
- 16 GB RAM or more → Llama 3.1 8B Instruct (recommended first local model).
- 8 GB RAM → Mistral 7B (smaller footprint; still capable).
- Less than 8 GB RAM → plan to run cloud-only for now; revisit when hardware allows.
No GPU? Fine. CPU-only inference on a modern laptop is slow but workable for 7–8 B models.
Try it — Local vs. cloud decision tree
paper-and-pencil worksheet · open the printable →
You are given eight real tasks. For each, do three things:
- Name the dominant axis (capability, cost, privacy, or reliability).
- Decide: local, cloud, or hybrid.
- Write a one-sentence defense.
The tasks:
- Translate a 2-page Spanish travel itinerary your family is using next month into English.
- Summarize your own journal entries from the past year to help you prepare for a conversation with your pastor.
- Help you draft a long fundraising letter for a school club, using a folder of three past letters the club has sent for tone.
- Draft 30 variations of a short LinkedIn post about your summer internship.
- Grade your little brother’s math worksheet — he is homeschooled and the answer key is only on paper.
- Generate a daily personalized news digest for the next 90 days, tailored to your interests, running automatically at 7am.
- Read a long PDF of a classic novel you have on your hard drive and suggest discussion questions for your book club.
- Help you write a cover letter for a job that sent you the hiring manager’s name in confidence and asked you not to share it externally.
Deliverable. Turn in a one-column sheet: task → dominant axis → local/cloud/hybrid → one-sentence defense. Keep it; Lesson 2.5 will reuse it.
Done with the hands-on?
When the recipe steps and any activity above are complete, mark this stage to unlock the assessment, reflection, and project checkpoint.
Quick check
Four questions. Tap a question to reveal the answer and the reasoning.
Show explanation
Answer: C. The four-axis framing is the whole lesson. A ignores the capability gap on hard tasks; “cheap and worse” is not cheap if it means the task fails. B ignores privacy, offline, and high-volume use cases where capability is not the bottleneck. D is the drift posture — treating them as interchangeable is the failure mode the lesson is written to prevent.
Show explanation
Answer: C. Private journal entries are exactly the class of input where “no copy of this leaves my machine” is load-bearing. Cloud may be more capable, but that gain does not outweigh shipping personal writing to a third party. The summary may be slightly rougher from a local 8B model; that is the right tradeoff.
Show explanation
Answer: C. One-model posture is drift, not choice. The cost and coverage gaps are real, and the deeper harm is that the student never practices the per-task decision that directing actually requires. “Cloud only” is defensible as a short-term starting point; as a permanent stance, it is a ceiling on how good a director you become.
Show explanation
Answer: B. Your default model is which one you reach for without thinking; your switching conditions are the explicit situations that override the default (“switch to local if privacy, offline, or over 500 runs/day”). Making this rule explicit is what keeps you from drifting into single-model use.
Reflection prompt
Choice or drift?
In 5–7 sentences, answer: Before this lesson, which model class did you reach for by default — and was that a choice or a drift? Describe a specific task from the past two weeks where the other class would have been a better fit. What would you have done differently, and what stopped you from considering it at the time?
This is not a test. It is the first time you are being asked to notice the per-task decision at all. Noticing it is most of the work.
Project checkpoint
Your first workstation decision, on paper.
Open your my-first-loop.md file from Lesson 1.5. Find the Model line. Fill it in, in this form:
Model: [local / cloud / hybrid]. Why: [one sentence.] Switch condition: [one sentence naming the axis that would flip the decision.]
Save the file. You are not locked in — Lessons 2.2 and 2.3 will give you the hands-on feel that may revise this — but you now have your first recorded workstation decision on paper.
Next in Module 2
Lesson 2.2 — Your dev toolkit: the foundations.
Install the four tools every later lesson assumes are working: VS Code, your terminal, Python, and git. Before you can install an LLM or set up a cloud account, the editor and terminal need to be open.