DEV Community: BetterToken.ai

Qwen Image 2.1 in ComfyUI: Local Setup by VRAM

Adela — Wed, 30 Sep 2026 09:18:53 +0000

The most reliable way to run Qwen Image 2.1 on a consumer GPU is not to begin with the smallest GGUF you can find. Update ComfyUI, load the official text-to-image workflow, select the official INT8 diffusion model plus a matching Qwen3-VL text encoder and VAE, then generate and save one small image. On an 8 GB or 12 GB card, do not start with BF16, 2K output, or the prompt enhancer.

Neither Qwen nor Comfy Org publishes one minimum-VRAM number that applies to every PC. The 8 GB and 12 GB configurations below are conservative starting points, not guarantees: system RAM, model offloading, drivers, resolution, and other GPU processes all change peak memory use.

Choose the weights first: file size is not peak VRAM

As of 2026-09-28, the official Comfy Org model repository contains two diffusion weights, three main text encoders, one VAE, and two separate prompt-enhancer models. A first image needs the diffusion model, one main text encoder, and the VAE. The qwen3.5_9b_..._pe_t2i file is an optional prompt enhancer; it does not replace the qwen3vl_8b_... encoder.

Role	Recommended first-run file	Approx. download size	Folder
Diffusion model	`qwen_image_2.1_int8_convrot.safetensors`	7.26 GB	`ComfyUI/models/diffusion_models/`
Main text encoder, lower-memory choice	`qwen3vl_8b_w4a8.safetensors`	6.31 GB	`ComfyUI/models/text_encoders/`
Main text encoder, official template default	`qwen3vl_8b_int8_convrot.safetensors`	9.35 GB	`ComfyUI/models/text_encoders/`
VAE	`qwen_image_2.1_vae_bf16.safetensors`	0.68 GB	`ComfyUI/models/vae/`
Optional T2I prompt enhancer	`qwen3.5_9b_qwen_image_2.1_pe_t2i.int8_convrot.safetensors`	9.47 GB	`ComfyUI/models/text_encoders/`

Those figures are repository file sizes, not runtime VRAM. INT8 diffusion + W4A8 encoder + VAE is about 14.24 GB of downloads; the official template's INT8 + INT8 + VAE combination is about 17.28 GB. Enabling the prompt enhancer adds about 9.47 GB of storage and another large model-loading stage.

A practical first configuration for each VRAM tier

Available VRAM	Try first	First-generation settings	Upgrade only after success
8 GB	INT8 diffusion + W4A8 main encoder + VAE; prompt enhancement off	768×768 or below roughly 1 MP, batch 1, CFG 1	Try 1024 next; consider community GGUF only if the official path still OOMs
12 GB	INT8 diffusion + W4A8 main encoder; try INT8 encoder later	1024×1024, batch 1, CFG 1	Enable the enhancer or raise resolution one change at a time
16 GB and up	Official-template INT8 diffusion + INT8 encoder + VAE	1024×1024, 25 steps, CFG 1	Test prompt enhancement and 2K separately
Plenty of VRAM and system RAM	Prove the INT8 path first, then compare BF16 components	Keep prompt, seed, and dimensions fixed	Use BF16 only when you accept the larger footprint and want a controlled comparison

The 8 GB and 12 GB rows minimize troubleshooting cost; they are not official hardware requirements. Qwen documents model offloading for limited-memory GPUs, while ComfyUI decides what to keep on the GPU for a particular machine. Two systems with the same GPU can therefore behave differently.

1. Update ComfyUI before looking for custom nodes

Qwen Image 2.1 has native ComfyUI support. The official workflow should not require a third-party node pack. Red nodes, a missing Qwen Image 2.1 template, or an absent TextEncodeQwenImage21 node usually mean the core application or its packaged dependencies are out of date.

Windows Portable: close ComfyUI and run ComfyUI_windows_portable/update/update_comfyui.bat, then restart. Do not use update_comfyui_and_python_dependencies.bat as the routine first choice because it reinstalls the dependency stack.
ComfyUI Desktop: update the Engine from Manage → Update. Stable releases can lag the newest model support; use the available Latest on GitHub channel, or move to Portable/manual installation if your current Desktop build still lacks the nodes.
Manual Git install: update code and dependencies inside the Python environment that runs ComfyUI, then restart it.

cd /path/to/ComfyUI
git pull
python -m pip install -r requirements.txt
python main.py

The official update guide warns that git pull alone can leave the frontend, workflow templates, and new nodes outdated. Updating requirements.txt dependencies is part of the update, not an optional cleanup step.

2. Put each model in the folder its loader scans

Download your selected files from the official ComfyUI model repository. Keep every filename unchanged; browser-added suffixes such as (1) can prevent the workflow from finding the model it names.

A low-memory first run can use this layout. Choose either the W4A8 or INT8 main encoder:

ComfyUI/
└── models/
    ├── diffusion_models/
    │   └── qwen_image_2.1_int8_convrot.safetensors
    ├── text_encoders/
    │   ├── qwen3vl_8b_w4a8.safetensors
    │   └── qwen3.5_9b_qwen_image_2.1_pe_t2i.int8_convrot.safetensors  # optional
    └── vae/
        └── qwen_image_2.1_vae_bf16.safetensors

To match the official template's default, replace qwen3vl_8b_w4a8.safetensors with qwen3vl_8b_int8_convrot.safetensors. Restart ComfyUI after copying the files; loader dropdowns normally reflect the files found during startup.

3. Import the official text-to-image workflow

Open the Qwen Image 2.1 text-to-image template from ComfyUI's Templates panel, or download and drag the official T2I workflow JSON onto the canvas. The current official template packages the main graph as a subgraph and starts at 1024×1024, 25 steps, CFG 1, and euler + simple.

Check the loaders and controls in this order:

Select qwen_image_2.1_int8_convrot.safetensors as the diffusion model.
Select qwen3vl_8b_w4a8.safetensors or qwen3vl_8b_int8_convrot.safetensors as the main text encoder, with type qwen_image.
Select qwen_image_2.1_vae_bf16.safetensors as the VAE.
Keep refine_prompt set to false for the first run. The current template exposes a PE-model selector, but the qwen3.5_9b_..._pe_t2i model is only for prompt enhancement.
Start an 8 GB card at 768×768. Start 12 GB and larger cards at 1024×1024. Prefer dimensions divisible by 32.
Keep batch size 1 and CFG 1. Do not add LoRA, ControlNet, reference-image, or upscaling branches yet.

Use a deliberately simple first prompt so that success is easy to judge:

A red ceramic teapot on a wooden table, soft window light, plain background.

Do not begin at 2K. Native 2K support means the model can generate 2048×2048 directly; it does not mean an 8 GB or 12 GB GPU can complete that size under every configuration.

4. Queue one job, wait, and verify that the PNG was saved

Click Queue Prompt once. The first run may load tens of gigabytes and move components among VRAM, system RAM, and the CPU. If the canvas has no new preview yet, watch the launch terminal or log rather than repeatedly adding the same job to the queue.

Treat the first run as successful only when all four signals are present:

The queue finishes without model not found, missing node type, CUDA out of memory, or a crashed process.
SaveImageAdvanced displays the image; the sampler finishing by itself is not enough.
A PNG exists under ComfyUI/output/. The official template uses the filename prefix Qwen_image_2.1 by default; if you changed the Save Image node, use the location shown there.
The PNG opens normally, has the expected dimensions, and is not fully black, fully transparent, or corrupt.

On an NVIDIA system, you can watch memory in a second terminal:

nvidia-smi -l 1

Record the diffusion file, text encoder, dimensions, and observed peak. When you later change weights or resolution, change one variable at a time so a new failure has an identifiable cause.

5. Troubleshoot by symptom, not by replacing everything

A node is red or says `missing node type`

Update ComfyUI core and dependencies, then restart. TextEncodeQwenImage21, ResolutionSelector, and the logic switch in the official workflow are core ComfyUI nodes. Installing an unrelated third-party pack with a similar name can make the graph harder to diagnose.

A model dropdown is empty or reports `model not found`

Check the folder, extension, and exact filename, then restart ComfyUI. Common mistakes are placing the main encoder in models/clip/, placing the diffusion model in models/checkpoints/, or allowing the browser to rename a duplicate download.

VRAM runs out before sampling starts

Turn prompt enhancement off, switch the main encoder from INT8 to W4A8, keep batch 1, and close GPU-heavy browsers, games, or video tools. Drop an 8 GB card to 768×768; return a 12 GB card to 1024×1024 and remove optional branches.

VRAM runs out during VAE decode or just before saving

Reduce width and height, then queue one new job. Lowering steps mostly changes sampling time; reducing resolution more directly lowers latent and decode memory.

The queue looks frozen while disk or CPU activity continues

This is often model loading or offloading rather than a finished failure. Wait for a clear completion or error state. Repeated clicks only stack more large jobs. If system memory keeps climbing into heavy swapping, cancel, lower the configuration, and restart ComfyUI.

The image looks washed out, overcooked, or structurally broken

Confirm that CFG is still 1. The official template notes that the negative prompt is unused at CFG 1; copying a high-CFG habit from an SDXL workflow is a poor starting point here.

1024 works but 2K always OOMs

Keep 1024 as the working baseline. Try 1280, then 1536, and only then 2048, changing one tier at a time with batch 1 and prompt enhancement off. Model capability and local memory capacity are separate constraints.

What 8 GB and 12 GB users should actually choose

On 8 GB, the goal is to prove the pipeline, not to enable every template feature. Use the INT8 diffusion model, W4A8 main encoder, and VAE; disable PE; start at 768×768 and batch 1. If this still fails, confirm that ComfyUI is current and that the machine has enough system RAM before moving to GGUF. Do not insert an unknown quantized file into the stock workflow and assume it is interchangeable.

On 12 GB, use 1024×1024 as the first target. Start with the W4A8 encoder for headroom, then try the official template's INT8 encoder after the base run is stable. Prompt enhancement is a second-stage feature: it loads another 9B model to rewrite the prompt before image generation, so it should not be introduced while the base graph is still failing.

Community posts only show that individuals are experimenting; they do not establish a minimum. One user said they were running the model on an 8 GB RTX 5060 laptop while trying to optimize it. A separate 12 GB RTX 3060 user suggested W4A8 to an 8 GB user. These are the first report and the second suggestion, not controlled tests with complete logs, so they are useful as leads rather than guarantees.

GGUF is an optional low-memory route, not the official first run

The Qwen and Comfy Org templates use .safetensors. GGUF requires a third-party loader, a Qwen Image 2.1-specific quantized file, and a graph built for that loader. The ComfyUI-GGUF project describes itself as work in progress and does not certify every third-party Qwen quant.

Consider the community route only after the official INT8/W4A8 path still fails for memory:

Update ComfyUI, then install ComfyUI-GGUF through Manager or from its repository.
Obtain a file explicitly built for Qwen Image 2.1. Check the publisher, license, hash, and required loader.
Replace the stock diffusion loader with Unet Loader (GGUF). Keep a Qwen Image 2.1-compatible main text encoder and VAE.
Select the exact filename in the loader and test below roughly 1 MP, CFG 1, batch 1.
When it fails, return to that quant's own workflow notes. Do not mix a Qwen Image 1.x, Flux, or generic Stable Diffusion graph into the diagnosis.

A Russian user reported getting qwen-image-2.1-UC-Q4_K_M.gguf to run in ComfyUI but also said the installation required extra help. A separate community Q8_0 workflow combines GGUF with the official text encoder and VAE. Those reports show that a community route exists; they do not prove that arbitrary Q4 or Q8 files are compatible or safe downloads.

Add prompt enhancement, 2K, and editing only after the baseline works

Once the base image is stable, extend the graph in this order:

Prompt enhancement: download qwen3.5_9b_qwen_image_2.1_pe_t2i.int8_convrot.safetensors, select it, and turn on refine_prompt. Keep seed, dimensions, and steps fixed when comparing the result.
Higher resolution: raise dimensions in stages instead of jumping from 1024 to 2048×2048. Save as PNG when you need an alpha channel.
Image editing: switch to the official Image Edit workflow. Its prompt enhancer uses the ..._pe_i2i... file, not the T2I file.
Transparent output: use the official RGBA/transparent-background prompt wording and save as PNG. First prove an ordinary opaque image so transparency is the only new variable.

Final acceptance checklist

ComfyUI core, frontend dependencies, and workflow templates are current; no core node is red after restart.
The diffusion model, main text encoder, and VAE are in their correct folders and visible by exact filename.
Prompt enhancement is off, batch is 1, and CFG is 1; 8 GB starts at 768, while 12 GB starts at 1024.
Only one task is queued, and the terminal finishes without a missing-model, missing-node, or OOM error.
A valid PNG exists under ComfyUI/output/ with the requested dimensions.
The successful weight combination, resolution, and observed peak memory are recorded before PE, higher resolution, editing, or GGUF is added.

When all six are true, you have a reproducible local Qwen Image 2.1 baseline. Every later optimization should change one element of that successful baseline, not replace it with a large graph whose failure source is impossible to isolate.

Originally published on the BetterToken blog.

BetterToken provides pay-as-you-go access to AI model APIs through
OpenAI-compatible and Anthropic-compatible endpoints — useful if you are wiring
Claude Code, Codex, or your own tooling to a custom base URL.
See the docs to get started.

OpenAI API Key Governance: Creation Rules, Ownership, Expiration, and Zero-Downtime Rotation

Adela — Mon, 28 Sep 2026 06:35:16 +0000

You are about to add expiration rules to OpenAI API keys, but you do not want a policy change to take down an application—or to discover at the next rotation that the required replacement key can no longer be created. You may also be deciding whether production should use service-account keys while developers keep user-owned keys.

This guide gives you a practical order of operations: choose ownership by workload, set a lifetime your team can actually rotate within, then replace old keys through a controlled overlap. Keep two facts in mind from the start: new creation rules do not change existing keys, and organization restrictions override project settings.

Start with the answer: the new controls govern future keys, not old ones

You can treat the September changes as two controls: which new key types may be issued, and how long newly created project keys may remain valid.

Date	OpenAI update	Operational meaning
September 10, 2026	Project API keys can be created with expiration dates. Administrators can enforce a maximum key lifetime at the organization or project level.	Newly issued keys can be required to expire, so teams need a repeatable rotation process before enforcing a short lifetime.
September 15, 2026	Organizations and projects can restrict new key creation to `service-account keys`, restrict it to `user-owned project keys`, or disable all new API key creation.	Production workloads, individual development, and frozen projects can use different issuance rules.
September 15, 2026	Organization restrictions take precedence over project settings.	A project may tighten the organization rule, but it cannot use its own settings to relax an organization-wide restriction.
September 15, 2026	Existing API keys are unaffected by the new creation controls.	Turning on a rule does not revoke old credentials and does not complete legacy-key cleanup.

Two boundaries matter. First, “disable new key creation” is not the same as “revoke every existing key.” Second, the September 10 description applies the maximum-lifetime requirement to newly created keys. Do not assume that an old key will receive a retroactive expiration date unless you verify that behavior in the actual project.

Separate three decisions: who can create, how long keys live, and how they exit

Design these three decisions separately; one Platform switch cannot complete key governance for you.

Issuance policy determines whether a project can create service-account keys, user-owned project keys, or no new keys at all.

Expiration policy determines whether a new key must expire and the longest lifetime permitted by organization and project rules.

Lifecycle execution determines who creates a replacement, where the secret is stored, how applications receive it, how the transition is validated, when the old key is revoked, and how a failed rollout is rolled back.

The first two can be constrained in the OpenAI Platform. The third still depends on your secret manager, deployment process, observability, ownership model, and incident procedures. Enforcing a maximum lifetime without assigning a rotation owner or allowing enough time for deployment converts a security control into a scheduled outage.

Choose by workload: service accounts for production, user-owned keys for personal development

Prefer a service-account key for production and shared workloads, a user-owned project key for local or short-term work, and disabled issuance only for projects that are genuinely frozen or retiring.

Workload	Usually better suited to	Why	Main risk to manage
Production service, shared backend, scheduled job, team-operated agent	`service-account key`	The credential belongs to the workload rather than one employee, so staff changes do not determine application continuity.	A single service account used by many unrelated applications creates a large blast radius. Split by project or workload.
Local development, short-lived debugging, exploratory script	`user-owned project key`	Ownership and individual accountability are clear, and offboarding can include the user's credentials.	A personal key must not quietly become a shared production dependency.
Archived, decommissioning, or temporarily frozen project	Disable new key creation	Prevents the credential inventory from growing while the project is closed or reviewed.	Freezing issuance too early may block creation of a replacement key needed for rotation or recovery.

A useful test is: should this application continue running after a particular employee leaves the team? If the answer is yes, a production credential generally should not depend on that employee's user account. Conversely, giving every developer a shared service-account key weakens attribution and spreads the same secret across more machines.

Neither key type is inherently safe on its own. Scope, storage, access control, lifetime, rotation, logging, and revocation determine the practical risk. A long-lived service-account key copied into dozens of workloads remains a serious single point of exposure.

Organization policy is the ceiling: projects may tighten it, not relax it

An organization restriction is the ceiling for every project, so verify the next rotation before you apply it broadly.

Suppose the organization allows only service-account keys. A development project cannot override that rule and start issuing user-owned project keys. A project can usually be made more restrictive within the organization boundary, but it cannot make the organization policy more permissive.

Before changing an organization-wide rule, perform this sequence:

List all projects and classify them as production, staging, development, testing, temporary, archived, or decommissioning.
Record the key type each project will need at its next rotation, not merely the types it has today.
Identify the replacement credential needed by every active workload and confirm that the proposed organization rule permits its creation.
Rehearse creation, deployment, validation, and revocation in a low-risk project.
Apply the organization restriction only after the rehearsal proves that normal rotation remains possible.

Because existing keys continue to work, an overly strict organization rule may look harmless on the day it is enabled. The failure appears later, when a key nears expiration and the team discovers that policy prevents it from creating the correct replacement. Test the next rotation before relying on the current application's continued success.

Do not pick one lifetime for everything: start with the time a real rotation takes

Set the maximum lifetime longer than the full time needed to approve, issue, distribute, deploy, observe, and roll back a replacement.

For each project class, define at least the following:

Policy field	Question it must answer
Maximum lifetime `N`	How long may a newly created key exist from issuance to expiration?
Rotation lead time `R`	How long before expiration must replacement work begin?
Primary and backup owner	Who is responsible, and who acts if that person is unavailable?
Distribution method	Can the application load a new secret version, or does it require restart/redeployment?
Validation evidence	Which requests, logs, error rates, and usage signals prove that the new key is carrying traffic?
Rollback window	How long is the old key retained after cutover to allow safe recovery?
Exception process	Who may approve an extension, for how long, and with which compensating controls?

R must cover the whole path, including approvals, secret distribution, phased deployment, observation, and rollback. A very short lifetime paired with manual copy-and-paste, cross-time-zone approval, and no backup owner is less reliable than a somewhat longer lifetime backed by automated reminders and a practiced rotation runbook.

Use the organization-level maximum as a common ceiling. High-risk projects can adopt a shorter project-level limit, but a project should not be able to exceed the organization rule. Production services, personal development, temporary tests, and retiring projects may need different internal standards because their owners, impact, and recovery speed differ.

Use this seven-step overlap to rotate without downtime

The safest pattern is to run old and new keys briefly in parallel, then revoke the old key only after real traffic proves the cutover.

1. Build an inventory of current keys

Record the project, key ownership type, workload, application, environment, accountable owner, secret-storage location, deployment method, creation date, known expiration date, and last observed usage. A key with unknown purpose or owner should enter a high-priority investigation queue; do not start with blind bulk revocation.

OpenAI's August 4, 2026 changelog entry says the Usage and Costs dashboards, Usage API, and Costs API support filtering and grouping by API key. That key dimension can help establish whether a credential is still generating requests. It is only one piece of evidence: low-frequency batch jobs, disaster-recovery paths, and monthly workflows may remain idle for long periods.

2. Create a compliant replacement

Create a new key in the intended project, using the ownership type permitted by current organization and project rules. Give it an expiration date that does not exceed the applicable maximum lifetime. Confirm the issuance rule before the maintenance window rather than discovering a conflict during deployment.

3. Store it as a new secret version

Do not overwrite the only copy of the old value immediately. Keep the old and new secret versions during the controlled transition, with clear states such as “current production,” “rotation candidate,” and “pending revocation.” Do not place keys in source code, container images, deployment tickets, logs, or chat messages.

4. Shift traffic gradually

Start with one instance, one low-risk job, or a small percentage of traffic. Verify authentication, expected project attribution, permissions, and request behavior before expanding the rollout. If an application reads the key only at startup, schedule restarts and capacity so the rotation itself does not reduce availability.

5. Observe both application health and key-level usage

Check successful requests, authentication failures, rate-limit errors, latency, and business-level results. At the same time, verify that the new key begins producing the expected usage and that old-key usage falls. A successful deployment event is not proof that traffic has moved.

6. Keep a time-bounded rollback window

Retain the old key for a predefined observation period after the new key is stable, then revoke it. The window must be long enough to cover delayed workers, multiple regions, and low-frequency tasks, but it must not remain open indefinitely. Permanent dual-key operation doubles the number of valid secrets without delivering a completed rotation.

7. Revoke, verify, and schedule the next rotation

After revocation, confirm that attempts with the old key fail and that the new key continues to succeed. Update the inventory, on-call notes, owner, expiration date, and next rotation deadline. Do not wait until the final days of the new key's life to rediscover the process.

Legacy keys do not become compliant automatically: migrate them by risk

After you enable the new rules, you still need a separate migration queue for old keys because they keep their existing ownership and lifetime.

Create a separate migration queue and prioritize it by risk:

credentials known to have appeared in source code, tickets, logs, or chat;
keys whose owner or purpose cannot be identified;
user-owned keys associated with people who left or changed roles;
keys shared by multiple production applications and therefore difficult to revoke independently;
broad-scope or high-impact keys;
keys with a clear owner, a single workload, and a tested replacement path.

Do not measure success by revoking every old key on the same date. A safer completion criterion is that each legacy key has a known workload map, an approved replacement, cutover evidence, and a revocation deadline. For a key that cannot yet be migrated, document the exact blocker, owner, compensating control, and expiry of the exception. “Legacy system” is not a permanent risk treatment.

Your internal policy needs at least these 11 fields

An executable policy must name the rule, owner, validation evidence, rollback window, and revocation condition—not just a maximum lifetime.

Policy item	What to record
Scope	Organization, project, environment, and workload classes covered by the policy
Allowed new-key type	Service-account only, user-owned project only, or no new keys
Rationale	Continuity, individual accountability, project freeze, or another documented reason
Maximum lifetime	Organization ceiling and any stricter project limit
Rotation lead time	When an alert or work item must be created before expiration
Secret storage	Approved secret manager and access roles
Deployment	Canary or phased method, restart requirements, and rollback procedure
Evidence	Successful requests, error metrics, key-level usage, and old-key traffic reaching zero
Revocation condition	New key stable, delayed jobs covered, rollback window closed
Exception approval	Approver, reason, compensating control, and exception expiration
Audit trail	Creation, policy change, deployment, revocation, and ownership changes

Assign long-term accountability to a workload or team role, while still naming the person executing the current rotation. “The platform team owns it” is not operational unless the policy also defines an on-call path, deadline, and escalation.

Before enforcement, rehearse the next rotation

Enable organization or project restrictions only after you can answer every item below and complete a low-risk rehearsal.

every active application maps to a specific project and credential;
each project's next required key type is known;
the organization rule will not prevent a critical workload from creating its replacement;
production does not depend on one employee's personal credential;
the secret store supports versioning or another reliable rollback mechanism;
the application has been tested to load a new secret, including any restart requirement;
the team can observe usage or cost by API key and has accounted for low-frequency jobs;
primary and backup rotation owners are assigned;
expiration alerts arrive early enough to complete the runbook;
old-key revocation criteria are explicit, so overlap does not become permanent; and
each unresolved legacy key has a concrete blocker, owner, and deadline.

Frequently asked questions

Will a new creation restriction immediately break existing applications?

According to OpenAI's September 15, 2026 changelog entry, existing API keys are unaffected by the new creation governance controls. Changing which new keys may be created does not automatically revoke the credentials already used by applications. The rule can still affect the next rotation, so replacement-key creation should be rehearsed in advance.

Does a maximum lifetime retroactively expire old keys?

The September 10 update describes the maximum lifetime as a requirement for newly created keys. Do not assume it retroactively adds expiration dates to legacy credentials. Verify the actual key details and migrate old keys through a separate process.

Can a project administrator relax an organization-level restriction?

No. The release note says organization restrictions take precedence over project settings. Project policy must remain within the organization boundary.

Should an organization allow only service-account keys?

Use service-account keys first for production services, shared backends, scheduled jobs, and team-operated agents. Use user-owned project keys first for local development and short-lived exploration. An organization-wide service-account-only rule makes sense only when nearly every project fits the first group and development projects already have a workable alternative.

When should a project disable all new key creation?

Typical cases include an archived or decommissioning project, or a temporary freeze during a security investigation. Confirm first that the project will not need a replacement key for rotation or recovery; otherwise the freeze can obstruct the response it was meant to support.

What proves that an old key is safe to revoke?

Use combined evidence: rollout state, successful requests with the new key, error monitoring, key-level usage, execution of low-frequency jobs, and completion of the rollback window. A short interval with no traffic is usually insufficient on its own.

What to do first

Start with three actions: record the key type each project will need at its next rotation, complete one overlap rotation in a low-risk project, and only then enforce organization and project restrictions.

The order matters. If you set the ceiling first, current applications may keep working while the policy quietly blocks the replacement key you will need later. Prove that the next rotation works before you tighten the rules.

Official source:

OpenAI API Changelog: September 10 and September 15, 2026 updates

Originally published on the BetterToken blog.

GitHub Copilot App Local Sandbox: Setup and Verification

Adela — Mon, 28 Sep 2026 06:33:14 +0000

You enable sandboxing, but an existing session keeps its old permissions—or the agent repeatedly asks for access to install packages, reach a local server, or push a branch. The usual problem is not simply whether the sandbox is on; it is how project defaults, session overrides, and the separate file, network, and credential controls interact.

By the end of this guide, you can choose a starting policy for a local repository or worktree, apply changes to the correct session, and verify the boundaries with dummy data. The shortest path is: confirm the session type → enable Sandbox new sessions → narrow the three permission areas → start or restart the session → run safe checks.

GitHub announced this feature on September 23, 2026, and it remains in public preview, so the interface and behavior may change. Keep three boundaries in mind: local sandboxing is off by default, policy is configured per project, and a host that cannot enforce the requested policy fails the sandboxed shell instead of silently running the command without protection.

First confirm that your session is covered

Only local repository and local worktree sessions use this project policy. Cloud sandboxes, remote hosts, and GitHub Copilot CLI follow different isolation or configuration paths, so check the table before changing settings that your target session will never read.

Session type	Covered?	Boundary to remember
Local repository session	Yes	Uses the sandbox settings for the current project
Local working-tree session	Yes	A working tree separates branches and files, but does not restrict access elsewhere on the machine; the sandbox provides that permission boundary
Cloud sandbox session	No	Uses the cloud session's own isolation
Session running on a remote host	No	The local project policy is not applied to the remote host
GitHub Copilot CLI	Configured separately	Copilot app and Copilot CLI sandbox settings do not replace each other

Enterprise-managed settings can make the effective policy more restrictive than the policy requested in project settings. The project page therefore describes what the app requests, not necessarily the maximum access an organization will permit.

How to enable sandboxing for new sessions

To protect later local sessions, turn on Sandbox new sessions and then start a new session; changing the switch does not update one that is already running. Use these steps:

Open the GitHub Copilot app settings.
Select the project you want to configure.
Find the Sandbox section.
Turn on Sandbox new sessions.
Start a new local session.

The switch affects only sessions created afterward. It does not modify a session that is already running. Later changes to file, network, or credential policy also apply only to new sessions or after a session restart.

To keep the current conversation history while reloading policy, enter /restart-session in the existing session.

GitHub recommends starting with the default policy for most projects. It supports common development work such as installing dependencies, connecting to a local development server, pushing a branch, and creating a pull request. Tighten it when the project sits next to sensitive folders, does not need network access, or should not use your credentials.

How to limit files, network, and credentials separately

Treat these as three independent controls: restricting files does not disable credentials, and disabling credentials does not protect a sensitive directory that remains readable. Tighten each area according to the task instead of turning everything off at once.

1. Filesystem: decide what can be read and changed

Start with the smallest file scope: keep workspace read/write access and add other paths only when the task truly needs them. A sandboxed session can read and write its workspace and current working directory by default, and project settings add three lists:

Additional read/write: extra folders that agent-run tools may read and modify.
Additional read-only: extra folders they may read but not modify.
Denied: folders they may not access.

A more-specific denied folder remains denied even when a broader parent folder has read or write access. Prefer granting the smallest necessary path instead of opening an entire home directory and depending on many exceptions.

Windows has an important enforcement boundary. You can save a denied path in project settings, but if the active Windows sandbox capabilities cannot guarantee the denial, the command fails with an unsupported-policy message. It does not continue with the path exposed and does not automatically disable the sandbox.

2. Network: separate the internet from the local network

If the task installs dependencies or uses a local development server, do not disable both network paths automatically; decide separately whether outbound internet and the local network are needed. Sandboxed sessions can reach both by default, and you can control:

Outbound internet: access to GitHub, package registries, and other internet services.
Local network: loopback and local-network connections, including local development servers.

Network restrictions can affect dependency installation, API calls, preview servers, and any other tool that needs a connection. Treat network denial as a task trade-off, not a cost-free switch.

Linux has a specific limitation: the sandbox cannot independently control local-network access for spawned processes such as shell commands and local MCP or LSP servers. The setting still applies to in-process operations such as web requests and remote MCP connections. On Linux, verify both in-process and spawned-process behavior rather than testing only one path.

3. Credentials: control Git and GitHub CLI separately

For code reading or offline analysis, disable Git and GitHub CLI credentials first; enable them only when the task must push a branch or create a pull request. Authenticated Git and GitHub CLI operations are available inside the sandbox by default, and you can turn off:

Git credentials: authenticated HTTPS Git operations.
GitHub CLI credentials: authentication used by GitHub CLI.

Disabling them can prevent actions such as pushing a branch or creating a pull request. Filesystem and credential policy are separate boundaries: even with credentials disabled, use filesystem rules to protect directories that contain keys, configuration, or other sensitive material.

When to change the project, the current session, or one operation

Change project settings when future sessions should inherit the rule, use /sandbox on or /sandbox off for the current session, and run /restart-session after a project-policy change that the active session must reload.

Action	When it takes effect	Effect on other sessions
Change project `Sandbox` settings	New sessions or a restarted session	Changes the default inherited by later sessions in that project
Enter `/sandbox on` in an active local session	Immediately, as a persistent override for that session	Does not change the project default for other sessions
Enter `/sandbox off` in an active local session	Immediately disables sandboxing for that session	Does not change other sessions; commands then have the same file, network, and credential access as your user account
Enter `/sandbox on` or `/sandbox off` before a session starts	Changes the project default inherited by new sessions	Affects sessions started from that default afterward
Enter `/restart-session`	Restarts the current session, keeps its history, and reloads policy	Does not itself edit project policy

When a tool needs access that policy does not allow, the app may show Run outside the sandbox?. Depending on the effective policy, you can cancel, run that operation once outside the sandbox, or disable sandboxing for the rest of the current session. An enterprise owner can prevent users from running tools outside the sandbox.

Disabling through this prompt does not rewrite the project default or the existing session override. The temporary state ends when the session restarts or reattaches. After Sandbox off for this session appears, Re-enable sandbox turns it back on.

A safer decision order is to cancel first and understand why the command needs more access. If the access is a recurring requirement, narrowly update project policy and restart. Use a one-time run outside the sandbox only after reviewing the command, its arguments, and its impact. For an unfamiliar repository or a command assembled dynamically from a prompt, avoid disabling the sandbox for the whole session merely for convenience.

If the host cannot enforce the policy, the command stops

When the operating system cannot enforce a requested rule, the safe result is a failed command—not an automatic downgrade to unsandboxed execution.

The GitHub Copilot app accepts sandbox settings before it knows whether the operating system can enforce all of them. Support is checked when the first sandboxed shell starts.

If the host cannot enforce the requested policy:

The shell reports an unsupported-platform or unsupported-policy message.
The command does not continue unsandboxed.
If the app shows Sandbox unavailable, fix the reported problem and select Retry sandbox.

This is fail-closed behavior, not best-effort execution. Saving settings successfully therefore does not prove that policy is active on the current machine. Start at least one sandboxed shell, confirm that no unsupported message appears, and run a minimal verification.

How to verify the policy with dummy data

GitHub documents the behavior the policy should enforce, but only a check on your own machine can confirm that this operating-system and policy combination works. The procedure below uses disposable folders and dummy files, so you do not need to touch real keys or production configuration.

Create disposable test folders outside the workspace and place only dummy files in them. Do not test with real SSH keys, cloud credentials, or production configuration.

Check	Safe procedure	Expected policy behavior
New-session inheritance	Enable `Sandbox new sessions`, then create a new local session	The new session uses project policy; an old session does not change automatically
Applying a policy edit	Change one rule and enter `/restart-session`	The session restarts, keeps history, and reloads policy
Read-only folder	Add a disposable folder to `Additional read-only`, read a dummy file, then try to create a test file	Reading should work; modification should be blocked
Denied folder	Add another disposable folder to `Denied`, then try to list or read a dummy file	Access should be blocked even if a broader parent path is allowed
Internet access	Turn off `Outbound internet` and make a harmless connection check	The external connection should fail; turn it back on and compare
Local network	Turn off `Local network` and connect to a disposable local test service	Access should follow platform capabilities; account for the Linux spawned-process limitation
Git credentials	Turn off `Git credentials` and run a non-mutating authentication check in a test repository	Authenticated HTTPS Git operations may be unavailable
GitHub CLI credentials	Turn off `GitHub CLI credentials` and run a non-mutating check such as `gh auth status`	GitHub CLI should not receive the previous authentication capability; exact errors can vary
Fail-closed behavior	If `unsupported-platform` or `unsupported-policy` appears, check that a target dummy file was not created	The command should not continue unsandboxed or cause the intended side effect

Delete the test folders afterward and restore only the minimum permissions the project actually needs. Do not prove a denial rule by attempting to access a real sensitive directory.

Which starting policy fits your task

Everyday development, an unfamiliar repository, and offline analysis should not share one policy. Keep the capabilities required for normal development, start tighter for unfamiliar code, and disable network and credentials first for offline work.

Everyday development

Enable the sandbox, retain the default network and credential capabilities, add only required external folders, and explicitly deny neighboring sensitive directories. This fits normal work that installs dependencies, runs local services, pushes branches, and opens pull requests.

Reviewing an unfamiliar repository

Give read/write access only to the workspace, make extra reference material read-only, disable Git and GitHub CLI credentials by default, and keep outbound internet off until you understand where the dependencies come from. When temporary access is necessary, open one specific capability rather than immediately using /sandbox off.

Local offline analysis

Disable outbound internet and unneeded credentials, keeping only necessary file access. If local-network isolation also matters, verify spawned-process behavior separately on Linux instead of assuming that one UI switch controls every process identically.

These are not GitHub-named presets. They are starting points assembled from the permission dimensions GitHub exposes. Match the final policy to the repository, operating system, enterprise rules, and actual task.

Mistakes that make the policy ineffective or too broad

The most common errors are treating “settings saved” as “policy enforced” and disabling the whole sandbox after the first denial. The seven cases below either invalidate your test or grant more access than the task needs.

Treating a working tree as a security boundary. It separates concurrent branches and files; it does not prevent commands from reaching other locations on the machine.
Editing policy and continuing to test an old session. Project changes are not retroactive; start a new session or use /restart-session.
Assuming the app and CLI share one sandbox. They are configured separately.
Treating a successful save as proof of host support. Enforcement support is checked only when the first sandboxed shell starts.
Overlooking what /sandbox off means. Agent-run commands then receive the same access scope as your user account.
Assuming network behavior is identical on every platform. Linux has a documented local-network limitation for spawned processes.
Using a broad bypass whenever access is denied. Usually it is safer to confirm the need, make the smallest policy adjustment, and restart the session.

What to do next

First confirm that you are using a local repository or local worktree session, then turn on Sandbox new sessions. For everyday development, begin with the default policy and keep only the directories, network paths, and credentials the task needs; for unfamiliar code or offline analysis, start with the tighter scenario policy and add one capability at a time.

After changing project policy, start a new session or run /restart-session, then verify read-only, denied, network, and credential boundaries with disposable data. If you see unsupported-platform, unsupported-policy, or Sandbox unavailable, resolve the compatibility issue instead of using /sandbox off and mistaking an unsandboxed result for a successful sandbox test.

Official references

Use these GitHub pages before and after configuration to confirm the current interface, scope, and failure behavior.

Originally published on the BetterToken blog.

Russian neural text-to-speech: how to choose by pronunciation, pauses, and cost

Adela — Mon, 28 Sep 2026 06:31:12 +0000

You may have sampled several Russian TTS services already: every demo sounds polished, but your own surnames, amounts, abbreviations, and long sentences can expose stress and pause errors. By the end of this guide, you will know which pair to test first, how to blind-rate one script, and how to include retries and rejected takes in the cost of each accepted minute.

Start with this shortlist: for long-form Russian audio, test gemini-3.8-flash-tts against ElevenLabs Multilingual v2; for high-volume short prompts, test gemini-3.8-flash-lite-tts against ElevenLabs Flash/Turbo; for telephony and IVR, start with Gemini and ElevenLabs because both document direct μ-law and A-law output. Add gpt-4o-mini-tts when you already use the OpenAI audio stack or need its streaming and export formats, but make it pass your Russian script because the built-in voices are optimized for English.

Public documentation does not provide an independent same-script listening comparison across these services. Use the official capabilities and prices below to choose a first round, then let your own script, blinded listening, and actual bill decide; models, formats, and prices were checked on September 24, 2026 and should be rechecked before production.

Filter by Russian support, control, format, and billing first

Reject any option that fails one of these four gates before you spend time listening.

Russian is explicitly documented. Language support qualifies a model for testing; it does not prove correct stress or natural delivery.
The control method fits your workflow. You need to know where pace, tone, and pauses are specified—and whether those instructions can accidentally be spoken.
The output format fits your pipeline. WAV or MP3 may be enough for editing, raw PCM can matter for streaming, and telephony often needs μ-law or A-law.
The billing unit is measurable. A service may charge by characters, text tokens, audio tokens, or seconds. “From $X per minute” is not a production budget until retries and rejected takes are included.

Use the table to choose your first test pair

All three services can enter a Russian test, but they differ in control, output formats, and billing. Use the table to decide what is worth testing first—not to declare a sound-quality winner.

Provider	Models and Russian support	Delivery controls	Export formats	Price evidence checked on 2026-09-24
Google Gemini	`gemini-3.8-flash-tts` and `gemini-3.8-flash-lite-tts`; Russian is listed for both	Sustained delivery in `speech_metadata.style`; point-in-time pauses and vocal events through tags such as `<short pause>`	Unary requests return 24 kHz mono 16-bit WAV; streaming returns raw PCM; μ-law and A-law are also available	Standard output through 2026-12-31 is $9 or $6 per 1M audio tokens; audio uses 25 tokens per second
OpenAI	`gpt-4o-mini-tts`, plus `tts-1` and `tts-1-hd`; Russian appears in the supported-language list	Instructions can control accent, speed, intonation, emotional range, tone, and whispering	MP3, Opus, AAC, FLAC, WAV, and 24 kHz raw PCM; streaming is supported	The official TTS guide does not list the current rate; record the live pricing-page or invoice amount on the test date
ElevenLabs	Eleven v3, v3 Conversational, Multilingual v2, and Flash/Turbo; Russian is listed for Multilingual v2 and Flash v2.5	Textual context, Stability, and Similarity; `seed` can improve consistency; `previous_text` / `next_text` can connect chunks	MP3, PCM, μ-law, A-law, and Opus	$0.10 per 1,000 characters for v3 and Multilingual; $0.05 for v3 Conversational and Flash/Turbo; taxes excluded

Vendor phrases such as “studio-grade,” “most stable for long-form,” or “highest quality” are starting points, not evidence that a model will handle your names, numbers, or terminology. Keep a candidate only after the same Russian script is accurate, stable across three runs, and affordable to correct.

Use a test script that mirrors your real workload

Do not test with a random paragraph or a vendor’s showcase sentence. Use a miniature version of your actual workload. A course script should include terminology and long explanations; an e-commerce flow should include SKUs, amounts, and addresses; an IVR script should include short commands, names, and numbers.

The first version should be neutral, with no provider-specific tags and no manual edits. The following Russian passage is a useful starting point. It deliberately remains in Russian in every localized version of this article because Russian pronunciation is what the test is meant to measure:

Добрый вечер! Заказ № 1847 готов к выдаче 5 октября в 18:30.

Сумма — 1 250 рублей 50 копеек. Код подтверждения: А-7-Б-9.

В письме указаны адреса example.ru/support и support@example.ru.

Сначала откройте за́мок, затем осмотрите старинный замо́к.

Компания ООО «Северный ветер» выпустила API для CRM и IoT.

Анна сказала: «Подождите… Я проверю данные и перезвоню через две минуты».

This passage probes several failure modes at once:

dates, time, money, decimals, and a character sequence;
Russian abbreviations, Latin letters, a URL, and an email address;
two readings of the same spelling with different stress;
short and long pauses;
the transition from narration to quoted speech;
Russian names and an organization name.

Add five to ten terms that are critical to your product: expert surnames, city names, brands, medical or legal language, or technical vocabulary. Store a reference reading next to the script that specifies the intended stress, number expansion, and abbreviation handling. Without an answer key, reviewers quickly end up debating taste rather than correctness.

Run three untuned baselines to expose instability

For each candidate, freeze the model, voice, speed, format, and all other settings. Generate the exact same uncorrected script once, then repeat it twice with identical settings. Three outputs are not meant to give you three chances to cherry-pick the best take; they reveal how much the result varies.

Rename files A1, A2, A3, B1, and so on, so listeners cannot see the provider. Ask at least two native Russian speakers to score them independently. For specialist material, at least one reviewer should understand the domain vocabulary.

A simple 0–2 rubric works well:

Criterion	0 points	1 point	2 points
Pronunciation and stress	An error changes meaning or forces a new take	A noticeable but repairable issue	All critical words are correct
Numbers, dates, abbreviations	Data are omitted or distorted	The source text must be rewritten	No correction is needed
Pauses and phrase boundaries	Meaningful units run together	Usable rhythm, but editing is needed	Pauses match the intended delivery
Stability across three runs	Words, timbre, or rhythm change materially	Minor variation	Predictable output
Audio artifacts	Clicks, repetitions, truncation, or clear failure	Small defects	No obvious defect
Readiness for use	Both regeneration and editing are required	One of them is required	The file can be accepted immediately

Define hard failure conditions before adding scores. A misread amount can disqualify an IVR recording even if the voice is pleasant. A rare-name error in an audiobook may be repairable, while voice drift across chapters may not be.

Use the second round to fix critical errors, not to tune forever

The baseline shows what happens without assistance. The second round should reveal how much work it takes to correct the output—not how long you can keep tuning until one lucky generation appears.

Google Gemini TTS

Gemini 3.8 treats the text field as a verbatim transcript. Sustained directions such as “calm, slow, and confident” belong in speech_metadata.style so they are not read aloud. A point-in-time pause can be placed in the transcript as <short pause>. Google’s documentation also recommends English inline tag names even when the transcript is not in English.

A unary request returns a complete WAV file with a RIFF header: 24 kHz, mono, 16-bit signed little-endian PCM. A streaming request returns headerless raw audio/l16 with the same basic audio parameters by default. Telephony workflows can request audio/mulaw or audio/alaw and specify a sample rate.

Both 3.8 models share the same API schema. Google positions gemini-3.8-flash-tts for higher fidelity, expressive control, difficult pronunciation, and long-form work, while gemini-3.8-flash-lite-tts is positioned for high-volume, low-latency, lower-cost speech. Treat those as vendor guidance until your Russian test confirms them.

OpenAI Speech API

With gpt-4o-mini-tts, instructions can control accent, speed, intonation, emotional range, tone, and whispering. Russian is in the supported-language list, but the documentation explicitly says the built-in voices are optimized for English. That makes a Russian script test essential, especially for regional delivery, surnames, and specialist terms.

The API returns MP3 by default and also supports Opus, AAC, FLAC, WAV, and 24 kHz raw PCM. The guide recommends WAV or PCM for faster response, and streaming lets playback begin before the whole file is complete.

There is also a product requirement to account for: OpenAI requires clear disclosure to end users that the voice is AI-generated rather than human.

ElevenLabs

The official guide lists Russian for Multilingual v2 and Flash v2.5 and recommends selecting a voice whose accent matches the target language and region. Textual phrases such as “she said excitedly” can influence delivery, but they are also spoken; if you use that technique, the phrase must be removed, rewritten, or edited out.

Output can be MP3, PCM, μ-law, A-law, or Opus. The models are nondeterministic: seed can improve repeatability but does not guarantee identical audio. For long material, the documentation recommends splitting the text and passing previous_text / next_text or adjacent request IDs to preserve prosodic continuity.

Up to two free regenerations apply only when the text, voice, and all parameters remain exactly the same. Any text or setting change creates a new paid generation. The documentation also states that commercial usage rights require a paid plan.

Include retries and rejected takes in the accepted-minute cost

Counting only the first request systematically understates cost. Divide every generation charge for the item by the duration of the audio you actually accept.

Accepted-minute cost = all generation spending for the item ÷ accepted audio duration in minutes.

Paid alternatives, retries after script edits, and rejected takes all belong in the numerator. Track editing time separately so API price and labor remain visible.

Google Gemini example

Google states that audio is billed at 25 audio tokens per second, so one generated minute uses 1,500 audio tokens. Under Standard pricing through December 31, 2026:

gemini-3.8-flash-tts: $9 per 1M output audio tokens, or $0.0135 per generated minute, plus text input;
gemini-3.8-flash-lite-tts: $6 per 1M output audio tokens, or $0.009 per generated minute, plus text input.

For Batch/Flex, output is about $0.00675 and $0.0045 per generated minute; for Priority, about $0.0243 and $0.0162. The official table doubles these rates starting January 1, 2027.

If you create three one-minute Flash-Lite takes and accept only one, output spending per accepted minute is already about $0.027, not $0.009. Add input tokens, taxes, and any other billed items from the actual account.

ElevenLabs example

ElevenLabs bills TTS by character rather than audio duration:

v3 and Multilingual: $0.10 per 1,000 characters;
v3 Conversational and Flash/Turbo: $0.05 per 1,000 characters.

A 1,200-character script costs $0.12 or $0.06 for one generation. If a final one-minute file requires three paid generations, the accepted-minute cost is $0.36 or $0.18. But the same 1,200 Russian characters may last 50 seconds or 90 seconds, so use the accepted file’s actual duration. The approximate “per minute” figures on the pricing page are averages, not a substitute for measuring your Russian speaking rate.

How to handle OpenAI pricing

The OpenAI TTS guide lists models, controls, and formats but not the current rate. On the test date, copy actual usage and cost from the live pricing page or invoice into the same worksheet; an old rate or the price of another audio product will make the comparison look precise while being wrong.

Choose the first test pair by workload

You do not need to test every service in the first round. Pick two based on content length, output path, and the correction work you can tolerate; expand the shortlist only when both fail.

Long courses, podcasts, and audiobooks: test Gemini Flash and Multilingual v2 first

For long-form Russian audio, first compare gemini-3.8-flash-tts with ElevenLabs Multilingual v2. Gemini provides verbatim scripts, structured style, and inline pause controls; ElevenLabs positions Multilingual v2 for stable long-form output and supports previous_text / next_text across chunks.

Start with Gemini when exact scripts, WAV/raw PCM, or structured two-speaker turns matter most. Start with ElevenLabs when voice choice and chunk continuity matter more; switch the lead candidate if chapter-to-chapter timbre drifts, critical words are misread, or corrections require repeated generations.

High-volume short prompts: test Gemini Flash-Lite and ElevenLabs Flash/Turbo first

For catalog text, notifications, and UI prompts, first compare gemini-3.8-flash-lite-tts with ElevenLabs Flash/Turbo. Both are positioned for lower cost or higher throughput, so choose on accepted-minute cost rather than the list rate.

ElevenLabs is easier to forecast when text length is stable and character billing suits your workflow. Gemini is the more direct first choice when you need raw PCM, μ-law, or A-law, or want to log audio-token usage; if retries and manual fixes erase the price gap, choose the option with fewer errors.

Existing streaming stack: let the decoder determine the first test

If your product already uses OpenAI Speech API, test gpt-4o-mini-tts first because it supports chunked streaming and WAV or PCM output. If exact recitation, structured delivery controls, and 24 kHz raw PCM matter more, test Gemini first.

Use ElevenLabs Flash as the first candidate when low latency and a broad voice choice are central. Change course if Russian stress errors or cleanup work raise end-to-end latency and cost, even when time to first audio looks good.

Telephony and IVR: test Gemini and ElevenLabs first

For telephony and IVR, test Gemini and ElevenLabs first because both can return μ-law or A-law directly, avoiding an extra transcode. Make amounts, dates, names, and confirmation codes hard-fail checks: a pleasant voice cannot compensate for wrong information.

Add OpenAI only when you already have a reliable PCM transcoding path. Otherwise, reusing a familiar API can create more conversion and troubleshooting work than it saves.

Two or more speakers: Gemini first for two, Eleven v3 first for more

For exactly two fixed roles, test Gemini 3.8 first; for more speakers or more dramatic dialogue, test Eleven v3 first. Change the recommendation if Russian voices do not fit the roles, speakers bleed into each other, or long turns lose continuity.

Brand or cloned voice: clear rights before comparing sound

For a brand or cloned voice, first eliminate any option that cannot meet consent, retention, and commercial-use conditions, then test long-form quality. A technically convincing clone is not automatically cleared for publication, storage, or monetization.

Move to a pilot only after all six checks pass

A single failed item is enough to keep the candidate out of production until you fix it or choose another option.

critical Russian words, surnames, amounts, and abbreviations are correct;
pace and pauses are controllable without instructions leaking into the audio;
three identical requests are stable enough for the use case;
format and sample rate fit editing, streaming, or telephony;
commercial rights and synthetic-voice disclosure rules are understood;
cost includes every generation and is divided by accepted duration;
the model ID and price have been rechecked immediately before production.

Reduce the first round to two candidates and blind-rate the same script across three runs. Start long-form work with Gemini Flash and ElevenLabs Multilingual v2, high-volume short prompts with Flash-Lite and Flash/Turbo, and telephony with Gemini and ElevenLabs; keep only the option that reads critical content correctly, stays stable, and delivers a controllable accepted-minute cost.

Official references

Checked on September 24, 2026:

Originally published on the BetterToken blog.

Gemini Omni video extension and frame interpolation: API workflow and continuity checks

Adela — Mon, 28 Sep 2026 06:29:09 +0000

You may already have a short clip that ends before the action is complete, or only a first and last frame with no motion between them. With gemini-omni-1.1-flash, you can append a 3–10 second continuation or generate a transition between two boundary images; by the end, you will know which mode to use, how to call the API, and how to decide whether the result is deliverable.

Use tail extension when you want to preserve the motion, camera, and sound of an existing clip; use first/last-frame interpolation when the start and finish are fixed and only the middle is missing; an MP4 response only completes generation, so you still need to inspect the subject, motion, seam, and audio.

Should you extend the clip or interpolate two frames?

If you have source video, start with tail extension; if a specific final image must be reached, start with interpolation. Extension is not bounded by a target final frame, so using it for that job can add another generation and review cycle.

Job	Input	Best use	Continuity to inspect most closely
Tail extension	One video, optionally with reference images	Continue an action, camera move, or scene for a few seconds	Pose, speed, camera direction, lighting, and audio around the seam
First/last-frame interpolation	A first frame, a last frame, and a transition prompt	Fill in motion between two defined states	Identity, spatial relationships, motion path, and arrival at the target frame

Uploaded-video extension is designed for short increments: the official guide describes a 3–10 second continuation, and the prompt guide also documents 10-second steps up to 40 seconds total. Your uploaded clip must be 10 seconds or shorter, and footage can only be appended at the tail; use a conventional editor if you need to insert a shot at the beginning or in the middle.

Decide these four things before you call the API

Fix the model, output specification, cut behavior, and source material you will use for comparison before generating. Missing one of these decisions often means rerunning the job or being unable to tell whether a seam change came from the model or the source.

Use the GA model ID

Use the GA model ID gemini-omni-1.1-flash. It became generally available on August 27, 2026; the older gemini-omni-flash-preview endpoint is scheduled for deprecation on September 30, 2026.

Validate continuity at 720p first

For the first pass, use the default 720p so continuity debugging stays separate from high-resolution delivery. The resolution field in response_format accepts 360p, 720p, 1080p, and 4k; the documentation identifies 1080p and 4k as upscaled outputs, with 16:9 as the default aspect ratio and 9:16 available on request. For results larger than 4 MB, especially above 720p, use delivery="uri", wait until the file becomes active, and then download it.

Choose between one continuous shot and a deliberate cut

Decide whether the extension is one continuous shot or an intentional cut. In an extension prompt, 0s means the start of the newly generated portion, not the start of the source clip. Ask for a “single continuous shot” and “no scene cuts” when the action must remain unbroken. When a cut is intentional, state when it should happen within the extension.

Keep the source clip and boundary images

Retain the source clip and both boundary images. The official prompt guide says Omni uses the last 10 seconds of the original video as context and may edit some final input frames to make the transition. That makes a source-versus-output comparison part of the continuity review, not an optional backup step.

Have a source clip? Extend it from the tail

Use tail extension when you already have video and want the action, camera move, or scene to continue for a few seconds. Start with a minimal 720p request, then tighten the subject, motion, camera, and audio constraints.

Run a minimal 720p extension request

The Python example below uploads the clip through the Files API, waits for processing, and passes the video URI and continuation instructions to interactions.create. It stays at 720p so you can solve continuity before dealing with high-resolution file delivery.

import base64
import time
from google import genai

client = genai.Client()
video_file = client.files.upload(file="my_video.mp4")

while video_file.state == "PROCESSING":
    time.sleep(10)
    video_file = client.files.get(name=video_file.name)

if video_file.state == "FAILED":
    raise ValueError(video_file.state)

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input=[
        {"type": "video", "uri": video_file.uri},
        {
            "type": "text",
            "text": (
                "Continue the scene as one unbroken shot. "
                "Keep the same subject, wardrobe, camera direction, lighting, and motion speed. No scene cuts and no new dialogue."
            ),
        },
    ],
    response_format={"type": "video", "resolution": "720p"},
)

with open("extended.mp4", "wb") as f:
    f.write(base64.b64decode(interaction.output_video.data))

Write prompts as observable conditions

Do not stop at “continue the scene.” State at least five observable dimensions: what must remain unchanged about the subject, how the action should develop, how the camera should move, whether light or environment may change, and whether cuts or new sound are allowed. “The right hand keeps rising at the same speed” is testable; “make it natural” is not.

Set `task` only when prompting selects the wrong mode

If prompting does not select extension mode, add {"video_config": {"task": "extend"}} under generation_config. The guide recommends prompting first because setting task adds stricter constraints. For a video generated in the preceding turn, previous_interaction_id can continue the sequence without another upload. That path requires stored interaction state; a result created with store=false cannot be edited later through that ID.

Change the plan when dialogue or region limits apply

There are important dialogue and region boundaries. An uploaded video in which someone is already speaking cannot currently be extended with additional dialogue; a silent continuation or a prompt that adds no dialogue is allowed. Spoken continuation is supported for multi-turn extension of model-generated video through previous_interaction_id. Editing and extending uploaded video are currently unavailable to users in the EEA, Switzerland, and the United Kingdom, while extension of model-generated video remains supported in available regions.

Only have boundary frames? Generate the motion between them

Use first/last-frame interpolation when the start and finish are clear but the motion between them is missing. Submit the two images in order and describe how the subject, camera, and environment should move from the first state to the last.

Submit the two boundary images first

Interpolation fits a job with clear boundary states but no middle motion. Put the two images in order in input, then describe how the subject, camera, and environment should travel from the first state to the last. This complete example reads local JPEGs, encodes them, and requests a 720p result.

import base64
from pathlib import Path
from google import genai

client = genai.Client()

first_frame_b64 = base64.b64encode(Path("first.jpg").read_bytes()).decode()
last_frame_b64 = base64.b64encode(Path("last.jpg").read_bytes()).decode()

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input=[
        {"type": "image", "data": first_frame_b64, "mime_type": "image/jpeg"},
        {"type": "image", "data": last_frame_b64, "mime_type": "image/jpeg"},
        {
            "type": "text",
            "text": (
                "Transition naturally from the first frame to the last frame. "
                "Preserve subject identity and camera direction, keep the motion path continuous, and avoid abrupt cuts."
            ),
        },
    ],
    response_format={"type": "video", "resolution": "720p"},
)

with open("interpolation.mp4", "wb") as f:
    f.write(base64.b64decode(interaction.output_video.data))

Use `image_to_video` only if the mode is still unclear

After submitting the images in order, state that the first is the start and the second is the finish. If the mode is still wrong, use image_to_video as a task value; it supports a precise description of subject, camera, and motion rather than replacing one.

The larger the difference, the more you should sequence the changes

Compatible boundary frames make the problem easier to specify. Keep subject identity, aspect ratio, camera axis, and spatial layout reasonably consistent, or explain the order of change: turn the subject first, move the camera second, and change the light last. That is production guidance, not a guarantee of model behavior; the returned video still has to be inspected.

Is the result deliverable? Inspect the seam, subject, motion, and audio

The standard is not whether the result “looks close enough,” but whether defects can be pointed out and converted into actionable revision instructions. Watch once at normal speed, inspect the seam slowly or frame by frame, and listen to the audio in a separate pass.

Dimension	What to inspect	Actionable revision wording
Subject	Face, hair, wardrobe, accessories, body proportions, hands, and held objects	“Keep the coat color and the object in the right hand unchanged.”
Motion	Direction, speed, balance, contact points, gaze, and camera trajectory	“Continue the current stride to the right without accelerating or reversing.”
Edit and image	Jump cuts, exposure, color temperature, depth of field, perspective, and background geometry at the seam	“Keep the same camera axis and focal length; do not cut.”
Audio	Ambience, music beat, dialogue, reverb, volume, clicks, and new noise	“Continue the ambience, add no dialogue, and keep the music beat unchanged.”

Check the seam for extension and both endpoints for interpolation

For extension, concentrate on roughly the last second of the source and the first second of the generated continuation, and verify whether the output altered the original tail frames. For interpolation, inspect the middle path but also confirm that the start really corresponds to the first image and the finish reaches the second image, rather than merely producing something stylistically similar.

Tighten one variable per revision

On revision, tighten one major variable at a time. Fix identity first, then motion, then camera and audio. This makes each prompt change easier to evaluate. Describe the location and behavior of the defect—“the left sleeve changes color at the seam”—instead of asking for something vague such as “more cinematic” or “smoother.”

Do not force this endpoint into these jobs

This endpoint is not a one-call editor when you need to insert a shot into the middle of a long program, continue existing dialogue, or reason across several source clips. If any limit below affects the job, split the work into shots or switch to a conventional editing workflow first.

Uploaded clips can only be extended at the tail and must be 10 seconds or shorter.
Additional dialogue cannot be generated from an uploaded clip in which someone is speaking; voice editing itself is unsupported.
Audio references cannot be uploaded. Audio in a video reference is ignored.
Video references support at most three clips of up to three seconds each. Reasoning across multiple videos is unsupported.
System instructions, temperature, top_p, stop sequences, and a separate negative-prompt field are unsupported. Put negatives in the ordinary prompt, such as “Do not cut.”
Every generated video includes invisible SynthID, and both inputs and outputs are subject to content-safety filtering.
The documentation marks English prompts as fully supported; other languages have not been evaluated and may vary.

A practical fallback is to generate short shots separately, then assemble and mix them in a conventional editor. That is usually faster than repeatedly asking a tail-extension endpoint to perform mid-program insertion, dialogue continuation, or multi-clip reasoning.

Run this checklist before delivery

A successful generation call is not a quality approval. Before delivery, confirm that:

you retained the input video, output video, and both boundary images;
you recorded the model ID, resolution, and complete prompt;
you inspected the extension seam frame by frame and checked whether source tail frames changed;
you confirmed that interpolation starts at the first image and actually reaches the second;
you listened to the audio separately for gaps, clicks, or unexpected new noise;
you checked regional, input-duration, dialogue, and reference-media limits.

If any item is unexplained, revise the result instead of approving it from the API status alone.

Official references

Originally published on the BetterToken blog.

Veo 3.1 Cost per Accepted Video: Calculate Duration, Resolution, and Retries

Adela — Mon, 28 Sep 2026 06:27:07 +0000

You may have calculated that one eight-second Fast clip at 1080p costs only $0.96 and treated that as the price of a usable shot. If the third generation is the first one you approve, the bill is already $2.88; add several shots and the gap grows quickly. By the end of this guide, you can calculate cost shot by shot, set a retry stop-loss, and decide which tier and resolution to test first for your delivery specifications.

Use this formula to calculate the real cost of an accepted video

The generation cost of a deliverable video is not final runtime multiplied by one rate; it is the total of every billable attempt across every shot.

Cost of one successful generation:

billable seconds × the per-second rate for the selected tier and resolution

Generation cost of an accepted video:

Σ (billable seconds per shot × per-second rate × billable attempts)

For example, one eight-second Fast generation at 1080p costs 8 × $0.12 = $0.96. If the third result is the first usable one, that shot costs $0.96 × 3 = $2.88 to generate.

A “billable attempt” here means a version that was generated successfully and incurred a charge. A request that never produces a video is different from a generated result that you later reject during review.

Choose a tier by scenario: what should you test first when cost matters?

For a cost-first workflow, test Lite first for 720p or 1080p and Fast first for 4k; move to another tier only when the current choice does not pass your acceptance criteria.

Your scenario	Test first	Why	When to change
High-volume drafts, social experiments, or internal previews at 720p/1080p	Lite	At $0.05/sec for 720p and $0.08/sec for 1080p, it has the lowest official rate of the three tiers	Test Fast if Lite cannot meet your criteria for subject, motion, composition, or consistency
You need 1080p and want room to iterate without starting at the highest rate	Fast	Its 1080p rate is $0.12/sec, versus $0.40/sec for Standard	If Fast reaches your stop-loss without passing, revise the prompt or shot design first; test Standard only if you still need another tier comparison
The final deliverable explicitly requires 4k	Fast	Fast costs $0.30/sec at 4k; Lite does not support 4k, and Standard costs $0.60/sec	Test the same shot with Standard only when Fast misses specific acceptance criteria; do not default every shot to Standard
You need scene extension, last-frame control, or integration with a legacy pipeline	Veo 3.1	Google lists these as specific Veo 3.1 use cases	If you do not need these capabilities, compare Gemini Omni Flash before committing to a Veo 3.1 workflow

This is a cost-first test order, not a quality ranking. A lower rate does not guarantee approval, and a higher rate does not guarantee success on the first attempt. Write the acceptance criteria first, then find the least expensive workflow that actually meets them.

Official rates set the floor for every attempt

As of September 24, 2026, paid Veo 3.1 usage in the Gemini API is billed per second, with both tier and resolution determining the cost. Check the official Google pricing page again before approving a production budget because prices and model status can change.

Tier	Model ID	720p	1080p	4k
Standard	`veo-3.1-generate-preview`	$0.40/sec	$0.40/sec	$0.60/sec
Fast	`veo-3.1-fast-generate-preview`	$0.10/sec	$0.12/sec	$0.30/sec
Lite	`veo-3.1-lite-generate-preview`	$0.05/sec	$0.08/sec	Not supported

Four conclusions directly affect the budget:

Standard costs the same at 720p and 1080p. If delivery genuinely requires 1080p, there is no API-price reason to fall back to 720p.
Fast rises from $0.12/sec at 1080p to $0.30/sec at 4k, a 2.5× increase.
Lite does not support 4k, so a 4k project must be budgeted with Fast or Standard.
The listed prices are for video with audio by default; there is no published no-audio discount you can safely subtract.

None of the three Veo 3.1 model IDs has a free tier. Google also says that when certain audio-processing problems prevent a video from being generated, charging applies only when a video is generated successfully. A generated version you later discard should still be recorded according to the actual bill.

Eight-second shots: what do one, three, and five attempts cost?

A small per-attempt price can become a large line item because the bill grows in direct proportion to billable attempts. Eight seconds is used only to make the arithmetic easy; it is not a claim about a fixed or maximum generation length.

Tier	8 sec at 720p	8 sec at 1080p	8 sec at 4k
Standard	$3.20	$3.20	$4.80
Fast	$0.80	$0.96	$2.40
Lite	$0.40	$0.64	Not supported

For an eight-second 1080p shot, retry scenarios look like this:

Billable attempts	Standard	Fast	Lite
1	$3.20	$0.96	$0.64
3	$9.60	$2.88	$1.92
5	$16.00	$4.80	$3.20

The table cannot tell you which tier has better quality. It can answer a more useful budgeting question: how many paid attempts are you willing to fund for one shot? If you cap Fast 1080p at five attempts, the API budget for that shot is $4.80. Once the cap is reached, change the prompt, redesign the shot, or change the workflow instead of generating without a limit.

Multi-shot videos must be calculated shot by shot

Multiplying a final 32-second runtime by one rate misses the cost of every discarded version. A useful production sheet needs one row per shot, not just one row for the whole project.

Suppose a project contains four eight-second shots, all generated with Fast at 1080p for $0.12/sec. The shots require 1, 2, 3, and 4 billable attempts respectively:

Shot	Seconds	Attempts, example	Calculation	Cost
A	8	1	8 × $0.12 × 1	$0.96
B	8	2	8 × $0.12 × 2	$1.92
C	8	3	8 × $0.12 × 3	$2.88
D	8	4	8 × $0.12 × 4	$3.84
Total	32 accepted seconds	10 shot attempts		$9.60

A one-pass calculation for 32 seconds would be $3.84; the shot-level calculation is $9.60. The extra $5.76 comes from additional versions, not from a longer finished video.

Set three retry limits when you do not know the acceptance rate

Do not borrow an imaginary “industry-average retry rate”; define target, stress, and stop-loss scenarios for each shot. This shows the cash range before production begins and tells the team when it must stop and change the plan.

Target scenario: the number of attempts you consider reasonable for an ordinary shot.
Stress scenario: a higher cap for difficult motion or an important hero shot.
Stop-loss scenario: the hard limit after which you change the prompt, redesign the shot, change resolution, or test another tier.

For the same eight-second Fast 1080p shot, one, three, and five attempts cost $0.96, $2.88, and $4.80. You might set three attempts as the target and five as the stop-loss. Every attempt after the fifth adds another $0.96 without guaranteeing that the result will be closer to approval.

Important shots can receive a higher cap, but the cap should be written into the budget before generation starts. Otherwise, “the attempt is cheap” can turn into unlimited retries whose total exceeds a higher-priced alternative.

Choose resolution by delivery need: do not make every draft 4k

Unless 4k is a real delivery need, use the lowest resolution that lets you evaluate the shot and reserve 4k for selected final assets. This lowers both the first attempt and every failed retry that follows it.

Using the official prices checked on September 24, 2026:

Standard: 720p and 1080p cost the same; 4k costs 50% more.
Fast: 1080p costs 1.2× the 720p rate; 4k costs 2.5× the 1080p rate.
Lite: 1080p costs 1.6× the 720p rate; 4k is not supported.

With Standard, 720p and 1080p have the same API price if your workflow supports 1080p. Fast is different: an eight-second shot rises from $0.96 at 1080p to $2.40 at 4k. At five attempts, the comparison is $4.80 versus $12.00.

For social posts, internal previews, or composition checks without a hard 4k need, do not upgrade every intermediate version merely for consistency. Apply 4k only to approved shots when the delivery channel truly needs it.

Put the API bill back into the full production budget

Generation is only one production cost; editing, sound, captions, and human review belong in the same budget. When generation is inexpensive, selection and editing may cost more. With high resolution and many retries, the API bill can become a major line item.

Record at least these fields for every shot:

Field	What you should enter
Shot ID	A, B, C, or the storyboard name
Billable seconds	The seconds shown in the actual billing record
Tier and resolution	Standard, Fast, or Lite; 720p, 1080p, or 4k
Current rate	The per-second price from the official page
Target / stop-loss attempts	The planned attempt count and hard cap
Actual billable attempts	Based on request results and billing records
Shot generation cost	seconds × rate × billable attempts
Acceptance result	accepted, revise, or abandoned

At project level:

full production budget = total generation cost + editing + voice/music + captions/localization + human review + storage and other costs

When comparing two workflows, do not compare only the per-second rates. Put actual attempt counts, human selection time, and post-production costs into the same sheet to see which workflow truly costs less.

Use your own records for the numbers public pricing cannot provide

Public pricing tells you the rate per second, but it cannot supply your retry rate, acceptance rate, taxes, or actual billing-rounding behavior. Those variables directly affect the final budget and should come from request logs and invoices.

Google’s public pricing information does not publish a universal average retry count or promise that any tier will pass review on the first attempt. The one-, three-, and five-attempt examples in this article are budgeting scenarios, not model success rates.

For actual reconciliation, use durations supported by the current request, billable seconds shown in your account, real billable attempts, and your own acceptance history. After several projects, group attempts by shot type—people, products, complex motion, or dialogue—to make the next estimate more accurate.

Add taxes, exchange rates, card fees, and platform fees separately. Do not mix Gemini API, Vertex AI, Flow, Gemini app subscriptions, or third-party API prices in one rate table because their billing models may differ.

Frequently asked questions

How much does Veo 3.1 cost per second?

Using Gemini API prices checked on September 24, 2026, default video-with-audio rates range from $0.05/sec for Lite at 720p to $0.60/sec for Standard at 4k. The exact rate depends on tier and resolution.

Is it cheaper without audio?

The official pricing page lists default prices with audio and does not publish a no-audio discount that can be used in this calculation. Do not subtract an audio charge unless the current official page explicitly lists a separate rate.

Are failed generations billed?

Google says that when certain audio-processing problems prevent a video from being generated, charging applies only when the video is generated successfully. A successfully generated clip that later fails your creative review is a different case and should be counted according to the actual bill.

Is there a Veo 3.1 free tier?

The current official pricing table shows no free tier for any of the three Veo 3.1 model IDs. Budget testing as paid attempts.

Build your budget in four steps

Start with the delivery specification, calculate one attempt, and then set a retry stop-loss. Use this sequence:

Write down the duration, resolution, and acceptance criteria for every shot.
Choose the first tier to test using the cost-first order and calculate its per-attempt price.
Calculate one-, three-, and five-attempt scenarios, then set a hard cap for important shots.
Record actual billing and acceptance shot by shot, and add editing, sound, captions, and human labor.

If the total is too high, first remove unnecessary 4k generations and unlimited retries; then consider another tier or redesigning the shot. That optimizes the cost of a deliverable video, not a deceptively low one-attempt price that retries can multiply.

Originally published on the BetterToken blog.

Mistral Studio Prompt and Skill Version Control: A Traceable Release Workflow

Adela — Mon, 28 Sep 2026 06:25:05 +0000

You ship a Prompt change, the output regresses the next morning, and nobody can immediately say which version is live, who approved it, or what should be restored. Mistral Studio's immutable versions, named owners, version comparison, audit logs, and rollback can turn that kind of ad hoc change into a traceable release chain.

By the end of this guide, you can set up a minimum process for one Prompt or Skill: name an owner, freeze a candidate, test it against fixed cases, promote it only after approval, and return to a known-good version when behavior degrades.

If it affects real users, stop managing it like ordinary copy

You need a versioned release process as soon as a Prompt or Skill is edited by several people, runs in production, or must be investigated and restored after a failure. A solo experiment can stay lightweight. Once an output affects customers, business actions, or downstream systems, record at least the production version, owner, test result, approver, and rollback target.

A Prompt determines how a model responds. A Skill may also choose a tool, pass parameters, and produce a structured contract. The wrong version can therefore change policy, tone, permissions, or downstream fields—not just wording—and make diagnosis much slower.

Studio provides versioning and traceability; you still define “pass”

Mistral Studio answers which version ran, who owns it, what changed, and whether you can go back, but your team still decides what acceptable behavior means. In its July 9, 2026 announcement, Mistral described Prompts and Skills as tracked assets with immutable versions, owners, labels, full history, audit logs, comparison, and rollback.

Studio capability	What it helps you answer	What you still need to define
Immutable versions	Which exact content was running during an incident	Which changes require a candidate and who may release it
Version comparison and rollback	What changed between two versions and how to restore a known-good one	What triggers rollback and how recovery is verified
Named owners	Who is accountable for each Prompt or Skill	Who owns business behavior and who reviews it
Classification labels	Which asset is `Staging` or `Production`	Entry criteria for each label and whether production can ever point to more than one version
Audit logs	Who changed what and when	Where approval evidence, test results, and incident records live
Observability and lineage	Which asset version produced a production output; lineage is the link from output back to the assets behind it	Which quality, compliance, latency, or cost indicators define regression
Workspace sharing and access control	How an asset moves from creator-only access to a team or organization	Who may view, edit, approve, and invoke it
Skills delivered as MCP servers	How the executed Skill can remain in the same governed system as the versioned asset	Client compatibility, permissions, and production validation

Studio lets a domain expert or developer edit and test a Prompt or Skill without waiting for a full code pipeline on every attempt. A production change should still pass your existing tests and approvals. Mistral gives SDK-based label promotion connected to CI/CD such as GitHub Actions as one example; check the current documentation for exact interfaces and configuration.

Name one accountable owner before adding more collaborators

Every production asset should have one clearly named primary owner, even when a small team combines several roles in one person. Version history cannot compensate for a setup in which everyone can edit but nobody owns the resulting behavior.

Role	Minimum responsibility	How a small team can combine it
Asset Owner	Defines purpose, allowed and prohibited behavior, acceptance criteria, and next-version priorities	May also act as Release Operator, but must still record the exact version being approved
Reviewer / Approver	Reviews the diff, test evidence, risk, and production decision	A colleague may review low-risk changes; use independent review for policy, tool-permission, or critical-output changes
Release Operator	Promotes the label or runs the release pipeline, then records time, target version, and rollback target	May be the Owner, but cannot skip version and approval records
Incident / Audit Owner	Locates the active version, coordinates rollback, and preserves the incident record	Can be an on-call or platform owner

If only one person maintains the asset today, do not leave every responsibility blank. Put the same name in multiple roles if necessary, while keeping four answers visible: who changed it, who reviewed it, who released it, and who can order a rollback.

A small team still needs Draft, Staging, and Production

The minimum setup is not four separate systems; it is a clear distinction between editing, validating, and running. Add Shared when several people collaborate. With a single maintainer, collaboration can remain inside Draft, but the boundary between Staging and Production should not disappear.

Draft — creator-controlled, open to rapid edits and experiments.
Shared — visible in the workspace for collaboration and review, but not used in production.
Staging — a frozen candidate under fixed tests and approval; do not keep editing it while it is being evaluated.
Production — the approved immutable version that represents the single current production baseline.

These names are a team convention, not a mandatory Studio state machine. What matters is that each state has explicit entry criteria, approval is attached to one exact version, and only one version represents the current production baseline for an asset.

Run every release in seven version-linked steps

1. Freeze the current baseline before you change anything

Record the production version and rollback target before editing. At minimum, capture the asset name, owner, production version ID, production label, latest release time, and previous known-good version.

Without that baseline, even a passing candidate cannot be compared against a reliable starting point. During an incident, the team also has to guess what it should restore.

2. Create a candidate instead of overwriting production

Save every change as a new immutable version and state why it exists, what should change, and what must not change. A useful change note answers three questions:

Which user, policy, or operational problem triggered the work?
Which behavior is expected to change?
Which existing behaviors must remain unchanged?

“Improve the Prompt” cannot guide a test. A useful note is more like: “When the order number is missing, ask for it before proceeding; do not change the refund-policy answer or the JSON field names.”

3. Define pass conditions before running a fixed case set

Do not decide which version ‘looks better’; give every case an observable pass condition. Fixed cases make versions face the same inputs and stop reviewers from selecting only favorable examples.

Change type	Test first	Cost of choosing too narrow a test scope
Tone or wording	Normal requests, brand voice, prohibited phrasing	A few polished examples can hide old failures on edge inputs
Policy or refusal rules	Allowed, refused, escalated, and insufficient-information cases	A request that should be refused may pass, or a normal request may be blocked
Tool use	Tool choice, parameters, failure paths, permission boundaries	The text may look fine while the Skill calls the wrong tool or sends bad arguments
Structured output	Required fields, types, enum values, downstream compatibility	Downstream parsing fails, often later than a visible wording regression
Historical bug fix	The original failure and nearby cases	One example is fixed while an older behavior breaks again

A practical minimum covers normal requests, missing or ambiguous input, policy and safety boundaries, tool and output contracts, and previous regression cases. High-risk assets need a broader set. A low-risk internal tool may begin smaller, but every case still needs a clear decision rule.

4. Review the exact diff, then approve the exact version

A Reviewer should approve one immutable version, not a Draft that can keep changing after review. Use version comparison to confirm:

only the intended instructions changed;
policy, tone, tool permissions, and output structure did not shift unexpectedly;
the new rules do not conflict with each other;
the test evidence belongs to this exact candidate;
the rollback target still exists and is usable.

If someone changes one sentence after approval, create another version and rerun the affected checks instead of reusing the old approval.

5. Point the production label only at an approved version

Promote the candidate to Production only after tests and approval are complete. At minimum, the pipeline should verify the candidate version ID, approval record, test result, and whether the production baseline still matches the one that was reviewed.

If another release changed production after approval, stop and compare again. Silently overwriting that newer baseline can erase somebody else’s change and makes the earlier approval irrelevant.

6. Observe the release with existing metrics and trace anomalies to a version

A release needs an explicit observation window, not just a successful promotion. Use Observability, lineage, and telemetry to connect abnormal output to the relevant Prompt or Skill version, then apply the quality, compliance, latency, or cost indicators your organization already uses.

Mistral does not publish a universal threshold for every task, so do not copy one arbitrary percentage. A customer-service Prompt might track incorrect policy answers and human escalation. A tool-using Skill might track invocation failures, invalid parameters, and downstream parse errors. Record the time window, affected scope, representative anomalies, and decision owner.

7. Close a healthy release or enter rollback immediately

If the observation window is healthy, preserve the candidate, tests, approver, and promotion time; if behavior clearly regresses, execute the prepared rollback. Do not wait for an incident to decide for the first time who may roll back, which version to restore, and which checks confirm recovery.

Write the rollback playbook before the release

A minimum rollback playbook is usable if it answers what to pause, which version to find, how to restore it, and how to confirm recovery. Run it in this order:

Pause new promotions so the production baseline cannot move again.
Use lineage to identify the asset and production version connected to the anomaly.
Compare the problematic version with the previous known-good version and confirm the rollback scope.
Restore the known-good version or point the production label back to it.
Rerun critical cases and inspect the necessary production indicators to confirm recovery.
Preserve the failed version, triggering evidence, and post-incident conclusion instead of deleting history.

Rollback is not deletion. Keeping the failed version allows the team to explain what changed, who approved it, why the original tests passed, and which cases should be added next time.

Keep one minimum record for every release

When these fields are available in one place, an incident review does not have to reconstruct the story from chats and tickets. You can start with a structured table rather than a large governance platform.

Field	Question it must answer
Asset	Which Prompt or Skill is this, and what job does it perform?
Owner	Who is ultimately accountable for production behavior?
Production version	Which immutable version was active before the change?
Candidate version	Which exact version was tested and approved?
Change reason	Which user problem, policy change, or incident triggered it?
Test set and result	Which fixed cases ran, and which passed or failed?
Reviewer and approval time	Who approved which exact version, and when?
Promotion time	When did it enter production, and who performed the action?
Rollback target	Which known-good version will be restored after regression?
Observation / incident link	Where is the post-release observation or incident record?

Start with one high-impact asset, not a company-wide rollout

Choose a Prompt or Skill that affects real users, changes frequently, and has already shown behavioral drift. It will expose gaps in the process quickly and show whether version tracing and rollback actually work.

Start by naming one Owner, identifying the current production and rollback versions, building 10–20 fixed regression cases, and defining entry criteria for Draft, Staging, and Production. Then run one candidate release and one rollback exercise. Confirm that the audit log answers who changed what and when, and that lineage maps a production output to the correct version.

Once that loop works reliably, copy it to the next asset. Measure progress by the number of assets that truly have an owner, tests, a release chain, and a rollback path—not by the length of the governance document.

Recheck the current Studio UI, SDK, and permissions before implementation

Mistral's announcement describes versions, owners, labels, audit logs, comparison and rollback, Observability, lineage, workspace sharing, and MCP delivery for Skills, but implementation details should come from the current documentation. Label-promotion APIs, permission models, CI/CD configuration, and interface locations can change as the product evolves.

The announcement also does not provide a universal task success rate, measured quality gain, or standard rollback threshold. Your final release decision therefore needs to come from your own fixed cases and production indicators, not from treating a feature list as test evidence.

Originally published on the BetterToken blog.

GPT-6 Luna vs GPT-5.6 Luna: Calculating the Real Cost of a Successful Codex Task

Adela — Mon, 28 Sep 2026 06:23:02 +0000

You are not trying to decide which Luna generation sounds newer; you need to know which model should run the next batch of Codex tasks and when to switch after a failure. By the end, you can choose a first candidate from per-attempt cost, then use acceptance rate, retries, and manual-repair time to calculate the real cost of each successful task.

Start here: test `gpt-6-luna` first for most automatically verifiable tasks

gpt-6-luna is the better first candidate when the scope is clear and tests, lint, or an acceptance script can reject a bad result quickly. Its lower per-attempt token cost lets you build a baseline cheaply, then decide whether complex work should move back to gpt-5.6-luna.

Your situation	What to do first	What would change the recommendation
Small fixes or batch changes with automated tests	Start with `gpt-6-luna`	It fails repeatedly, or manual repair erases the price advantage
Cross-file features, refactors, or interface changes	Run paired tests on both models	Use `gpt-5.6-luna` for this class if it materially cuts retries and repair time
Input is near or above 272K	Remove irrelevant files, shorten history, or split the task first	If context cannot be reduced, compare with long-context rates
You are using ChatGPT or Codex plan allowances	Use the plan dashboard and credit rules, not the API table	Apply the token prices below only after moving to an API key or custom provider

Public information does not yet include paired results for both models on the same Codex version, repository, and reasoning effort. Price can determine your testing order, but your own task data should determine the default model.

The interface limits are similar, so they do not predict coding quality

The two models have similar core interfaces and context limits, so the specification sheet cannot tell you which one will be more reliable in your codebase. Both support text and image input, text output, the Responses API, reasoning tokens, and reasoning effort from none through max; each has a 1,050,000-token context window, a maximum input of 922,000 tokens, and a maximum output of 128,000 tokens.

Item	`gpt-6-luna`	`gpt-5.6-luna`
Official positioning	Efficient model for focused, high-volume tasks	Model for cost-sensitive, high-volume workloads
Knowledge cutoff	2026-05-18	2026-02-16
Context window	1,050,000 tokens	1,050,000 tokens
Default reasoning effort	`medium`	`medium`

Those specifications do not prove that either model will have a higher acceptance rate, finish faster, or require fewer retries in your codebase. Codex outcomes also depend on task shape, context quality, tool permissions, client version, reasoning effort, and the acceptance criteria you apply.

Below 272K, `gpt-6-luna` has the lower token rates

When complete input context is at or below 272K, gpt-6-luna costs half as much for input, cache reads, and cache writes, while its output rate is about 41.7% of gpt-5.6-luna. The table was verified on 2026-09-25, uses USD per 1 million tokens, and compares only OpenAI Standard with BetterToken API billing—not ChatGPT or Codex plan allowances or credit billing.

At or below 272K: calculate directly from this table

Use this tier directly when the complete input context of each request stays at or below 272K; do not apply the long-context multipliers.

Model ID	Provider	Input	Cache read	Cache write	Output
`gpt-6-luna`	OpenAI Standard	$0.10	$0.01	$0.125	$0.50
`gpt-6-luna`	BetterToken	$0.068	$0.0068	$0.085	$0.34
`gpt-5.6-luna`	OpenAI Standard	$0.20	$0.02	$0.25	$1.20
`gpt-5.6-luna`	BetterToken	$0.136	$0.0136	$0.17	$0.816

BetterToken prices are dynamic, so view current prices on the day you publish or buy and use the values shown then. BetterToken is not an OpenAI product. The prices above are for its GPT group used through APIs, Codex, and tools that support a custom Base URL; they are not ChatGPT or Codex subscription allowances.

OpenAI Batch and Flex are priced at 50% of Standard for these models, so they are lower than the BetterToken rates shown here. They are outside this comparison. The table must not be read as a claim that BetterToken is cheaper than every OpenAI processing option.

Above 272K: reduce the input first, then use long-context rates if needed

If the task can be split, remove irrelevant files, shorten history, or divide the work before crossing the threshold because the entire request becomes more expensive. The threshold uses the complete input context, including cached portions; above 272K, input, cache reads, and cache writes cost 2× the short-context rate, while output costs 1.5×:

Model ID	Provider	Input	Cache read	Cache write	Output
`gpt-6-luna`	OpenAI Standard	$0.20	$0.02	$0.25	$0.75
`gpt-6-luna`	BetterToken	$0.136	$0.0136	$0.17	$0.51
`gpt-5.6-luna`	OpenAI Standard	$0.40	$0.04	$0.50	$1.80
`gpt-5.6-luna`	BetterToken	$0.272	$0.0272	$0.34	$1.224

Separate four token categories to reproduce the cost of one attempt

To calculate one Codex attempt, keep uncached input, cache reads, cache writes, and output separate. The shared usage profile below demonstrates the method; replace these hypothetical numbers with your own billing details to get your actual per-attempt cost:

32,000 uncached input tokens;
160,000 cache-read tokens;
16,000 cache-write tokens;
8,000 output tokens;
a complete input context at or below 272K for every request, so short-context rates apply.

The formula is:

Task cost = uncached input / 1,000,000 × input price
          + cache read / 1,000,000 × cache-read price
          + cache write / 1,000,000 × cache-write price
          + output / 1,000,000 × output price

Model ID	Provider	Input cost	Cache-read cost	Cache-write cost	Output cost	Total per attempt
`gpt-6-luna`	OpenAI Standard	$0.003200	$0.001600	$0.002000	$0.004000	$0.010800
`gpt-6-luna`	BetterToken	$0.002176	$0.001088	$0.001360	$0.002720	$0.007344
`gpt-5.6-luna`	OpenAI Standard	$0.006400	$0.003200	$0.004000	$0.009600	$0.023200
`gpt-5.6-luna`	BetterToken	$0.004352	$0.002176	$0.002720	$0.006528	$0.015776

With this hypothetical token structure, one gpt-6-luna attempt costs about 46.6% of one gpt-5.6-luna attempt. BetterToken applies the same price multiplier to both models, so the ratio between the two models is identical on both providers. This is still a cost per attempt, not a cost per successful task.

Count cache reads separately or you will overstate or understate cost

Do not charge cache reads at the ordinary input rate, and do not omit them from the bill. Codex repeatedly reads repository context, conversation history, and tool output; cached tokens are usually cheaper, but their volume can be large, so one combined “input” number gives the wrong answer.

For every run, retain separate values for input, cached input, cache write, and output. If an access layer exposes only a final dollar amount and not the four token categories, it becomes much harder to explain why one model or task costs more than another.

Choose the default model by cost per successful task

A cheaper call does not guarantee a cheaper completed task; include the API cost of failures, rollbacks, and retries. The more useful metric is:

Cost per successful task = total API cost of all attempts / accepted tasks

Track at least these dimensions:

Acceptance rate: the share of tasks that pass the predefined criteria without a developer rewriting the solution;
Retries: repeated prompts, rollbacks, or fresh model runs for the same task;
Elapsed time: time from task start to an acceptable diff, not merely first-token latency;
Manual repair: whether and how long a developer had to edit generated code;
Token mix: uncached input, cache reads, cache writes, and output.

Using the hypothetical OpenAI Standard costs above, the per-attempt ratio is 0.010800 / 0.023200 ≈ 46.6%. If the token profile stayed identical, gpt-6-luna would still have a lower expected API cost whenever its acceptance rate exceeded roughly 46.6% of the gpt-5.6-luna acceptance rate. This is only a break-even relationship derived from hypothetical prices, not a measured quality claim. The threshold changes when token use, retries, or task mix changes.

Fix five conditions before trusting the comparison

Running each model once is not a valid comparison; both must start from the same state, receive comparable tasks, and face the same acceptance criteria. These five steps reduce bias from caching, run order, and human judgment.

1. Freeze the environment

Use the same Codex version, starting Git commit, configuration, tool permissions, reasoning effort, prompt, and acceptance command for both models. Do not call one model through OpenAI Standard and the other through a different access path, then attribute every latency or failure difference to the model.

2. Separate task categories

At minimum, keep three task classes distinct:

Task class	Example	Suggested acceptance criteria
Small fix	A well-defined defect in one or a few files	Targeted tests pass; unrelated files remain unchanged
Cross-file change	Feature, refactor, or coordinated interface change	Full tests and lint pass; requested behavior is present
Review and diagnosis	Find a bug, explain risk, propose a fix	Finds the known issue and points to concrete code evidence

Do not collapse all three into one average. Two models may be nearly equal on small fixes but differ materially in retry rate on cross-file work.

3. Define acceptance before running the model

Before testing, fix the required tests, allowed directories, dependency policy, and failure conditions. Lowering the bar after seeing an output makes the acceptance rate meaningless.

4. Alternate model order

Do not always run the same model first. Alternate the order, or use equivalent independent tasks when possible, so first-run caching, environment repair, and operator familiarity do not systematically favor one model.

5. Preserve per-task records

A useful row contains: task ID, task class, model ID, provider, processing tier, reasoning effort, start and end time, the four token categories, attempt count, pass/fail result, failure reason, manual-repair minutes, and final cost. Aggregate by task class only after retaining the raw rows.

When to keep `gpt-6-luna` and when to switch to `gpt-5.6-luna`

Keep gpt-6-luna as the default candidate while its acceptance rate remains high enough to preserve the price advantage and manual-repair time is comparable. When the results differ by task class, route the work instead of forcing one global model on every task.

What you observe	Recommended action
`gpt-6-luna` acceptance exceeds roughly 46.6% of `gpt-5.6-luna` acceptance, with similar token profiles and repair time	Keep `gpt-6-luna`; its expected API cost is lower
`gpt-6-luna` falls below that break-even point, or retries and repair make total cost higher	Move that task class to `gpt-5.6-luna`
`gpt-6-luna` wins on small fixes but `gpt-5.6-luna` causes less rework on cross-file changes	Route by task class rather than choosing one universal default
The difference mostly comes from provider latency, errors, or rate limits	Rerun through the same access path before blaming the model
Input frequently exceeds 272K	Optimize context and test again; do not treat a pricing-tier jump as a quality difference

The 46.6% threshold applies only to the hypothetical token profile above. If output length, cache usage, or retry count differs, recalculate the break-even point from each model’s actual per-attempt cost.

Recommendation: baseline with `gpt-6-luna`, then decide from successful-task cost

If you must choose one model today, start clear, automatically verifiable work with gpt-6-luna. Keep a representative sample of complex tasks for a same-condition gpt-5.6-luna control; do not stop at comparing the price of one call.

After a batch of comparable tasks, calculate acceptance rate, average retries, manual-repair time, and cost per successful task. Keep gpt-6-luna as the default when it remains cheaper; if gpt-5.6-luna removes enough rework to cover its higher token rate for a specific task class, route only that class to it.

Official references

Use these three official pages to recheck model specifications and OpenAI pricing.

Originally published on the BetterToken blog.

GPT-6 Astra vs Sol vs Luna: Choose by Task Difficulty and Total Cost

Adela — Mon, 28 Sep 2026 06:21:00 +0000

You may already know that Luna is the cheapest and Astra is the most capable, but that still does not tell you whether this task is worth a 20× or 100× jump in token price. Use this default: start verifiable, high-volume work on Luna, complex coding and ordinary agentic workflows on Sol, and ambiguous or expensive-to-fail end-to-end work on Astra. By the end, you will know where to start, which failure signals justify escalation, and how to compare the same token workload on OpenAI Standard and BetterToken.

Start here: Luna for verifiable volume, Sol for complex builds, Astra for costly mistakes

Choose the starting model from task boundaries and failure cost, then revise that default with your own acceptance data.

Model	OpenAI positioning	Good initial candidates	Escalate when
`gpt-6-luna`	An efficient model for focused, high-volume tasks	Small scoped edits, structured extraction, classification, format conversion, tests from a clear specification, and batch work with deterministic validation	Validation repeatedly fails; cross-file reasoning is required; the tool chain grows; a critical ambiguity remains
`gpt-6-sol`	Built for complex coding and agentic workflows	Multi-file feature work, debugging, code review, repository tasks with several tool calls, and moderately complex research or documentation with clear boundaries	A wrong plan has high impact; repeated plans miss key constraints; the task requires cross-system trade-offs or difficult research
`gpt-6-astra`	OpenAI's most capable model for the hardest end-to-end work	Architecture decisions, complex migrations, cross-system incident analysis, high-risk code changes, and long workflows combining research, document creation, or computer use	Astra is already the top tier in this group; if it still fails, narrow the task, add evidence, or introduce a human decision point instead of escalating by name

The goal is not to declare that Luna must handle every “easy” task. The goal is to choose the least expensive model that consistently clears the required quality bar. A cheaper model that triggers repeated retries can cost more in the end. Conversely, starting every well-specified task with Astra may pay for capability the workflow never uses.

Public documentation does not yet include an independent comparison of Astra, Sol, and Luna on the same real tasks. Treat this matrix as an actionable starting point, then record first-pass acceptance, retries, actual elapsed time to an accepted result, and total cost per accepted task.

Similar context limits do not make the models interchangeable

The three models have similar context and tool envelopes, so task shape, reasoning configuration, and failure cost matter more than context-window size. OpenAI positions Astra for complex reasoning, coding, computer use, research, and document creation; Sol for complex coding and agentic workflows; and Luna for focused, high-volume work. Those descriptions help select the first candidate, but your task results must decide the default.

All three models have a 1,050,000-token context window, a maximum input of 922,000 tokens, and a maximum output of 128,000 tokens. Context capacity alone therefore does not separate them. More practical differences include:

Astra supports reasoning.effort values of low, medium, high, xhigh, and max.
Sol and Luna also support none, with medium as the default. For tightly bounded tasks, testing a lower reasoning level can reveal whether cost comes from the model choice or from unnecessary reasoning.
For tool-heavy agent workflows, prefer the Responses API. With Sol and Luna, Chat Completions function calling requires reasoning_effort to be none.
Model choice, context, reasoning, tool use, retrieval, and caching all affect usage. Prompt length alone is not a reliable proxy for task cost.

A fair comparison therefore fixes the interface, context, tools, reasoning effort, maximum output, and acceptance checks. If several of those change at the same time, the observed difference may be a configuration effect rather than a model effect.

For the same tokens, compare BetterToken with OpenAI Standard

For identical token usage, the BetterToken rates verified on 2026-09-24 were 68% of the corresponding OpenAI Standard rates. That does not make it the cheapest route in every case: OpenAI Batch and Flex are lower, while retries, tools, and human rework still determine full cost. The table uses USD per 1 million tokens and shows the rates for input context at or below 272K.

Model ID	Source	Input	Cached input read	Cache write	Output
`gpt-6-astra`	OpenAI Standard	$10.00	$1.00	$12.50	$50.00
`gpt-6-astra`	BetterToken	$6.80	$0.68	$8.50	$34.00
`gpt-6-sol`	OpenAI Standard	$2.00	$0.20	$2.50	$10.00
`gpt-6-sol`	BetterToken	$1.36	$0.136	$1.70	$6.80
`gpt-6-luna`	OpenAI Standard	$0.10	$0.01	$0.125	$0.50
`gpt-6-luna`	BetterToken	$0.068	$0.0068	$0.085	$0.34

When a request exceeds 272K input context, all three GPT-6 models move to the long-context tier on both services: input, cached input read, and cache-write rates become 2× the table values, while output becomes 1.5×, for the full request. For example, long-context gpt-6-sol costs $4.00/$0.40/$5.00/$15.00 on OpenAI Standard and $2.72/$0.272/$3.40/$10.20 on BetterToken for input/cached read/cache write/output.

Prices are dynamic. Before deploying, view current prices and recheck model availability, currency, and the applicable tier. OpenAI Batch and Flex currently cost 50% of Standard and are lower than the BetterToken rates in this snapshot; use them when asynchronous or lower-priority processing fits the workload. The table also excludes regional-processing premiums, tool-call fees, container charges, and retries.

BetterToken's GPT group can be used through the API, Codex, and external tools that support a custom Base URL. BetterToken is not an OpenAI product, and its API usage is not the same as ChatGPT or Codex subscription messages, included plan capacity, or credits.

Already on GPT-5.5? Keep the baseline before switching

If your GPT-5.5 workflow is stable, do not switch only because the model family changed. Preserve its quality, elapsed-time, and cost baseline, then replay the same tasks on Sol, Luna, and Astra. The prices below are USD per 1 million tokens, verified on 2026-09-24.

Model ID	Source	Context	Input	Cached input read	Output
`gpt-5.5`	OpenAI Standard	≤ 272K	$5.00	$0.50	$30.00
`gpt-5.5`	OpenAI Standard	> 272K	$10.00	$1.00	$45.00
`gpt-5.5`	BetterToken	No tiers	$3.40	$0.34	$20.40

BetterToken does not apply a separate long-context tier to gpt-5.5; OpenAI Standard does above 272K. A cache-write price is not listed because OpenAI’s published GPT-5.5 pricing row does not provide one; it is left blank rather than estimated.

There are also two different migration questions. OpenAI says GPT-5.5 will retire from ChatGPT, ChatGPT Work, and Codex on all plans on 2026-10-14, while the OpenAI API is unaffected. Codex plan users therefore need a replacement path before that date. API-key workloads do not need to migrate solely because of the plan-side retirement. Codex plan allowances, additional credits, and USD-priced API usage are separate accounting systems.

The useful metric is cost per accepted task

A single-call price cannot tell you which model is cheaper to finish the job. Count failed attempts, retries, cache writes, tool charges, and human rework, then divide the total by accepted results. The example below first isolates the two billing paths with the same token mix.

Assume one accepted run uses:

120,000 uncached input tokens;
100,000 cached input tokens;
10,000 output tokens;
no new cache write in this run;
220K total input context, so the short-context tier applies.

Using “tokens ÷ 1,000,000 × the relevant rate,” the model charge for that single run is:

Model ID	OpenAI Standard	BetterToken
`gpt-6-luna`	$0.01800	$0.01224
`gpt-6-sol`	$0.36000	$0.24480
`gpt-6-astra`	$1.80000	$1.22400
`gpt-5.5`	$0.95000	$0.64600

This example compares billing for the same token mix; it does not compare quality, speed, or final value. With identical tokens and processing tier, Sol costs 20 times Luna and Astra costs 5 times Sol. But failed attempts, longer outputs, more tool calls, or human rework can narrow or reverse the difference in total completion cost.

A more useful formula is:

Completion cost = token charges across all attempts + cache-write charges + tool charges + failed retries and rework.

Divide that total by the number of accepted tasks to obtain cost per accepted result. That metric is much closer to a production routing decision than the price of one successful request.

Choose the first model by workflow, then define escalation

The default route can be explicit: start low-risk work with reliable automated checks on Luna, complex development on Sol, and high-risk or highly ambiguous work on Astra.

Verifiable, high-volume work: start with Luna

If a schema, linter, unit test, or another deterministic rule can catch failure quickly, test Luna first. Good candidates include fixed-format transformations, extraction from known fields, local renames, tests from a precise specification, and other batch outputs with reliable automated acceptance.

Escalate to Sol when validation fails, an unstated dependency appears, or the task requires a cross-module decision. Do not let a smaller model retry indefinitely in the same wrong direction.

Multi-file coding and agent workflows: start with Sol

When the task must understand several files, use tools in sequence, or change its plan after execution results, start with Sol. Typical examples are cross-file feature work, diagnosing test failures, searching a repository before editing, and continuing from tool output.

Keep the task bounded. Explicit completion conditions such as “analyze, modify, run the most relevant tests, and report unresolved items” are usually more useful than raising reasoning.effort without a plan. Move to Astra when Sol repeatedly misses architectural constraints on representative tasks.

Ambiguous or high-risk end-to-end work: start with Astra

Start with Astra when the cost of a wrong answer clearly exceeds the model premium. Cross-system migrations, difficult production incidents, critical security boundaries, research-heavy decisions, and workflows combining coding, computer use, and a long tool chain belong in this group.

Astra still requires validation. Split long work into checkpoints for the plan, evidence, changes, and verification so the strongest model does not spend more time following a bad assumption.

Still unsure? Compare the models on the same real tasks

You do not need a universal fixed sample size. You do need a representative set covering normal, boundary, and failure cases, with the same acceptance rules for every model.

Choose a representative set. Include small changes, multi-file development, debugging, tool use, and knowledge work instead of selecting only polished demos.
Define acceptance before running. Use tests, lint, schemas, a factual checklist, or human review. Changing the rubric after seeing an answer makes the comparison unreliable.
Hold other variables constant. Use the same context, tools, API surface, reasoning effort, maximum output, and environment. Treat a different reasoning.effort as a separate experiment.
Record every attempt. Capture first-pass acceptance, retries, actual elapsed time to an accepted result, input/cached/output tokens, tool calls, and final spend.
Compute cost per accepted result. Include failed attempts and human rework, not only the last successful run.
Conclude by task class. A model may pass coding edits but fail research or long agent runs. Do not hide that behind one global default.
Review after each task class has accumulated repeated real runs. If a higher tier does not produce a repeatable improvement in acceptance or total cost, return to the smaller model or keep the existing GPT-5.5 API workflow.

At minimum, compare first-pass acceptance, final acceptance, total cost per accepted result, and median plus high-percentile completion time. A model should become the default only when it consistently wins under your actual quality threshold.

Escalate on repeated failure and risk, not on model prestige

Escalation should be triggered by observable failure signals, not by the assumption that a more expensive model must be better.

Luna → Sol: deterministic validation repeatedly fails; the task needs cross-file or cross-module reasoning; tool results materially change the plan; or a critical ambiguity remains after adding the missing task constraints.
Sol → Astra: repeated plans omit critical constraints; an error affects production, security, or a major migration; or the task combines difficult reasoning, research, documentation, and execution.
Astra → narrow the task: when Astra still fails, add evidence, split the workflow, or request a human decision instead of continuously increasing context and reasoning.
New model → GPT-5.5 rollback: in API workloads, keep GPT-5.5 whenever it still meets quality, latency, and maintenance requirements. A newer model name alone is not a migration reason.

Use Luna → Sol → Astra as the default escalation chain: reliable verifier first means Luna, complex development means Sol, and high risk means Astra. Change that rule only when your own acceptance rate, retries, elapsed time, and cost per accepted result show that another route is better.

Originally published on the BetterToken blog.

How to switch Claude Code to Opus 5.5 and keep it selected

Adela — Mon, 28 Sep 2026 06:18:57 +0000

You run /model, choose Opus, and Claude Code still uses another model—or it returns a 400 before the first response. The reliable fix is to separate three things: the model command, the Claude Code version, and any request-level fallback triggered by a refusal.

Use the full model ID when you need a reproducible setup, use the opus alias only after checking what it resolves to, and remember that Opus 5.5 defaults to medium effort rather than the high default used by Opus 5.

Use the full model ID to pin Opus 5.5

The most explicit command is:

/model claude-opus-5-5

Anthropic documents claude-opus-5-5 as a fixed model ID without a date suffix. That makes it the better choice for project instructions, team runbooks, and custom providers where you need everyone to request the same model.

The shorter alternative is:

/model opus

Use the alias only when Claude Code—or the provider behind your custom Base URL—shows that it resolves to Opus 5.5. An alias is convenient for interactive work, but the full ID is easier to audit when a session, script, or gateway behaves differently than expected.

Your goal	Prefer	Why
Pin the exact model	`/model claude-opus-5-5`	The requested ID is explicit and reproducible
Use the current Opus alias interactively	`/model opus`	Faster to type, but you should verify the resolved model
Diagnose a custom provider	Full ID first	It separates alias mapping problems from model availability problems

If you run Claude Code through an Anthropic-compatible custom Base URL such as BetterToken, the /model procedure is unchanged; confirm that the provider actually exposes claude-opus-5-5 before treating an alias result as proof.

Update Claude Code before switching

A client that predates the model may reject the selection even when your account or provider supports it. Update first:

claude update

Then restart the active Claude Code session or update the Claude desktop app if that is the client you use. After the restart, run the full-ID command again.

A community issue captured one concrete error on September 22, 2026: Claude Code 2.1.257 was rejected with claude_code_version_too_old, and the response required 2.1.280 or newer. That report is useful as an example of the version gate, not as a permanent universal minimum. Follow the minimum named by the error you actually receive, because later releases can raise it.

Switch the model and verify the result

Follow this order so that one failure does not hide another:

Run claude update, then restart Claude Code.
Enter /model claude-opus-5-5 in the session where you will work.
Check the model selection that Claude Code displays after the command. Do not infer success only because the command was accepted.
Reopen /model before a long or expensive task and confirm the current selection again.

If the full ID works but /model opus does not, keep the full ID. That points to alias resolution rather than a general inability to use Opus 5.5.

If neither works and you use a third-party endpoint, verify model availability and mapping on that provider. The Claude API can expose the official ID while a compatible gateway uses a separate catalog or has not enabled it yet.

Expect `medium` effort unless you set another level

Claude Opus 5.5 uses adaptive thinking and its documented default effort is medium. This differs from Claude Opus 5, whose default was high, so a model switch can change latency, token use, and how much reasoning the model applies even when you do not change any visible Claude Code setting.

For ordinary Claude Code use, there is no need to invent an effort value just to complete the switch. First confirm the model, then evaluate whether the default behavior fits the task. If your client or API gateway exposes an effort control, set it deliberately rather than assuming the old Opus default carried over.

Custom integrations also need to respect the Opus 5.5 request rules. The model rejects requests that disable thinking or send a manual thinking budget. If model selection succeeds but the first request returns a 400, inspect any upstream payload transformation instead of repeatedly changing /model.

A flagged message can take a fallback path

A safety refusal is separate from your normal model selection. At the API level, Opus 5.5 can return HTTP 200 with stop_reason: "refusal" and a stop_details object. A client or provider with fallback enabled may retry that request on another model.

Treat that event as a request-level fallback, not proof that your saved /model choice changed. Before continuing important work, reopen /model and verify the active selection. If the fallback moved the conversation from Opus 5.5 to most other models, Anthropic notes that the later turns run without the previous Opus 5.5 thinking blocks; restate critical constraints instead of assuming all hidden reasoning carried over.

The practical sequence is:

Read the refusal or flagged-message notice instead of resending the same request unchanged.
Remove or reframe the part that triggered the safeguard when the request is legitimate.
Check whether your client or provider used a fallback model.
Confirm Opus 5.5 again before resuming a task that depends on a fixed model.

Troubleshoot the common failure modes

Symptom	Most likely check	Next action
400 with `claude_code_version_too_old`	Claude Code or desktop version	Run `claude update`, restart, and retry the full ID
Opus 5.5 is missing from the model list	Client catalog or provider catalog is stale	Update the client; then check provider availability
`/model opus` chooses an unexpected model	Alias resolution	Use `/model claude-opus-5-5` and verify the displayed selection
Full ID is accepted, but the first request returns 400	Upstream payload is incompatible	Check for disabled/manual thinking settings or other gateway rewrites
A message is flagged and another model answers	Refusal fallback	Review the refusal, verify the active model, and restate critical constraints
A mid-session switch feels less consistent	Thinking blocks may not transfer to the target model	Confirm the model and give the new turn the context it needs

Final checklist

Before starting the real task, confirm all five points:

Claude Code has been updated and restarted.
/model claude-opus-5-5 is accepted.
The displayed selection resolves to Opus 5.5.
You expect the default medium effort unless another level is explicitly configured.
A flagged or refused request has not silently moved that request onto a fallback model without your review.

Once those checks pass, the exact model ID is the safest way to keep a session reproducible. The opus alias remains useful for quick interactive switching, but it should be verified rather than assumed.

Sources

Originally published on the BetterToken blog.

Local Qwen Context Stops Early: Isolate KV Cache, Backend, and GPU Limits

Adela — Mon, 28 Sep 2026 06:16:55 +0000

You configured a local Qwen model for 128K context, but it may fail near 72K, slow down until it is impractical, or finish while ignoring instructions from the beginning. There is rarely one magic setting: model-weight quantization, the KV cache, the inference backend, and hardware placement all contribute to the limit.

This guide gives you a repeatable diagnosis. You will identify whether the failure is capacity, speed, or effective memory, then change one variable at a time to decide whether to use a different KV cache, switch backends, rebalance multiple GPUs, or lower the production context target.

The direct answer: configured context is a ceiling, not a guarantee

A 128K context setting only asks the backend to prepare for an input of that size. The setup is viable only when this memory budget holds:

model weights + KV cache + runtime workspace + safety margin ≤ memory the backend can actually use

Model weights usually take a large, mostly fixed allocation at load time. The KV cache grows with the number of retained tokens, while workspaces and temporary buffers vary with the backend, batching, and kernels. Even when allocation succeeds, latency or long-range recall may become unacceptable before memory is exhausted.

That means you need three separate answers: does it fit, does it finish fast enough, and does the model still use information from the beginning? A maximum-context value in a UI answers none of them by itself.

Identify the symptom before changing the stack

“Cannot reach 128K” can describe several different failures. Classify yours first so you do not optimize the wrong component.

Symptom	More likely direction	First check
The model or long context allocation immediately runs out of memory	Weights and KV cache compete for memory, or one device cannot allocate its share	Record peak and free memory on every GPU
The backend fails near the same token count every time	KV-cache format, backend implementation, or an allocation boundary	Hold model and hardware fixed; change only KV cache or backend
The prompt is accepted, but prefill or generation becomes unusably slow	Bandwidth, cross-GPU traffic, kernels, or an excessive target length	Measure prompt processing and generation separately
Generation completes, but early constraints are forgotten	Effective-context quality, not raw capacity	Test facts placed throughout the prompt
The same run sometimes passes and sometimes fails	Too little headroom, concurrent load, or an unstable runtime	Remove other load and repeat the identical run three times

If the system fits but is too slow, a smaller KV cache is not automatically the best answer. If it fits but cannot recall early information, adding memory alone may not improve the result.

What a reported move from 72K to 128K does—and does not—show

In a September 23, 2026 configuration report, Nigel Hungerford-Symes described running Qwen3.8-27B (Unsloth UD-Q5_K_M) on an RTX 5060 Ti 16GB plus an RTX 3070 8GB. The reported 128K stack used beellama.cpp + kvarn5 KV + MTP n=2, at about 36 tok/s for short context and 18 tok/s at 126K; the earlier mainline llama.cpp setup with q8_0 KV reportedly stopped near 72K.

The report matters because it shows that the usable limit on one specific machine can move when the inference stack changes. It does not isolate the cause: the backend, KV-cache scheme, and other runtime settings changed together, so it cannot prove that one cache format alone produced the difference or that the same speeds apply elsewhere.

Use it as a diagnostic lead. When your limit repeatedly appears at one length, include the KV cache and backend in the comparison instead of looking only at the model file.

Build a baseline before touching the 72K setup

Save a reproducible baseline before changing anything. Otherwise, a successful new stack still will not tell you which change mattered.

Record at least the following:

Area	Values to capture
Model	Full model name, exact model file, weight quantization, file size
Backend	Backend name, version or commit, launch method
Context	Requested window, actual input tokens, reserved output tokens
KV cache	Data type or scheme, GPU or host placement, compression settings
Hardware	Every GPU model and VRAM size, system RAM, PCIe topology
Placement	GPU split, offloaded components, whether work crosses devices
Runtime	Batch settings, concurrency, sampling values, maximum output
Result	Success or error, exact error text, peak VRAM/RAM, prefill speed, generation speed

Do not treat a 16GB GPU plus an 8GB GPU as one simple 24GB pool. The backend decides where weights, KV cache, and workspaces live; one device may fill first, and cross-device traffic may dominate at long context.

Test four variables separately instead of replacing everything at once

1. Weight quantization changes the fixed footprint

Weight quantization primarily changes the memory required to load the model. Smaller weights can leave more room for the KV cache, but they do not guarantee a longer usable window and may also change quality or speed.

To test whether weights are crowding out the cache, hold the backend, KV-cache type, and prompt constant. Change only the weight quantization, then record how much memory is freed and whether the failure point moves.

2. KV-cache type changes the per-token footprint

The KV cache stores reusable history needed for subsequent tokens. For a fixed model and cache representation, its memory use generally grows roughly with retained token count, which makes it the most direct long-context memory lever.

When comparing cache schemes, evaluate three outcomes together: peak memory, longest stable input, and recall accuracy. “It fits 128K” is not a useful win if accuracy degrades or the backend becomes unreliable.

3. The backend decides how those formats are implemented

Backends can differ in cache layout, allocation, multi-GPU placement, and kernels. The same context value and model file can therefore produce a different memory curve and different speed.

If a candidate backend requires a different cache format, report the result as “this stack passed,” not “this cache format caused the gain.” To isolate the backend, run another A/B comparison using settings both backends support whenever possible.

4. Hardware placement decides which resource fails first

The common multi-GPU mistake is to watch only total VRAM. A run may fail because one device lacks a large enough allocation, the cache is concentrated on one GPU, the workspace has no headroom, or cross-GPU transfers make the result too slow.

Track every GPU separately. If one device is nearly full while another has meaningful headroom, rebalance placement before sacrificing model quality.

Run a repeatable long-context acceptance ladder

Do not jump from a short prompt straight to 128K. A fixed length ladder shows whether failure is abrupt or gradually becomes impractical.

A useful starting ladder is 8K → 32K → 64K → 72K → 96K → 126K. The 126K point is close to 128K while leaving an explicit output budget; increase that reserve if your task needs long generations.

Prepare one controlled prompt set

Count tokens with the tokenizer actually used by the target model; do not estimate from characters or file size.
Place distinct “canary facts” near 10%, 20%, and so on through 90% of the input, such as ORBIT-17 = copper.
Put one coding constraint near the beginning, middle, and end, then ask the final response to repeat the constraints and make a small code change.
Keep content order, sampling settings, and output budget identical at every length.
Remove other system load and repeat each critical length three times.

Canary facts measure retrieval, not complete coding ability. Add code, logs, or repository documentation resembling your real workload for the final acceptance run.

Record the same evidence for every run

Metric	Question it answers
Actual input tokens	Did the backend really accept the target length?
Allocation result and exact error	Where did capacity or compatibility fail?
Peak memory per GPU and peak system RAM	Which device became the bottleneck?
Prompt processing time or rate	Is long-input prefill still acceptable?
Generation speed	Is interaction after a long prompt practical?
Canary facts recovered	Can the model use distant information?
Coding constraints satisfied	Does the long window help the real task?

Define pass criteria before running the test. One example is three consecutive completions at the target length, no memory or backend error, at least 9 of 10 canaries correct, and prefill plus generation within your workflow limit. 9/10 is only an example; the important part is deciding the threshold before seeing the result.

Choose the next step from the result

It consistently runs out of memory at one length

Find which device fills first. If cache growth consumes the remaining headroom, compare a lower-footprint KV scheme first. If loading the weights already leaves almost no room, compare a smaller weight quantization. Change one item per run and check whether the failure point moves as predicted.

A new backend reaches 128K while the old one stops at 72K

Treat the new stack as a candidate, then reproduce it three times and run the recall test. Because backend and cache settings may have changed together, the defensible conclusion is that the candidate stack works—not that you have isolated a single root cause.

128K completes, but performance is unacceptable

That is an operating boundary, not a capacity failure. Use a smaller default window and enable very long context only for the few tasks that need it, or compare a smaller model, another backend, or better hardware placement. Separate “can run” from “worth running every day.”

128K completes, but early information is repeatedly lost

Treat it as an effective-context quality problem. Run the same prompt at 64K, 72K, and 96K to build a recall curve. If shorter inputs are clearly more reliable, set the production limit where quality passes rather than where allocation succeeds. Retrieval, chunking, or summarizing before coding can also remove irrelevant material from very large repository tasks.

Optimize for a verified working window, not the largest menu value

If 72K already covers your normal repositories and logs, do not replace weight quantization, KV cache, backend, and GPU split all at once just to display 128K. Preserve the stable baseline and require each change to demonstrate a capacity, speed, or recall benefit.

If your work genuinely needs more than 100K input, build the length ladder and pass criteria first, then compare KV-cache and backend combinations. The useful final claim is specific: “this model, backend, cache, and hardware passed 126K three times at our required speed and recall”—not merely “the configuration supports 128K.”

Originally published on the BetterToken blog.

Claude Opus 5.5 Code Audit Checklist: Verify Every Finding Before Merge

Adela — Mon, 28 Sep 2026 06:14:54 +0000

You let Claude Opus 5.5 audit a repository for several hours. It returns dozens of “high-risk” findings and may even prepare a large patch. The hard part is no longer getting suggestions; it is deciding which findings are real, which changes respect the system’s architecture, and which fixes are safe to merge.

This workflow treats model output as audit hypotheses that require evidence, not as conclusions. You establish a reproducible baseline, separate discovery from editing, and make every accepted finding pass reproduction, risk, architecture, fix, and regression gates.

Use Opus 5.5 to widen the audit, not to approve the merge

Opus 5.5 is a reasonable choice for broad, long-running audits, but it is not an independent reviewer. Anthropic’s September 22, 2026 announcement specifically describes codebase-wide migrations and audits as a strength and reports results from internal tests and early testers. Those vendor and tester results do not prove the same outcome on your repository. Read Anthropic’s Opus 5.5 announcement.

Kent C. Dodds also published a broad audit prompt covering security, performance, accessibility, maintainability, scalability, architecture, documentation, testing, and automation. He said Opus 5.5 found a significant security issue that other models missed, but the post does not disclose the flaw, reproduction steps, or a controlled comparison. It supports trying the workflow, not waiving verification. Read the public report.

Your goal should therefore be: produce as many reproducible, graded, independently reviewable findings as possible—not simply maximize the number of warnings.

Define success as commands before the audit starts

Without a clean baseline, you cannot tell whether a later failure was pre-existing or introduced by the model. Before the model scans the full repository, record the current commit, environment, dependency versions, and the exit code from every baseline command.

Replace the placeholders with the commands your project actually uses. Mark a gate “not applicable” rather than inventing one.

git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>

Record at least:

the commit SHA, runtime, package manager, and material dependency versions;
the exact command, working directory, exit code, and failure summary for each check;
known failures, flaky tests, and temporary exemptions;
directories that are in scope and files the model must not edit, such as generated code, historical migrations, lockfiles, or vendored sources;
critical paths such as authentication, authorization, billing, data migration, and external API contracts.

If the baseline already fails, decide whether to fix, isolate, or register the failure before the audit. Do not allow an old failure to be presented as a new discovery.

Ask for an audit first and no code changes

Discovery and remediation must be separate phases. If the model edits while it investigates, a new failure may come from the original code, the first patch, or a later patch that interacts with it.

Use this as a first-pass prompt and add repository-specific commands and boundaries:

Perform a long-running code audit of this repository. In this phase, investigate and report only; do not modify files.

Scope: <directories, services, languages, critical business flows>
Exclusions: <generated files, third-party code, historical migrations, inaccessible systems>
Baseline: <commands already run, exit codes, known failures>

Audit areas:
1. Security and authorization boundaries
2. Correctness, concurrency, transactions, and error handling
3. Performance and resource use
4. Accessibility where applicable
5. Maintainability and scalability
6. Architecture and module boundaries
7. Documentation, testing, and automation gaps

For every finding, provide:
- a unique ID and short title
- severity and impact rationale
- affected files, symbols, and exact lines
- trigger, expected behavior, and actual behavior
- a reproducible command or minimal test
- output summary and exit code
- a plausible false-positive explanation
- the smallest remediation direction
- verification commands required after a fix
- confidence: high, medium, or low

Rules:
- Mark any command you did not run as NOT RUN.
- If you cannot reproduce a finding, label it UNVERIFIED, not confirmed.
- Never delete, skip, or weaken tests to make a result pass.
- Stop and list missing credentials, services, or dependencies.
- Update the audit status table at the end of each phase before continuing.

The prompt does not guarantee compliance. You still need to inspect terminal records, file diffs, and test output. Its purpose is to make acceptance fields explicit so that “this looks risky” cannot move directly into the fix queue.

Split the long task into four controlled phases

A long autonomous run should not mean unlimited scope or permissions. Pause at each phase boundary and review the evidence before allowing the model to continue.

Phase 1: Build a system map

The model reads code, configuration, tests, and architecture documents. It identifies entry points, trust boundaries, data flows, external dependencies, and high-impact paths. It should not chase a target number of bugs or change files.

Phase 2: Produce candidate findings

The model groups candidate issues by audit area and points each one to concrete code. Advice without a location or trigger belongs in an “improvement ideas” list, not the defect count.

Phase 3: Reproduce one finding at a time

Start with high-impact findings that are cheap to test. Add a minimal test or run an existing check, retain the raw output, and record the environment. Do not bundle several hypotheses into one experiment.

Phase 4: Prepare a remediation plan

Only reproduced findings enter the fix plan. The plan must state the smallest change, compatibility impact, migration risk, rollback path, and required gates. Architecture disputes go to the code owner before implementation.

Track state in audit-plan.md or a ticket table:

ID	Status	Risk	Reproduction evidence	Architecture decision	Fix branch	Approver
AUD-001	Awaiting reproduction	High	None yet	Not reviewed	—	—

Allow only an explicit progression: candidate → awaiting reproduction → reproduced → architecture reviewed → fixed → accepted. A finding that cannot be reproduced returns to candidate status or closes; confident wording is not a reason to advance it.

Risk gate: keep severity separate from confidence

Severity measures impact; confidence measures evidence quality. A possible authorization bypass can be high severity and low confidence. A reproducible typo in a log message can be low severity and high confidence.

Severity	Use when	Minimum evidence before remediation
Critical	Broad privilege escalation, sensitive-data exposure, irreversible corruption, or core-service failure is plausible	Controlled reproduction, clear blast radius, immediate owner review
High	A critical business flow is affected or realistic input triggers the failure reliably	Minimal reproduction, failing test or command output, code-owner confirmation
Medium	Impact is bounded, a workaround exists, or unusual conditions are required	Repeatable evidence, impact note, prioritization decision
Low	Local quality, documentation, maintainability, or non-critical performance issue	Concrete code evidence and a case that benefit exceeds regression risk

Do not let the model assign business impact alone. It can trace code paths, but data sensitivity, customer commitments, acceptable downtime, and compatibility policy usually require an owner’s judgment.

Reproduction gate: turn each finding into a failing check

Suspicious code is not enough; acceptance needs a check that fails before the fix and passes after it. For every finding, answer:

Which commit and environment exhibit the behavior?
What is the smallest triggering input?
Is expected behavior defined by a test, specification, interface contract, or business rule?
What exactly happened, and where is the raw output?
Why did existing tests miss it?
Could a valid design choice or environment difference explain it?

The best evidence is a minimal regression test. If automation is impractical, provide deterministic manual steps, expected observations, and cleanup instructions. Reproduce security findings only in systems you own or are authorized to test, preferably local, isolated, or pre-production environments.

When the model says it ran a command, look for the full command, working directory, exit code, and relevant output. A prose summary by itself is not execution evidence.

Architecture gate: learn why the old code exists before changing it

A cleaner-looking implementation can break compatibility, deployment ordering, or an intentional boundary. Before accepting an architecture finding or broad refactor, review ADRs, design documents, API contracts, migration constraints, and the relevant history.

When the repository has usable Git history, the model can help inspect it:

git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>

Then require answers to these questions:

What constraint is the current design preserving?
Which callers, data formats, or deployment steps depend on it?
Is the proposed change correcting a defect or changing product behavior?
Can a smaller local change solve the reproduced issue?
Does rollback require restoring code, configuration, or data?

History is evidence, not a perfect record of intent. If no rationale is available, mark the decision “architecture intent unknown” and ask a maintainer. Do not let the model silently redraw module boundaries.

Fix gate: one reproduced finding per small patch

Do not accept a mega-patch that claims to fix a dozen unrelated findings. A safer pattern is one reproduced issue per branch or independently reviewable commit: add the failing regression test first, then make the smallest change that passes it.

Each patch should clear these gates:

Gate	Requirement	If it fails
Scope	The diff addresses only the approved finding	Split unrelated changes and review again
Regression test	Fails before the fix and passes after it	Repair the test or reconsider the finding
Static checks	Format, lint, and type checks pass	Do not hide new errors with broad exemptions
Project tests	Relevant unit, integration, and build checks pass	Investigate the first new failure before stacking patches
Architecture	The owner confirms boundaries and compatibility	Reduce scope or open a design review
Human diff review	Error handling, permissions, data changes, and deletions are inspected	Explain every suspicious change

Explicitly reject fake passes: deleting assertions, skipping tests, swallowing exceptions, weakening validation, increasing retries to hide races, or performing a large refactor that makes the original defect hard to trace.

Regression gate: run project-owned checks, not only model-selected tests

The model will naturally focus on checks closest to its change; merge acceptance needs an independent project-level gate. Use existing repository scripts or CI definitions for the final run rather than letting the model substitute an easier command.

Compare:

the full baseline before the audit with the post-fix result;
whether the new regression test fails on the unpatched revision;
lockfiles, database migrations, public APIs, and configuration defaults for unintended changes;
performance claims using the same environment and input before and after;
security fixes for new authorization or availability regressions;
documentation and operational steps against the final behavior.

For flaky tests, do not rerun until green. Record the failure pattern, isolate the source of nondeterminism, and determine whether the patch made instability worse.

Reject the audit result when any of these conditions appear

Do not move a finding toward merge when:

it lacks an exact code location, trigger, or inspectable evidence;
an unexecuted command is reported as passing;
severity is just an adjective with no impact path;
the patch exceeds approved scope or casually redesigns architecture;
tests are deleted, skipped, weakened, or errors are swallowed;
the change conflicts with an ADR, contract, or migration policy without owner approval;
you receive only a final summary, with no reviewable commands or diff;
a security claim is supported only by another model agreeing with it.

A second model can search for counterexamples, but model consensus is not independent evidence. Independent validation comes from tests, runtime output, history, specifications, and accountable human judgment.

Final pre-merge acceptance checklist

Treat the model-assisted fix as mergeable only when all ten items are true:

[ ] Scope, exclusions, and the baseline commit are frozen.
[ ] Baseline commands and exit codes are retained.
[ ] Every accepted finding has a unique ID and exact code location.
[ ] Severity and confidence are recorded separately.
[ ] The defect is reproduced by a test or deterministic procedure.
[ ] Architecture intent, compatibility, and rollback are reviewed.
[ ] Each finding maps to a small, reviewable patch.
[ ] The regression test fails before the fix and passes after it.
[ ] Full project gates run through existing scripts or CI.
[ ] A code owner reviews the final diff and explicitly approves it.

The available public reports make Opus 5.5 a credible candidate for broad, long-running audits and suggest it can surface issues missed elsewhere. They do not remove the need for verification. The minimum next step is not to let it edit the repository: save a clean baseline and issue the first “audit only, no modifications” task.

Originally published on the BetterToken blog.

DEV Community: BetterToken.ai

Qwen Image 2.1 in ComfyUI: Local Setup by VRAM

Choose the weights first: file size is not peak VRAM

A practical first configuration for each VRAM tier

1. Update ComfyUI before looking for custom nodes

2. Put each model in the folder its loader scans

3. Import the official text-to-image workflow

4. Queue one job, wait, and verify that the PNG was saved

5. Troubleshoot by symptom, not by replacing everything

A node is red or says missing node type

A model dropdown is empty or reports model not found

VRAM runs out before sampling starts

VRAM runs out during VAE decode or just before saving

The queue looks frozen while disk or CPU activity continues

The image looks washed out, overcooked, or structurally broken

1024 works but 2K always OOMs

What 8 GB and 12 GB users should actually choose

GGUF is an optional low-memory route, not the official first run

Add prompt enhancement, 2K, and editing only after the baseline works

Final acceptance checklist

OpenAI API Key Governance: Creation Rules, Ownership, Expiration, and Zero-Downtime Rotation

Start with the answer: the new controls govern future keys, not old ones

Separate three decisions: who can create, how long keys live, and how they exit

Choose by workload: service accounts for production, user-owned keys for personal development

Organization policy is the ceiling: projects may tighten it, not relax it

Do not pick one lifetime for everything: start with the time a real rotation takes

Use this seven-step overlap to rotate without downtime

1. Build an inventory of current keys

2. Create a compliant replacement

3. Store it as a new secret version

4. Shift traffic gradually

5. Observe both application health and key-level usage

6. Keep a time-bounded rollback window

7. Revoke, verify, and schedule the next rotation

Legacy keys do not become compliant automatically: migrate them by risk

Your internal policy needs at least these 11 fields

Before enforcement, rehearse the next rotation

Frequently asked questions

Will a new creation restriction immediately break existing applications?

Does a maximum lifetime retroactively expire old keys?

Can a project administrator relax an organization-level restriction?

Should an organization allow only service-account keys?

When should a project disable all new key creation?

What proves that an old key is safe to revoke?

What to do first

GitHub Copilot App Local Sandbox: Setup and Verification

First confirm that your session is covered

How to enable sandboxing for new sessions

How to limit files, network, and credentials separately

1. Filesystem: decide what can be read and changed

2. Network: separate the internet from the local network

3. Credentials: control Git and GitHub CLI separately

When to change the project, the current session, or one operation

If the host cannot enforce the policy, the command stops

How to verify the policy with dummy data

Which starting policy fits your task

Everyday development

Reviewing an unfamiliar repository

Local offline analysis

Mistakes that make the policy ineffective or too broad

What to do next

Official references

Russian neural text-to-speech: how to choose by pronunciation, pauses, and cost

Filter by Russian support, control, format, and billing first

Use the table to choose your first test pair

Use a test script that mirrors your real workload

Run three untuned baselines to expose instability

Use the second round to fix critical errors, not to tune forever

Google Gemini TTS

OpenAI Speech API

ElevenLabs

Include retries and rejected takes in the accepted-minute cost

Google Gemini example

ElevenLabs example

How to handle OpenAI pricing

Choose the first test pair by workload

Long courses, podcasts, and audiobooks: test Gemini Flash and Multilingual v2 first

High-volume short prompts: test Gemini Flash-Lite and ElevenLabs Flash/Turbo first

Existing streaming stack: let the decoder determine the first test

Telephony and IVR: test Gemini and ElevenLabs first

A node is red or says `missing node type`

A model dropdown is empty or reports `model not found`

Set `task` only when prompting selects the wrong mode

Use `image_to_video` only if the mode is still unclear

Start here: test `gpt-6-luna` first for most automatically verifiable tasks

Below 272K, `gpt-6-luna` has the lower token rates