Expensive cost, nothing to show for it.

[ParsingMAINFRAME]

I set a $20 budget. It spent the whole $20 budget getting setup. How can I budget something when I have no ability to estimate it's expected cost? Am I supposed to set it to $50 now and just hope I don't burn a $50 budget on top of a $20 budget? How do I estimate before I run? :(

[brahimhamichan]

Hitting this too, with data that may help isolate it: scan cost appears to be independent of scan scope.

CLI 0.1.1, model gpt-5.6-sol, --mode standard, macOS, Node 26.5.0, Python 3.14.6, auth via stored ChatGPT sign-in.

I ran the same repo three times, varying only scope and reasoning effort:

	Run 1 (whole repo)	Run 2 (--path × 5)	Run 3 (same paths, medium effort)
Files in scope	7,994	458	458
Reasoning effort	xhigh	xhigh	medium
--max-cost	25	25	5
inputTokens	34,958,075	33,002,347	6,386,426
cachedInputTokens	33,798,400	31,573,504	5,978,368
cacheWriteInputTokens	0	0	0
outputTokens	129,425	127,163	25,223
Stopped at	$26.58	$26.75	$5.79
progress.phase	preflight	preflight	preflight
findingCount	0	0	0

Two independent levers, neither of which controls spend:

• Scope (runs 1 → 2). Cutting scope by 94% reduced input-token consumption by 5.6% and cost by 0.6%.
• Reasoning effort (runs 2 → 3). Dropping xhigh to medium did not reduce the burn rate; run 3 simply hit a lower ceiling sooner. Input tokens per dollar were ~1.23M in run 2 and ~1.10M in run 3.

All three runs were killed by the cost limiter in preflight with worklistRows: 0 and closedRows: 0 — file review never started, so no run could produce a finding. The limiter works exactly as documented; the problem is that nothing reaches the phase that generates findings before the budget is gone.

Two things stand out:

1. ~72,000 input tokens per in-scope file on run 2 (33M input / 458 files), against only 127k output tokens across the whole scan — a ~260:1 input-to-output ratio. That suggests a large context being re-sent in a loop during ranking rather than work proportional to the codebase.
2. cacheWriteInputTokens: 0 alongside 31.6M cachedInputTokens. If nothing is being written to cache, it's worth confirming the cached-input accounting is attributing reads correctly in the cost estimator.

The artifacts match the counters: on run 2, 02_discovery/rank_input.jsonl was written with exactly 419 records, but 03_coverage/, 04_reconciliation/ and 05_findings/ were all created and left empty. Same on runs 1 and 3.

On the original question in this issue — how to budget a scan up front — the practical problem is that --path and model_reasoning_effort are the two documented levers for controlling spend, and on this evidence neither one does. That leaves no way to buy a smaller scan: the only outcome available at any budget I tried was a full spend with zero findings. A cost estimate from --dry-run, or making the ranking phase's context scale with the selected scope, would each address that directly.

Happy to supply the full scan records or rerun with different flags if it would help narrow this down.

[createsomethingtoday]

I now have natural-terminal data from two report-only standard scans using gpt-5.6-sol/xhigh, with the scope/finalizer fixes in #71. The fixes allow scans to complete, but they confirm that cost is not predictable from source-file count.

Scope	Inventory	Elapsed	Input / cached	Output	Cost	Result
authentication package	33 rows (28 first-party + 5 installed wrappers before the latest exclusion)	63m47s	71.39M / 68.94M	320k	$56.30	48 findings, partial coverage; original run hit a now-fixed finalizer binding error
shared authorization package	36 rows (12 tracked + 24 generated dist files)	32m44s	90.21M / 86.17M	478k	$77.62	8 findings, complete coverage, sealed successfully

The smaller tracked package was ~38% more expensive. Its 12-session tree spent ~95.5% of input tokens as cached input. Artifact timing was also highly back-loaded: deterministic inventory existed before model start, but the first candidate ledger did not persist until roughly 19 minutes; final findings appeared near 28 minutes and sealing completed at 32:44.

This changes the diagnosis from “the cost cap prevents all value” to “natural-terminal scans can produce substantial value, but neither scope size nor dry-run metadata gives an operator a usable cost estimate, and most spend is repeated cached context across delegated sessions.” Generated artifacts are another material lever: this 12-file package became a 36-row exhaustive inventory because shipped dist output is intentionally included.

#71 fixes deterministic standard inventory and workbench target binding; it does not address cost estimation or orchestration duplication. The most useful next product controls from these runs would be: (1) a dry-run estimate based on planned session topology plus inventory classes, (2) configurable first-party/generated/dependency inventory policy, and (3) incremental durable candidate/validation checkpoints so a late stop retains more than setup artifacts.

[thedaviddias]

Additional reproduction data from CLI 0.1.3 (bundled plugin 0.1.14) shows the same behavior on both the default model and the README's lower-cost model/effort example.

Environment:

• macOS (Apple Silicon)
• Node.js 24.15.0
• Python 3.14.6
• stored ChatGPT authentication
• standard/report-only scans
• private mixed TypeScript/Swift monorepo; no source or credentials included below

I progressively narrowed the scope and then switched from gpt-5.6-sol/xhigh to gpt-5.6-terra/high:

Run	In-scope files	Model / effort	Max cost	Final estimated cost	Input / cached	Output	Result
Whole repository	15,594	sol / xhigh	$5	$5.001623	5,143,297 / 4,782,336	26,855	failed in preflight
Two application paths	7,895	sol / xhigh	$5	$5.033842	6,007,898 / 5,718,784	24,296	failed in preflight
One application path	3,033	sol / xhigh	$5	$6.075278	5,668,954 / 5,142,016	28,986	failed in preflight
Twelve security-boundary paths	294	terra / high	$3	$3.3742245	6,056,397 / 5,554,688	48,752	failed in preflight

All four scans recorded:

• progress.phase: preflight
• findingCount: 0
• worklistRows: 0
• closedRows: 0
• no sealed report.md, findings.json, or coverage.json

The most focused run did create deterministic discovery artifacts and six review_slice_*.txt files, but the scan stopped before any candidate or coverage row became durable. Across the four attempts the estimated cost was about $19.48 with no actionable output.

The 294-file run is particularly useful evidence that reducing scope and using Terra/high does not currently provide a predictable small scan: it consumed more input and output tokens than the much larger sol/xhigh runs before stopping. The $5 one-app run also ended at $6.08 because in-flight delegated work completed after the configured estimate was crossed.

This reinforces the requests already raised here for:

1. a dry-run estimate based on planned session topology;
2. durable incremental candidate/coverage checkpoints before the terminal phase;
3. a way to control delegated-session concurrency/context duplication;
4. clearer operator guidance for setting a budget that is likely to reach a report.

Happy to provide the four scan IDs or sanitized scans show output if useful.

[createsomethingtoday]

Extended exact-commit use found additional real project issues, then exposed a separate completion defect: immutable commit/range scans had no snapshotDigest and could not be saved after model work completed. PR #112 adds the deterministic diff binding and regression. This is separate from the scope-inventory fix in PR #71.

[mldangelo-oai]

Maintainer reproduction on @openai/codex-security@0.1.4: a supposedly single-file scan using --path .github/release.yml, gpt-5.6-luna, low effort, and one worker generated an in_scope_files.txt containing 186 repository files. The separate rank-input ledger correctly contained one requested file, but the agent followed the oversized inventory and had already consumed approximately $0.20 before I stopped it.

This demonstrates that scan cost cannot currently be predicted from requested path scope when the model-generated inventory broadens to the entire repository. The candidate fix is #88, which creates and attests the exact scope inventory before starting Codex or spending model tokens. Nested desktop sandboxing can additionally prevent the agent from writing required artifacts at all; that should fail before model execution rather than surfacing only as a missing manifest afterward.