Five AI products shipped or advanced in the last two weeks. Each places a specific demand on your time and cognitive availability, and none of them helps you estimate that demand before you commit.
Compute is metered. These products can tell you what a call cost in tokens and dollars. What they can't tell you is what it cost you to stay available while the call ran. This issue is about that gap.
Astra Fast sells speed it can't guarantee
OpenAI's GPT-6 Astra introduced a paid Fast mode: twice the cost, "up to" twice the speed, and the developer guide states plainly that there is no latency SLA. You pay a premium for a speed improvement that cannot be converted into a time commitment.
That matters more than it would for a chat model, because Astra is built for multi-step work: tool use, browser interaction, steering the model mid-turn. The developer guide hands you real intervention capability. You can redirect during a turn, update configuration while work is in progress, let the model ask non-blocking questions. Those are controls that assume you're watching.
What's absent is guidance on when you can stop watching: no completion estimate, no marked safe departure point, no description of the summary you get when you come back. Full-stack developer Ewan Mak made the point that actually bites: inference speed is not workflow speed. The tools, screenshots, verification steps, and caching wrapped around each model call may dominate elapsed time. The economic unit is the completed task, not the last inference call.
The attention obligation: open-ended availability. You've committed money. You can't derive a time commitment from it, and the product won't help you estimate one.
Confidence: high. This is visible in the public documentation. The absence of completion-window guidance is a fact, not an inference.
Fable 5.1 designed the updates, not the schedule
Anthropic's Fable 5.1 reasoning summaries could easily be dismissed as uninterpretable telemetry, but with thinking.display: "updates" enabled, the model emits short summaries written for someone watching the work rather than for someone debugging the model. The prompting guide recommends rendering each update as a status line and asking for a closing recap. That recap is a limited but real re-entry affordance: something you can read when you come back.
The updates themselves are interpretable. The problem is cadence. Anthropic's own documentation warns that the model may skip an update, batch several together, pause for seconds at a stretch, or go quieter during long tool chains. The tasks where you most need to know what's happening are the ones most likely to go silent.
This is harder to manage than Astra's obligation. You can understand every update that arrives, but you cannot count on one arriving at the moment intervention would matter. The documentation defines no signal for an irreversible next action and no way to tell "the model is thinking and will update shortly" from "the model has already moved past a decision you would have wanted to review."
Anthropic designed the content of the updates well. What's left undesigned is the attention contract around them: when your presence is required versus optional, and how you would know which one you're in.
The attention obligation: intermittent monitoring on an unreliable cadence.
Confidence: high on the cadence gap, since the documentation describes the unreliability itself. Moderate on the claim that longer tasks produce systematically fewer updates. It's stated in the docs, but I've seen no quantified data behind it.
Enterprise Frontier Safeguards create a staffing problem they don't scope
EFS was announced September 1 and hasn't broadly shipped. Phased rollout is planned for later this fall. The shape of its attention obligation is already legible.
The system runs automated rolling-window reviews of model activity, stored under the customer's own cloud account with customer-controlled encryption. When it flags something, the alert routes to customer-designated reviewers. Anthropic employees don't see the data. The customer's people decide whether the event is misuse or a false positive, and then, in Anthropic's phrasing, "take it from there."
Two qualifiers. EFS is opt-in, and the automated review component is separately opt-in inside EFS, so "mandatory review" overstates it. The obligation is mandatory only once you've opted in and the system has flagged something. And Anthropic charges no EFS fee. Customers pay their own cloud costs for storage and transfer.
The obligation is real anyway, because nobody has sized it. The announcement publishes no expected alert volume per account, no false-positive rate, no estimated reviewer minutes per flag, no escalation rate, no triage SLA. Musthave.AI founder Abdessalam Alaoui put the cost in the right place:
"Cheap storage can support an expensive queue."
The operational measures he proposes — cost per reviewed alert, reviewer minutes per thousand model interactions, escalation rate, time to contain — are precisely what a customer would need to staff the function. None of them appear in the public materials.
The attention obligation: review work at unknown volume. You know who reviews and where the data lives. You don't know how much review the system will generate, how much of it will be noise, or what "take it from there" costs in analyst hours. You're being asked to build a team for a workload that hasn't been characterized. Making it staffable would take exactly the numbers Alaoui names: alert volume relative to model usage, false-positive rates by flag type, reviewer minutes per flag. Until those exist, from Anthropic or from early adopters' operational data, the review obligation is real and unplannable.
Confidence: high on the scoping gap. The absence of volume and false-positive metrics is a fact. Speculative on why: Anthropic may hold these numbers internally from its 100+ pilot customers and have chosen not to publish, or the system may not yet have run at enough scale to produce them.
MCP cancellation stops at acknowledgment
The Tasks extension to MCP — the Model Context Protocol, the open standard governing how agents call external tools — stabilized its schema August 24. The cooperative cancellation pattern works like this. You send a tasks/cancel request. You get back an empty acknowledgment. The server may hold the task in a working state, may eventually return a terminal state other than cancelled, and is under no obligation to halt immediately.
The specification gives you task-status polling and status-message notifications. It gives you no inventory of what the task created before you cancelled: files written, external API calls made, messages sent, credentials used, reservations placed. You can check whether the task eventually reported itself cancelled. You cannot check what it left behind.
I covered this pattern in Issue #8 as a negotiated interruption, and again in Issue #9, where the delegation envelope's Revocation Sequence separated the cancellation request from settlement and surfaced residual obligations. As of today, the specification still doesn't standardize residual-effect reporting. The official C# sample polls until a terminal state appears and produces no residual-effect inventory. The MCP Inspector exposes cancel requests and status polling, not containment verification.
The attention obligation: post-action verification with no way to verify. You asked the system to stop. The system acknowledged the request. Confirming that the external world reflects the stop is now your job, and the protocol gives you no standard means to do it.
Confidence: high. The specification is public. The distance between cancellation acknowledgment and residual-effect reporting is structural, not a documentation oversight.
Gemini 3.8 Flash explains the setting without telling you when to use it
Google's Gemini 3.8 Flash exposes an effort control: an API parameter called thinking_level, set to low, medium, or high. Google does better here than shipping a bare knob. The documentation attaches each level to recognizable workload types — incident-response pipelines at low, complex coding at medium, deep multi-step reasoning at high — and names the latency-cost-quality tradeoff outright. Developers can also read thinking-token consumption from API usage metadata after a call completes.
The parameter is still model-facing. Nothing in the documentation translates thinking_level into terms a person on the other end of the product would recognize: deadline pressure, stakes of error, reversibility of the output, budget ceiling. The position in Issue #8 was that the user specifies consequences and the system handles parameters. Contextualizing the parameter with task examples is a partial step toward that. It still leaves the developer to bridge from model vocabulary to user vocabulary unaided.
The attention obligation: a configuration decision that determines someone else's experience, made without guidance for matching it to that experience. The developer picks an effort level that sets how long the user waits, what quality they get, and what it costs. The docs explain what each level does to the model. They don't explain how to match a level to a given user's situation.
Confidence: high. The task examples and tradeoff descriptions are more than most vendors ship. The absence of user-facing translation guidance is a fact in the representative documentation I checked.
What this adds up to
These are well-engineered products. The attention costs they generate — hours of presence for Astra, sustained monitoring for Fable, review labor for EFS, verification work for MCP, a judgment call for Gemini that determines someone else's wait — sit in a layer none of them addresses.
Practitioner commentary this cycle arrives at the same place from two directions. Alaoui moves EFS cost from infrastructure to labor. Mak moves Astra speed from model performance to workflow time. In both cases, the number the vendor publishes is not the number the user pays in time or effort.
What's needed and largely absent: surfacing expected time commitments, signaling when presence is required versus optional, reporting what happened while you were away, confirming that disengagement is safe. There is no pattern library for this work and no standard practice around it yet.
Build Queue priorities this cycle
Inference-Aware UX is the most urgent domain. Three of the five developments here — Astra, Fable, Gemini effort controls — create attention obligations that come directly from inference behavior the user can't see or predict. The artifact gap is translation: turning model-level uncertainty about duration, update timing, and effort settings into commitments a user can plan around. The effort-control problem from Issue #8, consequences rather than parameters, is the concrete entry point.
Agent Infrastructure as UX stays second. Advanced, not resolved. MCP's cooperative cancellation is now stable. The containment-verification gap identified in Issues #8 and #9 is unchanged. The delegation envelope's Revocation Sequence already specifies the pattern; the protocol lacks the residual-effect reporting that would make it implementable. Status is the same as last cycle, but stabilization makes the gap easier to argue: this is a settled specification with a known missing layer rather than a moving target.
Human-Agent System Design enters the queue through EFS. A system that generates human work at unspecified volume is a team-design problem before it's an interface problem. It needs workload characterization, staffing models, triage design. That's new territory for the Build Queue. Scope it before the fall rollout, because the organizations that adopt EFS early will write the operational playbook everyone else copies.
- Astra's monitorability gap: OpenAI's safety overview reports lower chain-of-thought monitorability for Astra than GPT-5.6, meaning the model whose attention demands are hardest to scope is also the one whose internal reasoning is hardest for the provider to supervise.
- Agent coordination through shared infrastructure: OpenAI's August incident report describes experimental agents using shared Artifactory files as a coordination channel during cyber evaluations, which grounds the MCP residual-effect problem in observed behavior rather than theoretical risk.
- Gartner's workflow cost forecast: Gartner predicts inference cost per agentic workflow will increase more than fivefold through 2028 even as unit prices fall, because cheaper tokens encourage longer chains and more model calls — the aggregate version of the per-task attention accumulation covered here.
- Anthropic's Model Hardware Standard: Anthropic's research preview lets agents discover, sequence, and adjust laboratory-device operations through a shared interface, extending the attention-obligation question from digital residual effects to physical ones where reversal may be impossible.