Module 8: Cost, Safety & Governance

You now know how to run ADW locally, how it scales to the cloud, and how to onboard a new repo onto it. Before the capstone, one more topic deserves a straight answer instead of marketing gloss: what does this actually cost, and where are the edges you should not push past?

The honest cost model

There are two fundamentally different cost regimes, and confusing them is the single most common mistake teams make when scaling up:

	Local ADW	Cloud ADW
Runs on	Your Claude Code subscription	The org's metered Anthropic API
Cost shape	Flat, unmetered — a fixed subscription cost regardless of how much you run	Metered — real per-token spend, tracked centrally via the Anthropic org Admin API
Where it shows up	Not itemized per task	ops cost (the org Admin API view) — the authoritative source for real spend
Should be your default for	Learning, day-to-day development, most work	Unattended/high-throughput work you've deliberately decided needs it

Local is the floor, not a fallback

Local ADW is not a "cheap tier" you graduate away from — it's the correct default for the large majority of work. Cloud dispatch is something you opt into deliberately, for a specific reason (needing unattended runs, or more throughput than you can drive locally), not something you migrate everything to just because it exists.

Where the metered spend actually goes

Two concrete facts worth internalizing:

• The commit-message step is deliberately cheap. The ADW loop's commit step uses Gemini Flash instead of Claude to generate the commit message — a roughly 98% cost reduction on that one step. This is a good example of the general principle: use the cheapest model that's fit for a given step, not the same model for everything.
• Draft-by-default has a cost dimension, not just a safety one. Because every ADW-produced PR opens as a draft with a human merge gate (unless a project has explicitly opted into ADW_AUTO_COMPLETE=true legacy auto-squash-merge), nothing gets silently merged and re-run downstream without a human noticing. A human catching a bad direction at the draft-PR stage is far cheaper — in both compute and cleanup time — than the same mistake compounding through several more automated runs before anyone looks.

If you're ever unsure what your team's actual cloud ADW spend looks like, the authoritative source is ops cost (backed by the Anthropic org Admin API) — not an estimate, not a guess from token counts in a log.

Safety gates and guardrails, restated plainly

By this point in the track you've met every one of these individually. Here they are together, as the checklist they actually function as:

1. Draft PR + human merge — always on. Every ADW-produced PR is a draft until a human merges it. This is the one gate that never goes away, regardless of local vs. cloud, or which model dispatched the work.
2. Independent maker–checker verifier. An adversarial reviewer distinct from the implementing agent sits between implementation and commit — "the maker doesn't grade its own homework" (Module 4).
3. Evidence-gated promotion. For web-UI projects, missing or incomplete validation evidence (RESULTS.md, walkthrough, screenshots) blocks promotion outright (Module 5).
4. The hardcoded repo allowlist (Model 1). Cross-repo dispatch via pipeline 9 re-validates the target repo name against a fixed allowlist before cloning anything — a guard against a mistyped or malicious targetRepo value (Module 6).
5. Injection-safe issue triggers (Model 2). The Mars model passes only an issue number into the workflow and reads the issue body as data via gh issue view, not as interpolated prompt/command text — closing the obvious prompt-injection path a labeled-issue trigger would otherwise open (Module 6).
6. The lat check hard gate. A required, offline, deterministic CI check that blocks a merge if a PR breaks a documented [[link]] or @lat: ref — keeping the knowledge graph agents rely on from silently rotting (Module 2, Module 7).

🗑️

Wastey says

Every one of these is a place where an agent's output is not trusted on its own — it's checked, gated, or scoped down by something outside the agent. That's the actual shape of "safety" here: not one big switch, but several narrow, specific checks, each closing a specific failure mode.

What NOT to automate

None of the gates above are a reason to automate everything you can reach. Some judgment calls worth stating explicitly:

• Don't bypass the draft-PR gate. ADW_AUTO_COMPLETE=true exists for specific legacy cases — it is not a default setting to flip because reviews feel slow. Treat it as an exception that needs its own justification, not a convenience toggle.
• Don't dispatch to cloud by default. If a task can be done locally in the time it takes to set up and monitor a cloud dispatch, do it locally — cloud spend should track actual need (unattended execution, throughput), not habit.
• Don't grant Contribute + Create-PR broadly "just in case." Grant it per-repo, when you're actually about to onboard that repo onto Model 1 — not ahead of time across every repo an admin can reach.
• Don't treat a passing evidence artifact as license to skip reading the diff. RESULTS.md and a walkthrough make review faster and better informed; they are not a substitute for a human actually reading what changed before merging it.
• Don't automate the decision to change what's being measured or gated. Loosening a gate (skipping validation, widening an allowlist, disabling lat check) is a decision with organizational consequences and should be made and reviewed by a person, not quietly adjusted by an agent trying to get its own PR through.

Hands-on lab

Without spending any real cloud budget, do the following against a project you have visibility into (your practice repo, or one you support at work):

1. Run (or ask a teammate who has access to run) ops cost and look at the actual recent cloud ADW / Anthropic API spend for your org or team. Note roughly how it breaks down, if the tool shows a breakdown.
2. Find one place in your own workflow where you'd be tempted to reach for cloud dispatch out of habit rather than actual need for unattended execution or throughput. Write one sentence on why local would work just as well there.
3. Write down, in your own words, which of the six gates above would catch a mistake in your project specifically, and which (if any) don't apply because your project has no web UI or isn't on GitHub. This is meant to make the gates feel concrete rather than abstract.

Decide: local or cloud, and is this worth automating?

Choose your pathcost & automation check

Does this specific task need to run unattended, or at higher throughput than you can drive by hand?

▸What's the honest cost model, in one comparison?

Knowledge check

Why does the ADW commit step use Gemini Flash instead of Claude?

Gemini Flash produces better commit messagesIt's roughly 98% cheaper for that specific step, and a lighter model is fit-for-purpose thereClaude cannot write commit messages

What is the authoritative source for actual cloud ADW spend?

Counting tokens in the agent's chat transcriptops cost, backed by the Anthropic org Admin APIThe subscription invoice

Which of these is a correct instinct from the "what NOT to automate" section?

Flip ADW_AUTO_COMPLETE=true broadly to speed up mergesGrant Contribute + Create-PR to the ADW-Agents identity across every repo up front, just in caseTreat gate-loosening changes (skipping validation, widening an allowlist) as decisions a person should make and review