Safe defaults: cost, privacy, and a posture you’ll actually keep.

Why “posture” beats “rules” CORE

You could walk out of Module 2 with a long list of rules — never commit a key, always set a cost cap, turn off Wi-Fi to test local, never upload my journal to cloud. Rules are useful. They are also easy to forget under pressure. The minute you are pushing a deadline, the rule you broke is the rule that mattered.

A posture is different. A posture is a short, written commitment about how you work — specific enough to act on, general enough to survive new tools and new tasks. It is the thing you read to yourself at the start of a new project and ask: does what I am about to do match what I said I do?

Two postures matter for Module 2: a cost posture and a privacy posture. You will write both today and freeze them as the second artifact in your /capstone/ folder. Every Module-onward recipe will carry a “Safe default” callout; those callouts have teeth only if you already know what your own default is.

Your cost posture, in four lines CORE

A cost posture answers: how much am I willing to spend, how will I know before I get there, and what do I do when a bill surprises me?

Four lines, fill them in:

1. Monthly cost ceiling, per provider, in dollars. Pro-only students: write your subscription fee here ($20/month or whatever Pro currently costs). API-path students: this is the hard cap you set in the developer console in Lesson 2.4 ($5–20/month is a sensible starting point).
2. How I know I am approaching it. Most providers email when you cross 50%, 75%, 90% of your cap. Confirm the email address on your account is one you actually read. If your provider does not send warnings, check your usage dashboard once a week; put it on a calendar.
3. What I do when I hit it. Two real choices: raise the cap (you underestimated; that is fine if the work is real) or stop and audit (you had a loop going sideways; never raise a cap without knowing why you hit it). Writing this line in advance prevents the “quickly raise cap to unblock myself” reflex that drains accounts.
4. High-volume rule. For any task you plan to run repeatedly (scheduled agent, batch processing, anything hitting the API dozens of times per hour), you commit to a dry run on a small sample first, with a paper estimate of the total cost before scaling up.

If all four lines are populated and you can point at them, you have a cost posture. If any line says “I’ll figure it out later,” you do not.

Your privacy posture, in four lines CORE

A privacy posture answers: what kinds of data am I willing to send to which providers, and what do I do when I am not sure?

Four lines:

1. My default placement rule. One sentence like cloud is my default; local is required when the input is personal, medical, financial, or subject to a promise of confidentiality. Or the reverse. Either is defensible; vague is not.
2. A list of categories that always go local. Populate it. Examples: my journal, my family’s financial records, anything my parents shared with me in confidence, draft text of a private letter, images of family members’ faces.
3. A list of categories that are fine in cloud. Examples: schoolwork I plan to turn in and would not mind a teacher seeing anyway; public data; code for open-source projects; my own writing I plan to publish.
4. The “when unsure” rule. If I am on the line, I default to local, even if it is slower. Or: if I am on the line, I redact the sensitive parts and use cloud. Either is a rule you can execute; “I’ll trust my gut” is not.

Notice that the privacy posture is not a policy about providers — it is a policy about your own data. Providers change; your data categories do not.

Two drift failure modes CORE

Postures fail in two characteristic ways. Both are slow, and both start invisibly.

Sneaky-cost drift. Happens when a low-cost tool inches upward without you noticing. Scheduled agents are the worst offenders — a 5-cent daily run does not catch your eye, but 365 days at 10× that cost is a $180 surprise. A coding agent that spawns sub-agents inflates token counts non-linearly. The counter-move: check your usage dashboard weekly, not monthly, and always estimate before scaling up a recurring task. A one-time calendar reminder to check spend every Sunday does more than every cap in the world.

Sneaky-privacy drift. Happens when a new tool you add to your workflow quietly widens the data surface going to cloud. A browser extension that “helps you summarize pages” may send pages to a cloud model. An editor plugin that “autocompletes code” may send your surrounding context — which may include .env — to a cloud provider. The counter-move: for every new tool you install, read the one-sentence summary of what it uploads and to whom before you enable it on real work. If there is no such summary, that is your answer.

Both drifts are defeated by the same habit: look at the dashboard, read the one sentence, before, not after.

The four-part checklist before any new tool goes on real work CORE

New tools will keep arriving for as long as you do this work. You need a cheap, repeatable filter.

Four questions, ask them every time:

1. What data does this tool see, and where does it go? One sentence from the tool’s docs or settings. If you cannot find it, that is the answer: do not use on real data yet.
2. What does it cost, and how do I know I am approaching a limit? Same cap-and-warning pattern you set up in Lesson 2.4.
3. What can it do on my behalf without asking? Is it read-only? Does it write files? Send messages? Move money? The more it can do autonomously, the more carefully you gate it.
4. Where does it live in my posture? Local-only? Cloud-default? Only for categories of data listed above?

If all four have answers you are willing to live with, adopt it. If any answer is “I’ll figure it out,” the tool is not ready for your real workflow.