# Per-use confirmation has a break-even point Per-use confirmation is worth its cost only while the calls it catches are exceptional enough to deserve a fresh human decision. Once routine production work generates a steady stream of prompts, the control starts charging the team for the same decision again and again. The break-even point is usually lower than people expect because the click is the cheap part. Waiting, reading enough context to trust the request, and recovering the interrupted train of thought dominate the bill. A useful comparison needs two separate ledgers. One records operator time. The other records the security consequence of granting a wider window. Mixing them produces bad answers such as `twelve prompts feels annoying` or `production must always require a click`. Neither statement tells you whether a prompt changes a decision. The model below puts a price on interruption without pretending that a destructive database command carries the same risk as a read-only status call. ## Calculate the loaded cost of one confirmation The loaded cost of one confirmation is response time plus the share of interruption recovery that the prompt actually causes. Use seconds, not a vague rating such as low friction. Define these values: - `p`: confirmations presented per day - `t`: median seconds from prompt arrival to a completed decision - `r`: median seconds needed to resume the interrupted task - `q`: fraction of prompts that arrive during focused work - `d`: developers whose individual prompt counts are represented by `p` If `p` is a per-developer count, daily team cost is: ```text per_use_seconds = p * d * (t + q * r) ``` If `p` already counts every confirmation across the team, remove `d`: ```text per_use_seconds = p * (t + q * r) ``` That distinction prevents the most common spreadsheet error: taking a team-wide prompt total and multiplying it by team size a second time. Write the unit next to every input. `8 prompts/person/day` and `48 prompts/team/day` may describe the same six-person team. Use the median for `t` because a few abandoned prompts can distort the mean. Do not hide those abandoned requests, though. Track their count separately as failed work. For recovery, measure the time until the developer resumes the previous meaningful action, not the time until the approval window closes. A developer who approves in nine seconds and then spends two minutes reconstructing a query paid 129 seconds, not nine. The `q` term stops the model from charging recovery to prompts handled between tasks. If you cannot measure it yet, calculate a range with `q = 0.5` and `q = 1`. The range is more honest than a precise figure built on a guess. ## Count prompts at the boundary people experience Count every decision a person must make, not every API request and not every notification emitted by the system. One approval card that covers five retries is one confirmation. Five cards caused by an automatic retry loop are five confirmations even if the underlying operation is logically one task. The model prices human work, so its unit must match the human boundary. Start the count when the prompt becomes actionable. A card that appears but cannot be understood without opening a terminal has already consumed response time. Include denials, expired prompts, and duplicate requests because they occupy attention. Record automated calls that never ask a person separately; they matter to risk and capacity, but they have no direct confirmation cost. Burst shape matters even when the daily count stays fixed. Twenty prompts spread across ten hours may be tolerable. The same twenty arriving during a release can stall the only people able to diagnose the release. Keep a simple maximum for confirmations in any 15-minute window. The daily equation estimates labor, while the burst figure exposes operational delay. Do not treat alerts sent to several people as several confirmations unless several people actually inspect them. If a production prompt fans out to four developers and two routinely open it before one approves, record two human responses. Notification delivery is not the cost boundary; attention is. A sound event record needs only a few fields: ```text ts, request_id, responder, decision, shown_at, decided_at, prior_task_resumed_at, key_class 2026-07-21T14:03:10Z, r-1842, dev-3, allow, 14:03:10, 14:03:22, 14:05:01, deploy-read ``` From that row, `t` is 12 seconds and observed recovery is 99 seconds. The record also lets you find repeat prompts for the same request, uneven load across responders, and expensive classes of keys without collecting the secret or request payload. ## Session authorization changes what the approval means Session authorization does not remove confirmation. It moves the decision from each use to the start of a bounded agent run. The comparison unit therefore changes from calls to sessions. A session approval should identify the process and end when that process exits; an approval tied only to a friendly display name or an open-ended clock window is a different and weaker control. Define `s` as new agent sessions per developer per day and `a` as median seconds to inspect and approve a session. The daily operator cost is: ```text session_seconds = d * s * a ``` The arithmetic favors sessions quickly because one decision can cover many calls. The security debit is broader authority inside the approved run. A compromised or misdirected process can make another permitted call without presenting a new prompt. That is why a time comparison cannot declare a universal winner. A session needs an unambiguous end. Process exit is easy to reason about: the grant disappears with the process that received it. A fixed eight-hour window can outlive the task, survive a handoff, and cover a later action nobody considered at approval time. If the authorization system cannot revoke an active session or show which process holds it, price that as a control defect rather than pretending it is free. The session prompt must also give the responder enough identity to make the decision. Path names and agent labels can be copied. Code-signing authority, executable identity, and launch context provide stronger evidence about what started. The person is approving a principal for a period, not blessing a sentence that says an agent wants access. ## The break-even equation exposes the real threshold Per-use confirmation costs more operator time when its daily loaded seconds exceed the cost of session approvals. For a per-developer prompt count, set the two equations equal: ```text p * d * (t + q * r) = d * s * a p_break_even = (s * a) / (t + q * r) ``` Team size cancels when every developer has the same prompt and session rates. This does not make `d` irrelevant. It means the per-person threshold stays the same as the team grows; total cost grows on both sides. Team size returns when work is uneven, several responders inspect the same prompt, or only part of the team starts agent sessions. Consider six developers. Each starts two production-capable agent runs per day, and a session decision takes 15 seconds. Per-use decisions take a median of 12 seconds. Seventy percent arrive during focused work, and median recovery is 90 seconds. ```text p_break_even = (2 * 15) / (12 + 0.70 * 90) p_break_even = 30 / 75 p_break_even = 0.4 confirmations per developer per day ``` At eight per-use prompts per developer per day, the team handles 48 prompts. Their loaded cost is: ```text 48 * (12 + 0.70 * 90) = 3,600 seconds = 60 minutes/day ``` The 12 session approvals cost `6 * 2 * 15 = 180 seconds`, or three minutes. The gap is 57 minutes each production day. Click time alone would report only 9.6 minutes for per-use approval and miss most of the cost. The threshold of 0.4 is not an instruction to grant every session broad access. It says repeated prompts have already become the more expensive way to approve comparable routine calls. Keep per-use decisions for calls whose consequence can change from one invocation to the next. Move predictable, bounded work to session scope only when the session identity, lifetime, allowed channel, and revocation behavior make that scope acceptable. Run a sensitivity check before acting. With the same inputs but zero recovery cost, the threshold becomes `30 / 12 = 2.5` prompts per developer per day. With three minutes of recovery, it falls below 0.22. If the recommendation changes only under an implausible recovery estimate, the decision is stable. If it flips across your credible range, measure recovery instead of debating it. ## A cheap prompt can still hold the whole operation Labor cost and elapsed delay answer different questions. The equation above totals human time, but the agent also waits while nobody can act. A 15-second decision may consume only 15 seconds of labor and still add four minutes to a deployment if the prompt sits unseen for 225 seconds. Track both values. The first tells you what the control costs the team; the second tells you what it costs the production workflow. Consider an agent that performs a five-call release check: read deployment state, fetch recent errors, inspect the active revision, run a health command over SSH, and record the result. Each call uses a key configured for per-use approval. The first card reaches the on-duty developer during code review. The developer checks it and returns to the diff. The next call arrives 40 seconds later, after the agent has processed the first response. This repeats until the workflow finishes. The five clicks might total only one minute. They are not one interruption, because the gaps let the developer re-enter the review and get pulled out again. If each interruption carries 75 seconds of recovery, loaded human cost reaches 435 seconds: `5 * (12 + 75)`. The agent's elapsed delay can be higher because its work serializes behind every approval. Neither number appears if the dashboard reports only click latency. Now suppose the fourth call asks to run a health command against an unexpected host. The developer denies it. That denial proves one prompt carried useful, call-specific information. It does not prove the other four routine reads needed separate decisions. A better design can authorize the identified agent process for the three known read calls, retain per-use approval for SSH, and reject hosts outside the intended scope. The model supports this split because it groups costs and denials by key class instead of averaging the whole workflow. This failure also exposes the cost of serial confirmations. When calls depend on previous results, approval delay sits on the critical path. For independent calls, an agent may issue several requests together, which creates a burst that the responder must inspect. The daily loaded-time equation treats the same number of human decisions similarly, but the operational shape differs. Record workflow elapsed time or agent wait time when release speed and incident response matter. Do not convert agent wait time directly into developer labor dollars. A waiting process is not a person working. Report it as elapsed delay, then decide what that delay harms: deployment duration, incident diagnosis, an automated deadline, or nothing material. Keeping the ledgers separate prevents an impressive but false total. The same discipline applies to denied calls. A denial saves the consequence of an unwanted action, which can dwarf interruption cost, but you cannot assign a credible monetary value without evidence. Report what the gate caught in concrete terms. `Denied SSH to an unrecognized host` is decision evidence. `Approval prevented a major incident` is speculation unless an investigation established that outcome. Use the failure walkthrough as a design test. If removing four prompts would also remove the context needed to catch the fifth, your proposed session scope is too broad. If each call uses a separate key class and the sensitive call retains its gate, the routine prompts add cost without helping that decision. The break-even equation tells you when to inspect the design; the call sequence tells you where to cut it. ## Median response time misses queues and abandoned work Median response time describes a typical handled prompt, but production work often fails in the tail. A prompt waiting for the one authorized developer can block an agent, a deployment, or an incident check for far longer than the median. Record the 90th percentile response time, expired prompts, and time to the first valid responder alongside the value used in the labor equation. Do not simply substitute the 90th percentile into every cost calculation. That would charge every prompt as if it were slow. Use the median to estimate ordinary labor and report the tail as an operational constraint. For example: `42 loaded minutes/day; median decision 11s; p90 decision 96s; 3 expirations/week`. That compact line tells more truth than one blended score. Interruption recovery also has a tail. A prompt that lands while someone reads logs may cost half a minute. One that lands while the same person holds an unexecuted database repair in working memory can force a full recheck. Classify the prior task with two or three categories such as routine, focused, and incident. You are looking for a policy boundary, not a neuroscience paper. Abandoned work belongs in the cost ledger. If an agent times out while waiting, retries, and presents another card, the first prompt did not cost zero merely because nobody approved it. Count the attention it received, the delay imposed on the agent, and the duplicate if a person later inspects that too. Approval fatigue is not proved by a large prompt count alone. Look for repeated approvals of the same key class, falling inspection time, duplicate requests, and a denial rate near zero for routine operations. Those signals suggest the interface asks people to reconfirm an established decision. A high denial rate says the prompts still separate acceptable calls from unacceptable ones, even if they are expensive. ## More developers change coordination, not multiplication The number of production responders matters because prompt distribution is rarely even. Multiplying a team-wide prompt count by headcount overstates cost, while averaging across everyone can hide that two people absorb nearly all interruptions. Calculate per-person loaded minutes first, then sum them. Report the median and the busiest responder as well as the team total. Suppose 60 prompts reach a ten-person production group, but routing sends 45 to the primary pair. A team average of six prompts per person describes nobody's day. The primary responders may need session authorization for routine calls even if the rest of the group sees little friction. Rotating the primary role can distribute the pain, but it does not reduce total cost and may add handoff work. Fan-out creates another cost. When a prompt goes to several people, one approval ends the wait but other developers may already have read it. Add `w`, the average number of people who inspect each prompt. Then a team-total form becomes: ```text per_use_seconds = p * w * (t + q * r) ``` Use this form only when each inspection has similar cost. If the winning responder spends 20 seconds and everyone else glances for two seconds, calculate those groups separately. A model should become slightly more detailed when the operating pattern demands it, not because a spreadsheet has room for more cells. Session cost can also concentrate. If only two designated operators start production-capable runs, use two for the session side rather than the ten people who could receive a per-use prompt. State the population beside each term. Headcount is not a risk multiplier by itself; authority distribution and actual attention are. This is also where queue ownership matters. A shared approval queue with a clear on-duty responder reduces duplicate inspection. Broadcasting every request to the whole team may improve the chance of a quick click while quietly consuming more collective focus. Fast approval and cheap approval are different metrics. ## Risk determines which calls keep per-use gates Volume can show that a control is expensive, but consequence decides whether to keep paying. Separate keys or action classes by what another call could do inside the same session. Read-only inventory, deployment initiation, production mutation, and credential administration should not inherit one setting merely because the same agent invokes them. The field often blurs authentication, authorization, and confirmation. Authentication identifies the process or person. Authorization grants a scope. Confirmation asks a human to reconsider one proposed use. Repeating confirmation cannot repair weak process identity, and strong identity does not make a broad grant safe. If you confuse the three, you end up clicking on every call while granting the wrong process permission. Keep per-use confirmation when the request carries facts that materially change the decision: the target host, operation class, environment, or affected resource. A destructive command against production may deserve a fresh check even at high volume. If responders approve it without reading because it appears fifty times a day, the design has already failed; reduce the source volume or narrow the permitted action rather than treating rapid clicks as control. Session authorization fits repeated calls when the human can make a meaningful decision about the process and scope once. Good candidates have a bounded lifetime, predictable channel, visible identity, immediate revocation, and an audit record detailed enough to reconstruct individual calls. The session must not turn into an all-day bearer grant passed between unrelated processes. A hybrid decision is often correct. Put routine API reads and known deployment checks inside a process-bound session. Retain per-use approval on the small set of keys that can mutate production or administer credentials. This lowers interruption volume while keeping a deliberate stop where a single action changes the risk. Do not justify per-use confirmation by saying more prompts always mean more safety. A control that people approve reflexively has high ceremony and weak discrimination. The useful question is whether the prompt causes a different decision often enough to pay for its loaded cost. ## Measure one production week before changing scope A one-week sample is usually enough to replace guesses with a credible range, provided it includes normal production work and at least one busy period. Do not manufacture an incident for the measurement. Export prompt events, ask responders to record recovery for a small sample, and keep the worksheet simple enough that someone will finish it. Use one row per responder per day: ```text date | responder | prompts_seen | prompts_allowed | prompts_denied | median_response_s | focus_share | median_recovery_s | sessions_started | median_session_approval_s 2026-07-21 | dev-3 | 11 | 10 | 1 | 12 | 0.70 | 90 | 2 | 15 ``` Calculate these cells: ```text loaded_per_use_min = prompts_seen * (median_response_s + focus_share * median_recovery_s) / 60 session_min = sessions_started * median_session_approval_s / 60 break_even_prompts = sessions_started * median_session_approval_s / (median_response_s + focus_share * median_recovery_s) ``` Then inspect prompts by key class. A team total can tell you that change is warranted, but the class breakdown tells you what to change. If 80 percent of prompts come from read-only status checks and the few denied requests concern production mutation, moving every key to one mode would discard the most useful part of the evidence. Record one reason for each denial in plain categories such as wrong target, unexpected operation, duplicate, or insufficient context. Free-form incident essays make aggregation painful. The reason distribution reveals whether the gate catches dangerous requests or compensates for confusing prompts. Recovery sampling does not need surveillance. Ask each responder to mark `0`, `30`, `90`, or `180+` seconds for a subset of prompts, or infer resumption from a local work trace they control. Publish the method with the result. A rough observed distribution is better than an invented constant carried to two decimal places. Before changing authorization, write the prediction: which prompt classes will disappear, how many session approvals will replace them, and which per-use gates will remain. Measure the following week using the same fields. If call volume rises because agents can proceed without waiting, compare human decisions rather than raw API requests. ## Spend confirmation where it can change a decision The model should produce a routing decision, not one global threshold. For each key class, compare loaded per-use minutes with session approval minutes, then write the consequence of one extra call during an approved session. Routine classes with a wide cost gap and a tolerable session consequence can move. High-impact classes stay per-use even when their time cost is obvious. Set a review trigger based on observed behavior. Recalculate when prompt volume doubles, the responder group changes, session length changes, or the denial reasons shift. A threshold copied from another team is nearly useless because recovery time and fan-out differ more than click time. The control system must preserve evidence after the scope changes. Log the session start, the identity approved, revocation, and every individual call. Otherwise session authorization buys time by removing the very trail needed to investigate what the agent did. Verify that the audit history can expose deletion or alteration without depending on the agent that produced the actions. Sallyport implements this split as a fixed ladder: a locked vault denies every action, a new agent process receives one session decision by default, and selected keys can still demand approval on every use. Its Sessions and Activity journals keep run-level and call-level records, so changing confirmation scope does not erase individual actions. Do not set the threshold in a meeting by asking what feels annoying. Put seven days of prompts into the equation, keep the units visible, and separate routine calls from calls whose facts alter the decision. Keep the raw worksheet with the decision so the team can challenge the assumptions later. When a person has approved the same bounded authority dozens of times without a denial, another identical card is not preserving judgment. It is consuming it.