The AI model release nobody covers: what happens on the Mac when Opus 4.7's personal-plan access has not rolled out to your account yet
The SERP for "ai model release april 2026" is 10 roundups of GPT-5.4, Opus 4.7, Gemini 3.1, Gemma 4, and Llama 4 specs. None cover the consumer app problem that actually bites on launch day: the SDK adds the new model id within hours, but per-account access flips over 3 to 5 days, and in that gap a naive Mac client hands the user a red error and drops the query. Fazm eats that gap with three substring tests and ten lines of retry.
The rollout gap is real, and it is client-facing
An AI model release in April 2026 is not an atomic event from the perspective of a shipping Mac app. Three distinct systems turn on at different wall-clock times. The public blog post lands on anthropic.com within minutes. The Claude Agent SDK starts returning the new model id in availableModels within hours. Per-account OAuth access on paying personal plans flips on a rolling schedule that can stretch 3 to 5 days. That third one is the interesting one, and the one nobody writes about.
In that window, the model id is in the user's floating bar picker, the user has it selected, and the API still returns The model may not exist, or you do not have access to it when they submit a prompt. A roundup page cannot see this happen because a roundup page is not a running consumer app. Fazm is a running consumer app, and on Opus 4.7 GA day (April 14) a non-trivial fraction of personal-plan users hit this error for several hours.
The anchor fact: three substring triggers
The whole detector is six lines of Swift. Copy this file out of the Fazm repo and you will find it at the line numbers quoted. Substring matching against the lowercased agent error message beats regex here for one reason: Anthropic changes exact wording across minor API revisions, but the semantic tokens (may not exist, not have access, model, not found, not available) stay the same.
Two lanes, one visible result
The ACP bridge (Node) proxies Claude Agent SDK calls to whichever lane is active. The Swift app owns the lane-swap policy. On an access error in the personal lane, the Swift side sets pendingBridgeModeSwitch = "builtin" and the bridge restarts with shared credentials before the next prompt.
What the ACP bridge routes on a rollout-gap day
Naive app vs. dual-lane app, on the same prompt
The difference is not cosmetic. It is the difference between the user getting an answer on launch day and the user re-typing their question into a different model.
Same Opus 4.7 prompt, same rollout-gap moment
Surfaces Anthropic's agentError verbatim as a red banner. The user sees 'The model may not exist, or you do not have access to it'. They retype the question against Sonnet or go read the Anthropic status page. Their original context is now stale. Trust in the new model release is lower, not higher.
- Red error banner renders on the chat
- pendingRetryMessage is discarded, not replayed
- User blames the app, not the rollout
The seven steps Fazm walks on April 14 at 10:03 AM PDT
This is the ordered sequence of events for one user whose personal plan had not yet been flipped to Opus 4.7 access on the morning of release day, reconstructed from the code paths in ChatProvider.swift and ACPBridge.swift.
Anthropic flips the ACP SDK
The Claude Agent SDK starts returning 'opus' in its availableModels response. Every connected Fazm app gets the new model id on the next session/new call. No binary rebuild, no notarization tick.
Fazm surfaces Opus 4.7 in the floating bar
emitModelsIfChanged at acp-bridge/src/index.ts:1271 detects a changed JSON snapshot and sends models_available to the Swift app. updateModels at ShortcutSettings.swift:178 substring-matches 'opus' and drops it into the Smart slot. The user sees Smart (Opus, latest) in the picker.
User picks Smart, sends a prompt
The floating bar calls sendMessage which saves the original text into pendingRetryMessage (ChatProvider.swift:2304), calls acpRequest prompt on the existing session, and starts streaming expected.
Personal plan returns a model access error
The Anthropic backend returns an agentError whose message contains 'model' and 'not found' (the exact phrasing varies). bridgeMode is 'personal', so the guard at line 2943 matches and isModelAccessError returns true.
Fazm flips the lane and clears the banner
Line 2950 sets pendingBridgeModeSwitch = 'builtin'. Line 2951 sets retryAfterModelFallback = true. Line 2953 explicitly clears errorMessage so no red error renders. The UI shows the spinner continue.
The ACP bridge restarts on the built-in lane
applyPendingBridgeModeSwitch at line 2965 actually switches the bridge process to the built-in shared Claude credentials that Fazm provisions. The retry flag is still true, pendingRetryMessage still holds the original text.
Fazm replays the original query, no user input
Lines 2967 to 2973 pull retryText out of pendingRetryMessage, null the pending state, and re-call sendMessage(retryText). The query that failed on Opus 4.7 on the personal lane lands on Opus 4.7 on the built-in lane. Log lines land in /tmp/fazm-dev.log. The user sees one reply arrive late, no error.
The retry code, literally
Here is the actual block that replays the query on the new lane. The local retryAfterModelFallback flag is scoped to a single sendMessage invocation (see line 2400), which is why the retry cannot loop: it is a one-shot per call, and the second send cannot also set the flag because it runs on the built-in lane already.
What it looks like in the log
The fallback fires without a UI event, but the log is verbose by design so the pattern is auditable after the fact. These lines land in /tmp/fazm-dev.log on dev builds and /tmp/fazm.log on production builds.
The handoff, as a sequence diagram
Three actors, six messages. The prompt lands, the personal lane rejects, the Swift layer rewrites the bridge mode, the bridge restarts, and the original text rides again. The user is watching a spinner the whole time.
sendMessage on Opus 4.7 rollout-gap day
Why only model-access errors get this treatment
There are three error classes that personal-lane responses can produce: auth failures, terms-of-service acceptance required, and model access. Each gets a distinct handler because silent lane-swap is the wrong response for two of them.
- isAuthRelatedError: OAuth is broken. Lane-swap would hide the re-auth prompt and the user could never recover. Handler re-triggers sign-in.
- isTermsAcceptanceRequired: Anthropic updated terms. Lane-swap would suppress an actionable message. Handler surfaces the verbatim message with a link.
- isModelAccessError: Account-specific rollout gap. Built-in lane provably has access. Lane-swap is exactly what the user wanted.
April 2026 model releases, ordered by when Fazm users could actually use them
Fazm's ACP bridge routes through the Claude Agent SDK, so the Claude family is the direct story: Opus 4.7 flipped live in availableModels within hours of GA, but personal-plan access lagged for many users until April 17 or 18. Non-Anthropic models are listed for completeness; they ship through different code paths that do not invoke isModelAccessError.
One commit, one commit hash, one day before launch
The retry block shipped in commit dc741c22 on 2026-04-04 at 17:37 PDT, ten days before Opus 4.7 GA. The changelog entry for v2.0.7 (2026-04-05) reads: "Fixed chat failing silently when personal Claude account lacks access to the selected model, now auto-falls back to built-in account." The user-visible fix was available before the rollout event it was built for, which is how a consumer app should work. You cannot wait until launch day to write the fallback for launch day.
The accessibility API is the other half of "uncopyable"
Everything above is about Fazm's cloud inference layer. The other half of the product works at the macOS accessibility API (AXUIElement) rather than against screenshots. That is what lets Fazm read a native Mail window, a Safari tab, a Finder list view, and a Terminal buffer as structured text with coordinates, not as pixels to OCR. When a model release lands and the inference layer shuffles itself around a rollout gap, the perception layer is not involved. When Apple ships an AX change in a macOS point release, the inference layer is not involved. That orthogonality is why "consumer-friendly app, not a developer framework" is a real claim: both halves can evolve independently, and the user never has to know which half just fixed the problem they did not see.
Want to see the rollout-gap fallback fire in your own Fazm log?
Book a 20-minute walkthrough. We'll tail /tmp/fazm-dev.log together and trigger the auto-retry on a staging account with access stripped for a specific model.
Book a call →Frequently asked questions
What is the April 2026 AI model release rollout gap that this page is about?
When Anthropic released Claude Opus 4.7 to general availability on April 14, 2026, the model id started appearing in the Claude Agent SDK's availableModels response within hours. But the server-side access rollout for paying personal-plan OAuth users was staggered over several days. Users whose plan had not yet been flipped saw a server error whose message varied slightly but always contained 'model' plus either 'not found', 'not available', or the combination 'may not exist' and 'not have access'. In a consumer Mac app that naively surfaces agent errors as a banner, the user sees a red box that says 'This model may not exist, or you do not have access to it' and has to re-type the question against a different model. The new Opus is in the picker, but it does not actually respond for them. This page is about the dual-lane client-side fix Fazm shipped so the same query lands on a lane that has access.
What does Fazm literally do when the personal Claude lane returns a model access error?
Three things, in order, all inside Desktop/Sources/Providers/ChatProvider.swift. First, a guard at line 2943 checks that bridgeMode is 'personal', the error type is BridgeError.agentError, and Self.isModelAccessError(msg) returns true. Second, line 2950 sets pendingBridgeModeSwitch to 'builtin' and line 2951 sets retryAfterModelFallback to true; line 2953 explicitly clears errorMessage so no red banner renders. Third, after the bridge actually switches lanes via applyPendingBridgeModeSwitch at line 2965, lines 2967 to 2973 check the retry flag, pull the original query out of pendingRetryMessage, null it, and call sendMessage(retryText) again. The user sees one spinner, one reply, no error. The query that failed on Opus 4.7 on the personal lane gets re-run on Fazm's built-in shared Claude account, which Fazm keeps provisioned for exactly this rollout-gap case.
What are the exact substring patterns that count as a model access error?
Three disjunctive patterns in ChatProvider.swift isModelAccessError, lines 1362 to 1368. Pattern one: the lowercased message contains both 'may not exist' and 'not have access'. Pattern two: it contains both 'model' and 'not found'. Pattern three: it contains both 'model' and 'not available'. Any one of those triggers the dual-lane fallback. The rest of the error pipeline, isAuthRelatedError and isTermsAcceptanceRequired, handles 401 and terms-of-service errors and is intentionally separate so auth-required and terms-of-service issues do not silently swap lanes. You can verify by running grep -n 'isModelAccessError' Desktop/Sources/Providers/ChatProvider.swift in the Fazm repository; it returns lines 1362, 2946, 2949, 2967, 2970.
Why not just default everything to the built-in lane?
Because personal Claude usage is free for the user up to their plan's rate limit, while built-in usage bills against Fazm's pooled API budget. The built-in lane is a reliability backstop, not the primary path. When a new frontier model drops and Anthropic has rolled access out for a given user's plan, Fazm wants that user's queries to land on their own personal credit, not Fazm's. The dual-lane fallback is specifically for the window where a personal plan has not yet been flipped to the new model. Once the rollout catches up, the personal lane stops returning model-access errors and the user is right back on their own credit, with no app or setting change.
Does the auto-retry create a loop risk or a double-charge if the built-in lane also fails?
No. The retry guard at line 2968 specifically requires retryAfterModelFallback to be true, and that flag is set exclusively in the personal-lane branch at line 2951. If the built-in lane fails for any reason (credit exhaustion, network, terms acceptance), the error flows through the generic else branch at line 2954 which clears pendingRetryMessage and surfaces errorMessage to the UI. The retry is a one-shot. The flag is scoped to a single sendMessage invocation via the local 'var retryAfterModelFallback = false' at line 2400. There is no loop, and no second automatic lane swap without fresh user input.
Where does Fazm's accessibility-API architecture fit into a model-release story?
It does not, and that is the point. Accessibility APIs are the local perception layer: how Fazm reads, clicks, and types into any app on your Mac via AXUIElement rather than screenshots. The dual-lane model fallback is the cloud inference layer: which Claude account serves the reply. They are orthogonal by design. A new Claude release (Opus 4.7, Mythos) only touches the second layer. A macOS update that changes AX semantics only touches the first. The consequence: Fazm handled the Opus 4.7 rollout gap without touching a single line of accessibility-API code, and handles macOS AX-API changes without touching a single line of model routing.
Can I reproduce the rollout gap and see this path fire?
Yes. On a macOS build of Fazm from 2026-04-04 or later, connect a personal Claude account that has not been granted Opus 4.7 access, open a new chat, pick Smart in the floating bar (which resolves to the 'opus' alias in the Claude Agent SDK), and send a message. Then tail /tmp/fazm-dev.log. You should see 'ChatProvider: model access error in personal mode, falling back to builtin:' followed by the raw message, then 'ChatProvider: auto-retrying query after model access fallback to builtin', then the normal Claude response streaming. Ultimately the same prompt gets answered by Opus on Fazm's built-in lane while the SDK error is logged but not shown. This behavior was added in commit dc741c22 on 2026-04-04 at 17:37 PDT.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.