Hospital Agent Usage Audit

Scope And LimitsCopy Anchor Link

This audit inspected local session metadata and usage events, not private reasoning or patient records. The sample covers locally available Kulcare session files created on 18-21 October 2026 and the active long-running Hospital thread. It is not the provider's billing ledger or a complete account-wide weekly audit. Session counters, cache hits and quota percentages must not be converted to credits or money without the provider's accounting rules. Forked counters and overlapping account activity can overlap; do not sum parent and child totals as independent spend. Raw session files, user prompts, credentials and transcripts are not included in this repository.

Measured FindingsCopy Anchor Link

An earlier Hospital orchestration session recorded 51,345,314 input tokens and 142,000 output tokens between 19 October 01:08 and 03:05 UTC. Of that recorded input, 50,153,728 tokens were cached: about 98%. That session's quota samples moved from 43% to 76%, but other account activity cannot be excluded from that change. The parent also had an implementation worker; its recorded 14,773,096 input tokens are not added to the parent total here.

Several later Hospital implementation workers individually reported large input counters:

These are observations from individual files, not proof of independent billed amounts. Usage samples are not a verified request count. The profile metadata names the Hospital implementer role; configured names are not independent served-model receipts.

For the main thread's 21 October 14:45:19-15:34:34 UTC interval, the recorded counter increase was:

• Input: 28,449,078 tokens.
• Cached input: 28,097,152 tokens, about 98.8% of recorded input.
• Input not marked cached: 351,926 tokens.
• Output: 56,568 tokens; the reported reasoning subset is already part of output and is not added again.
• 170 usage samples and 157 tool-call records.

A command-text classification of those 157 calls found 23 skill/reference reads, 53 orchestration calls, 27 verification calls, 36 source reads and 18 other calls. These categories are heuristics and counts, not token attribution or pricing. That interval spans merge/supervision/delegation activity; it does not isolate only the Claude task or all concurrent account usage. The account-level quota samples changed during the interval; their reset timestamps also shifted, so the difference is not assigned to one task.

InterpretationCopy Anchor Link

The evidence supports repeated large-context processing and many host supervision turns as cost drivers. It does not prove that cached input is free or that every cached token has the same quota weight. The task also required launcher repair and three serial author attempts before host tests/lint passed. The first attempt had an invalid occupancy fixture; the next passed tests but failed style checks. Those repairs were useful correctness checks, but they made a small tests-and-guide task an expensive delegation trial.

Delegating authoring to Claude does not suspend the Codex orchestrator. The measured Codex interval includes active host work while the external worker ran. Claude account usage is separate and was not established from these Codex counters. No cost saving from the trial is claimed.

Official Codex pricing and usage guidance explains that task/context characteristics affect usage. Use the account usage dashboard for authoritative allowance and credit information; this local analysis cannot replace it.

Execution Policy For Remaining WorkCopy Anchor Link

Keep the existing orchestration safety rules and software pattern rules. This policy narrows unnecessary work; it does not waive security, review, tests or clinical release gates.

1. Start a fresh implementation session at a completed unit boundary with a short, source-linked handoff instead of the full historical chat.
2. Send one complete bounded packet: source commit, goal, requirements, allowed paths, domain/API contract, known dependencies and acceptance tests.
3. Do not delegate tiny characterization-only work by default. Prefer a cohesive source/API or UI integration slice that includes its own focused tests and lint.
4. Provision an owned disposable test environment before the worker starts. Give only the approved test authority; never copy production credentials into its packet.
5. Keep one writer and no swarm by default. Read-only parallel review needs a concrete independent risk that justifies its extra context.
6. Use a fixed requested model and effort for the packet; record actual receipt limits. Do not change global model settings or silently choose another provider.
7. Have the worker complete its focused tests and lint before handoff. The host runs authoritative integration checks, rather than paying a round trip for each style offense.
8. Wait through the supported runner with meaningful status updates. Avoid repeated short polls that trigger another full host inference without new evidence.
9. Read only the active plan unit, its cited constraints and relevant source; do not reload every skill, full plan or schema dump at each step.
10. Keep full test output in local logs. Return summaries and failing excerpts; metadata collection must not export full transcripts.
11. Run focused checks after each change and canonical full CI on the integrated stable candidate. Reuse receipts when source/configuration is unchanged and record exactly what they cover.
12. Run the required review on a stable scope. Fix and rerun affected checks; do not repeat unrelated personas or full suites just to collect another completion marker.
13. After two failures caused by the same assumption, diagnose that assumption before another worker launch. Preserve evidence and avoid duplicate live jobs.
14. Record per-unit usage snapshots where available, elapsed time, attempts and accepted output. Mark unavailable data as unavailable; do not claim savings from a model name.

Planning Before ImplementationCopy Anchor Link

The remaining delivery plan indexes seven focused source plans and three shared concerns. It covers all ten remaining programme units plus U20 acceptance. Its local implementation units are work packets, not separate product promises or mandatory PRs. Planning does not grant clinical, Inventory, financial, storage or network approval. Review the contracts before authoring runtime changes; keep each body of work on its one integration PR.

Measurement ChecklistCopy Anchor Link

• Record the unit's starting commit and available usage counters.
• Check that no duplicate worker or second writer owns the task.
• Record one bounded packet and requested model/effort.
• Record focused worker checks, host integration checks and review scope.
• Record terminal usage counters, attempts and any overlapping sessions.
• Separate input, cached input, output and reasoning subsets without double counting.
• Use provider accounting, not raw token sums, for any cost or quota claim.