DSHREM robustness audit, October 2026

We read the paid task path — cancellation, timeouts, retry, fallback, cost accounting and the write gate — and found six defects. One of them could corrupt the money ledger; it is fixed and covered by tests. The rest are listed with their exact location so the next engineer does not have to rediscover them.

🧭 What was audited

The path a paid task takes: the local client, the terminal agent and its guards, the transport service that holds provider keys, and the budget ledger that reserves money before a call and settles it afterwards.

Method: source reading only, no paid inference during the audit. Every claim below points at a file and a function, so it can be re-checked without repeating the whole review.

📊 What it cost to find this

The two refused attempts are worth mentioning: a rate-limited provider returns an error before generation, so they cost nothing. That distinction — zero versus unknown — is exactly what one of the defects was about.

🚧 The defect that was fixed

Late money could be booked against a closed reservation.

A reservation is money held before the call. When a task closes cleanly, the unused part returns to the pool. The ledger accepted a charge, a freeze or an uncertainty hold on that released row afterwards:

• the charge inflated spent_usd on a task whose limit had already been returned, so the day's totals no longer matched the pool;
• an uncertainty hold turned a finished task back into a frozen row that no live run could reconcile — a permanent block for the account.

Fix: charge, freeze and mark_uncertain refuse a released reservation with a named error (reservation_closed). A reconciled row stays chargeable on purpose: its reservation is still held, and the "reconcile, then continue" flow depends on that.

Verified by four regression tests: charge after release, freeze after release, uncertainty after release, and the positive case — a frozen task may still take more holds.

📋 What remains open

These are documented, not fixed. None of them is a reason to stop using the service; each is a reason to keep the daily cap in place.

1. Bash can write outside the working directory. The write/edit tool denies paths that escape the workspace, but the shell gate only blocks listed protected paths. A write-shaped command aimed at a file outside the workspace and not on that list runs. Impact: blast radius, not billing.
2. A worker can close its own task. The endpoint that releases a reservation authorises with the same token the worker holds, so a mid-run close returns the unspent budget to the pool while the run continues.
3. A resumed task can exceed its own cap. The reservation is re-created for the full task budget on resume, without comparing what the same task already spent.
4. Re-opening a reservation does not refresh its day and spend. After a release on a later UTC day, the row keeps the first day's counters, which distorts the daily cap arithmetic.

✅ How to use this page

• If you are evaluating the service: the fixed defect is the one that could have made a receipt look healthy while the pool was wrong. The receipt you see is the settled number, not a guess.
• If you operate it: keep the per-task cap and the daily cap on. Findings 1–4 are the reason both exist.
• If you are re-checking: start from the ledger file, not from this text. A page can be corrected; the code is what runs.

➡️ Next

• Costs, budgets and limits — the numbers this audit protects.
• Recovery after a failed run — reconcile, cancel, resume.
• AI judging — why "tests pass" needs a command and a return code, not a sentence.