Test Claude Code Budget Controls

August 21, 2026 - Build a Windows evidence pack for Claude Code budget controls.

Introduction

30 Second Summary

A limit only earns trust when you know exactly where it works. Without evidence from a real run, a reassuring setting can support a decision it never proved.

In this project, you will test Claude Code's --max-budget-usd control on Windows. You will capture its print-mode behavior without treating its local cost estimate as billing data.

What You'll Build

You will finish with a Windows evidence pack that shows the tested boundary, preserves the observed result, and supports a clear operational verdict.

By the end of this project, you'll have:

  • A pre-run decision record that defines the evidence required for Adopt, Reject, Watch, or Park before the control is exercised.
  • A bounded print-mode result that preserves the configured cap, Claude Code's reported total, the calculated difference, and the literal stop evidence.
  • An evidence-backed verdict that records the interactive-session result, wall time, evidence limits, reversal trigger, and re-check date when required.
  • Secret Mission: Challenge your verdict with the strongest contrary outcome and turn its reversal trigger into a testable condition.

What do I need before starting?

You need a Windows device with Windows PowerShell and an existing Claude Code installation at version 2.1.217 or later. You also need an existing Claude Pro, Max, Team, or Enterprise subscription login.

Before We Start

This checkpoint commits you to deciding whether Claude Code's --max-budget-usd behavior is dependable for the exact print-mode use case you test. Real-billing claims stay outside this project's evidence boundary.

Establish the Timed Subscription Baseline

Your operational question is set. The result needs an environment baseline before it can support a decision.

The whole project clock starts here in Windows PowerShell. This baseline also proves that Claude Code meets the enforcement requirement and uses your existing subscription.

In this step, get ready to:
  • Capture the project start time in the current PowerShell session.
  • Verify that Claude Code is version 2.1.217 or later.
  • Confirm that the test path uses subscription authentication with no API key.
Anchor the project clock

The final verdict compares the total wall time with a 30-minute limit. An in-memory timestamp gives that calculation a fixed starting point.

  • Set the project start time in the PowerShell session by running this command:
$projectStartedAt = Get-Date

What does this command do?

PowerShell stores the current date and time in $projectStartedAt. Keep this PowerShell window open because the variable exists only in the current session.

  • Display the stored start time by running:
$projectStartedAt

What should I see?

PowerShell prints the date and time captured by Get-Date. This timestamp marks the start of the counted project window.

Your timing anchor is live. Every remaining project action now falls inside the same measured window.

Verify the Claude Code version

The budget-cap enforcement baseline requires Claude Code version 2.1.217 or later. Checking the installed client prevents an older implementation from weakening the result.

  • Check the installed Claude Code version by running:
claude --version

What does this command show?

The command prints the installed Claude Code version. Your result must show 2.1.217 or a later version before you continue.

✔️ The version meets the baseline

Good. Your installed client meets the 2.1.217 enforcement baseline.

ⓧ The version is too old

An older client cannot support the required enforcement baseline. Update the existing installation before you collect any control evidence.

  • Apply the available Claude Code update by running:
claude update

What does this command do?

The command applies an available Claude Code update to the existing installation. No additional software is installed.

  • Restart the client by closing any running Claude Code session.
  • Check the updated version by running:
claude --version

What should I see now?

The version output should now show 2.1.217 or later. This fresh process uses the updated client.

Having trouble with the version check?

Confirm that the same PowerShell window can run Claude Code. A different installation on your command path can produce an unexpected version.

If the update or version check still fails, help me verify which Claude Code installation PowerShell is using.

Confirm the subscription path

The measured run must consume usage from your existing Claude Pro, Max, Team, or Enterprise subscription. An active ANTHROPIC_API_KEY takes precedence during a non-interactive print-mode run.

Before you check, do you expect the status view to name your subscription account or show an API key?

  • Start an interactive Claude Code session by running:
claude

What happens here?

Claude Code starts an interactive session in the open project folder. Do not enter a model prompt because this check only establishes the authentication path.

  • Inspect the active authentication source by entering this command at the Claude Code prompt:
/status

How do I read the status?

The Login method row should identify your subscription account. An API key row means the upcoming print-mode run would use an API key.

✔️ I see subscription authentication

That is the baseline locked in. Your status view names the subscription login and contains no API key row.

  • Exit without sending a model prompt by pressing Ctrl+D twice within 800 milliseconds.

ⓧ I see an API key row

Removing a credential from the test path can feel risky. The next command clears ANTHROPIC_API_KEY only from the current PowerShell session.

  • Return to PowerShell by pressing Ctrl+D twice within 800 milliseconds.
  • Remove the API key from the current test session by running:
Remove-Item Env:ANTHROPIC_API_KEY

What does this command change?

PowerShell removes the ANTHROPIC_API_KEY environment variable from the active session. The saved subscription credential can now become the active path.

The login flow can open a browser window. Use the existing Claude subscription account required for this project.

  • Start a fresh Claude Code session by running:
claude

Why start a fresh session?

The fresh process reads the updated PowerShell environment. It no longer receives the removed API key variable.

  • Start subscription authentication by entering:
/login

What happens during login?

Claude Code starts the authentication flow. The browser sign-in stores subscription credentials for the selected Claude account.

  • Complete the browser sign-in with your existing Claude Pro, Max, Team, or Enterprise account.
  • Return to the Claude Code prompt.
  • Recheck the active authentication path by entering:
/status

What confirms the fix?

The Login method row should now identify the subscription account. The API key row should be absent.

  • Exit without sending a model prompt by pressing Ctrl+D twice within 800 milliseconds.

You should now be back in the project folder in PowerShell. Your terminal history shows a qualifying version plus a subscription-only authentication check.

✔️ My baseline is ready

Your project timer remains in memory. Claude Code is ready for the later subscription-backed print-mode test.

ⓧ I'd like to double check the full code

Compare your current environment with this exact checkpoint:

Claude Code version is 2.1.217 or later. /status confirms subscription authentication and no API key is on the test path.

$projectStartedAt is set with Get-Date; Windows PowerShell is open in the project folder.

What does this checkpoint prove?

The first line captures the Claude Code baseline. The second line captures the timed PowerShell session that remains open for the rest of the project.

Your timed subscription baseline is ready. Next up, you will write the decision rules and run plan before exercising the control.

Write the Decision Record and Run Plan

Your timed Windows baseline now proves Claude Code meets the minimum version. It also confirms your existing subscription is the only authentication path.

The measured run still needs rules that were written before its result exists. Pre-registering the expected behavior prevents a surprising result from being rationalised after the fact.

In this step, get ready to:
  • Write the decision record before execution.
  • Write the run plan with dated release anchors.
  • Display both files before the bounded run.
Define the decision boundary

A decision record makes your acceptance criteria testable before the evidence can influence them. Its scope also protects the final report from turning a local estimate into a billing claim.

  • Use the PowerShell session from earlier to write decision-record.md by running this block:
$decisionRecord = @'
# Decision Record
Created before execution.
## Operational question
Is Claude Code's `--max-budget-usd` behavior dependable enough for the exact print-mode use case tested?
## Scope
- Evaluate the flag as a local computed-cost control.
- Exclude authoritative billing control claims.
- Treat Windows as the only empirically tested platform.
- Require subscription authentication with no API key on the test path.
## Verdict definitions
- Adopt: The print-mode stop and client total support the narrow local-estimate guard tested.
- Reject: The expected stop or client total is absent.
- Watch: The control works, but evidence or semantics need a dated re-check.
- Park: A blocker prevents a valid test.
## Acceptance criteria
- Preserve the literal result subtype and stop text.
- Capture `total_cost_usd` without altering it.
- Calculate the reported total minus the cap as a separate difference.
- Test the documented print-only boundary in an ordinary interactive session.
## Evidence limits
- Preserve contrary evidence and give it priority.
- Treat the cap and reported total as local figures.
- Make no untested macOS or Linux equivalence claim.
## Reversal conditions
- Reverse the verdict if a repeatable contrary outcome breaks its acceptance criteria.
- Give Watch or Park a concrete re-check date.
'@
$decisionRecord | Set-Content .\decision-record.md

What does this block do?

  • The $decisionRecord here-string holds the complete record as literal text.
  • The Set-Content command writes that text to decision-record.md in the open project folder.
  • The sections fix the verdict meanings before the measured result can influence your interpretation.
  • Display the saved decision record by running this command:
Get-Content .\decision-record.md

What does this check prove?

The command reads the saved file from disk. Seeing the complete record proves the pre-run criteria exist outside the current command history.

You should see every heading from the operational question through the reversal conditions.

Your first pre-run safeguard is in place. The verdict rules now exist before the control is exercised.

Decision record missing or incomplete?

  • Confirm your PowerShell prompt still points to the project folder from the baseline.
  • Re-run the creation block if the file was written elsewhere.
  • Help me check why my decision record was not created correctly.

✔️ My decision record is complete

Your decision criteria are saved before execution. Keep this PowerShell session open so the project timer remains available.

ⓧ I'd like to double check the full file

  • Compare decision-record.md with this complete reference:
# Decision Record
Created before execution.
## Operational question
Is Claude Code's `--max-budget-usd` behavior dependable enough for the exact print-mode use case tested?
## Scope
- Evaluate the flag as a local computed-cost control.
- Exclude authoritative billing control claims.
- Treat Windows as the only empirically tested platform.
- Require subscription authentication with no API key on the test path.
## Verdict definitions
- Adopt: The print-mode stop and client total support the narrow local-estimate guard tested.
- Reject: The expected stop or client total is absent.
- Watch: The control works, but evidence or semantics need a dated re-check.
- Park: A blocker prevents a valid test.
## Acceptance criteria
- Preserve the literal result subtype and stop text.
- Capture `total_cost_usd` without altering it.
- Calculate the reported total minus the cap as a separate difference.
- Test the documented print-only boundary in an ordinary interactive session.
## Evidence limits
- Preserve contrary evidence and give it priority.
- Treat the cap and reported total as local figures.
- Make no untested macOS or Linux equivalence claim.
## Reversal conditions
- Reverse the verdict if a repeatable contrary outcome breaks its acceptance criteria.
- Give Watch or Park a concrete re-check date.
Pre-register the measured test

The run plan fixes the exact command plus the evidence fields you need to preserve. Two dated release anchors keep changes in estimate calculation separate from the gap you observe.

  • Write run-plan.md in the same project folder by running this block:
$runPlan = @'
# Run Plan
Created before execution.
## Fixed setup
- Run on Windows, the only empirically tested platform.
- Use subscription-only authentication with no API key.
- Set the predeclared cap to `$0.0001`.
## Print-mode test
- Run `claude -p "Give five numbered points on why a local estimate should be validated before use as a control." --max-budget-usd 0.0001 --output-format json | Tee-Object -FilePath .\bounded-run.json`.
- Expect the result subtype `error_max_budget_usd`.
- Capture `total_cost_usd` exactly.
- Capture the installed client's literal stop text.
- Calculate `difference = reported total - cap` with separate decimal source values.
## Interactive boundary
- Start `claude --max-budget-usd 0.0001`.
- Enter `Reply with exactly CONTROL CHECK.`.
- Record whether the client answers, rejects the flag, or stops on the cap.
## Timing
- Complete the end-to-end project within 30 minutes.
## Interpretation rules
- Treat the cap, reported total, and difference as separate local computed figures.
- Do not treat the difference as authoritative billing data.
- Do not claim cross-platform equivalence from the Windows run.
## Dated anchors
- `v2.1.217`, published `2026-07-21`, fixed background-subagent enforcement after the cap.
- `v2.1.239`, published `2026-08-21`, added the `1.1×` US-only-inference premium to estimates for data-residency workspaces.
- The `v2.1.239` change affects estimate calculation. It does not determine the observed cap-to-total gap.
'@
$runPlan | Set-Content .\run-plan.md

What does this plan lock in?

  • The fixed setup limits empirical claims to Windows with subscription-only authentication.
  • The print-mode section preserves the $0.0001 cap plus the expected error_max_budget_usd subtype.
  • The interpretation rules keep total_cost_usd separate from the calculated difference.
  • The anchors record v2.1.217 and v2.1.239 as dated context for the control.
  • Display the saved run plan by running this command:
Get-Content .\run-plan.md

What does this check prove?

The displayed content confirms the command plus its interpretation rules were saved before execution. This timestamped ordering protects the test from hindsight.

You should see the fixed setup plus the print-mode test. You should also see the interactive boundary plus both dated anchors.

That completes the pre-registration. The cap plus the evidence fields are now fixed before any usage is consumed by the bounded run.

Run plan missing a section?

  • Check that the here-string closes with '@ at the start of its own line.
  • Re-run the complete block if PowerShell displayed only part of the plan.
  • Help me check why my run plan is incomplete.

✔️ My run plan is complete

Your measured command plus its evidence rules are saved. No bounded request has been run yet.

ⓧ I'd like to double check the full file

  • Compare run-plan.md with this complete reference:
# Run Plan
Created before execution.
## Fixed setup
- Run on Windows, the only empirically tested platform.
- Use subscription-only authentication with no API key.
- Set the predeclared cap to `$0.0001`.
## Print-mode test
- Run `claude -p "Give five numbered points on why a local estimate should be validated before use as a control." --max-budget-usd 0.0001 --output-format json | Tee-Object -FilePath .\bounded-run.json`.
- Expect the result subtype `error_max_budget_usd`.
- Capture `total_cost_usd` exactly.
- Capture the installed client's literal stop text.
- Calculate `difference = reported total - cap` with separate decimal source values.
## Interactive boundary
- Start `claude --max-budget-usd 0.0001`.
- Enter `Reply with exactly CONTROL CHECK.`.
- Record whether the client answers, rejects the flag, or stops on the cap.
## Timing
- Complete the end-to-end project within 30 minutes.
## Interpretation rules
- Treat the cap, reported total, and difference as separate local computed figures.
- Do not treat the difference as authoritative billing data.
- Do not claim cross-platform equivalence from the Windows run.
## Dated anchors
- `v2.1.217`, published `2026-07-21`, fixed background-subagent enforcement after the cap.
- `v2.1.239`, published `2026-08-21`, added the `1.1×` US-only-inference premium to estimates for data-residency workspaces.
- The `v2.1.239` change affects estimate calculation. It does not determine the observed cap-to-total gap.
Verify the pre-run evidence pack

The evidence pack only counts as pre-run evidence if both records can be displayed before bounded-run.json exists. That bounded evidence file has not been created at this point.

Before you display both files, do you expect their scope, cap, outcome fields, timing boundary, and dated anchors to describe one consistent test?

  • Display both pre-run files together by running these commands:
Get-Content .\decision-record.md
Get-Content .\run-plan.md

What does this final check prove?

  • The first command prints the decision criteria that govern the eventual verdict.
  • The second command prints the planned test plus the fields that must be preserved.
  • Their shared scope proves both files describe the same Windows subscription-authenticated test.

You should see the decision record define all four verdicts plus the local-control boundary. You should see the run plan declare the $0.0001 cap plus both release anchors.

Strong work. Your future verdict now has a testable baseline that cannot shift after the result arrives.

Your decision rules plus the measured run plan are fixed. Next, you will exercise the tight print-mode cap and preserve what the installed client actually reports.

Run and Measure the Bounded Print Session

Your pre-run records now lock the test before execution. This step turns that plan into evidence from Claude Code.

The configured ceiling can differ from the final local cost estimate. You need both source figures before you can judge the control boundary.

In this step, get ready to:
  • Capture one bounded print-mode JSON result in bounded-run.json.
  • Extract the required result fields from bounded-run.json.
  • Calculate the cap-to-total difference without changing either source figure.
Run the bounded print request

Print mode runs one request before returning structured result metadata. The tight cap makes the control boundary reachable in a small test.

This request consumes some existing subscription usage. The cap keeps the experiment narrow.

Before you run this, do you think the reported total will equal the configured cap exactly?

  • Run the bounded request from the PowerShell session by entering this command:
claude -p "five numbered points on why a local estimate should be validated before use as a control" --max-budget-usd 0.0001 --output-format json | Tee-Object -FilePath .\bounded-run.json

What does this command do?

  • The -p option sends one non-interactive request.
  • The --max-budget-usd 0.0001 option applies the pre-registered local budget cap.
  • The --output-format json option returns structured result metadata.
  • Tee-Object writes the displayed result to bounded-run.json. It also keeps the result visible in PowerShell.

You should see one structured result in PowerShell. The same displayed result is now stored in bounded-run.json.

That's the main experiment captured: its displayed result is preserved in bounded-run.json.

Missing the captured result?

  • Confirm that PowerShell still points to the project folder from the previous step.
  • Check the command for a missing quote or pipeline character.
  • Help me diagnose why the bounded Claude Code result was not displayed or saved.
Parse the installed client's result

Structured output lets you preserve the installed client's exact result. Keeping the emitted text literal prevents documentation wording from replacing observed evidence.

  • Parse bounded-run.json by running this PowerShell block:
$boundedRun = Get-Content -Raw .\bounded-run.json | ConvertFrom-Json
$observedSubtype = $boundedRun.subtype
$stopText = $boundedRun.result
$reportedTotal = [decimal]$boundedRun.total_cost_usd

[PSCustomObject]@{
    subtype = $observedSubtype
    stop_text = $stopText
    total_cost_usd = $reportedTotal
}

What does this PowerShell block do?

  • Get-Content -Raw .\bounded-run.json | ConvertFrom-Json reads the file as one string. It converts that string into a PowerShell object.
  • $observedSubtype retains the installed client's literal result subtype.
  • $stopText retains the exact result text emitted by the installed client.
  • $reportedTotal retains total_cost_usd as a decimal value.
  • The total_cost_usd field is a client-side estimate. It does not provide authoritative billing data.

You should see labelled values for subtype, stop_text, and total_cost_usd.

A subtype of error_max_budget_usd matches the pre-registered expectation. Any other subtype is contrary evidence that must remain unchanged.

Seeing an empty result field?

  • Check each property name against the keys displayed in the captured JSON.
  • Confirm that bounded-run.json contains the complete result object.
  • Help me inspect empty parsed fields without inventing missing result text.
Calculate the cap-to-total difference

The cap and reported total remain separate decimal source values. Their difference is a comparison between two local figures.

Before you calculate it, do you expect the difference to be zero or positive?

  • Calculate the unrounded difference by running this PowerShell block:
$cap = [decimal]0.0001
$difference = $reportedTotal - $cap
$displayedDifference = [Math]::Round([double]$difference, 6)

[PSCustomObject]@{
    cap_usd = $cap
    reported_total_usd = $reportedTotal
    displayed_difference_usd = $displayedDifference
}

How are the three figures handled?

  • $cap preserves the configured $0.0001 ceiling as a decimal.
  • $reportedTotal preserves the separate total_cost_usd value from the captured result.
  • $difference subtracts the cap from the reported total without rounding either source figure.
  • $displayedDifference rounds only the displayed difference to six decimal places.
  • A budget-limited result includes the crossing response in total_cost_usd. This can place the final local estimate above the configured cap.

You should see cap_usd as 0.0001. You should also see the captured total under reported_total_usd.

For an error_max_budget_usd result, the displayed difference quantifies the local cap-to-total gap. Keep a contrary result unchanged if your installed client behaved differently.

Missing the reported total?

  • Confirm that the parsing block populated $reportedTotal before running the calculation.
  • Check that total_cost_usd exists in the captured result before interpreting the difference.
  • Help me preserve the source figures while debugging the difference calculation.

✔️ Awesome, I've got everything!

Your PowerShell session now retains the observed subtype, literal result text, reported total, cap, unrounded difference, and rounded displayed difference.

ⓧ I'd like to double check the full code

Compare your PowerShell commands with this complete sequence:

claude -p "five numbered points on why a local estimate should be validated before use as a control" --max-budget-usd 0.0001 --output-format json | Tee-Object -FilePath .\bounded-run.json

$boundedRun = Get-Content -Raw .\bounded-run.json | ConvertFrom-Json
$observedSubtype = $boundedRun.subtype
$stopText = $boundedRun.result
$reportedTotal = [decimal]$boundedRun.total_cost_usd

[PSCustomObject]@{
    subtype = $observedSubtype
    stop_text = $stopText
    total_cost_usd = $reportedTotal
}

$cap = [decimal]0.0001
$difference = $reportedTotal - $cap
$displayedDifference = [Math]::Round([double]$difference, 6)

[PSCustomObject]@{
    cap_usd = $cap
    reported_total_usd = $reportedTotal
    displayed_difference_usd = $displayedDifference
}

You now have a bounded print-mode result with its source figures preserved. Next, you'll test whether the same flag controls an ordinary interactive session.

Test the Interactive Mode Boundary

Your bounded print-mode result from Claude Code is preserved with its cap, reported total, difference, subtype, and literal stop evidence.

The budget flag is documented for print mode only. This step tests the same flag at the ordinary interactive boundary before you decide how narrowly to rely on it.

In this step, get ready to:
  • Attempt an ordinary interactive session with the same budget flag.
  • Classify the first observed behavior using one of three declared outcomes.
  • Preserve the terminal evidence without opening a billing page.
Start the ordinary interactive test

The earlier request included -p to activate print mode. An ordinary session leaves that switch out while keeping the test cap unchanged.

This test intentionally consumes a small amount of your existing subscription usage. No billing page is involved.

Before you run this, do you think the flag will affect an ordinary interactive session?

  • Start an ordinary Claude Code session with the same cap by running:
claude --max-budget-usd 0.0001

What does this command test?

This command starts Claude Code without -p while retaining --max-budget-usd 0.0001. Keeping the cap fixed isolates the change from print mode to ordinary interactive mode.

  • If Claude Code opens an ordinary prompt, enter this exact test message:
Reply with exactly CONTROL CHECK.

Why keep the prompt exact?

The fixed low-effort prompt makes an ordinary answer easy to identify. It also keeps the interactive test consistent with your predeclared run plan.

  • Submit the message by pressing Enter.
  • Observe the first complete terminal behavior.
  • Press Ctrl+D twice if the interactive session remains open.
  • Continue without opening any billing page.
Classify and preserve the outcome

The first observed behavior determines the classification. Match your terminal evidence to one of these three outcomes.

✔️ It answered normally

Claude produced an ordinary answer to the prompt. If it followed the instruction exactly, you saw CONTROL CHECK..

Classify the outcome as answered normally. The flag was inert in ordinary interactive mode.

ⓧ It rejected the flag at startup

Claude Code rejected the flag before an ordinary prompt became available. Preserve the startup text exactly as displayed.

Classify the outcome as rejected at startup. The flag was unavailable in ordinary interactive mode.

ⓧ It stopped on the cap

Claude Code stopped the ordinary session because of the configured cap. Preserve the stop text exactly as displayed.

Classify the outcome as stopped on the cap. This contradicts the documented print-only boundary and becomes the primary finding.

  • Keep the terminal output visible until you capture it in the checkpoint below.
  • Record the matching outcome with its boundary meaning in the text checkpoint.

Seeing an unrelated startup problem?

An authentication or environment problem prevents a valid mode-boundary classification. Preserve the terminal text before changing your environment.

  • Return to the verified subscription baseline from earlier.
  • Repeat this single interactive check after the baseline is restored.
  • Ask for help separating the startup problem from the boundary result: Help me interpret this startup behavior.

You should now have one terminal observation classified as answered normally, rejected at startup, or stopped on the cap.

That's the mode boundary captured for this installed Windows client. Next, you'll reconcile the result with your pre-run records before writing the evidence-backed verdict.

Reconcile Records and Write the Verdict

Your bounded print result is preserved in the open PowerShell project folder. The ordinary-session observation now shows where the control applied.

The raw cap-to-total difference is easy to mislabel as spend. This final step keeps both values as local estimates before turning the evidence into a defensible Claude Code decision.

In this step, get ready to:
  • Reconcile the pre-run records with the actual execution.
  • Write one evidence-backed operational verdict.
  • Measure the full project time against the 30-minute limit.
Reconcile the pre-run records

A pre-run record protects your original decision rules from hindsight. Reconciliation keeps that audit trail while bringing every factual description in line with the observed execution.

  • Review decision-record.md with the same text-editing method you used earlier.
  • Compare its operational question with the narrow control test you completed.
  • Confirm that Windows remains the only empirically tested platform.
  • Reconcile each mismatch with a corrected fact that preserves a concise divergence note.
  • Save decision-record.md.
  • Display the reconciled decision record in PowerShell by running this command:
Get-Content -Path .\decision-record.md

What does this check show?

The Get-Content command reads the saved file from the current project folder. The displayed record should preserve its original decision framework alongside any divergence note.

You should see the operational question, local computed-cost scope, verdict definitions, acceptance criteria, evidence limits, contrary-evidence requirement, reversal conditions, Windows-only empirical scope, and any required divergence note.

Can't display the decision record?

  • Confirm that PowerShell remains in the project folder containing decision-record.md.
  • Check that the filename contains both hyphens.
  • Ask for help with the current folder or file path: Help me display decision-record.md from my current PowerShell folder.
  • Review run-plan.md with the same text-editing method.
  • Compare the declared command with the command you actually ran.
  • Compare the declared Windows platform with the tested platform.
  • Compare the declared subscription path with the verified authentication path.
  • Compare the expected outcome with the bounded result and interactive result.
  • Preserve error_max_budget_usd as the predeclared expected subtype.
  • Reconcile each mismatch with a corrected fact that preserves a concise divergence note.
  • Save run-plan.md.
  • Display the reconciled run plan in PowerShell by running this command:
Get-Content -Path .\run-plan.md

What should remain in the run plan?

  • Windows remains the declared test platform.
  • Subscription authentication remains the declared test path.
  • The predeclared cap remains $0.0001.
  • The plan still requires total_cost_usd as a separate reported value.
  • The plan still requires a separate difference calculation.
  • The plan still requires literal stop-text capture.
  • The plan still includes the ordinary interactive-session check.
  • The plan still includes the 30-minute limit.
  • The dated anchors remain v2.1.217 on 2026-07-21 and v2.1.239 on 2026-08-21.

You should see a run plan that still distinguishes the predeclared expectation from the observed result. Any divergence should remain visible beside the corrected account.

Does the run plan hide a divergence?

Compare the saved plan with bounded-run.json and the interactive-session observation. Keep the original expected subtype visible before adding the actual outcome.

Ask for help checking the audit trail: Help me identify where run-plan.md differs from my observed Claude Code results.

Write the evidence-backed verdict

The final Markdown report connects each conclusion to a preserved local source. Its scope stays narrow enough for another practitioner to repeat the same Windows test.

What belongs in the verdict?

  • Clock identifies the project start time.
  • Clock identifies the project end time.
  • Clock reports total wall minutes against the 30-minute limit.
  • Setup records Claude Code version 2.1.217 or later.
  • Setup records subscription authentication with no API key on the test path.
  • Platform states that Windows is the only empirically tested platform.
  • Scope limits the control finding to the tested print-mode use case.
  • The first dated anchor records v2.1.217 as published on 2026-07-21.
  • The first dated anchor records the background-subagent enforcement fix after the cap.
  • The second dated anchor records v2.1.239 as published on 2026-08-21.
  • The second dated anchor records the 1.1× US-only-inference premium in estimates for data-residency workspaces.
  • The release interpretation states that this estimate change does not determine the observed cap-to-total gap.
  • Measurements preserve the $0.0001 cap as a separate figure.
  • Measurements preserve the exact total_cost_usd value as a separate figure.
  • Measurements preserve the calculated difference with only its displayed value rounded to six decimal places.
  • Stop evidence quotes the installed client's emitted message verbatim.
  • Interactive evidence records the exact observed ordinary-session outcome.
  • Billing limitation states that the billing console was never opened.
  • Subscription usage states that the test intentionally consumed existing plan usage.
  • Resource scope records that no metered API key entered the test path.
  • Resource scope records that no payment card, new account, or cloud resource was created.
  • Create verdict.md inside the open project folder with the same file-writing method used for the pre-run records.
  • Populate the report with every evidence area from the checklist above.
  • Save verdict.md.
  • Display the draft verdict in PowerShell by running this command:
Get-Content -Path .\verdict.md

What does this draft check prove?

The command displays the saved report from the current folder. You can now compare its headings with the evidence checklist before selecting a verdict.

You should see sections for clock, setup, platform, scope, dated anchors, measurements, stop evidence, interactive behavior, billing limitations, subscription usage, and the decision.

Is a verdict section missing?

Compare the displayed headings with the evidence checklist above. Add each missing section through the same text-editing method.

Ask for help reviewing the report structure: Help me check verdict.md against the required evidence headings.

💡 Which verdict fits the evidence?

  • Adopt means the observed print-mode behavior is suitable for the narrow local-estimate guard tested.
  • Reject means the expected stop or client total was absent.
  • Watch means the control worked while its evidence or semantics require a dated re-check.
  • Park means a blocker prevented a valid test.
  • An interactive cap stop contradicts the documented print-only boundary. That contradiction becomes the primary finding.
  • Every selected verdict requires one observable reversal trigger.
  • Watch and Park also require a concrete re-check date.
  • Complete the decision section with exactly one verdict from the guidance above.
  • Add one observable finding that would reverse the selected verdict.
  • Add a concrete re-check date when the selected verdict is Watch or Park.
  • Save verdict.md.

Your verdict now has a defined operating boundary. Its reversal trigger makes the decision testable when new evidence appears.

Stop the clock and verify the pack

The final timing calculation closes the same project window that began with $projectStartedAt. The measured duration belongs in the report beside the 30-minute limit.

  • Record the project end time by running this command:
$projectEndedAt = Get-Date

What did this record?

The command stores the current date and time in $projectEndedAt. This timestamp closes the counted project window.

Before you calculate it, do you expect the full project to land inside the 30-minute limit?

  • Calculate the total wall minutes by running this command:
(New-TimeSpan -Start $projectStartedAt -End $projectEndedAt).TotalMinutes

What did this calculate?

New-TimeSpan compares $projectStartedAt with $projectEndedAt. The TotalMinutes property returns the whole and fractional minutes across the project.

You should see one whole or fractional number. That number is the measured duration for comparison with the 30-minute limit.

Missing a wall-time result?

  • Confirm that the current PowerShell session still contains $projectStartedAt.
  • Confirm that $projectEndedAt was set in the same session.
  • Ask for help checking both timestamp variables: Help me debug my PowerShell wall-time calculation.
  • Compare the displayed duration with the 30-minute limit.
  • Complete the clock section in verdict.md with the exact duration and limit comparison.
  • Save verdict.md.

Before the final check, which report requirement is most likely to reveal an inconsistency?

  • Display the completed verdict by running this command:
Get-Content -Path .\verdict.md

What does the final check prove?

The command displays the saved report from the evidence pack. Reading this output confirms that the measured timing result sits beside the evidence-backed decision.

You should see every required evidence section, one selected verdict, one reversal trigger, and a re-check date when the verdict is Watch or Park.

✔️ My evidence pack is complete

Your reconciled records now match the observed execution. The completed verdict.md preserves the measured wall time and narrow operational decision.

ⓧ I'd like to double check the evidence pack

Check each artifact against the required final state:

  • Confirm that the Claude Code baseline records version 2.1.217 or later. It records subscription authentication. No API key is on the test path.
  • Confirm that the PowerShell session contains $projectStartedAt and $projectEndedAt from Get-Date. Total wall minutes have been calculated with New-TimeSpan. The result has been compared with the 30-minute limit.
  • Confirm that the bounded-run measurements retain the decimal $0.0001 cap. The exact total_cost_usd remains separate. The difference equals reported total minus cap. Only the displayed difference is rounded to six decimal places.
  • Confirm that bounded-run.json preserves the displayed JSON output from the bounded print request. It contains the observed subtype. It contains total_cost_usd. It contains the literal emitted result text.
  • Confirm that decision-record.md matches the actual execution. It preserves the operational question, local computed-cost scope, verdict definitions, acceptance criteria, evidence limits, contrary evidence, reversal conditions, Windows-only empirical scope, and any concise divergence note.
  • Confirm that the interactive observation records one observed outcome from the ordinary session started with --max-budget-usd 0.0001. It confirms that no billing page was opened.
  • Confirm that run-plan.md matches the actual execution. It retains Windows, subscription authentication, the test cap, the print-mode JSON command, the expected subtype, the client total capture, the separate difference, the literal stop text, the interactive check, the timing limit, both dated anchors, and any concise divergence note.
  • Confirm that verdict.md contains clock, setup, Windows-only platform scope, narrow print-mode scope, both dated anchors, all three measured figures, the verbatim stop message, the interactive result, the billing limitation, and intentional subscription usage. Exactly one verdict is selected. An observable reversal trigger is present. Watch or Park includes a concrete re-check date. The report confirms that no billing console was opened. It confirms that no metered API key, payment card, new account, or cloud resource was created.

That's the evidence pack complete. Your Windows result now supports a narrow operational decision with its limits visible.

Secret mission

Try to Reverse Your Own Verdict

Put your verdict under pressure by naming the interactive result that would overturn it. You will add a traceable evidence map. You will also tighten every cost claim to the local estimates you actually measured.

Clean Up Your Resources

Clean Up Your Resources

Your completed evidence pack lives entirely on your Windows device. Keeping it creates no ongoing cloud costs.

Existing Claude Code subscription usage remains consumed. Choose whether to keep the evidence pack, pause your work, or delete the local records.

Resources you used:

  • The pre-run decision record, decision-record.md.
  • The pre-run test plan, run-plan.md.
  • The completed control verdict, verdict.md.
  • The captured print-mode evidence, bounded-run.json.
  • The active PowerShell session holding the recorded timing values.

Keep everything running

Keeping the evidence pack requires no cleanup. The folder remains available for a future control review.

  • Retain the project folder as your reproducible Windows evidence pack.
  • Keep verdict.md as the durable record of the calculated wall time.
  • Leave the PowerShell session from earlier open only while you need its in-memory timing values.

Pause - I'll come back to this later

Pausing preserves the local evidence pack while releasing the current PowerShell session. The completed wall-time result remains in verdict.md.

  • Confirm that verdict.md contains the calculated wall minutes.
  • Close the PowerShell window from earlier.
  • Leave the project folder unchanged for your next control review.

Delete - I don't want to use this again

Deletion is permanent for these local records. Existing subscription usage remains unchanged.

  • Copy any evidence you need into a different folder.
  • Close the PowerShell window from earlier.

The in-memory timing values are now cleared. The project folder remains as the final local resource to remove.

  • Use Windows search to open a file manager.
  • Locate the project folder that contains decision-record.md, run-plan.md, verdict.md, and bounded-run.json.
  • Move up one level so the project folder itself is visible.
  • Select the project folder.
  • Press Shift+Delete to permanently remove the selected project folder.
  • Approve the confirmation prompt.

You should no longer see the project folder in its previous location. The local evidence pack is now deleted.

Nice Work!

Nice Work!

You did it! Your Windows evidence pack now supports a timed verdict on Claude Code's local print-mode budget control.

You've learned how to:

  • Establish a verified baseline with a qualifying client version. Confirm subscription authentication before the measured run.
  • Write pre-registered decision rules in decision-record.md and run-plan.md before exercising the control. Preserve acceptance criteria plus evidence limits plus reversal conditions.
  • Capture bounded print-mode evidence in bounded-run.json. Keep the configured cap plus reported total_cost_usd plus computed difference as three separate local figures. Test the same --max-budget-usd control in an ordinary interactive session before selecting a timed Adopt, Reject, Watch, or Park verdict.
  • Secret Mission: Challenge your verdict with a testable reversal trigger. Build a claim-to-evidence map that marks Windows as tested. Keep macOS plus Linux as reasoned only. Add a concrete re-check date where required.

Ready to quiz yourself?