Removed .navigationBarHidden(true) and all custom header layout.
Now uses standard iOS 26 navigation APIs that get Liquid Glass free:
- .navigationTitle("Reader") + .navigationSubtitle("74 unread")
- ToolbarItemGroup for sub-tabs (Unread/Starred/All) on leading
- ToolbarSpacer between groups
- ToolbarItemGroup for grid/list + menu on trailing
- Feed filter chips in .bottomBar toolbar
- When auto-scrolling: toolbar swaps to speed controls
The glass nav bar is translucent — content scrolls underneath.
Collapses to inline glass pill on scroll (system behavior).
No custom backgrounds, no custom layout — all system-managed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Uses .safeAreaBar(edge: .bottom) on the Reader content — the iOS 26
API that places content in the collapsed tab bar area, same position
as the Now Playing mini bar. Speed controls [ - ] 1.50x [ + ] appear
in the glass bar when auto-scrolling.
Removed the floating speed pill overlay from ContentView.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Speed pill and feedback button were in separate VStacks with
independent absolute padding, causing misalignment. Now they share
one VStack with .padding(.bottom, 70) at the container level.
The speed pill sits directly above the tab bar area, positioned
relative to the same anchor as all other bottom controls.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Speed pill was floating mid-screen (padding.bottom 90). Moved to
bottom (padding.bottom 8) to sit just above the tab bar area.
Switched from ultraThinMaterial to regularMaterial for better
Liquid Glass look with more opacity and stronger blur.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ROOT CAUSE (confirmed by instrumentation):
Every markRead during auto-scroll mutated entries[idx].status,
causing SwiftUI to re-render the row (bold→regular, dot removed).
This changed card height, causing contentSize jumps of 10-128pt
per entry — visible as jitter.
FIX: During auto-scroll, collect entry IDs in deferredReadIDs
instead of mutating entries array. When auto-scroll stops,
flushDeferredReads() applies all status changes at once and
sends a single batched API call.
Manual scroll still marks immediately (no deferral needed since
the user controls the scroll position).
Removed all debug instrumentation.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Calling scrollViewWillBeginDragging/DidEndDragging on the delegate
didn't trigger tabBarMinimizeBehavior — iOS 26 likely tracks actual
touch events, not delegate calls. Reverted to avoid side effects.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
tabBarMinimizeBehavior needs scrollViewWillBeginDragging to recognize
a scroll session. Now ScrollViewDriver calls it on the original
delegate when auto-scroll starts, and scrollViewDidEndDragging +
scrollViewDidEndDecelerating when it stops.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bug: when action tab (value=3) was tapped, selectedTab was already 3
by the time handleActionTap ran. The check 'if selectedTab == 2'
always failed, falling through to food assistant.
Fix: use onChange(of: selectedTab) oldValue to capture which tab the
user was on BEFORE tapping the action button. Pass that to
handleActionTap(from:). If from Reader (2), toggle auto-scroll.
If from Home/Fitness, open food assistant.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Single separated circle in tab bar (like Photos search icon):
- Home/Fitness: shows + icon, taps opens food assistant
- Reader idle: shows play icon, taps starts auto-scroll
- Reader playing: shows pause icon, taps stops auto-scroll
Icon updates dynamically via computed actionIcon property.
handleActionTap() routes the tap based on selectedTab.
After action, selectedTab returns to the previous tab (doesn't
stay on the invisible "action" tab).
Speed controls still appear as glass capsule overlay when playing.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Removed Tab(role: .search) — it was always visible on all tabs.
Now the floating action button changes based on selected tab:
- Home/Fitness: FAB (+) → opens food assistant (same as before)
- Reader: Play/Pause circle → toggles auto-scroll
- Idle: play.fill icon, warm accent background
- Playing: pause.fill icon, red background
- Tapping toggles between play/pause
Speed controls appear as glass capsule above the FAB when playing.
Auto-scroll stops when switching away from Reader tab.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Migrated to new Tab API (iOS 18+). The auto-scroll play button
uses Tab(role: .search) with systemImage: "play.fill" — this gives
the separated circular placement on the trailing side of the tab
bar, identical to the Photos app search icon.
Tapping the play icon:
- Switches to Reader tab
- Starts auto-scroll
When playing: a Liquid Glass speed control capsule appears above
the tab bar with [ - ] 1.00x [ + ] [ stop ].
Removed the old floating glass pill implementation.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Moved auto-scroll control from ReaderTabView to MainTabView so it
sits at the tab bar level, trailing side — matching the iOS Photos
search icon placement.
Idle: 48px glass circle with play icon (bottom-right, tab bar row)
Playing: expands to capsule with [ - ] 1.00x [ + ] [ stop ]
Spring animation between states.
Grid/list toggle and ellipsis menu moved inline to the sub-tab
header row (next to Unread/Starred/All) so they're always visible
without needing a toolbar.
ReaderTabView now receives isAutoScrolling and scrollSpeed as
bindings from MainTabView.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. FAB hidden when selectedTab == 2 (Reader) — no plus button
on Reader since it's for food logging
2. Auto-scroll now notifies original UIScrollViewDelegate via
scrollViewDidScroll after each contentOffset change — this
triggers tabBarMinimizeBehavior so the tab bar collapses
during auto-scroll just like manual scrolling
3. Glass control bar positioned bottom-right (like Photos search
icon) instead of bottom-center
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Floating glass pill above the tab bar with .ultraThinMaterial:
Idle state: [ ▶ ] [ grid/list ] [ ⋯ ]
- Play: starts auto-scroll
- Grid/list: toggles card/list view
- Ellipsis menu: mark all read, refresh, manage feeds, add feed
Playing state: [ - ] 1.00x [ + ] | [ ■ ]
- Speed adjustment in 0.25 increments (0.25x–3.0x)
- Stop button (red)
- Animated spring transition between states
Removed .navigationBarHidden(true) toolbar items — all controls
now in the glass bar. Nav bar stays hidden (no title needed).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The GPU warmup set webView.alpha = 0 to keep it invisible while
attached to the window. makeUIView reparents it to the article
container but never restored alpha — articles rendered invisibly.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
GPU process can exit due to idle timeout if user waits before opening
Reader. reWarmIfNeeded() checks elapsed time since last warm — if >60s,
re-attaches WKWebView to window and loads minimal HTML to restart the
GPU process. Called on ReaderTabView.onAppear.
No timers, no keep-alive loops. Just a timestamp check on tab appear.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The GPU process was exiting due to idle timeout between warmup and
first article open. Now the WKWebView stays attached to the window
(alpha=0, invisible) until first article use. makeUIView reparents
it to the article container via removeFromSuperview + addSubview.
Also: removed all debug logging (warmup, article open, WebView timing).
Confirmed by instrumentation:
- GPU process launches during warmup (1.3s, background)
- First article open: 22ms total, WebView finish: 3ms
- No user-visible freeze
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
THEORY: WKWebView at frame .zero or detached from window skips GPU
compositor init. First real display triggers GPU process launch (~3s).
FIX: Create WKWebView at screen bounds, attach to key window (alpha=0)
during warmup. WebKit launches GPU process while user is on Home tab.
Remove from window after 2s (GPU process stays alive).
Also: ensureAttachedToWindow() fallback if init runs before window
exists. Called from ContentView.task where window is guaranteed.
Added 1x1 transparent GIF in warmup HTML to force image decoder init.
Kept all debug logging for verification.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ROOT CAUSE: Articles from sites like onemileatatime.com serve WebP
images with .jpeg extensions. WebKit attempts JPEG decode, fails,
retries as WebP — the retry loop blocks the compositor thread during
scroll, causing ~1s freezes per image.
FIX 1 — Image attributes (ArticleHTMLBuilder.optimizeImages):
Regex injects loading="lazy" decoding="async" on all <img> tags
that don't already have loading= set. This tells WebKit to:
- decode images off the main/compositor thread (decoding=async)
- only decode when approaching viewport (loading=lazy)
FIX 2 — CSS max-height:
img { max-height: 600px; object-fit: contain; }
Limits decoded image buffer size. A 1200x900 image still displays
at full width but WebKit doesn't need to composite oversized tiles.
Both fixes are content-rendering optimizations only — no changes
to WKWebView architecture, scrolling model, or layout system.
Also marked Atmos Rewards articles as unread for testing.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LOG EVIDENCE:
1. notVisible: wasVisible never set for entries already on screen
at list load. Removed wasVisible guard — trackingActive (100pt
scroll) is sufficient protection.
2. aboveVP: maxY never goes below 0. LazyVStack destroys views at
~maxY=0. Changed threshold from maxY<0 to maxY<30 (nearly off).
3. notDown flickering: per-entry deltas are ~1pt, causing direction
to flip between down/not-down on every callback. Made direction
sticky: scrollingDown stays true until 30pt of cumulative upward
scroll is detected. Prevents jitter from sub-pixel noise.
Removed debug logging.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
EVIDENCE (from xcode.txt):
- down=false ALWAYS: per-entry deltas are ~1-2pt per callback,
but filter required >2pt. Every delta was rejected.
- cumDown stuck at 129: threshold was max(100, 956*0.2) = 191.
With most deltas rejected, cumulative barely grew.
FIXES:
1. Delta filter: >2pt → >0.5pt for direction detection.
Cumulative accumulation accepts any delta >0 (no filter).
Per-entry callbacks deliver small deltas — filtering at 2pt
discarded virtually all genuine scroll events.
2. Threshold: removed 20% viewport scaling, fixed at 100pt.
The scaling made sense for a global offset tracker (large
deltas), not per-entry tracking (small deltas).
Removed debug logging.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bug: lastKnownMinY[entryId] was set to newMinY on line 83, then
read back on line 97 to check direction. Since it was just set to
newMinY, the check (lastKnownMinY[entryId] <= newMinY) was always
true, making isMovingUp always true, so the guard always failed.
Fix: Read prevMinY BEFORE writing newMinY. Compute isScrollingDown
from the delta between prev and new. Use that boolean in the guard.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ROOT CAUSE (confirmed by instrumentation):
1. viewportHeight was 0 — background GeometryReader onAppear fired
before ScrollView layout, never updated. Visibility ratio was
always 0.00, so wasVisible was never populated.
2. cumulativeDown was 0 — PreferenceKey + onPreferenceChange on the
zero-height anchor never delivered scroll offset updates.
3. Both tracking mechanisms were dead. Only per-row onChange fired.
FIX: Removed dead PreferenceKey scroll tracker and dead viewport
background GeometryReader. All tracking now lives in the per-row
GeometryReader onChange(of: frame.minY), which the logs confirmed
fires reliably:
- Scroll direction: computed from delta between current and previous
minY for each entry (stored in lastKnownMinY dictionary)
- Cumulative scroll: accumulated from positive deltas (>2pt filter)
- Activation: requires cumulative downward scroll > threshold
- Visibility: computed using UIScreen.main.bounds.height (reliable,
doesn't depend on layout timing)
- Mark condition: trackingActive + moving down + unread + was visible
+ maxY < 0 (fully above viewport)
Navigation protection preserved: onAppear resets trackingActive,
cumulativeDown, and lastKnownMinY.
Removed debug instrumentation.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Temporary logging to identify which guard condition prevents marking.
Logs visibility ratio, scroll state, and failure reasons for entries
that are above viewport but not being marked. Will remove after fix.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ROOT CAUSE: The exact crossing condition (oldMaxY >= 0 && newMaxY < 0)
required onChange to fire at the exact moment maxY crosses zero. But
LazyVStack recycles views when they scroll off-screen, destroying the
GeometryReader before the crossing event is delivered. The entry goes
from maxY=15 to being recycled — onChange never sees maxY go negative.
FIX: Replace exact crossing with position check (newMaxY < 0). The
entry just needs to be fully above the viewport. The other 5 guards
prevent false positives:
1. trackingActive (scrolled past threshold)
2. isScrollingDown
3. !entry.isRead
4. !markedByScroll (dedup)
5. wasVisible (was >=50% visible)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Madiha sees only Home + Fitness tabs (same as web dashboard).
Reader tab, pre-warm, and data pre-fetch all skipped for her login.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. Visibility requirement (new condition 5):
- Tracks max visible ratio per entry via GeometryReader
- Entry must have been >=50% visible at some point to qualify
- Prevents marking entries that were never genuinely seen
- Uses wasVisible set, populated by onChange(of: minY)
2. Dynamic activation threshold:
- max(100pt, 20% of viewport height)
- Taller screens (iPad) require proportionally more scroll
- Measured via background GeometryReader on ScrollView
3. Stabilized scroll direction:
- Ignores micro deltas <2pt (was 1pt)
- Filters layout noise, rubber-banding, and momentum artifacts
Existing protections preserved:
- trackingActive reset on onAppear (navigation protection)
- downward-only marking
- crossing detection (oldMaxY >= 0, newMaxY < 0)
- markedByScroll dedup set
6 conditions must ALL be true to mark an entry:
1. trackingActive (scrolled past threshold)
2. isScrollingDown
3. !entry.isRead
4. !markedByScroll.contains(id)
5. wasVisible.contains(id) — was >=50% visible
6. bottom edge crossed above viewport
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Uses GeometryReader + coordinate space to track entry positions —
NOT onAppear/onDisappear.
How it works:
1. ScrollView has a named coordinate space ("readerScroll")
2. Invisible anchor at top measures scroll offset via PreferenceKey
3. Each entry row has a background GeometryReader that tracks its
frame in the scroll coordinate space
4. onChange(of: maxY) detects when an entry's bottom edge crosses
above the viewport top (oldMaxY >= 0 → newMaxY < 0)
5. Entry is marked read only when ALL conditions are true:
- trackingActive (user scrolled down >100pt)
- isScrollingDown (current direction is down)
- entry is unread
- entry hasn't been marked by scroll already
- entry's bottom edge just crossed above viewport
Navigation protection:
- onAppear resets trackingActive = false and cumulativeDown = 0
- When returning from an article, tracking is suspended
- User must scroll down 100pt before tracking reactivates
- This prevents all visible entries from being marked read on
navigation back (they were already below viewport, not crossing)
- Scrolling up never marks anything (isScrollingDown = false)
State updates are local-first (immediate) with background API sync.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Empty HTML warmup only spun up the WebContent process. The first
real article still paid ~3s for CSS parsing, font measurement,
layout engine init, and compositing pipeline startup.
Now ArticleRenderer.init loads the full ArticleHTMLBuilder template
with sample content covering all styled elements (paragraphs,
headings, blockquotes, code blocks). WebKit performs real rendering
during app launch while the user is on Home/Fitness. By the time
they open the first article, CSS is parsed, fonts are measured,
and the pipeline is warm — the first article renders as fast as
subsequent ones.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The local entries mutation now runs synchronously at the top of
.task, before any Task {} or await:
1. vm.entries[idx].status = "read" ← synchronous, immediate
2. currentEntry syncs from mutated array ← immediate
3. Task { api.markEntries + getCounters } ← background
4. await getEntry ← content fetch, merge preserves local status
Previously markAsRead was wrapped in Task {} (fire-and-forget),
which SCHEDULED the mutation but didn't execute it until the main
actor yielded. Line 2 read stale state because the mutation hadn't
run yet.
Now the @Observable array mutation happens before any async work,
so the ForEach row re-renders on the same run loop — the list
shows "read" even during the push animation.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Toolbar:
- Removed star, read/unread, and ellipsis menu
- Single "Save to Brain" button (brain icon, turns green when saved)
Open original article:
- Title in HTML header is now a tappable link (when URL exists)
- Subtle ↗ icon after title indicates external link
- Tap opens in Safari via existing WKNavigationDelegate link handler
- No accidental triggers: styled as text link, not a button
- Active state dims to 0.6 opacity for tap feedback
- Dark mode: title link inherits text color (not accent)
No floating buttons added. No architecture changes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
API deprecated since iOS 15. All WKWebViews already share one
WebContent process. Our singleton WKWebView + shared config is
sufficient.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- HTML template now wraps article content in <div id="article-body">
- Content upgrade JS targets only #article-body.innerHTML, leaving
header, CSS, and outer document structure untouched
- Returns 'ok'/'no-container' status for reliable fallback detection
- extractArticleBody() parses the #article-body content from HTML
- escapeForJS() separated into its own method
- Full reload fallback if container not found or JS fails
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. Explicit WKProcessPool — static shared instance assigned to
WKWebViewConfiguration. Prevents any future divergence even
though iOS 15+ shares by default.
2. Scroll-preserving content upgrade — when articleContent updates
(partial → full), uses JavaScript DOM replacement instead of
loadHTMLString. Captures window.scrollY before swap, restores
after. No visible flash or scroll jump. Falls back to full
reload if JS replacement fails.
3. No unnecessary reloads — coordinator tracks lastHTML. Only
loads if content actually changed. First article open = full
page load (lastHTML is nil). Content upgrade = DOM swap
(lastHTML exists, new content is different).
4. Clean separation — isUpgrade flag distinguishes first load
from content upgrade. First load uses loadHTMLString (needs
full <html> document). Upgrade uses innerHTML replacement
(preserves scroll, CSS, page state).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Changes:
1. Article opens INSTANTLY — articleContent initialized from entry's
existing content in init(), not after API fetch. WebView renders
immediately with whatever we have. Full content swaps in silently
when getEntry returns (only if longer than current).
2. markAsRead is fire-and-forget — wrapped in detached Task inside
.task, does not block the content display chain. Toolbar syncs
from vm.entries immediately after.
3. CSS template pre-built as static string in ArticleHTMLBuilder.
Avoids rebuilding ~2KB of CSS on every article open. HTML builder
is a stateless enum with a single static method.
4. Removed isContentReady flag — no longer needed since content is
available from init. Spinner only shows if entry truly has no
content at all (rare edge case).
Flow is now:
tap → ArticleView created with entry.articleHTML →
WebView loads immediately → user can scroll →
background: markAsRead fires, getEntry fetches full content →
if full content is better, WebView updates silently
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Bug 1: First open didn't mark as read
ROOT CAUSE: Race condition. markAsRead set local status="read",
then getEntry returned the server's status="unread" (API sync
hadn't completed yet) and overwrote the local mutation.
FIX:
- markAsRead runs FIRST, before getEntry (was concurrent before)
- After getEntry, merge server response but PRESERVE local
status/starred (which may differ from server due to race)
- currentEntry syncs from vm.entries after markAsRead, ensuring
the toolbar reflects the correct state
## Bug 2: Long articles freeze before scrollable
ROOT CAUSE: WKWebView.scrollView.isScrollEnabled = false, embedded
inside SwiftUI ScrollView with .frame(height: webViewHeight).
For a 15000px article, WebKit had to render the entire document,
JavaScript measured document.body.scrollHeight, SwiftUI relaid out
the 15000px frame — all blocking before scroll became responsive.
FIX:
- WKWebView now handles its own scrolling (isScrollEnabled = true)
- Removed SwiftUI ScrollView wrapper around article
- Removed contentHeight binding and height measurement JavaScript
- Removed the Coordinator's didFinish height evaluation
- Article header (title, feed, time) moved into the HTML document
so it scrolls naturally with the content
- WKWebView fills available space, scrolls natively via WebKit's
compositor thread — immediate scroll response
Both fixes preserve the shared WKWebView architecture.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root-cause investigation identified 5 architectural issues. This commit
fixes all of them with structural changes, not patches.
## 1. Persistent ArticleRenderer (fixes first-article freeze)
BEFORE: Every article tap created a new WKWebView with a new
WKWebViewConfiguration and a new WKProcessPool. Each spawned a
WebContent process (~3s). The "warmer" used a different config,
warming a different process — useless.
AFTER: Single ArticleRenderer singleton owns one WKWebView with
one shared WKProcessPool + WKWebViewConfiguration. Created at app
launch via `_ = ArticleRenderer.shared` in ContentView.task.
ArticleWebView wraps the shared WKWebView in a container UIView.
SwiftUI owns the container lifecycle, not the WKWebView's.
Zero process launches after first warm-up.
## 2. Stable Reader layout (fixes tab jitter)
BEFORE: Sub-tabs and feed chips were conditionally rendered
(`if !vm.isLoading || !vm.entries.isEmpty`). When loading finished,
~80px of UI appeared suddenly, causing layout shift that rippled
to the tab bar.
AFTER: Sub-tabs and feed chip bar ALWAYS render. Feed chip bar has
fixed height (44px). No conditional wrappers in the layout hierarchy.
Content area shows LoadingView during fetch. Chrome never changes shape.
## 3. Local-first state updates (fixes mark-read lag)
BEFORE: markAsRead made 3 sequential API calls (mark, re-fetch entry,
re-fetch counters). toggleRead and toggleStar did the same. Each
action had 3 network round-trips before UI updated.
AFTER: Mutate local entries array immediately (status/starred are
now var). API sync happens in background via Task.detached. UI updates
instantly. Counter refresh happens async.
## 4. Atomic list replacement (fixes empty flash)
BEFORE: loadEntries(reset:true) set `entries = []` then
`entries = newList`. Two mutations = empty state flash + full
LazyVStack teardown/rebuild.
AFTER: Never clear entries. Fetch completes, then single atomic
`entries = newList`. SwiftUI diffs by Identifiable.id — only
changed rows update.
## 5. Reserved thumbnail space (fixes card layout jump)
BEFORE: AsyncImage default case was EmptyView() (0px). When image
loaded, 180px appeared. Cards jumped.
AFTER: Default case renders a placeholder Rectangle at 180px.
Card height is stable from first render.
## Additional: Pre-load moved off TabView
`.task { await readerVM.loadInitial() }` moved from TabView
(caused observable mutations during TabView body evaluation,
contributing to tab bar jitter) to the outer ZStack.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
