DEV Community: Ahab

GPT-6 Astra API migration checklist: budget accepted runs and keep agent authority fail-closed

Ahab — Fri, 04 Sep 2026 10:05:41 +0000

GPT-6 Astra API migration checklist: budget accepted runs and keep agent authority fail-closed

Quick answer

GPT-6 Astra is not a reason to replace every production route at once. OpenAI identifies the API model as gpt-6-astra, supports reasoning levels from low through max, and lists Standard API pricing of $10 per million input tokens and $50 per million output tokens. Its launch is staged, so first prove that your project can make a minimal request before planning a migration.

The safe unit of change is one route with one acceptance fixture. Pin the current model, set a whole-run budget, test tool authority separately from answer quality, then promote only if accepted-run economics improve. This is part two of the GPT-6 Astra series: part one separates ChatGPT, API, and enterprise access; this page is about an API route that is already eligible to test.

Who this is for

Use this when you operate an API-backed coding helper, research workflow, support classifier, or agent route and want to trial GPT-6 Astra without widening permissions or silently multiplying spend. It is not a claim that a visible ChatGPT picker grants API access, nor that a successful request means a production migration is complete.

If your immediate failure is a 429 or account ceiling, use the OpenAI API hard-spend-limit runbook before changing models.

What changes the migration plan

OpenAI's model page lists a 1,050,000-token context window, 128,000 maximum output tokens, and reasoning efforts low, medium, high, xhigh, and max. These are capacity settings, not a recommended default configuration. A longer prompt, higher effort, tool loop, retry, and large output can all contribute to the cost of the one result your user accepts.

The launch page also describes Fast mode as up to twice Standard speed at twice Standard price. Treat it as a route-level latency option, never as a blanket migration setting. The model is designed for complex multi-step work, but model capability does not authorize a file write, network request, purchase, or customer-facing action in your product.

Make one migration record

route: repo-fix | research-brief | support-triage
candidate_model: gpt-6-astra
baseline_model: pinned-current-model
fixture_id: stable-and-non-sensitive
reasoning_effort: medium
input_cap: 120000
output_cap: 12000
tool_call_cap: 8
retry_cap: 1
timeout_seconds: 180
write_authority: human-approval-required
accepted_result: explicit pass/fail rule
rollback_trigger: cost | latency | policy | quality threshold

Do not leave accepted_result as “looks better.” For a coding route, define tests that pass, files that may change, and a reviewer rubric. For research, define required sources, prohibited claims, and a citation check. For support, define label accuracy, escalation behavior, and a red-team fixture. The same fixture must run against the baseline and Astra with the same system instruction, retrieval, tools, timeout, and output cap.

A five-step migration

1. Prove access with a tiny, non-sensitive call

Record the model ID, provider, timestamp, response status, and sanitized usage metadata. Do not put customer data in an availability test. If the call is rejected, stop: an announcement, another account, or ChatGPT access is not a workaround for that API project.

2. Set a whole-run cost ceiling

For Standard model tokens, estimate the model portion before running a canary:

upper_bound = input_tokens / 1,000,000 × $10
            + output_tokens / 1,000,000 × $50
            + applicable cache and tool charges

Then add retry and tool-loop limits. A model-only token estimate is not an invoice and does not prove total product cost; it is a guardrail for deciding whether the route may continue. Keep Fast mode off until the accepted result needs its latency benefit.

3. Choose effort from evidence

Start at medium for a multi-step fixture. Move down when the result passes unchanged; move up only when a defined failure is fixed and the accepted-run cost remains below the ceiling. Do not compare max reasoning against a low-effort baseline and call the difference a model improvement.

4. Test authority as its own gate

Run five controlled cases: one read-only tool call, one malformed argument, one denied action, one timeout, and one action requiring human approval. The expected outcome for denied, malformed, and approval-required work is safe refusal or escalation—not creative completion. Keep irreversible writes outside the model's direct authority even if the quality fixture passes.

5. Promote by accepted-run economics

For each run, record acceptance, latency, input/output usage, tool calls, retries, human repair minutes, and policy failures. Promote one low-risk route, then 5%, 25%, and 100% only if every threshold holds. A higher-quality draft that requires more repair or violates a policy is not an accepted win.

Decision tree

Can the target project call gpt-6-astra?
  ├─ No → retain baseline; resolve access separately
  └─ Yes → run the pinned fixture with explicit effort and caps
       ├─ quality fails → keep baseline; diagnose fixture or prompt
       ├─ cost/latency fails → reduce caps or keep route on baseline
       ├─ authority test fails → fix policy; do not promote
       └─ all gates pass → low-risk canary with rollback trigger

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Treating a single API 200 as an approved migration.
Using the context maximum as a normal prompt budget.
Raising effort and enabling Fast mode before defining a route ceiling.
Measuring impressive output instead of accepted outcomes and repair time.
Letting a stronger model gain broader tool or write authority.

FAQ

Should GPT-6 Astra replace my default model now?

Only after the target project has verified API access and a pinned fixture passes quality, budget, authority, and rollback gates. OpenAI's rollout is staged.

What effort should I start with?

Use the lowest setting that passes a fixed test. medium is a practical initial point for multi-step work; evidence, not model prestige, should justify higher effort.

Does a better answer justify an authority failure?

No. Tool authority is an independent safety boundary. Fix the policy and rerun the controlled cases before promotion.

Sources

GPT-6 Astra rollout checklist: separate ChatGPT access, API access, and enterprise controls

Ahab — Fri, 04 Sep 2026 07:13:28 +0000

GPT-6 Astra rollout checklist: separate ChatGPT access, API access, and enterprise controls

Quick answer

OpenAI introduced GPT-6 Astra on September 3, 2026, but the release is a rollout—not a single switch. At launch, Astra is reaching a limited set of organizations; OpenAI says ChatGPT Plus, Pro, Business, and Enterprise access, plus API, Azure, and AWS Bedrock access, will follow over coming days. Enterprise access is off by default and an administrator can enable it. The API model ID is gpt-6-astra.

That means “GPT-6 is available” is not sufficient evidence for a team decision. Before changing a default, identify the surface you need, prove that the intended account can use it, budget its token and tool use, and keep a pinned fallback for a specific route. This guide gives you one record and six checks for doing that without confusing a model announcement with access in your workspace.

Who this is for

This is for an indie developer, team lead, or workspace administrator deciding whether GPT-6 Astra belongs in a ChatGPT workflow, an API-backed product, or an enterprise agent route. It is deliberately not a claim that every paid ChatGPT user can select Astra today.

If your immediate problem is an API spending ceiling rather than a new-model rollout, start with the OpenAI API hard-spend-limit runbook. If your team is selecting among the current Codex models, the GPT-5.6 Sol, Terra, and Luna guide is a separate, product-specific decision.

What OpenAI confirmed

Boundary	Confirmed by OpenAI	What you still need to prove
Model name	GPT-6 Astra	Do not call it “ChatGPT 6” as though every ChatGPT account already has it
API identity	`gpt-6-astra`	Your project, API key, region, and account can actually create a request
ChatGPT rollout	Limited organizations first; Plus, Pro, Business, and Enterprise follow over coming days	Your plan, region, workspace, and model picker currently expose it
Enterprise control	Admins can enable Astra; access is off by default at launch	The correct administrator enabled it for the target workspace and policy allows use
Context and output	1,050,000-token context window; 128,000 maximum output tokens	Your application limit, timeout, and retrieval design keep requests inside safe bounds
Reasoning	`low`, `medium`, `high`, `xhigh`, and `max` are supported	Your route has an explicit effort setting and a measured budget
Standard API price	$10 per million input tokens and $50 per million output tokens	The accepted task cost, cache behavior, tool calls, and retries remain inside your budget
Fast mode	Up to 2x Standard speed at 2x Standard price	The latency improvement is worth the route-level cost increase

The context limit is capacity, not a request to send a million tokens by default. A long prompt, long output, high reasoning effort, tool loops, and retries can make the first successful result much more expensive than a small model-picker comparison suggests. Use the model page and pricing page as the contract; use your own accepted runs as the cost evidence.

Use a three-surface access record

Keep ChatGPT, API, and enterprise policy as separate fields. A positive check in one column is not a substitute for another.

checked_at: 2026-09-04T09:00:00+08:00
route: support-triage | coding-agent | research
chatgpt:
  plan: Plus | Pro | Business | Enterprise
  model_picker_visible: true | false
  workspace: personal | named-workspace
api:
  model_id: gpt-6-astra
  request_accepted: true | false
  region_or_provider: OpenAI | Azure | AWS Bedrock
enterprise:
  admin_enabled: true | false | not_applicable
  policy_allows_route: true | false
runtime:
  reasoning_effort: low | medium | high | xhigh | max
  fallback_model:
  max_input_tokens:
  max_output_tokens:
  max_tool_calls:
  max_retries:

Record failures too. “Not in the model picker,” “API model unavailable,” and “admin setting disabled” identify different owners and different next actions. Do not route around an enterprise disablement with a personal account just to make a test pass.

A six-gate rollout

1. Choose one outcome, not one prestige model

Pick a route with a measurable acceptance test: a fixed repository issue, a research brief with required citations, or a support-triage fixture. Define what counts as an accepted result before you test the new model.

2. Establish access before changing defaults

For ChatGPT, capture the plan, workspace, and model-picker state. For the API, send a minimal non-sensitive test and store the model ID, timestamp, provider, request result, and sanitized usage metadata. For an enterprise workspace, capture the administrator-controlled setting and policy outcome. Never treat a public announcement as account-level availability.

3. Pin a baseline and make effort explicit

Keep your existing production model as the control. Test the same fixture with the same retrieval, system instructions, tools, timeout, and effort level. Start with medium for ordinary multi-step work; reserve high, xhigh, and max for routes whose accepted-result benefit justifies the added budget.

4. Put a budget around the entire run

Set maximum input, output, tool calls, retries, wall-clock time, and route-level spend. A simple upper-bound estimate for Standard API traffic is:

estimated_model_cost = (input_tokens / 1,000,000 * $10)
                     + (output_tokens / 1,000,000 * $50)
                     + cache and tool charges where applicable

Fast mode changes both the speed and the price multiplier. Do not enable it globally because one interactive route needs lower latency.

5. Test authority separately from capability

OpenAI describes Astra as strong for complex multi-step work, coding, browsing, computer use, research, and document creation. That does not grant it broader authority in your product. Test one read-only tool call, one malformed call, one denied action, one timeout, and one action that requires human approval. Keep irreversible writes behind the same policy boundary you used before the model change.

6. Promote by accepted-run economics

Compare accepted results, not attractive demos. For each fixture, record model cost, retries, human repair minutes, latency, tool calls, policy failures, and whether the outcome passed. Promote one low-risk route first, then 5%, 25%, and 100% only when your thresholds hold. Roll back to the pinned baseline when they do not.

Decision tree

Need a new GPT-6 Astra route?
  ├─ No verified access on this surface → wait; do not claim rollout completion
  ├─ Enterprise workspace disabled → ask the workspace admin; do not bypass policy
  ├─ API accepts a minimal test → run fixed fixture against a pinned baseline
  │    ├─ accepted result and route budget pass → low-risk canary
  │    └─ cost, latency, or policy boundary fails → keep fallback and investigate
  └─ ChatGPT picker visible only → use it for manual evaluation, not as API evidence

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Writing “ChatGPT 6 is live” when the official statement is a staged GPT-6 Astra rollout.
Treating a ChatGPT model-picker option as proof that an API project or enterprise workspace has access.
Increasing reasoning effort and enabling Fast mode before setting route-level cost limits.
Comparing a long, tool-enabled Astra task with a short baseline task.
Turning a stronger model into broader file, network, or write authority.
Reporting a successful test request as a production rollout.

FAQ

Is GPT-6 Astra generally available today?

No universal availability claim is supported by the launch material. OpenAI describes a limited-organization rollout first, with broader access for named ChatGPT plans and API providers following over coming days. Check the surface you intend to use.

Is GPT-6 Astra the same thing as ChatGPT 6?

GPT-6 Astra is the official model name. ChatGPT is one product surface in the rollout; API, Azure, Bedrock, and workspace administration have separate availability and control boundaries.

What does it cost in the API?

OpenAI lists Standard pricing at $10 per million input tokens and $50 per million output tokens. Cache and tool-related charges can be separate, and Fast mode is priced at twice Standard according to the launch page.

Should I use `max` reasoning effort by default?

No. Start from the lowest effort that passes your fixed acceptance test and compare accepted-run cost, latency, and reliability before raising it.

Sources

Gemini 3.8 Flash is Antigravity's default: audit agent cost and tool loops before rollout.

Ahab — Thu, 03 Sep 2026 10:16:51 +0000

Originally published at IndieSeek.

Gemini 3.8 Flash is Antigravity's default: audit agent cost and tool loops before rollout

Quick answer

Google released gemini-3.8-flash as a generally available Gemini API model on September 2, 2026. It supports a 1,048,576-token input window, up to 65,536 output tokens, multimodal input, function calling, structured output, code execution, caching, and Computer Use in preview. Google also changed the Antigravity managed agent and its SDK to use Gemini 3.8 Flash by default.

That default change is the operational risk. An unchanged agent identifier can now produce a different number of reasoning steps, tool calls, tokens, and retries. Google explicitly says 3.8 Flash may use more tokens on long, complex tasks by design. Before accepting the new default, record the effective model configuration, set a thinking level per route, cap the loop, and compare accepted-run cost against an explicitly pinned 3.7 baseline.

Who this is for

This guide is for indie developers and platform teams using Gemini Managed Agents, the Antigravity SDK, or a direct Gemini API agent loop. It focuses on a default-model change, not a generic benchmark contest.

If you are migrating direct requests and need a broad model comparison, start with the Gemini 3.7 vs 3.6 migration checklist. For high-volume routine work, the Flash vs Flash-Lite routing guide remains the cheaper-task decision layer.

What changed—and what did not

Boundary	Confirmed state	Operator consequence
API model	`gemini-3.8-flash` is GA	Pin this exact ID for a direct-API canary
Managed agent	Antigravity now uses 3.8 Flash by default	Re-test even when the agent name did not change
Thinking	`low`, `medium`, `high`; `medium` is default	Configure it explicitly; `minimal` returns an error
Long tasks	More reasoning and iterative verification can consume more tokens	Budget the whole run, not one request
Standard price	$0.75 input / $3.75 output per 1M tokens through 2026-12-31	Same list rate as 3.7 does not guarantee the same run cost
2027 price	$1.50 input / $7.50 output from 2027-01-01	Recalculate every production budget before the date boundary
Tool surface	Function calling, code execution, file/search tools, and preview Computer Use are supported	Re-run tool contracts and safety gates
Live API	Not supported	Keep real-time voice or streaming routes on a supported model

Output pricing includes thinking tokens. A run with 100,000 uncached input tokens and 20,000 output tokens, including thinking, costs about $0.15 at the introductory Standard rate and $0.30 from January 1, 2027, before grounding or cache-storage charges. The formula is simple; predicting the token counts is not.

Separate identity, effort, and authority

Treat the rollout as three independent controls:

Identity: which model the direct request or managed-agent configuration resolves to.
Effort: which thinking level, token usage, retries, and tool rounds the run consumes.
Authority: which tools, files, network destinations, and irreversible actions the agent can reach.

A stronger model does not reduce the need for a sandbox or approval boundary. Keep untrusted repositories behind the AI coding-agent sandbox checklist, especially when Computer Use is enabled.

Build a shadow-run ledger

Choose five representative tasks: one focused code fix, one multi-file refactor, one search-and-summarize job, one recoverable tool failure, and one task that must stop before an external write. Run each against the Antigravity default and a 3.7-pinned control where the supported configuration allows it.

Keep the task fixture, repository revision, instructions, tools, network policy, timeout, and acceptance tests identical. Record this per run:

agent_id: antigravity
configured_model: default | gemini-3.7-flash | gemini-3.8-flash
observed_at: 2026-09-03T18:00:00+08:00
thinking_level: low | medium | high
input_tokens:
output_and_thinking_tokens:
cached_input_tokens:
tool_calls:
repeated_tool_calls:
wall_time_seconds:
accepted: true | false
human_repair_minutes:
side_effect_attempted: false

If the runtime does not expose a resolved model field, do not invent one. Preserve the configured agent_config, request timestamp, SDK version, and response metadata that is actually available, and label the effective model as inferred from Google's documented default.

A six-gate rollout

1. Freeze the baseline

Save the current agent configuration, Gemini SDK version, tool schemas, safety policy, retry policy, and five-task fixture revision. Keep the 3.7 route available for rollback.

2. Make thinking explicit

Use low for latency-sensitive classification or retrieval, medium for ordinary coding and agent tasks, and high only for the hardest multi-step work. Add a negative test proving minimal fails rather than silently mapping it.

3. Cap the loop

Set maximum wall time, model turns, tool calls, repeated identical calls, and total token or spend allowance. Stop when the agent repeats the same failed action, not when the account-wide budget is exhausted.

4. Verify tool contracts

Test one valid tool call, one schema error, one timeout, one permission denial, and one irreversible action that requires a human. Computer Use remains preview; do not let a model upgrade convert a read-only canary into a production desktop session.

5. Compare accepted-run economics

Use accepted_run_cost = model cost + retry cost + human repair cost. Because 3.8 and 3.7 share the same current list rates, a higher 3.8 token count may still win if it removes retries—or lose if extra verification adds no accepted result.

6. Promote with a dated budget

Ramp one low-risk route, then 5%, 25%, and 100%. Require acceptance, latency, repeated-call rate, policy compliance, and cost to stay inside limits. Store both the current rate and the January 1 rate in the decision record so the rollout cannot rely on promotional pricing forever.

Canary matrix

Canary	Pass condition
Default identity	Configuration and timestamp prove whether default or pinned routing was used
`minimal` thinking	Request fails visibly; router does not retry forever
Recoverable tool error	Agent corrects once and completes inside the call cap
Repeated tool loop	Circuit breaker stops the run with a clear reason
Irreversible action	Human approval is required before the side effect
Live route	Unsupported Live API path stays on its existing supported model
Cost boundary	Ledger calculates both 2026 and 2027 rates
Rollback	Pinned 3.7 control can still complete the baseline fixture

Copyable decision record

owner / date / route:
agent_id / sdk_version / configured_model:
baseline_model / candidate_model:
fixture_revision / tool_schema_revision:
thinking_levels_tested:
accepted_runs / total_runs:
input / cached / output-plus-thinking tokens:
tool_calls / repeated_calls / retries:
intro_rate_cost / 2027_rate_cost:
human_repair_minutes / policy_violations:
promotion: hold | 5% | 25% | 100% | rollback
rollback_model / rollback_trigger:

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Assuming an unchanged Antigravity agent ID means the underlying model did not change.
Comparing 3.8 high with 3.7 medium and calling the result a model improvement.
Looking only at per-token price while ignoring thinking tokens, retries, and tool loops.
Sending minimal, then hiding the validation error behind unbounded retries.
Treating Computer Use preview as permission to remove human approval.
Forgetting that the published Standard rate doubles on January 1, 2027.

FAQ

Is Gemini 3.8 Flash generally available?

Yes. Google's September 2 Gemini API release notes identify gemini-3.8-flash as GA.

Is 3.8 more expensive than 3.7 per token?

Their published Standard, Batch, Flex, Priority, caching, and storage rates currently match. Actual run cost can differ because token use, tool calls, retries, and acceptance can differ.

Can I keep Antigravity on 3.7?

Google's Agents documentation says the underlying model can be configured, including Gemini 3.7 Flash. Verify the currently supported agent_config shape in your SDK and keep the pin as a rollback control.

Does Gemini 3.8 Flash support the Live API?

No. The model page lists Live API as unsupported. Route real-time workloads separately.

Sources

Claude Code 2.1.259 managed MCP servers: keep unattended headless runs fail-closed.

Ahab — Thu, 03 Sep 2026 01:24:15 +0000

Originally published at IndieSeek.

Claude Code 2.1.259 managed MCP servers: keep unattended headless runs fail-closed

Quick answer

Claude Code 2.1.259 adds two controls that fit the same automation problem. Organizations can distribute remote HTTP or SSE servers through the managed managedMcpServers setting, and unattended headless hosts can use --permission-prompts none so an action that would have opened a prompt is denied instead. The active permission mode—including Auto mode—still makes its normal decisions first.

Do not treat either control as blanket approval. Managed MCP distribution decides which server definitions arrive; permission policy decides which tools may run; --permission-prompts none only changes the final prompt fallback. Roll out all three layers separately, record the effective configuration, and make a denied write the success case for your first canary.

Who this is for

This guide is for platform teams and indie developers running Claude Code from CI, scheduled jobs, remote workers, or an SDK host where nobody can answer a terminal prompt. It assumes you need a small approved set of internal remote tools without giving every job ambient authority.

If you first need to reduce what a shared-machine evaluation can reach, read the Claude Code restricted-mode checklist. If your risk is broad shell matching, use the Bash wildcard permission audit. Neither replaces MCP server identity, credentials, or tool-level permission rules.

What changed in 2.1.259

Anthropic published Claude Code 2.1.259 on September 2, 2026. The stable release adds managedMcpServers as a managed setting. Administrators can supply remote HTTP/SSE entries using the same entry shape as .mcp.json; entries that name a local command are skipped. That transport boundary matters: this new setting is not a way to distribute arbitrary stdio launch commands.

The release also adds --permission-prompts none for unattended headless hosts. When the active permission mode cannot approve or deny an action and would normally ask a person, Claude Code denies it automatically. This is different from bypassPermissions, and it does not convert an Ask rule into an Allow rule.

Two adjacent changes deserve migration tests. A malformed managed-settings source now makes Claude Code refuse to start and names the invalid source. Also, allowedMcpServers now governs only servers users add. If an older allowlist had been filtering a literal managed-mcp.json server, that server can load after upgrade; Anthropic directs administrators to deniedMcpServers when it must remain blocked.

The release tag resolves to commit f173a697aa6486945f1b9c4aa9ce5383d2c87db6. The local client used for this article was still 0.2.36, so the configuration below is an operator-ready rollout design derived from the official 2.1.259 release and current docs, not a claim that this machine executed the new binary.

Separate the three control planes

Control plane	Primary question	Safe evidence
Server delivery	Which remote MCP definitions reach the session?	Effective managed source, exact URL, connection status
Tool authority	Which server tools can be invoked?	Deny/ask/allow rules, permission mode, credential scope
Prompt fallback	What happens when a decision still needs a person?	Allowed call proceeds; prompt-required call is denied, never hung

This model prevents a common mistake: seeing an MCP server connected and assuming its tools are approved. Connection is inventory, not authorization. A token also has its own server-side scope, so an allowed tool with an overpowered credential can still be too broad.

Build a minimal managed remote set

Start with one read-only remote server in managed settings. The new setting uses .mcp.json-style server entries:

{
  "managedMcpServers": {
    "incident-readonly": {
      "type": "http",
      "url": "https://mcp.example.com/readonly"
    }
  },
  "permissions": {
    "allow": ["mcp__incident-readonly__get_status"],
    "deny": ["mcp__incident-readonly__mutate_*", "Bash"]
  }
}

Treat this as a shape template, not a copy-paste production secret. Put authentication in the supported credential mechanism, scope the server token to read-only, and verify the effective settings on the exact host image. Managed file paths are /Library/Application Support/ClaudeCode/managed-settings.json on macOS, /etc/claude-code/managed-settings.json on Linux/WSL, and C:\Program Files\ClaudeCode\managed-settings.json on Windows.

A six-step unattended rollout

1. Snapshot the old effective state

Record the Claude Code version, managed-settings source, any managed-mcp.json, every allowed or denied MCP identity, permission mode, server credential scope, and the runner image digest. Keep the old binary and configuration together as one rollback unit.

2. Reconcile the allowlist semantic change

For every server in managed-mcp.json, ask whether an existing allowedMcpServers entry was the only reason it stayed off. Add an explicit deniedMcpServers identity before upgrading when the answer is yes. Prefer URL or command identity over display name for enforcement.

3. Validate managed delivery interactively

Upgrade one disposable host. Confirm startup succeeds, the correct managed source is visible, local-command entries are skipped, only the expected HTTP/SSE server connects, and no user or project setting widens the result. Intentionally break a copy of the managed file and verify startup refuses with the source named.

4. Prove tool-level permissions

Run one allowed read, one denied write, one unknown tool, and one call that would normally ask. Preserve the tool name, sanitized input, permission decision, server response class, and session ID. Do not record credentials or sensitive response bodies.

5. Add the no-prompt fallback

Run the headless job with --permission-prompts none only after the interactive matrix passes. Use structured output and inspect the initial system event. Current Headless documentation exposes mcp_servers plus mcp_server_errors; fail CI when the error array is non-empty rather than accepting a clean process exit with a missing server.

claude -p \
  --permission-prompts none \
  --output-format stream-json \
  --verbose \
  "Read the incident status and make no changes"

6. Promote from a recorded acceptance matrix

Canary	Expected result
Approved remote read tool	Runs and returns the expected schema
Write tool matched by deny	Blocked before side effect
Tool that would prompt	Denied automatically; job does not hang
Invalid managed settings	Client refuses to start and identifies the source
Command-based `managedMcpServers` entry	Skipped; no local process launches
Disconnected server during tool listing	Startup reports the error, not an empty connected server
Non-allowlisted user-added server	Follows the new user-added allowlist policy
Explicitly denied fixed managed server	Remains blocked after upgrade

Promote one runner group at a time. Roll back the no-prompt flag first if observability is insufficient, then the managed server set, then the binary. Never replace a deny with automatic approval just to keep a scheduled job green.

Copyable acceptance record

claude_code_version: 2.1.259
release_tag_commit: f173a697aa6486945f1b9c4aa9ce5383d2c87db6
managed_source: file
managed_remote_servers: [incident-readonly]
local_command_entries_loaded: false
permission_mode: default
permission_prompts: none
credential_scope: read-only
mcp_server_errors: []
allowed_read_passed: true
denied_write_blocked: true
prompt_required_denied: true
fixed_server_deny_migration_checked: true
rollback_binary_available: true

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Treating a delivered MCP definition as permission to use every tool.
Putting a local command entry under managedMcpServers and assuming it launched.
Using --permission-prompts none as if it were bypassPermissions.
Forgetting the 2.1.259 allowedMcpServers change for fixed managed servers.
Checking only the process exit code and ignoring mcp_server_errors.
Expanding credential scope to hide an authorization failure.

FAQ

Does `--permission-prompts none` approve tools automatically?

No. The active permission mode still decides first. Only a call that would otherwise prompt is converted to a denial.

Can `managedMcpServers` launch a local `stdio` command?

The 2.1.259 release says command-named entries are skipped. Use it for the remote HTTP/SSE boundary described by the release.

Is `managedMcpServers` the same as `managed-mcp.json`?

No. The new value is a managed setting for distributing remote entries. The existing system-level managed-mcp.json mechanism is a fixed server deployment with different behavior. Audit both when upgrading.

Is a connected server proof that the job is safe?

No. Verify tool permissions, server-side credential scope, prompt fallback, structured startup errors, and the absence of side effects.

Sources

GitHub Copilot Code Review Approvals: A Safe Rollout Checklist

Ahab — Wed, 02 Sep 2026 10:21:00 +0000

Originally published at IndieSeek.

GitHub Copilot code review approvals: protect merge requirements before enabling public preview

Quick answer

GitHub Copilot code review can now submit an approving pull-request review, and administrators can optionally let that approval satisfy a repository's required-approval rule. The feature is a public preview, is off by default, and is available on Copilot Pro, Pro+, Max, Business, and Enterprise plans.

Do not treat every positive Copilot assessment as merge authority. GitHub exposes three separate states: an approval assessment in the review summary, permission for Copilot to submit an approving review, and permission for that approval to count toward merge requirements. Keep the third state disabled until a path-scoped canary proves stale-approval dismissal, required checks, code-owner review, and bypass rules still behave as intended.

Who this is for

This guide is for repository administrators, platform teams, and indie developers who already use Copilot code review and are deciding whether an AI approval may become part of the merge gate. It focuses on GitHub.com governance, not on IDE suggestion quality or letting an agent merge code.

If you still need to tune review instructions and effort, start with the Copilot code-review setup guide. For security findings and deterministic scanning, use the Copilot and code-scanning workflow. Neither article previously allowed an AI review to satisfy a required approval; this public preview changes that exact boundary.

What changed—and what did not

Every Copilot code review now includes an approval assessment in its overview comment. That assessment only reports Copilot's judgment; by itself, it does not count toward merge requirements. When administrators enable approvals, Copilot can submit an approving review. A second control decides whether that approval can satisfy the repository's required-approval rule.

Controls exist at enterprise, organization, and repository levels. Repository administrators can also provide up to 15 file globs. An approval counts only when every changed file matches the configured globs. New commits dismiss Copilot's approval, after which a fresh review can be requested.

This is not automatic merge. Required status checks, conversation resolution, code-owner requirements, deployments, merge queue rules, and non-bypass settings remain independent controls. GitHub also says Copilot can miss problems and should be supplemented with human review.

Model the three gates separately

Gate	Default behavior	What it proves	What it does not prove
Approval assessment	Appears in every Copilot review	Copilot considers the reviewed revision ready or not ready	No approving review and no merge credit
Copilot may approve	Off by default	Copilot may submit an approving review	Approval may still not satisfy required reviews
Copilot approval counts	Separately configurable	The approval may satisfy one required-approval slot when scope matches	CI, code owners, latest-push rules, and merge authority are not bypassed

Treat the first gate as information, the second as reviewer authority, and the third as enforcement authority. Roll them out in that order.

Build a narrow approval envelope

Start with low-risk paths where review correctness can be tested without making the AI the sole risk owner. Documentation, examples, and generated snapshots may be candidates; authentication, billing, secrets, deployment, migrations, dependency manifests, and security policy should remain human-gated.

Use branch protection or rulesets to keep the envelope bounded:

require at least two approvals when one may come from Copilot;
require Code Owner review for sensitive paths;
dismiss stale approvals after code-modifying pushes;
require approval of the most recent reviewable push;
require named CI checks from the expected GitHub App;
require conversation resolution and disallow bypass for the protected branch.

File globs are an eligibility filter, not a security boundary. A mixed pull request containing one file outside the allowlist should not receive merge credit from Copilot. Also remember that Copilot reads instructions and agent skills from the pull request's head branch, so a change to review instructions deserves explicit human scrutiny.

A six-stage rollout workflow

1. Snapshot the existing merge contract

Record the active ruleset or branch-protection rule, required approval count, code owners, required checks and their expected apps, latest-push rule, dismissal rule, merge queue, deployments, and bypass actors. If you cannot reproduce the current contract, do not add another approval actor.

2. Enable assessment only

Run Copilot reviews without enabling approval authority. Compare the overview assessment with human reviewers across at least ten representative pull requests. Capture false positives, missed risk, excluded files, review effort, AI-credit usage, and Actions-minute impact.

3. Allow approvals without merge credit

Enable “Allow Copilot to approve pull requests,” but leave “Allow Copilot approvals to count toward merge requirements” off. Confirm the review event, actor, reviewed commit SHA, timestamp, and audit visibility. This separates event correctness from enforcement.

4. Add path-scoped merge credit

Use a small repository or a narrow set of file globs. Keep at least one required human approval. Do not leave the path list blank for the first canary, because blank means approvals can count for all files.

5. Run the canary matrix

Canary pull request	Expected result
All files match the low-risk globs	Copilot approval may count, but other gates remain required
One file is outside the globs	Copilot approval must not satisfy merge requirements
New commit after approval	Copilot approval is dismissed; re-review is required
Required CI check fails	Merge remains blocked
CODEOWNERS path changes	Required Code Owner approval remains necessary
Review instructions change in the head branch	Human reviewer inspects the policy change before merge

Stop if the merge box cannot explain which approval and rule satisfied each gate.

6. Expand only from evidence

Promote one path group at a time. Review false-approval rate, human override rate, escaped defects, spend, and bypass events. Roll back by disabling merge credit first; disabling Copilot's ability to approve is a second, separate rollback.

Copyable acceptance record

feature: github-copilot-code-review-approvals
preview_status: public-preview
repository: owner/example
protected_branch: main
copilot_may_approve: true
copilot_approval_counts: true
allowed_paths:
  - "docs/**"
  - "examples/**"
required_approvals: 2
human_approval_minimum: 1
dismiss_stale_reviews: true
require_last_push_approval: true
required_checks_source_pinned: true
code_owner_gate_preserved: true
bypass_disabled: true
canary_matrix_passed: true
rollback_owner: platform-admin@example.com
review_date: 2026-10-02

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Counting the overview assessment as an approving review.
Enabling merge credit enterprise-wide before a repository canary.
Leaving file paths blank and assuming that means “no paths.”
Reducing required approvals to one, allowing Copilot to become the only approver.
Forgetting that new commits require a fresh Copilot review.
Treating an AI approval as proof that tests, Code Owners, or deployment gates passed.
Ignoring head-branch changes to instructions, skills, or MCP context used during review.

FAQ

Does every positive Copilot assessment count as approval?

No. The assessment is informational. Copilot must be allowed to submit approvals, and a separate setting must allow those approvals to count toward merge requirements.

Is the approval feature generally available?

No. GitHub labels Copilot approvals as public preview and says the behavior is subject to change.

Can Copilot approval merge a pull request automatically?

No. An approval can satisfy one review requirement, but merge permission and every other protection rule remain separate.

What happens after another commit is pushed?

GitHub says Copilot's approval is dismissed. Request a new review and verify the new head SHA before relying on another approval.

Sources

Claude Fable 5.1 GitHub Copilot Data Retention and Pricing Checklist

Ahab — Wed, 02 Sep 2026 01:22:01 +0000

Claude Fable 5.1 in GitHub Copilot: verify retention, policy, and token cost before rollout

Quick answer

GitHub announced Claude Fable 5.1 as generally available inside GitHub Copilot on September 1, 2026. That does not establish broad availability through Anthropic's API, Claude apps, or every third-party model router. GitHub says rollout is gradual, the model is available to Copilot Pro+, Max, Business, and Enterprise users, and Business or Enterprise administrators must enable a policy that is off by default.

The unusual gate is data handling. GitHub's current model documentation says Anthropic retains prompts and outputs for Claude Fable 5 and 5.1 by default to operate safety classifiers. Certain eligible enterprise customers can request a time-limited zero-data-retention path through the end of 2026, but approval does not enable the model and it carries an internal-use boundary. Decide the retention lane before the model policy, then canary cost, availability, fallback, and audit evidence.

Who this is for

This checklist is for individual developers comparing premium Copilot models and for Business or Enterprise administrators deciding whether Fable 5.1 belongs in coding agent, CLI, IDE, mobile, or github.com workflows. It is especially relevant when repositories contain customer code, regulated data, confidential prompts, or long-running agent tasks that can generate substantial output.

If your first problem is inherited model access, start with the Copilot model-availability reconciliation checklist. For interrupted CLI sessions, use the Copilot CLI permission and restore checklist. Those controls do not replace this model-specific retention decision.

What changed—and what did not

GitHub describes Fable 5.1 as an Anthropic Mythos-class model designed for long-horizon autonomous coding and knowledge work. In Copilot, the model picker spans Visual Studio Code, Visual Studio, Copilot CLI, coding agent, the GitHub Copilot app, github.com, GitHub Mobile, JetBrains IDEs, Xcode, and Eclipse. Availability can still lag during gradual rollout.

The announcement is not a promise that Copilot Free or Pro includes the model. It is also not evidence that an organization policy, ZDR approval, or account-team approval has already taken effect. Treat plan entitlement, model visibility, admin policy, retention route, and billing as five separate states.

Choose the retention lane first

Lane	Entry gate	Data boundary	Safe use
Pro+ or Max	Eligible individual plan and completed rollout	Default Anthropic retention for prompts and outputs	Non-sensitive canary, then normal work only after accepting the policy
Business or Enterprise, default	Admin enables Fable 5.1 after organizational review	Default retention applies	Repositories approved for this data path
Eligible enterprise ZDR exemption	GitHub account team confirms eligibility and configuration; admin still enables the model	ZDR through the end of 2026 under the documented exemption	Internal operations, including internal product development and evaluation
Free, Pro, or not-yet-rolled-out account	No documented entitlement or model not visible	Not applicable	Keep the current approved model; do not infer an outage

GitHub says the time-limited ZDR terms prohibit making the model endpoints or outputs externally available. GitHub Support cannot determine eligibility or turn this access on. After the exemption, the documented direction is Enterprise Frontier Safeguards; that future state needs a fresh policy review rather than an automatic rollover assumption.

Price the workload, not just the subscription

GitHub's current pricing table is per one million tokens. Fable 5.1 is listed at $10 input, $0.25 cached input, $12.50 cache write, and $50 output. Anthropic models charge cache write in addition to cached input. Copilot plans include different AI-credit allowances; usage beyond allowances is billed through GitHub AI Credits, where one credit equals $0.01.

Use a reference estimate before rollout:

estimated_usd =
  input_tokens / 1_000_000 * 10
  + cached_input_tokens / 1_000_000 * 0.25
  + cache_write_tokens / 1_000_000 * 12.50
  + output_tokens / 1_000_000 * 50

A long task with 200,000 input tokens, 100,000 cached-input tokens, 20,000 cache-write tokens, and 40,000 output tokens has a $4.275 reference cost before plan allowances. Output and cache writes dominate quickly. Set a task budget and stop condition before comparing quality.

A six-stage rollout workflow

1. Classify the account and workload

Record plan, billing owner, organization and enterprise, repository, surface, data classification, expected token shape, and whether the output stays internal. Reject the rollout if nobody owns retention acceptance or overage spend.

2. Capture the effective policy

For Business and Enterprise, record the enterprise and organization settings, repository access, and the final Fable 5.1 policy state. “Allowed by enterprise” is not the same as “enabled by organization.” Preserve a screenshot or exported setting with timestamp and owner.

3. Resolve the retention path

Choose default retention or a confirmed ZDR exemption. Do not label a request, support ticket, or account-team conversation as approved configuration. For ZDR, retain the eligibility evidence, expiry date, internal-use restriction, enabled policy, and a re-review owner for the end of 2026.

4. Run a non-sensitive canary

Use a synthetic repository with no secrets or customer code. Verify the exact model label, surface, policy, request completion, attribution, audit log, and fallback behavior. If the model is absent, confirm gradual rollout and policy inheritance before retrying; do not widen repository access.

5. Measure cost and quality together

Run the same bounded task on the current approved model and Fable 5.1. Compare accepted changes, tests, review corrections, input, cached input, cache writes, output, wall time, and estimated credits. A stronger result is not economical if the output loop remains unbounded.

6. Expand gradually and keep rollback boring

Start with one low-risk repository and one surface. Roll back by disabling the policy or returning users to the prior approved model. Stop on unexplained model routing, missing audit evidence, retention mismatch, unexpected external output, or spend beyond the declared threshold.

Copyable acceptance record

model: Claude Fable 5.1
product_boundary: GitHub Copilot
plan: Business
surface: Copilot CLI
policy_owner: platform-admin@example.com
policy_state: enabled
retention_lane: default-retention
repository_class: internal-non-sensitive
canary_repo: synthetic-fable-canary
estimated_usd_limit: 5
fallback_model: prior-approved-model
audit_evidence: captured
rollback_owner: platform-admin@example.com
review_date: 2026-10-02

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Writing “Claude Fable 5.1 is available everywhere” when the verified release is GitHub Copilot-specific.
Enabling the model before deciding whether default retention is acceptable.
Treating ZDR eligibility approval as automatic model enablement.
Ignoring cache-write and output prices when estimating long agent tasks.
Calling a missing picker entry an outage before checking gradual rollout, plan, and policy.
Sending customer code through a synthetic canary or exposing ZDR outputs externally.

FAQ

Is Claude Fable 5.1 generally available outside GitHub Copilot?

This source set proves GA in GitHub Copilot only. Check the official product or API you intend to use before claiming wider availability.

Does Copilot Business or Enterprise enable it automatically?

No. GitHub says the policy is off by default and an administrator must enable it. Rollout is also gradual.

Is zero data retention automatic for enterprise customers?

No. Certain eligible enterprises can request the time-limited path through their GitHub account team. Approval and policy enablement remain separate.

Is the token price the same as the subscription price?

No. Plans include different allowances, while the model table supplies per-token reference rates used for additional AI-credit billing.

Sources

Originally published at IndieSeek.

Codex 0.152 Rate-Limit Reset and Queued Prompt Checklist

Ahab — Tue, 01 Sep 2026 10:17:57 +0000

Codex 0.152 rate-limit recovery: verify resets, fallback models, and queued prompts

Quick answer

Codex 0.152.0, released on September 1, turns rate-limit notices into recovery actions instead of leaving only a dead-end error. Depending on backend eligibility, a banner can lead you to usage details, credits, an earned reset, an owner notification, a plan page, or a fallback model. The important safety change is less visible: queued prompts remain paused while Codex refreshes the authoritative limit snapshot, and only one queued prompt is released after recovery completes.

Do not treat every stopped turn as “the rate limit.” A rolling usage window, a selected-model limit, a workspace credit cap, an earned reset, and expired Amazon Bedrock credentials have different authorities and recovery paths. Diagnose the state first, take one bounded action, refetch it, and then resume.

The checked stable tag resolves to commit 316795b3cf2a45e90d121d9f46499d4658b2645c. The local CLI available during this review is 0.145.0, so the workflow below is a source-verified rollout checklist, not a claimed live 0.152 canary.

Who this is for

This guide is for developers running Codex interactively, through codex exec, or behind an app-server client. It is especially useful when unattended work has queued follow-ups, when a team workspace controls credits, or when Codex uses an external model provider such as Amazon Bedrock.

For root-goal token accounting, use the Codex 0.151 subagent budget checklist. For API-side 429 and spend controls, see the OpenAI API hard-limit runbook. Those are adjacent controls, not substitutes for this ChatGPT-backed Codex recovery state.

What changed in 0.152

The stable release adds actionable rate-limit banners. The linked implementation carries backend-owned banner and account identity data through account/rateLimits/read, filters banners that do not match the authenticated account or user, refreshes state after a limit error, rejects stale responses, and keeps queued input paused until recovery finishes.

If the banner instructs Codex to use a fallback model, the client switches to the first available fallback without changing unrelated thread settings. This is not a general promise that every account, limit, or model has a fallback.

The same release separately adds provider-authentication recovery progress to the TUI and codex exec. App-server clients receive modelProvider/authRecoveryStarted and modelProvider/authRecoveryCompleted with thread, turn, provider, and message fields. A Bedrock credential refresh is therefore not evidence that a ChatGPT usage window reset.

Classify the stop before acting

Observed state	Authority	Safe next action	Do not assume
Rolling or selected-model usage limit	Backend usage snapshot and optional banner	Wait for reset or follow the offered fallback-model action	Buying credits or refreshing AWS credentials clears it
Workspace/member credits or spend control reached	Workspace billing policy	Notify the owner, add credits, or change the plan only through the offered action	A model switch bypasses workspace policy
Earned rate-limit reset available	account/rateLimits/read snapshot	Consume once with a unique idempotency key, then refetch	Every account has a reset or that one reset is free of expiry
Provider credential recovery	Model-provider auth events	Let refresh finish; reconnect only on failure	This changes ChatGPT quota or monthly credit state

The app-server documentation says reset-credit and banner data are snapshot-only. Sparse account/rateLimits/updated notifications must be merged into a recent full read or followed by a refetch; missing fields do not prove zero credits, no spend control, or no banner.

A six-stage recovery workflow

1. Pin the client and record the failed turn

Capture codex --version, authentication mode, account or workspace identity, selected model, thread and turn IDs, error class, queued-input count, and timestamp. Do not upgrade, switch accounts, or re-send the prompt before you can identify the original turn.

2. Read the authoritative snapshot

TUI users should open the banner's usage action. App-server clients should call account/rateLimits/read. Record usedPercent, window duration, reset time, reached type, effective individual limit, spend-control state, available reset count, and the banner actions actually returned.

Never manufacture a reset button client-side. The backend decides eligibility, and identity-mismatched banners are filtered.

3. Hold queued work

Keep queued prompts visible but unsent while recovery is pending. The 0.152 tests cover a failed turn with two queued messages: recovery changes the model when instructed, sends exactly the oldest queued follow-up, leaves the second queued, and does not submit again when recovery completion is repeated.

If your wrapper automatically retries outside Codex, disable that retry until it consumes the same recovery state. Two independent retry loops can duplicate side effects.

4. Choose exactly one recovery lane

Wait: use the backend reset time for an ordinary rolling window.
Fallback: accept only a banner-provided model action, then record the old and new model.
Earned reset: consume one returned credit with a fresh idempotency key; never retry with a new key after an uncertain response.
Workspace action: notify the owner or manage credits/plan through the returned action.
Provider auth: wait for the matching completion event; if it fails, repair the named provider rather than changing quota settings.

5. Refetch before releasing input

After any action, run a fresh full read. Confirm account identity still matches, recovery is no longer pending, the selected model is intentional, and the original failed turn has a terminal result. An account change should clear the recovery hold without auto-sending queued work.

6. Release one prompt and reconcile effects

Send only the oldest queued prompt. Check repository, deployment, issue, payment, or other external state before retrying any tool call from the failed turn. A rate-limit error does not prove that every earlier side effect rolled back.

Eight acceptance canaries

A limit error triggers one authoritative refresh.
Input submitted during refresh stays queued.
A stale response cannot overwrite a newer limit state.
A banner for another account or user is not rendered.
A banner-directed fallback changes only the model required for recovery.
Repeated recovery-complete handling does not send a second prompt.
Switching accounts clears the hold but does not auto-send the queue.
Provider-auth progress is logged separately from ChatGPT quota recovery.

Copyable recovery record

codex_version: 0.152.0
release_commit: 316795b3cf2a45e90d121d9f46499d4658b2645c
auth_mode: chatgpt|api_key|amazon_bedrock|other
account_id_hash: 
thread_id: 
failed_turn_id: 
limit_reached_type: 
selected_model_before: 
banner_action: wait|fallback|reset|notify_owner|manage_credits|manage_plan|none
reset_idempotency_key_hash: 
provider_auth_recovery: not_seen|started|completed|failed
queued_before: 
queued_released: 1|0
external_side_effects_reconciled: yes|no
fresh_snapshot_verified: yes|no
checked_at: 
~~~

Building something? Take a 60-sec game break. Score to rank your product or profile on [tapto.top](https://tapto.top/?utm_source=devto&amp;utm_medium=syndicated-blog&amp;utm_campaign=codex-0-152-rate-limit-reset-queued-input-recovery-checklist) and get more exposure—free, no signup.

## Common mistakes

- Calling every stopped turn a quota problem when provider authentication is actually refreshing.
- Assuming an absent reset-credit field means zero instead of unavailable snapshot data.
- Creating a client-side reset or plan action that the backend did not return.
- Retrying a reset with a new idempotency key after an uncertain response.
- Letting a wrapper and Codex both resend the same queued prompt.
- Switching models before recording which model and limit caused the stop.
- Treating a successful recovery as proof that prior tool side effects did not occur.
- Claiming 0.152 runtime validation from a machine still running an older CLI.

## FAQ

### Does Codex 0.152 give every user a free rate-limit reset?

No. It surfaces earned reset information and actions only when the backend says they are available for the authenticated account. Availability, count, details, and expiry can differ.

### Will Codex automatically switch models after every limit?

No. The release supports a fallback when instructed by the backend banner and when a fallback is available. It does not make model switching a universal recovery rule.

### Is Bedrock reauthentication the same as a Codex rate-limit reset?

No. Provider credential recovery has separate started/completed events. It restores provider authentication; it does not reset ChatGPT usage windows or workspace credits.

### Can I safely re-send the failed prompt after the banner disappears?

Only after a fresh snapshot, terminal-turn check, and external-side-effect reconciliation. Release one queued prompt, not the entire queue.

## Sources

- [Codex 0.152.0 stable release](https://github.com/openai/codex/releases/tag/rust-v0.152.0)
- [Actionable rate-limit banner implementation and tests](https://github.com/openai/codex/pull/41742)
- [Codex app-server account and rate-limit contract at the release commit](https://github.com/openai/codex/blob/316795b3cf2a45e90d121d9f46499d4658b2645c/codex-rs/app-server/README.md)
- [Queued-input rate-limit recovery tests at the release commit](https://github.com/openai/codex/blob/316795b3cf2a45e90d121d9f46499d4658b2645c/codex-rs/tui/src/chatwidget/tests/rate_limit_recovery_tests.rs)
- [Provider authentication recovery notifications](https://github.com/openai/codex/pull/41239)


Originally published at [IndieSeek](https://indieseek.co/blogs/codex-0-152-rate-limit-reset-queued-input-recovery-checklist/?utm_source=devto).

DeepSeek Harness alpha.3 SQLite Session Migration Checklist

Ahab — Tue, 01 Sep 2026 01:25:00 +0000

Liquid syntax error: 'raw' tag was never closed

GitHub Copilot CLI Permission and Session Restore Checklist

Ahab — Mon, 31 Aug 2026 10:32:35 +0000

GitHub Copilot CLI permission defaults: restore crashed sessions without widening authority

Quick answer

GitHub Copilot CLI 1.0.81 added two useful controls for new interactive sessions: defaultMode chooses the startup working mode, while defaultPermissionMode chooses the initial approval behavior. The same stable release also made startup offer to restore sessions that were still open when the CLI crashed or the machine restarted. GitHub highlighted these changes in its August 28 Copilot weekly release, and 1.0.82 is now the latest stable patch.

The important boundary is easy to miss: restoring context is not evidence that the restored process has the authority you intended. Before letting a recovered agent continue mid-turn, record the effective mode, permission mode, sandbox policy, working directory, repository state, managed-policy status, and pending action. Resume only when that evidence matches the interrupted session's approved envelope.

Who this is for

This guide is for developers and platform teams using Copilot CLI for long-running refactors, test repair, incident investigation, or agent automation. It matters most when a session may survive a terminal crash, a laptop restart, or an interrupted SSH connection while tools can still edit files or run commands.

If you govern several Copilot clients, first map their coverage with the Copilot managed-settings rollout checklist. If your concern is model visibility, use the separate Copilot model-availability checklist. This page is specifically about startup defaults and recovery authority.

What changed

Confirmed change	Practical value	What it does not prove
`defaultMode` for new interactive sessions	Start in a deliberate standard, plan, or autopilot posture	A restored session necessarily adopts the latest default
`defaultPermissionMode` for new interactive sessions	Avoid choosing approval behavior manually every launch	Sandbox, path, URL, MCP, or enterprise policy is configured correctly
Startup restore offer for sessions left open	Recover after a crash or restart without finding every terminal manually	The last tool call completed, rolled back, or is safe to repeat
Mid-turn restore can continue the interrupted work	Reduce manual reconstruction of long agent tasks	Resume is idempotent or side effects happened exactly once
Large-session history loads recent events first	Faster operator access to the recovery point	Older evidence is unnecessary for reconciliation

Version 1.0.81 is a stable release, tagged at commit 65006ce22099563526dcaca743451e99e9d834f7. Version 1.0.82, tagged at 024bf28728f3cc82365e0143f44d071ebafbce4d, is the latest stable patch checked for this guide. Its release notes do not remove the 1.0.81 startup and restore behavior.

Keep four states separate

State	Where to verify it	Why separation matters
Session mode	Current UI, startup record, and mode controls	Plan and autopilot have different execution behavior
Permission mode	`/permissions show` and startup configuration	Approval behavior is not OS containment
Sandbox and policy	`/sandbox status`, `/sandbox policy`, and managed settings	A permission approval can still be constrained by the sandbox or organization
Work progress	Git diff, tests, external receipts, and session timeline	Conversation recovery does not prove side-effect recovery

Never use a successful transcript restore as the only release gate. A session can remember why it intended to run a command while the repository, network service, or external API has already moved on.

A safe baseline

For a developer who wants review before mutation, a conservative user-level ~/.copilot/settings.json starting point is:

{
  "defaultMode": "plan",
  "defaultPermissionMode": "default",
  "stayInAutopilot": false
}

Treat this as a local preference, not an enterprise policy. Repository and local settings, environment variables, command-line flags, and managed settings may override user defaults. Organizations that must prohibit bypass modes should enforce the supported managed permission policy instead of relying on each developer's file.

Seven-stage recovery workflow

1. Pin the tested client

Record the Copilot CLI version, release channel, OS, shell, repository root, current commit, and settings scopes. Do not compare a crash on 1.0.81 with a recovery after an unrecorded upgrade.

2. Capture the fresh-session baseline

Start a disposable session and record its startup mode, /permissions show, /sandbox status, /sandbox policy, current directory, and clean or dirty Git state. This is the expected envelope for new work.

3. Create a reversible interruption

Use a fixture repository. Ask the agent to make one file edit, run one harmless test, and pause before a second mutation. Terminate the CLI during the pause or while a bounded, repeat-safe command is running. Never use payment, deployment, deletion, or message-sending actions for the first canary.

4. Inspect before restoring

Check the repository diff, process tree, lock files, test output, and any external receipts without starting another agent turn. Write down what definitely happened, what definitely did not happen, and what remains ambiguous.

5. Restore and re-read authority

Accept the startup restore offer or use copilot --resume / copilot --continue. Before answering a permission prompt or allowing the mid-turn continuation to proceed, capture the effective mode, permission state, sandbox state, working directory, policy status, and pending tool call.

6. Reconcile the interrupted action

Classify the pending step as completed, not started, failed, or unknown. For an unknown state, inspect the target system and use an idempotency key or a read-before-write guard. Do not simply repeat the command because the timeline still shows it as active.

7. Start a new session to verify defaults

After the recovered task reaches a safe boundary, open a fresh session. Confirm that defaultMode and defaultPermissionMode still control new sessions independently of the restored session's retained state.

Eight recovery canaries

Canary	Expected evidence
Fresh startup mode	A new session starts in the configured mode
Fresh permission mode	`/permissions show` matches the configured default
Scope precedence	Repository, local, environment, flag, and managed overrides are recorded
Crash discovery	Startup offers the exact interrupted session, not an adjacent one
Mid-turn restore	The task resumes only after the pending action is identified
No authority widening	Permission, sandbox, path, URL, and MCP boundaries are no broader after restore
Duplicate prevention	A repeat-safe fixture proves the interrupted action happens at most once
Fresh-after-restore	A new session uses current defaults while the recovered session retains only verified state

Decision tree

Was the session interrupted with a tool call in flight?
  no  -> restore, verify mode and authority, then continue
  yes -> can the target state prove whether the action completed?
           yes -> reconcile the timeline with that evidence
           no  -> block repetition until an idempotency or read-before-write guard exists

After restore, are permission or sandbox boundaries broader?
  yes -> stop, capture settings precedence, and return to the safe baseline
  no  -> run the duplicate-prevention canary before real work

Common mistakes

Assuming defaultPermissionMode is a sandbox.
Setting allow-all as a convenience default on a machine with broad credentials.
Restoring a session before checking whether its last command already changed the target.
Treating the transcript as proof that a deployment, API call, or file write completed.
Forgetting that settings scopes and managed policy can override the user file.
Testing resume only after a clean exit rather than a real interrupted state.
Allowing recovery to combine a client upgrade, a settings change, and repository mutations in one test.
Deleting session state before collecting the evidence needed to diagnose the recovery.

Copyable acceptance record

date / operator / Copilot CLI version / tag commit:
OS / shell / repository / base commit / dirty-state digest:
user / repository / local / environment / flag / managed setting scopes:
fresh defaultMode / defaultPermissionMode:
fresh permissions / sandbox / policy / cwd:
interruption point / pending action / target-state evidence:
restored session ID / effective mode / permissions / sandbox / policy:
duplicate-prevention result / diff / tests / external receipts:
fresh-after-restore result / rollback decision / unresolved ambiguity:

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

FAQ

Does restoring a Copilot CLI session automatically make it safe to continue?

No. Restore recovers session context and can continue interrupted work, but you must separately verify the target state and the effective authority envelope.

Should `defaultPermissionMode` be set to `allow-all` for autopilot?

Not as a general default. GitHub's documentation separates autopilot continuation from full permissions, and recommends considering sandboxing before granting broad authority. Start with the narrowest mode that can complete the fixture.

Is `copilot --continue` the same as starting a fresh session?

No. It resumes recent session state. Use a separate fresh session to prove what your current startup defaults do.

Sources

Originally published at IndieSeek.

DeepSeek Harness 0.1.2 Alpha.2 Reconnect Checklist

Ahab — Mon, 31 Aug 2026 01:24:54 +0000

DeepSeek Harness 0.1.2 alpha.2 connection recovery: make reconnects visible before trusting resume

Quick answer

DeepSeek Harness v0.1.2-alpha.2, published on August 30, 2026, makes Web-client connection failures visible, retries automatically, and adds an immediate reconnect action. That is useful, but it is not proof that every interrupted agent event was replayed. Treat recovery as two separate questions: did the transport reconnect, and did the session projection catch up without gaps or duplicates?

The tagged source uses a 2-second WebSocket heartbeat, a 3-second generation-readiness timeout, and six jittered retry waits before settling on disconnected. A manual reconnect interrupts the active generation or pending delay and starts a fresh attempt immediately. These are implementation facts at tag commit 0a53fb55; the project still labels itself a Developer Preview with compatibility-breaking changes.

Who this is for

This runbook is for independent developers running long DeepSeek Harness sessions in the Web UI, especially when subagents, schedules, or background jobs can continue while the browser-to-Host connection changes. It is also useful for teams wrapping the Harness behind SSH, a reverse proxy, or a private gateway where a green process check does not prove the browser stream is healthy.

If you need crash, compaction, and durable-history recovery, use the session persistence and replay guide. This article covers the narrower transport and projection handoff: browser network state, WebSocket replacement, readiness, cursor continuity, and operator evidence.

What changed and what did not

The official alpha.2 release adds visible connection failure state, automatic retry, and an immediate reconnect action. The same release also improves long-history and dense live-message processing, shows per-answer token usage and elapsed time, and exposes effective endpoints when web_search fails.

The tagged connection controller establishes the recovery contract:

Condition	Controller behavior	Evidence to require
Healthy initial connection	No recovery indicator after the first ready frame	One connected generation and no retry warnings
Browser reports offline	Abort active work, publish `disconnected`, suspend automatic retries	No new socket attempts while offline
Browser returns online	Publish `connecting`, reset the attempt number, restart at the base tier	Fresh socket plus a new ready frame
Transport or readiness fails	Replace the generation using jittered exponential backoff	One `retry #N` warning per physical attempt
User presses reconnect	Interrupt the generation or delay and attempt immediately	No parallel retry loop; attempt sequence resets
Final capped attempt fails	Stop automatic attempts and stay `disconnected`	Stable action for manual recovery, not endless traffic

navigator.onLine only decides whether retries should run. The source explicitly treats a fresh $events ready frame as Host-connectivity proof. Likewise, a visible Connected state proves a generation opened; it does not by itself prove every one-way notification was replayed.

Know the retry timeline

The default backoff cap begins at 500 ms, doubles through 1, 2, 4, and 8 seconds, then reaches the 10-second cap. Each actual delay is randomly chosen from 50% to 100% of its cap. The tagged test expects six retries after the initial failed connection:

Retry	Delay range
1	250–500 ms
2	500–1,000 ms
3	1–2 seconds
4	2–4 seconds
5	4–8 seconds
6	5–10 seconds

The waits therefore total roughly 12.75–25.5 seconds, excluding failed readiness and network time. Do not write an alert that assumes an exact reconnect second. Alert on state transitions, attempt count, and the terminal disconnected state.

A seven-stage rollout

1. Pin the alpha and preserve rollback

Record dsh-v0.1.2-alpha.2, commit 0a53fb55bea101816fa226bb964ae2bed71c343b, Node.js version, launch command, Host URL, and reverse-proxy path. Keep the previous build available. The official README says the project is a Developer Preview, not stable GA.

2. Capture the healthy baseline

Open one disposable session and record the initial generation ID, latest durable event sequence or cursor, visible answer count, active jobs, and active schedules. Confirm the recovery indicator is absent during uninterrupted operation. A permanently visible “connected” badge would make a later transition less useful.

3. Test browser-offline suspension

Use browser network emulation or disconnect the client network while leaving the Host alive. Expect disconnected quickly and zero new connection attempts during a 60-second offline window. Duplicate offline events must not create more loops.

4. Exercise bounded automatic retry

Bring the browser online while deliberately rejecting the WebSocket upgrade. Capture each retry warning and socket attempt. Expect six retries after the initial attempt, then a stable disconnected state. If attempts continue indefinitely, stop the rollout: the deployed client is not following the tagged controller.

5. Exercise one manual reconnect

While the client is waiting in backoff, restore the Host and press Reconnect now once. Expect the delay to be interrupted, the attempt sequence to reset, exactly one socket replacement, and a ready frame. Do not repeatedly click; that tests operator impatience rather than recovery correctness.

6. Reconcile projection and durable work

After reconnect, compare the pre-failure cursor with the fresh baseline or replay cursor. Verify that completed messages appear once, active background work remains owned by the same session, and schedules or jobs did not duplicate. A reconnect may disrupt shared logical streams; non-replayed one-way notifications need separate reconciliation. Use the delegation ownership guide when subagents are involved.

7. Promote only with evidence

Run the same canaries through the real proxy or SSH path. Keep retry count, time to ready, terminal disconnect count, cursor gap, duplicate event count, and post-reconnect job ownership in your acceptance record. Roll back if transport recovery succeeds but projection evidence does not.

Copyable acceptance record

version: dsh-v0.1.2-alpha.2
commit: 0a53fb55bea101816fa226bb964ae2bed71c343b
surface: web / proxy / ssh
initial_generation: 
cursor_before_failure: 
offline_attempts_60s: 0
automatic_retry_warnings: 6
terminal_state: disconnected
manual_reconnect_socket_replacements: 1
ready_frame_received: yes|no
cursor_after_recovery: 
missing_events: 0
duplicate_events: 0
jobs_or_schedules_duplicated: 0
rollback_required: yes|no

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Calling an alpha release stable because the reconnect UI looks polished.
Treating navigator.onLine=true, an HTTP health check, or a green Host process as a ready WebSocket generation.
Assuming Connected means every live event was replayed exactly once.
Alerting on a fixed 13- or 26-second deadline even though backoff is jittered and readiness has its own timeout.
Clicking reconnect repeatedly and then diagnosing duplicate physical attempts as an automatic-retry bug.
Logging transcript content or credentials when generation ID, cursor, state, and counts are enough.

FAQ

Does alpha.2 retry forever?

No. The tagged controller stops automatic recovery after the failed retry in the capped 10-second tier and publishes disconnected. A manual reconnect can start another sequence.

Does manual reconnect preserve the same session?

It replaces the connection generation, not the session identity. Session continuity still depends on fresh baseline or cursor replay and must be verified independently.

Is the two-second heartbeat configurable?

Yes. The tagged Gateway config exposes websocketHeartbeatIntervalMs, with 2,000 ms as the validated default. Changing it alters failure-detection traffic and timing, so record the deployed value.

Should I upgrade production immediately?

Use a canary first. The release is an alpha inside a Developer Preview. Promote only after the transport timeline and session-projection checks pass through your actual deployment path.

Sources

Originally published at IndieSeek.

Claude Code 2.1.251 Model Switch Cache Checklist

Ahab — Sun, 30 Aug 2026 10:32:05 +0000

Claude Code 2.1.251 model-switch hooks: stop cache rebuilds from becoming surprise spend

Quick answer

Claude Code v2.1.251, published on August 28, 2026, adds PreModelSwitch and PostModelSwitch hooks plus prompt-cache visibility in /usage and the status line. Together, they let you turn a model change from an invisible session event into a policy decision with an audit trail.

Use PreModelSwitch to allow, deny, or ask before a user- or client-requested switch. Use PostModelSwitch to observe every durable session-model change, including automatic fallback and resume. Before enforcing anything, capture context_tokens, prompt_cache_warm, estimated_cache_write_usd, and pricing. The estimate is a planning signal, not an invoice: it excludes the next response, and the server may not rebuild the entire cache.

This is a direct AI coding-workflow change. It does not make model routing cheap, deterministic, or fully interceptable by itself.

Who this is for

This guide is for independent developers and small teams that use long Claude Code sessions, switch between Sonnet and Opus, enable fast mode, resume older sessions, or let an SDK or Remote Control client select models. It is especially useful when a warm prompt cache is valuable enough that a mid-task switch should be deliberate.

If you only run short one-shot prompts, a lighter policy may be enough: record the switch and keep working. If you operate long agent sessions or a shared gateway, treat model changes as a cost and governance boundary. Keep this separate from the filesystem authority covered by the Claude Code restricted-mode checklist.

What changed in 2.1.251

The official 2.1.251 release and the current hooks reference establish three useful surfaces:

Surface	What it can see	What it can do
`PreModelSwitch`	Requested source and target models, context size, warm-cache state, TTL, estimated cache-write cost, and pricing source	`allow`, `deny`, or `ask` before the switch
`PostModelSwitch`	The completed switch, including automatic fallback and resume	Log it or add model-specific context; it cannot block
`SessionStart` on resume/fork	Session age, context tokens, likely cache expiry, and estimated cache-write cost	Warn or annotate before the first resumed request

The same release adds a per-session prompt-cache line to /usage and a prompt_cache object for status-line scripts. Behind a Claude apps gateway with spend limits, rate_limits.spend_limit exposes the applicable usage percentage and reset time. These are observability fields, not a universal billing API.

Know which transitions are actually covered

The first rollout mistake is assuming one pre-hook sees every model change. It does not.

Transition	`PreModelSwitch`	`PostModelSwitch`	Operator response
`/model`, picker, or `/config` request	Yes	Yes	Apply allowlist and cache-cost policy
SDK or Remote Control `set_model`	Yes	Yes	Avoid `ask` unless refusal is acceptable
Fast mode that changes the model	Yes	Yes	Treat it as a new model cache
Automatic model fallback	No	Yes	Detect and reconcile after the change
Restored model on session resume	No	Yes	Pair with `SessionStart` cost fields
One-turn fallback-model-chain substitution	No	No	The durable session model did not change

Only interactive /model can display an ask prompt. On non-interactive -p, /config, SDK, and Remote Control surfaces, ask behaves as a refusal. Also check to_model inside the hook: a custom gateway model may not resolve to the canonical name used by the matcher.

A six-stage rollout

1. Pin the version and keep a rollback

Deploy 2.1.251 to a disposable project first. Record the actual binary path and claude --version; do not assume an editor extension, desktop app, and terminal are using the same build. Keep the previous version available until the canaries below pass.

2. Observe before blocking

Run a representative long task without changing models. Capture the new /usage prompt-cache line and, if you use a custom status line, these fields:

prompt_cache.warm
prompt_cache.hit_ratio
prompt_cache.misses
prompt_cache.expected_rebuilds
prompt_cache.ttl

The prompt-caching documentation explains why model and effort are both cache keys. Changing either mid-session causes the next request to read the whole conversation without cache hits.

3. Start with three policy outcomes

Use a small decision table instead of a hard-coded “Opus is expensive” rule. The same principle applies when reconciling inherited access in the Copilot model-governance checklist: availability, selection, and cost are different facts.

deny when the target model is outside the approved model set.
ask when the current cache is warm and the estimated cache write exceeds your session threshold.
allow when the cache is already cold, the context is small, or the switch is part of an approved task phase.

Log from_model, to_model, source, context_tokens, prompt_cache_warm, cache_ttl, estimated_cache_write_usd, and pricing. Never log credentials or transcript content.

4. Reconcile after every durable switch

Use PostModelSwitch for an append-only event. Include whether the source was command, picker, sdk, auto, or resume. An automatic fallback bypasses the pre-hook, so post-switch evidence is what tells you the session moved.

If you add model-specific instructions through additionalContext, keep them short. They arrive with the next request, and rapid repeated switches deliver only the last target model's output.

5. Put stale resumes behind a warning

For resumed or forked sessions, SessionStart now provides seconds_since_last_response, context_tokens, prompt_cache_likely_expired, and estimated_cache_write_usd. Warn when a long conversation is stale enough that resuming it is likely to rebuild the cache. The useful choice may be to resume, compact at a task boundary, or start a clean session; the estimate alone should not choose for you.

6. Compare policy to real outcomes

After a week, compare switch events with cache misses, latency, accepted-task quality, and provider or gateway usage. A policy that minimizes cache writes but forces the wrong model is not a win. Keep the model decision tied to the user task, then optimize where the evidence shows avoidable churn. For delegated work, reconcile model choice alongside the subagent concurrency budget instead of treating model and worker count as separate cost systems.

Eight acceptance canaries

Canary	Expected evidence
Warm-cache `/model` switch under threshold	Pre-hook allows; post-hook logs one durable switch
Warm-cache switch over threshold	Interactive session asks with context/cost reason
Disallowed target model	Switch is denied and current model remains active
SDK switch with an `ask` result	Client receives refusal rather than waiting for a dialog
Automatic fallback	No pre-hook event; one post-hook event with `source: auto`
Resume a stale long session	`SessionStart` reports likely expiry and estimated cache write
Change effort without changing model	Cache rebuild is visible even though no model switch hook fires
Custom gateway model ID	Hook checks `to_model`; matcher ambiguity cannot bypass policy

Store one redacted acceptance record per surface:

claude_model_policy:
  version: 2.1.251
  requested_source: command
  from_model: claude-sonnet-5
  to_model: claude-opus-5
  cache_warm: true
  context_tokens: 182340
  estimated_cache_write_usd: 1.1396
  pricing: catalog
  decision: ask
  post_switch_seen: true
  outcome: accepted

The numbers above mirror the official documentation example; they are not a price quote for your account.

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

Common mistakes

Treating estimated_cache_write_usd as the final charge. It excludes the response and may overstate the cache rebuilt by the server.
Expecting PreModelSwitch to block automatic fallback or resume. Those paths reach PostModelSwitch only.
Returning ask from a headless or SDK workflow and assuming someone will see a dialog.
Using the matcher as the only guard for custom gateway IDs instead of checking to_model.
Reading prompt_cache as fleet-wide or subagent-inclusive. It summarizes the main conversation for that session.
Changing model and effort together, then attributing the cache miss to only one of them.

FAQ

Do I need 2.1.251 for these hooks?

Yes. The official hooks reference marks PreModelSwitch, PostModelSwitch, the resume cache-cost fields, and the prompt-cache status object as requiring Claude Code v2.1.251 or later.

Can the pre-hook block automatic fallback?

No. Automatic fallback is not a requested switch, so it skips PreModelSwitch. Observe it with PostModelSwitch and decide whether the new model is acceptable for the next turn.

Does a model switch always rebuild the whole cache?

Each model has its own cache, so the next request to a different model has no hits from the current model's cache. The reported dollar figure remains an estimate because the serving layer may already hold a compatible prefix.

Should I always deny switches with a warm cache?

No. The stronger model may save more engineering time or improve the acceptance rate. Use the hook to expose the tradeoff, not to replace task-level judgment with a single cost threshold.

Sources

Originally published at IndieSeek.

Codex 0.151 Subagent Token Budget Checklist

Ahab — Sun, 30 Aug 2026 01:20:53 +0000

Codex 0.151 subagent token budgets: make nested workers count toward the root goal

Quick answer

OpenAI released Codex rust-v0.151.0 on August 29, 2026. One fix changes how a persisted goal measures work: token usage from spawned descendants, including nested subagents, now rolls into the root goal's token budget.

This closes an accounting gap, not every delegation risk. A root goal still needs an explicit positive token_budget; concurrency, repeated work, tool side effects, provider billing, and account-level usage limits remain separate controls. The practical rollout is to create one bounded root goal, observe it with get_goal, and prove that child and grandchild deltas appear exactly once across active work, idle periods, runtime unloading, goal replacement, and concurrent checkpoints.

The official tag resolves to commit 78c290807ce710180111df227df3b7a4fe845452. The merged implementation PR is #41183, commit 4761851ff35c4ebdd35eb8801e1180a0a50fef60. This article separates those confirmed release facts from the operational checks you should run in your own environment.

Who this is for

This guide is for developers running multi-agent Codex tasks with a root agent that spawns reviewers, researchers, testers, or nested workers. It is especially useful when you want a task budget to cover the whole agent tree rather than only the root conversation.

If your main problem is controlling simultaneous workers, use the separate Claude Code subagent concurrency budget checklist. If your problem is assigning ownership between subagents, jobs, and workflows, see the DeepSeek Harness delegation guide. This page is specifically about Codex persisted-goal token accounting.

What 0.151 changed

Confirmed behavior	Why it matters	Verification target
Child and grandchild usage rolls up	A nested worker cannot remain invisible to the root goal ledger	Root `tokens_used` includes both levels
Active and idle progress both account descendants	Child work can be charged while the root is waiting	An idle checkpoint still advances usage
Goal replacement resets the descendant baseline	Work from a completed goal should not leak into the next goal	New goal starts from its own delta
Per-thread checkpoints are serialized	Two tool completions should not double-charge the same delta	Concurrent finishes preserve, but do not duplicate, usage
Parent runtime unloading does not break roll-up	A surviving grandchild still belongs to the root tree	Usage arrives after the parent runtime stops

The tagged source calculates goal usage as uncached input tokens plus output tokens. Cached input is subtracted; the goal counter is therefore not the same field as raw total tokens. The implementation stores a cumulative descendant counter, takes deltas against the last accounted baseline, and adds those deltas to root-turn progress.

Keep four budgets separate

Limit	What it governs	What 0.151 does not promise
Root goal token budget	Persisted work budget for one explicit goal	It does not exist unless a positive budget is requested
Model context window	Tokens available to a model call	It is not enlarged or replaced by goal accounting
Account or provider quota	Product-level usage allowance	The release does not redefine weekly or plan usage
Financial/tool budget	API spend and external side effects	Token accounting does not cap invoices, writes, or deployments

Treat BudgetLimited as a goal-runtime state, not proof that every already-running action was cancelled. The tagged tests show that a budget-limited goal can continue accounting usage until the turn stops. Your outer orchestrator should therefore stop new fan-out, let in-flight work reach a safe boundary, and verify the terminal state.

A six-stage rollout

1. Pin the tested build

Record the Codex version, tag commit, collaboration mode, root thread ID, worker tree, and model route. Do not compare runs that changed both the binary and the delegation topology.

2. Create one explicit root goal

Use the goal tool only when the task genuinely has a bounded objective and the user or system explicitly requested a token budget. A minimal tool payload looks like this:

{
  "objective": "Verify the multi-agent release candidate",
  "token_budget": 50000
}

Do not invent a budget for an ordinary task. create_goal rejects a second unfinished goal; complete the current goal before replacing it.

3. Capture a baseline before fan-out

Call get_goal and record the goal ID, status, budget, tokens_used, and remaining tokens. Then spawn one child with a small deterministic task. Check the goal again after a tool completion rather than relying on a UI estimate.

4. Add nesting and an idle checkpoint

Have the child spawn one grandchild. Let the root wait while the descendant completes a bounded step. The next goal snapshot should include new descendant usage even if the root produced no new model work during that interval.

5. Exercise lifecycle boundaries

Unload the parent worker runtime while a grandchild remains active, then verify roll-up. Complete the first goal, create a replacement goal, and confirm that usage recorded before the replacement does not become the new goal's opening balance.

6. Stop fan-out at the boundary

When the root goal reaches its budget, stop admitting new workers. Reconcile any usage that arrived between a checkpoint snapshot and its write, wait for in-flight work to stop safely, then capture the terminal goal record. Do not translate BudgetLimited into “subscription quota exhausted” or “all costs stopped.”

Eight accounting canaries

Canary	Expected evidence
Root only	Root work advances `tokens_used` once
Child roll-up	One child delta appears in the root goal
Grandchild roll-up	A nested descendant also appears in the same goal
Idle root	Descendant progress is recorded while the root waits
Parent unload	Grandchild usage still arrives after its parent runtime stops
Concurrent checkpoint	Usage recorded during a checkpoint remains pending for the next one, with no loss or duplicate
Goal replacement	The new goal excludes the previous goal's descendant baseline
Budget boundary	Status becomes `BudgetLimited`, new fan-out stops, and final usage is reconciled once

The official test suite includes a compact arithmetic example: 14 uncached-input-plus-output tokens from the root, 36 from a child, and 12 from a grandchild produce 62 tokens on the root goal and reach a 62-token budget. Use larger values in production, but keep this deterministic shape in CI.

Decision tree

Is there an explicit root goal with a positive token budget?
  no  -> do not claim a hard goal-token limit
  yes -> does child usage appear in get_goal?
           no  -> verify Codex >= 0.151, the root/descendant relationship, and checkpoint completion
           yes -> does grandchild usage appear after the parent unloads?
                    no  -> stop rollout and preserve the tree/lifecycle trace
                    yes -> run concurrent-checkpoint and goal-replacement canaries
                             -> any loss, duplication, or baseline leak?
                                  yes -> stop rollout with the accounting record
                                  no  -> enable bounded fan-out and monitor the terminal goal state

Common mistakes

Treating the goal token budget as the model context window.
Claiming it fixes account-level or weekly quota reporting.
Setting a budget but never checking get_goal after descendant work.
Testing only direct children and missing a grandchild path.
Assuming a budget crossing instantly cancels every in-flight tool call.
Replacing a goal without checking that the descendant baseline reset.
Combining a concurrency change with the accounting rollout, making regressions hard to locate.
Presenting community reports of runaway delegation as verified platform-wide behavior.

Copyable acceptance record

date / operator / Codex version / tag commit:
root thread / goal ID / objective / token budget:
model route / collaboration mode / worker topology:
baseline tokens_used / remaining:
root-only / child / grandchild deltas:
idle / parent-unload / concurrent-checkpoint results:
replacement-goal opening balance:
budget-limited status / in-flight reconciliation / terminal usage:
provider quota and tool-spend checks kept separate:

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

FAQ

Does Codex 0.151 cap all subagent costs automatically?

No. The release makes descendant usage count toward an explicit persisted root goal budget. It does not create a budget when none was requested, nor does it replace account quota, API billing, tool-spend, or side-effect controls.

What exactly is counted by the goal ledger?

In the tagged implementation, the delta is uncached input tokens plus output tokens. Cached input is subtracted. That is why the goal ledger should be compared with its own get_goal fields, not with a raw total-token counter from another surface.

Can I assume workers stop the moment the goal reaches its budget?

No. Treat the state as an admission boundary: stop new fan-out and reconcile work already in flight. The official tests explicitly preserve later accounting on a budget-limited goal until the turn stops.

Sources

Originally published at IndieSeek.

DEV Community: Ahab

GPT-6 Astra API migration checklist: budget accepted runs and keep agent authority fail-closed

GPT-6 Astra API migration checklist: budget accepted runs and keep agent authority fail-closed

Quick answer

Who this is for

What changes the migration plan

Make one migration record

A five-step migration

1. Prove access with a tiny, non-sensitive call

2. Set a whole-run cost ceiling

3. Choose effort from evidence

4. Test authority as its own gate

5. Promote by accepted-run economics

Decision tree

Common mistakes

FAQ

Should GPT-6 Astra replace my default model now?

What effort should I start with?

Does a better answer justify an authority failure?

Sources

GPT-6 Astra rollout checklist: separate ChatGPT access, API access, and enterprise controls

GPT-6 Astra rollout checklist: separate ChatGPT access, API access, and enterprise controls

Quick answer

Who this is for

What OpenAI confirmed

Use a three-surface access record

A six-gate rollout

1. Choose one outcome, not one prestige model

2. Establish access before changing defaults

3. Pin a baseline and make effort explicit

4. Put a budget around the entire run

5. Test authority separately from capability

6. Promote by accepted-run economics

Decision tree

Common mistakes

FAQ

Is GPT-6 Astra generally available today?

Is GPT-6 Astra the same thing as ChatGPT 6?

What does it cost in the API?

Should I use max reasoning effort by default?

Sources

Gemini 3.8 Flash is Antigravity's default: audit agent cost and tool loops before rollout.

Gemini 3.8 Flash is Antigravity's default: audit agent cost and tool loops before rollout

Quick answer

Who this is for

What changed—and what did not

Separate identity, effort, and authority

Build a shadow-run ledger

A six-gate rollout

1. Freeze the baseline

2. Make thinking explicit

3. Cap the loop

4. Verify tool contracts

5. Compare accepted-run economics

6. Promote with a dated budget

Canary matrix

Copyable decision record

Common mistakes

FAQ

Is Gemini 3.8 Flash generally available?

Is 3.8 more expensive than 3.7 per token?

Can I keep Antigravity on 3.7?

Does Gemini 3.8 Flash support the Live API?

Sources

Claude Code 2.1.259 managed MCP servers: keep unattended headless runs fail-closed.

Claude Code 2.1.259 managed MCP servers: keep unattended headless runs fail-closed

Quick answer

Who this is for

What changed in 2.1.259

Separate the three control planes

Build a minimal managed remote set

A six-step unattended rollout

1. Snapshot the old effective state

2. Reconcile the allowlist semantic change

3. Validate managed delivery interactively

4. Prove tool-level permissions

5. Add the no-prompt fallback

6. Promote from a recorded acceptance matrix

Copyable acceptance record

Common mistakes

Should I use `max` reasoning effort by default?

Does `--permission-prompts none` approve tools automatically?

Can `managedMcpServers` launch a local `stdio` command?

Is `managedMcpServers` the same as `managed-mcp.json`?