Agentic Commons

Claude 免費用戶的資料開關：訓練授權、五年保留期與產品團隊要留意的界線

Wed, 16 Sep 2026 00:00:00 GMT

一個彈出視窗，決定你的對話會不會進訓練集

Anthropic 在 2025 年 8 月 28 日公布消費者條款與隱私政策更新，核心是一個選擇權：Claude Free、Pro、Max 用戶可以自行決定是否讓自己的資料被用來改進 Claude，以及強化對詐騙、濫用等有害使用的防護。官方說法是，參與者能協助提升模型安全，讓偵測有害內容的系統更準確、更不容易誤判無害對話，也讓未來的 Claude 在coding、分析與推理上表現更好。

這不是預設全開、也不是預設全關的技術細節問題，而是產品介面上的同意流程問題。新用戶在註冊流程中選偏好；既有用戶會看到彈出視窗，並在 2025 年 10 月 8 日前接受更新後的消費者條款並做出選擇。若選擇現在接受，新政策立即生效。

適用範圍：消費者方案，不含商用與 API

這次更新只涵蓋 Claude Free、Pro、Max，包括用這些帳號使用 Claude Code 的情境。Anthropic 明確表示不適用於 Commercial Terms 下的服務，包括 Claude for Work、Claude for Government、Claude for Education，以及 API 使用，例如透過 Amazon Bedrock、Google Cloud Vertex AI 等第三方途徑。

對產品團隊來說，這條界線比條款本身更值得記下來：同一個模型家族，會因為帳號類型與存取途徑而有不同的資料處理規則。如果你的產品同時服務消費者與企業客戶，或同時走自家 API 與雲端市集，使用者問「我的資料會不會被拿去訓練」時，答案取決於他從哪個入口進來。

五年保留期與 30 天的分岔

若允許資料用於模型訓練，Anthropic 會把資料保留期延長到五年；不提供的用戶則維持原本的 30 天保留期。五年期只適用於新的或重新開始的對話與coding session，也適用於用戶針對 Claude 回應提交的回饋。官方補充，刪除的對話不會用於未來的模型訓練，且不會把用戶資料賣給第三方；敏感資料則透過工具與自動化流程過濾或模糊化。

這裡有兩個容易混淆的點。第一，條款更新只影響新的或重新開始的對話與 session，不是回溯全部歷史。第二，10 月 8 日之後，用戶必須就模型訓練設定做出選擇才能繼續使用 Claude，但選擇之後仍可隨時在 Privacy Settings 更改。

對開發者的實務影響

如果你的團隊把 Claude 接進內部工具或客戶流程，先確認流量走的是哪一種條款。走 API 或雲端途徑的商用情境不在這次更新範圍內；但同事用個人 Pro 帳號跑 Claude Code 做原型，就會落在消費者條款裡。這種混用很常見，也最容易在資安審查時被問倒。

同意流程的設計本身也有參考價值：把選擇放在註冊與既有用戶的彈出視窗、給出明確期限、允許隨時更改，並區分「接受條款」與「是否用於訓練」兩件事。這種把預設值與後續控制權分開處理的做法，和我們先前談過的 Cloudflare 把混合用途爬蟲拆成三種行為是同一個思路：不要用一個開關概括所有用途，而是讓不同用途有不同規則。

目前公開資訊來自 Anthropic 的公告，具體的資料保留實作、過濾流程細節，以及不同地區用戶的適用差異，公告中沒有進一步說明。若你要把這件事寫進內部政策，建議直接以官方 FAQ 與實際帳號設定為準，而不是憑這篇摘要推論。

參考來源

Updates to Consumer Terms and Privacy Policy

What Anthropic's Consumer Data Opt-In Changes for How You Build on Claude

Wed, 16 Sep 2026 00:00:00 GMT

What Anthropic's Consumer Data Opt-In Changes for How You Build on Claude

Anthropic is changing how consumer data flows into model improvement. On Aug 28, 2025, the company rolled out updated Consumer Terms and a Privacy Policy that give Claude Free, Pro, and Max users an explicit choice: allow their conversations to be used for training and safety work, or keep the existing 30-day retention and opt out. If you build on Claude or ship products that touch consumer accounts, the mechanics of this choice affect your data handling assumptions.

The opt-in changes what ‘consumer data’ means for training

Until now, consumer chats were not used for training by default. The new policy flips that to an opt-in model. Users who agree help improve model safety and future Claude capabilities, including coding, analysis, and reasoning. Anthropic says the data is filtered or obfuscated to protect sensitive information, and it does not sell user data to third parties.

For builders, the key boundary is scope. These updates apply only to consumer plans — Free, Pro, and Max — and to Claude Code sessions tied to those accounts. They do not apply to Commercial Terms services: Claude for Work, Claude for Government, Claude for Education, or API usage, including through Amazon Bedrock or Google Cloud’s Vertex AI. If you’re integrating Claude via API or enterprise agreements, your data handling remains unchanged.

The Oct 8 deadline forces a decision point

Existing users have until October 8, 2025 to accept the updated Consumer Terms and make their training-data choice. If they accept now, the new policies take effect immediately for new or resumed chats and coding sessions. After the deadline, users must select a training preference to continue using Claude. New users pick during signup.

This deadline matters for product teams that onboard users to Claude-powered features. If your app relies on consumer Claude accounts, your users may see a pop-up or notification asking them to decide. The choice affects what data you can expect to persist: opt-in users get a five-year retention window for new or resumed sessions, while opt-out users stay on the existing 30-day retention. Deleted conversations are never used for future training, regardless of the setting.

What this means for your data pipeline assumptions

If you build tools that process or store Claude conversation logs from consumer accounts, the retention change is a concrete variable. A user who opts in has their data retained for up to five years, which could affect compliance reviews, data deletion requests, or downstream analytics you run on those logs. The 30-day default for opt-out users is a much shorter window.

This is a different problem from the one Cloudflare tackled with its Disallow AI Training setting, where website owners control whether crawlers can use their content. Here, the control sits with the end user, not the site or app owner. Builders who proxy Claude consumer accounts need to surface that control clearly, not bury it.

The safety angle is part of the tradeoff

Anthropic frames the opt-in as a way to improve safeguards against scams and abuse, not just model quality. Users who participate help make harmful-content detection more accurate and less likely to flag harmless conversations. That’s a real benefit for consumer-facing products, where false positives on safety filters can break user trust.

But the tradeoff is data longevity. Five years of retained conversations is a long time for personal data, even with filtering and obfuscation. Builders who advise users on privacy settings should be explicit: opting in means your chats may be used to train future models and retained for five years, unless you delete them. Opting out keeps the 30-day window but means you don’t contribute to model improvement.

What to watch next

The supplied source does not specify how the opt-in rate will affect model quality or safety improvements, nor does it detail the exact filtering and obfuscation methods. Those details matter for builders who want to quantify the privacy risk. For now, the practical step is to check whether your product touches consumer Claude accounts and, if so, prepare your users for the Oct 8 decision point. The setting lives in Privacy Settings and can be changed at any time, but the deadline forces an initial choice.

Sources

Updates to Consumer Terms and Privacy Policy

當掃描器看不見攻擊：Cloudflare 用 ML 拆解店面前的惡意 JavaScript

Wed, 16 Sep 2026 00:00:00 GMT

當掃描器看不見攻擊：Cloudflare 用 ML 拆解店面前的惡意 JavaScript

頁面看起來正常，不代表沒有問題

一個電商店面可以載入很快、商品齊全、結帳流程順暢，但底層的 JavaScript 正在做店主從未授權的事：抽走聯盟佣金、劫持搜尋與點擊、竄改分析數據，或向遠端伺服器詢問下一步要執行什麼。Cloudflare 在 2026 年 9 月 16 日發布的文章裡，把這個盲點講得很清楚：頁面健康與程式碼安全是兩件事。

這篇貼文追蹤了四個實際營運中的惡意行動、共八個 payload，全部由 Page Shield ML 自動偵測，人類只在系統標記後才進場覆核。事後用一般安全掃描工具回頭檢查，八個 payload 有七個完全不在 VirusTotal 上，URLScan 也沒有對任何一個給出惡意判定。這個對比是整篇的核心：等到威脅情報資料庫替你貼上標籤，你已經晚了。

為什麼簽章式防禦在這裡失效

四個行動沒有共用簽章，也沒有共通的藏匿手法。Cloudflare 描述其中一個會等到裝置、國家、時間、referrer 或瀏覽器狀態符合條件才醒來；另一個把無點擊的聯盟請求塞進不可見的 iframe；還有攔截點擊、壓制監控、或條件式從遠端載入更多程式碼的變體。

換句話說，靜態掃描一次頁面是不夠的。這些腳本被設計成在正確的受害者出現前保持安靜，所以需要的是持續的瀏覽器可視性，而不是單點檢查。

Cloudflare 的做法是把 JavaScript 當成圖來推理，而不是一段平面文字。同一個 GNN 先前已經抓過惡意 npm 套件與一個實際運作中的 Magecart 付款側錄程式；它透過語法樹連結程式符號，看出誰呼叫誰、攻擊者埋了什麼、還有什麼仍在對外連線。被 GNN 標為惡意的流量不到全部分析量的 0.3%，這些會再送進 Workers AI 上的輕量 LLM 做即時第二意見，以壓低誤判同時維持召回率。

最複雜的腳本則交給一組前沿模型（Cloudflare 稱之為 teachers）各自在獨立 session 中分析，必要時用受限的 JavaScript 評估器拆解片段。模型之間的分歧被當成訊號而非雜訊，每個標記依模型在 Artificial Analysis Intelligence Index 的分數加權投票，形成 benign、payment skimming、other malware、cryptomining 四類的機率分布。只有被標為惡意或缺乏三分之二多數的腳本才需要人工檢視。

四個行動各自偷走不同的東西

第一個行動針對行動裝置訪客：攔截商品點擊後，用新分頁開啟攻擊者預選的商品頁，同時讓原分頁繞經攻擊者的聯盟追蹤連結再回到商店，把歸因 cookie 種在背景。店家可能付出一筆不該付的佣金，更麻煩的是，真正帶來轉介的合作夥伴被搶走歸因，信任一旦破裂，傷害會超過單筆佣金。這個行動的變體用 MutationObserver 監看動態出現的商品磚與按鈕，並在 localStorage 寫入三天冷卻期；被擷取到的暫停版本甚至留有版本註解，記錄自己在 Black Friday 之後被暫停。

第二個行動連點擊都不需要。訪客打開訂房頁、瀏覽選項、完全沒碰廣告，腳本可能已經送出聯盟請求，讓之後的成交看起來像別人轉介的。Cloudflare 指出，程式碼證明了隱蔽的自動化聯盟請求存在，但某個具體請求是否真的完成歸因、入帳或付出佣金，並未被觀察到。這裡的界線值得產品團隊記住：能證明機制，不等於能證明損失金額。

供應鏈與 typosquatting 才是入口

第一個行動的投放路徑經過兩個看起來很普通的 tag manager：Google Tag Manager → 另一個 tag manager → 惡意腳本。Cloudflare 明確說明，這是 payload 抵達瀏覽器的方式，不是任一 tag manager 被入侵的證據。

更值得留意的是網域偽裝。其中一個投放主機 adtargett[.]com 與 1998 年註冊的廣告網域 adtarget[.]com 只差一個 t，首頁還自稱 Performance Marketing Agency。這種 typosquatting 讓它混在例行行銷標籤裡，通過快速的人工審查。

對產品與行銷團隊來說，實務上的下一步不是買更多掃描器，而是承認第三方腳本是一條持續變動的攻擊面。Cloudflare 的案例顯示，偵測能力必須跟著程式碼的執行時行為走；而對一般開發者，這也呼應了我們先前談過的 Cloudflare 把混合用途爬蟲拆成三種行為那類思路：先分清誰在做什麼，再決定要不要放行。

至於這套 ML 流程本身，Cloudflare 說回饋迴路仍有一部分靠人工，正在開始自動化。這是個誠實的限制，也提醒我們：自動偵測的準確度不是一次性設定，而是需要持續維護的系統。

參考來源

When scanners miss the attack: how Cloudflare Client-Side Security protects storefronts

Catching JavaScript That Waits for the Right Victim

Wed, 16 Sep 2026 00:00:00 GMT

Catching JavaScript That Waits for the Right Victim

A storefront can look healthy while malicious JavaScript works underneath: siphoning affiliate revenue, hijacking clicks, or tampering with analytics. Pages load and checkout works, yet the browser quietly does something the owner never authorized. Cloudflare’s Client-Side Security machine learning model is built to expose that blind spot, and a recent post details four operations it caught in the wild.

Why scanners miss what Page Shield ML catches

The detection was automated; humans verified findings only after the system flagged them. When Cloudflare reviewed the campaigns using security scanning tools, seven of the eight payloads were entirely absent from VirusTotal, and URLScan returned no malicious verdict for any of them. Page Shield ML caught all eight in live traffic.

One payload version sat indexed by URLScan for nearly two and a half years with “No classification,” including during a direct scan in January 2024. A hash can be known long before the code behind it is classified as malicious. If your defense waits for that label, you are already late. You need ML that can unravel the JavaScript itself and judge it at scale.

The four operations shared no universal signature or common concealment technique. One remained dormant unless device, country, time, referrer, or browser state matched. Another concealed a clickless affiliate request within an invisible iframe. Others intercepted clicks, suppressed monitoring, or conditionally loaded additional code from remote servers. Checking the page once is not enough; such scripts stay quiet until the right victim shows up.

How a graph neural network reasons about code

The same GNN that flagged these operations had already caught malicious npm packages and an in-the-wild Magecart payment skimmer. It does not treat JavaScript as flat text; it reasons through the code as a graph: a syntax tree connecting code symbols and exposing what calls what, what the attacker tried to bury, and what still phones home. That structure helps it recognize suspicious patterns across minification, renaming, and some obfuscation without relying on a known URL or byte signature.

The few scripts the GNN flags as malicious (under 0.3% of all analyzed traffic) go to a lightweight large language model on Workers AI for a live second opinion. This further reduces false positives while keeping recall high. When the LLM corroborates the GNN, customers are alerted.

For the most complex scripts, Cloudflare uses a cohort of frontier models called teachers. The cohort draws leading models from around six different families, including open-weight models running on Workers AI. Each analyzes the same suspicious script in its own fresh, independent session. When useful, their agentic tool access lets them use a restricted JavaScript evaluator to unpack small snippets and reveal concealed behavior.

The frontier models sometimes disagree, especially on intricate scripts. Cloudflare treats that disagreement as signal, not noise. Each label becomes a vote, weighted by the model’s score in the Artificial Analysis Intelligence Index, producing a probability distribution over four labels: benign, payment skimming, other malware, and cryptomining. Human reviewers need only examine scripts flagged as malicious or lacking a clear two-thirds majority. Those label distributions feed back into GNN training, helping it distinguish ever more nuanced cases.

Four operations that show the range of threats

These operations do very different things, from commission theft to stolen analytics on shoppers the store already paid to acquire. If an ML model only knows one of those tricks, it will sleep through the others.

Operation 1: The after-hours affiliate-commission hijacker. A shopper taps a product on a phone. Instead of following the tap normally, the script opens a product or campaign landing page from an attacker-preselected list in a new tab and sends the original tab through an affiliate route. If the shopper completes a purchase, the detour hijacks the attribution, crediting the sale to an account that did not earn the referral. The shop could pay an unearned commission, and partners who stop trusting the attribution system may also stop trusting the retailer.

The attack chain: qualified mobile visitor → intercepted product tap → script-selected page opens in new tab + original tab follows attacker’s affiliate route. Five related script builds were found: two active and three paused when captured. Each active variant uses different gates before it acts, checking device and local time, whether the trick has run recently, whether a product button has appeared, and whether someone actually clicks it. The active scripts use a MutationObserver to watch for product tiles and buttons that dynamically appear after the page is first loaded. A crawler that loaded the HTML once and stopped there could miss the redirect path entirely.

In active later variants, the script intercepts a qualifying click and writes a three-day cooldown to localStorage, then executes a dual-tab maneuver: popping an attacker-chosen product page into a fresh tab while the original tab takes a quick round-trip through the attacker’s affiliate tracking link to plant an attribution cookie in the background. Console masking and self-defending source checks make inspection harder.

The paused builds showed how the campaign could go dark without removing the script. Their embedded configuration set status: “paused”, so they exited before installing click handlers. One paused script even recorded a version-history comment explicitly documenting that the campaign was paused after Black Friday.

To reach visitors, the operation leveraged the site’s marketing supply chain: third-party scripts and tag managers embedded by e-commerce sites. One confirmed delivery path ran through Google Tag Manager → another tag manager → malicious script. That is how the payload reached the browser, not proof that either tag manager was compromised. The attacker even disguised the domain hosting the script: adtargett[.]com differed by a single “t” from adtarget[.]com, an advertising domain registered in 1998. The lookalike was registered in 2025 and called itself “Adtarget.com - Performance Marketing Agency.”

Operation 2: The clickless affiliate theft. A shopper can open a booking page, linger over product options, and never touch an ad. In the background, the script might have already sent an affiliate request that could make a later sale look as though someone else had referred the shopper. When conditions are met, the payload sends that request through a hidden iframe or a link that clicks itself.

The script conceals the affiliate request in two layers: selective execution (a pre-flight network gate and hourly schedule) and stealth delivery (an off-screen iframe). The first layer is surprising because its country labels are disconnected from actual geography. The script calls a public IP-based geolocation service but ignores everything it returns, including the shopper’s country. If the geolocation request fails, the script silently stops; its promise chain ends with .catch(() => {}). This fail-closed behavior could help the script evade network-restricted sandboxes.

Instead of using the fetched geolocation data, the payload contains three TradeDoubler configuration objects labelled AU, US, and UK. Each contains an affiliate URL and start and end times. The script computes Asia/Kolkata time in JavaScript, checks those configured time windows, then applies fixed odd/even-hour rules to choose one of the three or else skip the affiliate request for that run.

What this changes for how you build storefronts

Static scanners and reputation feeds are not enough. Malicious scripts are built to stay quiet until the right victim shows up, and they evolve without changing their hash. Runtime detection that watches how scripts behave — when they wake up, what they hide, what they intercept, and what they fetch next — is the difference between catching an attack and missing it entirely.

For builders, this means treating client-side security as an ongoing monitoring problem, not a one-time audit. The same principle applies to any system where third-party code runs in your users’ browsers: you need visibility into what that code actually does, not just what it claims to be. Cloudflare’s approach shows how combining graph-based analysis with LLM second opinions and ensemble voting can catch threats that traditional tools miss. As with scoping Cloudflare Workers access so agents can’t touch production, the goal is to limit what untrusted code can do and detect when it oversteps.

The supplied RSS summary does not specify the full details of Operations 3 and 4, but the pattern is clear: attackers are using increasingly sophisticated techniques to hide in plain sight. The takeaway for product builders is to assume that some of the JavaScript running on your storefront is malicious and to build detection that works at runtime, not just at deploy time.

Sources

When scanners miss the attack: how Cloudflare Client-Side Security protects storefronts

當 agent 也能改 production：Cloudflare 把 Workers 權限切到單一資源

Wed, 16 Sep 2026 00:00:00 GMT

當 agent 也能改 production：Cloudflare 把 Workers 權限切到單一資源

過去在 Cloudflare 上管理 Workers 權限，最常見的麻煩是「範圍太大」。你要嘛給對方整個帳號的權限，要嘛在角色與權限之間來回猜測。當 CI/CD 流程和 agent 也開始部署程式碼，這個問題就從不方便變成風險：一個被賦予過多權限的 agent，可能因為一次錯誤的呼叫就動到 production。

Cloudflare 在 2026 年 9 月 15 日推出 Workers 的資源層級授權，讓你能把權限縮到單一 Worker，並搭配四種新角色。這篇文章談的是它改變了什麼，以及你在設計自動化流程時該怎麼用。

四種角色，對應四種「夠用就好」

Cloudflare 把角色收斂成四種，對應不同的工作情境：

Metadata Read-Only：能看設定、metrics、logs、traces，但看不到 Worker 的原始碼。適合除錯。
Content Read-Only：能讀取程式碼做審查，但不能修改或部署。適合 code review agent。
Editor：能部署新版本，但不能刪除 Worker。適合 CI/CD 流程。
Admin：最高權限，包含刪除。

這四種角色可以套用在三個層級：整個 Developer Platform、單一產品（例如所有 Workers），或單一資源（例如某一個 Worker）。角色決定「能做什麼」，層級決定「能對誰做」。

為什麼這對 agent 特別重要

Cloudflare 在公告中直接點出這個動機：你不會希望 agent 只因為被授予過多權限，就在 production 做出變更。

實際做法是替 agent 建立一個帶有 scoped access 的 API token，讓它只能存取某一個應用程式。如果 agent 被限制在單一 Worker，它透過 Cloudflare API 調查問題時，也只會拿到那個 Worker 的資料，看不到帳號裡其他 Worker 的內容。

這和我們之前在把互動介面塞進對話框之後談到的部署取捨是同一個問題：agent 能碰到的東西越多，你需要設計的邊界就越多。差別在於，這次的邊界不是寫在 prompt 裡，而是寫在授權層。

CI 部署與路由權限的分離

對 CI/CD 來說，最實用的組合是「Editor 角色 + 單一 Worker 範圍」。這樣即使流程設定錯誤或 token 外洩，影響也侷限在那個 Worker：它可以部署新版本，但不能刪除，也不能碰其他應用程式。

路由與 Custom Domain 是另一個需要留意的邊界。要新增、修改或移除路由，你需要同時具備該 Worker 的 Editor 權限，以及該 zone 的 Workers Routes 權限。Cloudflare 選擇要求 Workers Routes 權限而不是更廣泛的 zone 權限，讓你能管理流量怎麼進到 Worker，而不必交出整個網域的其他設定。

反過來說，一旦路由設定完成，只要部署不改變那個連線，你就能繼續部署新版本，不需要 zone 或相關資源的權限。這讓 CI 系統可以部署應用程式，而不必同時拿到你的網域、資料庫或儲存空間。

Durable Objects 與錯誤訊息的處理

Durable Objects 沒有自己的角色或權限，存取權取決於你對實作它的 Worker 的權限。Metadata Read-Only 能看 Durable Object 的 metrics、logs、traces，但看不到物件裡儲存的資料；因為 Data Studio 可以直接查詢和修改那些資料，所以需要 Editor 角色。

另一個實務上的改進是錯誤訊息。當權限不足時，API 不再只回傳通用的 403，而是附上相關 API 文件的連結，讓你和 agent 能查出需要哪些權限，而不是直接要求更大的權限。

現在可以怎麼開始

這些 Worker 層級的存取控制已經對所有客戶開放，可以透過 dashboard、API 或 Terraform 設定。如果同一個團隊或專案有多人需要相同權限，可以建立 User Group，把 policy 指派給群組，成員會自動繼承。

舊的角色與權限沒有設定淘汰日期，現有指派會繼續運作。Cloudflare 建議開始轉向新角色，因為只有新角色支援資源層級的授權。

下一步是把同樣的資源層級控制帶到更多 Developer Platform 產品，包括 KV namespace 和 D1 資料庫，並沿用同一組角色。對正在把 agent 接進部署流程的團隊來說，值得先盤點：目前有哪些 token 的權限範圍，其實比它實際需要的還大。

（本文依據 Cloudflare 官方公告整理，未經實測。）

參考來源

Give every teammate and agent the right level of access to your Workers

Scoping Cloudflare Workers Access So Agents Can't Touch Production

Wed, 16 Sep 2026 00:00:00 GMT

Scoping Cloudflare Workers Access So Agents Can't Touch Production

The problem with account-wide tokens

If you hand an agent an API token today, it usually carries the same reach as the account that issued it. That means a coding agent debugging one Worker can also read every other Worker’s source, and a CI workflow that only needs to deploy one app can delete another. Cloudflare’s new Worker-level access controls, published September 15, 2026, target exactly that gap: you can now scope a teammate or an agent to a single Worker instead of the whole account.

Four roles, three scopes

Cloudflare introduced four roles for Workers, each available today for all customers. Metadata Read-Only lets someone inspect settings, metrics, logs, and traces without seeing source code. Content Read-Only lets them read the code without deploying or changing settings. Editor allows deploys but not deletion. Admin is the highest level and can delete an application.

Each role can be applied at three scopes: the whole Developer Platform, a single product like Workers, or one specific resource. So a code review agent can hold Content Read-Only on one Worker and see nothing else in the account. Cloudflare says it plans to reuse these same roles as resource-level controls reach D1, R2, and KV.

What this changes for agent and CI tokens

The practical win is containment. A CI/CD workflow can get its own Editor token scoped to one Worker, so a misconfigured pipeline or a leaked token can deploy that app but cannot delete it or touch anything else. For agents, the same logic applies: an agent scoped to one Worker can query analytics and logs through the GraphQL API without pulling data from other Workers.

There is one wrinkle worth planning for. Routes and Custom Domains are not covered by Worker access alone. To add, change, or remove a route, you need Editor access to the Worker plus Workers Routes permission for the zone. Once a route is configured, though, you can keep deploying new versions without zone access, as long as the deployment does not change that connection. That separation matters if you want CI to ship code without also handing it your domain configuration.

Durable Objects inherit their access from the Worker that implements them. Metadata Read-Only covers their metrics, logs, and traces, but reading or modifying stored data through Data Studio requires Editor.

Errors that name the missing permission

Narrow scopes create a new failure mode: an agent hits a wall and cannot tell why. Cloudflare changed its API errors so that instead of a bare 403, the response links to documentation showing which permissions the request needs. That is a small change with outsized value for autonomous agents, which can otherwise retry blindly or ask for broader access than necessary.

If you are already thinking about how much system access to hand an agent, this connects to a broader question we covered in what it takes to hand an agent the whole system: the more surface area you grant, the more you need a way to bound the blast radius.

Migration and what to watch

The legacy Workers roles still work, and Cloudflare says there is no deprecation date yet, with advance notice promised before any change. The recommendation is to start moving to the new roles because they are the ones that support resource-level scoping.

For teams with several people on the same project, User Groups let you assign a policy once and add members to inherit it, rather than configuring each person individually. Setup is available in the dashboard, the API, or Terraform.

The supplied material does not specify how these roles interact with existing account-level policies in edge cases, so if you have layered permissions today, test the combination before rolling it out broadly. A reasonable first step is to pick one CI workflow or one agent and give it a scoped token, then watch what breaks.

Sources

Give every teammate and agent the right level of access to your Workers

公司融資資料 API 怎麼挑：獨立基準測試揭露的取捨

Wed, 16 Sep 2026 00:00:00 GMT

公司融資資料 API 怎麼挑：獨立基準測試揭露的取捨

如果你要為 GTM 團隊、VC 或 RevOps 挑一個公司融資資料 API，最直接的問題是：給它一個公司網域，它能不能正確說出最近一輪融資的階段？過去這個問題沒有標準答案，因為每個供應商都宣稱自己覆蓋率最好。2026 年 8 月，獨立組織 Openbenchmarks 做了一個公開、可重現的基準測試，把 17 家供應商放在同一個公司網域集合上，用同一套標準評分。結果顯示，Firecrawl 的 agent 在兩個關鍵指標上都領先，但其他供應商在速度與成本上各有優勢。

基準測試怎麼設計

Openbenchmarks 的融資資料看板把供應商分成三類：長時執行的 agent API、網頁搜尋 API、以及 GTM 資料庫。每個供應商都拿到相同的公司網域，透過各自的正式端點查詢，回傳的融資階段會跟人工審核過的真實資料比對。看板分成兩個指標：

新鮮度：過去 30 天內宣布的融資輪次，測試供應商多快能索引到新消息。
歷史補全：超過 30 天的舊融資輪次，測試供應商回溯歷史資料的完整度。

這兩個指標獎勵相反的設計。一個索引很快的供應商可能歷史資料很薄，一個歷史資料庫很深的供應商可能對上週的新聞反應很慢。所以把它們平均成一個排名會誤導人，Openbenchmarks 選擇分開排名。

誰在什麼任務上贏

在新鮮度看板上，Firecrawl 的 agent 拿到 100% 正確率，是所有供應商中最高的。Exa 的即時搜尋模式拿到 98.0%，Exa 的 agent 拿到 97.0%，Parallel 的 Task API 拿到 95.0%。Crunchbase 的資料庫匯出也拿到 95.1%，跟這些即時供應商差不多。但 GTM 資料庫供應商在新鮮度上明顯落後：Apollo 只有 59.7%，People Data Labs 只有 13.3%，CompanyEnrich 只有 12.7%。原因很直接：一個九天前宣布的融資輪次，資料庫還沒收錄，但讀取即時網頁的 agent 已經找得到。

在歷史補全看板上，Firecrawl 以 92.3% 領先，Parallel 拿到 90.0%，Exa 的 deep 和 agent 模式接近 88.6%，Crunchbase 拿到 85.8%。最強的 GTM 資料庫供應商 Fiber 拿到 84.9%，但其他資料庫供應商表現不佳：Ocean.io 只有 5.5%，Explorium 只有 21.9%。

成本和速度則完全相反。準確率領先的 agent 最慢也最貴，每家公司要跑一分鐘以上。網頁搜尋 API 幾秒鐘、幾美分就回傳，GTM 資料庫查詢只要幾百毫秒。所以如果你的任務是查已知公司的歷史融資，不在乎最新一輪，資料庫查詢又便宜又快。

Firecrawl 為什麼兩邊都贏

Firecrawl 是唯一在兩個看板都拿第一的供應商。它的 agent 用 spark-2 模型在新鮮度上拿到 100%，用 spark-1-mini 模型在歷史補全上拿到 92.3%。結構上的原因是：融資消息通常出現在公司新聞室、新聞稿、監管文件這些非結構化網頁內容上，而 Firecrawl 本來就是設計來讀這些內容的。它不需要預先收錄任何東西，所以能抓到上週才宣布、資料庫還沒收錄的融資輪次。

Firecrawl 的 agent 端點是深度優先的選擇，適合高價值查詢和監控工作流程。如果你需要大量查詢，Firecrawl 的 search 端點是快速路徑，但基準測試沒有測量它。search 用單一呼叫查詢即時網頁，比 agent 更快更便宜，同時保留即時網頁的新鮮度優勢。

對產品團隊的實際意義

這個基準測試最重要的啟示是：不要只看一個準確率數字就做決定。先定義你的任務，再選供應商。如果你要監控新融資輪次、做即時交易搜尋，agent 或網頁搜尋 API 是對的選擇。如果你要補全 CRM 裡大量已知公司的歷史融資資料，GTM 資料庫的便宜和快速可能更划算。

如果你正在為 agent 挑選網頁搜尋 API，可以參考為代理挑選網頁搜尋 API：先定義任務，再比較六種工具，裡面的框架同樣適用於融資資料 API 的選擇。

基準測試的數字都是公開可查的，包括 Firecrawl 輸掉的地方。Openbenchmarks 的看板會持續更新，所以如果你在評估供應商，最好自己跑一遍，而不是只看這篇文章的結論。

參考來源

The Best Company Funding Data API in 2026: What an Independent Benchmark Found

Funding Data APIs: Pick by Job, Not by Leaderboard Rank

Wed, 16 Sep 2026 00:00:00 GMT

Funding Data APIs: Pick by Job, Not by Leaderboard Rank

A funding round is a moving target. It appears on a company newsroom, gets picked up by press, lands in a regulatory filing, and only later reaches a structured database. Each hop adds lag, so a provider that is flawless on rounds from two years ago can be flatly wrong about a round announced last Tuesday.

That is the problem the Openbenchmarks company funding board set out to measure. In August 2026, per Firecrawl’s write-up of the results, the independent board ran 17 providers over the same company domains and judged each returned stage against a reviewed ground truth.

Two boards, because one rank hides the tradeoff

The board splits its score in half. Freshness covers rounds announced in the trailing 30 days — how fast a provider indexes a new announcement. Enrichment covers older rounds — how completely a provider has backfilled history.

Those two reward opposite things. A provider that indexes fast can hold a thin historical record; a deep database can lag badly on last week’s news. Averaging them into one number would describe neither job, so they are ranked separately.

One caveat worth carrying into any vendor conversation: only the latest stage is judged for correctness. Round amount, total raised, and round count are counted for presence, not accuracy. A high “funding fields returned” figure means fields were filled in, not that the numbers inside them are right.

What the freshness board shows

On recent rounds, live-web providers lead. Firecrawl’s agent posted 100% latest-stage-correct (Spark 2), with Exa’s instant search at 98.0%, Exa’s agent at 97.0%, Firecrawl’s second model at 96.0%, and Parallel’s Task API at 95.0%. Crunchbase’s reviewed export matched them at 95.1%.

Stored-database GTM providers trail hard here: Apollo at 59.7%, People Data Labs at 13.3%, CompanyEnrich at 12.7%. That gap is ingestion lag, not incompetence. A database has not yet absorbed a round announced nine days ago; an agent reading the live web has.

Where the stored records earn their place

On historical rounds the field tightens but agents still lead. Firecrawl topped enrichment at 92.3%, Parallel at 90.0%, Exa’s deep and agent modes near 88.6%, Crunchbase at 85.8%. The strongest true-API GTM provider on that board was Fiber at 84.9%.

Cost and speed run the other way. The accuracy leaders are the slowest and priciest per call — Firecrawl’s agent runs around 102 seconds and an estimated $1.98 per company, with Exa’s agent near $10.00. Web search APIs return in seconds for cents; GTM database lookups in a few hundred milliseconds. Cost figures are modeled from observed billing units at published rates, not invoiced.

How to choose without a single winner

Pick by the job, not the ranking:

High-value lookups and monitoring, where being right beats shaving milliseconds: a long-running agent.
Volume screening where a round from last week rarely matters: a database read is cheap and fast.
Middle ground: web search APIs, whose accuracy tracks how well a round was covered on the open web.

If you are already wiring retrieval into an agent, the same reasoning applies as in choosing a web search API for agents: define the retrieval task first, then let the benchmark axes — freshness, enrichment, latency, cost — decide the vendor.

The limitation is that this board judges one field. If your product depends on round amounts or investor names being correct, the supplied results do not tell you which provider wins that job.

Sources

The Best Company Funding Data API in 2026: What an Independent Benchmark Found

當 AI 的成果要能被檢驗：Google 把社會影響案例整理成一個入口

Wed, 16 Sep 2026 00:00:00 GMT

當 AI 的成果要能被檢驗：Google 把社會影響案例整理成一個入口

一個入口，而不是一份新聞稿

2026 年 9 月 15 日，Google 在官方部落格發布了 AI for Societal Impact 這個頁面。從抓取到的內容來看，它的結構是一頁「Collection」——隸屬於 Innovation & AI 底下的 Technology / AI 分類，而不是一篇獨立的產品公告。頁面帶有分享按鈕、麵包屑導覽，以及一張標示為實驗室場景的主視覺。

這件事對產品團隊的意義不在於 Google 又做了什麼，而在於它把散落的案例收攏成一個可被引用的位置。當一個組織開始替某類工作建立固定入口，通常代表這類工作已經多到需要索引。

抓取內容揭露了什麼、沒揭露什麼

必須說清楚：這次取得的來源文字主要是頁面的導覽骨架——上層選單、分類連結、分享元件、圖片網址。它顯示這個頁面存在、屬於哪個分類、發布時間是 2026 年 9 月 15 日，但沒有列出這個 collection 底下具體收錄了哪些專案、涵蓋哪些地區、用什麼指標衡量影響。

所以任何關於「Google 在健康或教育領域做了哪幾件事」的推論，都不該從這份素材長出來。如果你需要那些細節，得直接讀原頁面。

對做產品的人來說，真正的問題是「影響力怎麼被記錄」

社會影響類的專案有個共同的難處：成果很難像轉換率那樣被即時看到。一個偏鄉的診斷輔助工具、一套母語教材的生成流程，價值往往在幾個月甚至幾年後才顯現，而且很難歸因。

這讓我想起另一篇談探索紀律的文章——把「探索」當成一種工程紀律。當成果無法用單一數字衡量時，團隊需要的不是更漂亮的儀表板，而是事先決定「我們要拿什麼當證據」。Google 把這類案例集中成一個可查找的入口，至少解決了「找不到前例」這一層問題。

如果你正在做類似性質的專案，可以從這個頁面反推兩件事：

他們選擇用什麼形式呈現一個案例（問題、做法、結果，還是只有故事）。
案例之間的顆粒度是否一致。顆粒度不一致的案例集，很難拿來做跨專案比較。

一個實務上的限制

Collection 型頁面容易變成行銷素材的堆疊。判斷標準很簡單：看它有沒有寫出失敗的部分、有沒有標註合作對象與時間範圍、有沒有說明資料來源。這份抓取內容無法回答這些問題，因為它只包含頁面框架。

對讀者來說，比較務實的做法是把它當成一份索引，而不是結論。看到有興趣的案例，再往下追原始研究或合作單位的說法。

帶走什麼

如果你的團隊也在累積這類難以量化的成果，值得先問一個問題：半年後有人想引用我們的工作時，他找得到嗎？把案例寫成可被檢索的形式，本身就是一種產品決策。至於 Google 這個 collection 實際收了什麼，得回到原頁面確認——這份素材只給了入口，沒給內容。

參考來源

AI for Societal Impact

What a Collection Page Signals About Shipping Public-Interest AI

Wed, 16 Sep 2026 00:00:00 GMT

What a Collection Page Signals About Shipping Public-Interest AI

Google published a collection page on 2026-09-15 titled “AI for Societal Impact,” grouping its work under the Innovation & AI technology section. That is the whole of what the supplied page shows: a collection index, a breadcrumb trail, and a header image of two scientists in a laboratory wearing protective gear.

If you build anything where the buyer is a hospital, a school district, or a public agency, the interesting signal here is not a feature. It is the packaging.

A collection is a different artifact than an announcement

A product launch answers “what shipped and when.” A collection page answers “what does this organization want to be known for.” Those are different documents with different audiences, and Google chose the second one for this topic.

The supplied page does not name individual projects, partners, funding, or metrics. The supplied page does not specify which products or research efforts sit inside the collection. Missing detail in a page like this is not evidence that nothing exists behind it — it just means the index itself carries no claims you can build against.

So treat it as a positioning artifact. Useful for reading intent. Not useful as a spec.

Why this matters more for public-interest work than for consumer work

When you ship a consumer feature, the feedback loop is fast: usage, retention, churn. When you ship into a clinic, a court, or a municipal workflow, the loop is slow and the failure modes are expensive. Procurement teams there do not evaluate a single model call. They evaluate whether an organization looks like it will still be accountable in three years.

That is why a collection page is a real signal in this segment. It tells a public-sector buyer that the vendor is willing to be associated with the category, publicly, under its own brand. It is a weak signal, but it is not zero.

For builders, the practical read is about scoping. If your roadmap depends on a platform vendor treating public-interest AI as a first-class category, a collection page is a hint that the category has internal sponsorship. It is not a commitment to a specific API, price, or region.

The builder’s move: separate the story from the contract

When a vendor frames work this way, resist the temptation to fold the framing into your architecture decisions. Keep two documents.

One is the narrative: why this problem matters, who it serves, what “good” looks like. That document can cite a collection page, a mission statement, or a partner’s public writing.

The other is the contract: which model, which region, which retention policy, which SLA, which fallback when the primary provider degrades. That document should cite only things you can test.

This split is the same discipline that shows up when you decide how much of a system to hand to an agent — the narrative can be ambitious, but the execution boundary has to be explicit. I wrote about that tradeoff in what it takes to hand an agent the whole system, and the same logic applies to vendor positioning: enthusiasm at the top of the stack, hard constraints at the bottom.

What to actually do this week

If you are evaluating Google’s stack for a public-interest product, the collection page is a starting point for a conversation, not a substitute for one. Ask for the specifics the page omits: named deployments, data handling terms, and who owns the relationship when something goes wrong.

If you are building your own public-interest product, the lesson is cheaper to apply. Publish a page that says what you are trying to be known for. Then make sure every claim on it survives a procurement review. The gap between those two documents is where trust actually gets built — or lost.

Sources

AI for Societal Impact

當瀏覽器內建 AI：Mistral 與 Mozilla 把主權與隱私放進 Firefox Smart Window

Wed, 16 Sep 2026 00:00:00 GMT

當瀏覽器內建 AI：Mistral 與 Mozilla 把主權與隱私放進 Firefox Smart Window

瀏覽器一直是使用者與網路之間的中介層，現在這個中介層開始內建模型。2026 年 9 月 16 日，Mistral 與 Mozilla 宣布合作，Firefox 的 AI 瀏覽助理 Smart Window（beta）改由 Mistral 模型驅動，先在法國與北美推出，英國與德國預計今年稍後跟進。

這則消息對產品團隊的意義，不在於又多了一個 AI 功能，而在於「誰的模型、在哪裡跑、資料留多久」這三件事被寫進了合作條件。

合作內容與適用範圍

根據 Mistral 的公告，Smart Window 的用途包括：理解複雜搜尋、記住使用者點開又離開的重要內容，以及依據瀏覽器分頁整理資訊來源。Mistral 負責法國與北美的使用者，英國與德國預計今年內納入。

公告把這次合作定位為兩個開源倡議者的結盟，並列出四項理由：開源技術需要開源通路、模型針對地區語言與文化微調、使用者對 AI 互動保有控制權，以及把主權 AI 帶給一般消費者。

隱私條款是這次最值得細看的部分

公告明確寫出兩點：對話預設不會存在 Mozilla 的伺服器上，而像 Mistral 這樣的合作夥伴同意零資料保留（zero data retention）。

對正在評估 AI 功能的產品團隊來說，這是可以拿來對照自己架構的具體條件。多數團隊把模型接進產品時，預設會留下對話紀錄以便除錯與改善；這裡選擇的是相反方向，代價是少了訓練與分析的素材，換來的是使用者信任與合規上的空間。

Mozilla 執行長 Anthony Enzor-DeMeo 在公告中的說法是，瀏覽器不該是單向漏斗，應該讓不同 AI 供應商競爭、讓開源有一席之地。這段話點出的是通路問題：模型再好，沒有預設入口就難以觸及一般使用者。

多語言微調與主權 AI 的實際含義

公告提到 Mistral 針對區域語言、方言與文化脈絡進行微調，讓回應能理解在地語感。這裡的關鍵字是「微調」而不是「翻譯」——前者假設模型本身要吸收語言與文化差異，後者只是把既有輸出換一層語言。

Mistral 也說，過去主要服務企業客戶，透過與 Firefox 這類生態系夥伴合作，才延伸到一般消費者。對開發者而言，這代表同一批模型開始出現在兩種截然不同的使用情境：企業內部流程，以及每天開幾十次分頁的個人瀏覽。

如果你的產品需要處理多語內容，這類「在地微調」的做法值得留意，但公告沒有說明微調的資料來源、涵蓋語言數量或評估方式，這些細節在目前提供的內容中並未交代。

對產品團隊的三個實務提醒

第一，入口決定預設值。當瀏覽器直接內建助理，使用者不需要另外訂閱或安裝，採用門檻就從「註冊一個服務」降到「打開分頁」。這和過去把 AI 功能做成獨立 App 的路徑完全不同。

第二，資料保留政策會變成採購條件。零資料保留聽起來像法務條款，實際上會影響你能做什麼：沒有留存就沒有事後分析，也沒有從真實使用中持續改善的迴路。團隊在談類似合作時，最好先確認自己能不能接受這個限制。

第三，模型選擇正在從技術決策變成通路決策。當開源模型透過瀏覽器觸及消費者，評估重點就不只是 benchmark 分數，還包括它能不能進入使用者原本就在用的介面。

這類「把模型放進既有工作流」的取捨，和我們先前談過的 OpenRouter Presets：把模型參數移出程式碼是同一個問題的不同切面——前者決定模型從哪裡進來，後者決定參數怎麼被管理。

目前還不確定的地方

公告沒有說明 Smart Window 的定價、是否會擴展到其他地區，也沒有交代使用者在 Firefox 之外能否取得同樣的模型能力。英國與德國只寫「預計今年稍後」，沒有具體日期。

對想跟進的團隊，實際可做的下一步是：先確認自己產品的資料保留政策是否與這類合作相容，再評估多語言微調對你目標市場的實際效益。至於 Firefox Smart Window 本身的表現，目前只有官方公告的說明，還沒有獨立評測可以參考。

參考來源

Mistral x Mozilla: Private, Multilingual AI Browsing

Mistral Powers Firefox's Smart Window: What Zero Data Retention Changes for Browser AI

Wed, 16 Sep 2026 00:00:00 GMT

Mistral Powers Firefox's Smart Window: What Zero Data Retention Changes for Browser AI

Browser AI has a distribution problem. Assistants that read your tabs, remember what you clicked away from, and answer questions about your session are useful, but they also sit on top of the most personal data you own. On September 16, 2026, Mistral and Mozilla announced a partnership that puts Mistral models behind Firefox Smart Window (beta), Mozilla’s AI browsing assistant, for users in France and North America, with the United Kingdom and Germany expected later this year.

What Smart Window Actually Does

According to Mistral’s announcement, Smart Window helps users make sense of complex searches, recall something they clicked away from, and source information from their open browser tabs. That is a retrieval problem scoped to a session, not a general chat product. The interesting part for builders is the constraint set around it.

Mozilla and Mistral state that conversations are not saved on Mozilla’s servers by default, and that partners including Mistral agree to zero data retention. If you are routing user context through a model provider, that commitment is the product decision, not a footnote. The mechanics of enforcing provider-side retention limits are worth studying separately; our earlier post on zero data retention and API routing covers where those controls actually live.

Local Languages as a Distribution Strategy

Mistral frames the partnership around models fine-tuned on regional languages, dialects, and cultural context, so responses reflect local nuance rather than an exported default. The supplied announcement does not specify which languages or dialects are covered, or how the fine-tuning was evaluated. Treat the multilingual claim as a stated direction, not a benchmark result.

The rollout geography is more concrete: France and North America first, UK and Germany later in 2026. That sequencing suggests the language work is tied to specific markets rather than a single global model swap.

Why the Browser Is the Battleground

Mozilla CEO Anthony Enzor-DeMeo is quoted saying a browser should not be a one-way funnel, and that it should be a place where different AI providers compete. Mistral CEO Arthur Mensch frames the deal as bringing privacy, control, and choice to AI-powered browsing.

Read that as a distribution argument. Mozilla has spent two decades building an open web position; Mistral has shipped open-weight models. Neither owns the consumer surface alone, so the browser becomes the place where an open model stack meets mainstream users. For teams building browser-adjacent agents, the practical question is whether your assistant can be swapped at the provider layer without rewriting the product. That is the same portability concern behind config-as-code for LLM calls, where routing decisions live outside application code.

What to Watch Before You Build On It

Three things are still open in the supplied material. First, the announcement does not describe an API or SDK for third-party developers, so Smart Window is not yet a platform you can extend. Second, it does not specify latency, context limits, or which Mistral model versions are in use. Third, the zero data retention commitment is described at the partnership level; the announcement does not detail audit or verification.

If you are evaluating browser-based AI for your own product, the transferable lesson is the shape of the deal: a privacy-first host, an open-weight model provider, and retention terms written into the agreement rather than left to defaults. Start by writing down what your assistant is allowed to remember, and who can prove it.

Sources

Mistral x Mozilla: Private, Multilingual AI Browsing

讓長輩用 AI 查帳單、辨詐騙：OpenAI 與 OATS 的十場實體課透露了什麼

Wed, 16 Sep 2026 00:00:00 GMT

讓長輩用 AI 查帳單、辨詐騙：OpenAI 與 OATS 的十場實體課透露了什麼

對多數產品團隊來說，「使用者會不會用」通常不是上線前的阻礙，而是上線後才浮現的雜訊。OpenAI 在 2026 年 9 月 16 日公布的做法，把這個問題往前拉了一步：他們與 AARP 旗下的 Older Adults Technology Services（OATS）合作，舉辦 Older Adults AI Skills Jam，一場免費的實體學習活動，目標是讓長者能安全、有信心地使用 ChatGPT。

他們教的不是功能，是日常判斷

根據 OpenAI 的公告，課程涵蓋的場景包括規劃旅行、看懂一封令人困惑的信或帳單、辨識可能的詐騙、發展新興趣，以及與家人保持聯繫。這些都不是「AI 能做什麼」的展示，而是「我生活裡哪一件事卡住了」的清單。

活動屬於 OpenAI 與 OATS 一項多年計畫的一部分，透過 OATS 的 Senior Planet 計畫推動。這次的 Jam 會在美國十個社區舉行，合作單位包括 Denver、Miami、San Antonio、Montgomery County、Queens 的 Senior Planet，以及 St. Louis 的 Mirowitz Center、Twin Cities 的 Senior Community Services、Nashville 公共圖書館與 FiftyForward、Fresno EOC、Boise 的 LEARN Idaho。

安全不是附錄，是課程主體

公告明確把防詐放進工作坊內容：帶長者辨識常見警訊，包括催促性的語氣、要求保密、可疑連結，並給出一條簡單規則——暫停、想一想、再發問。同時也教他們把 ChatGPT 當成多一層的檢查與預防工具。

這裡有一個值得注意的數字：OpenAI 表示，每週有數以千萬計的人次請 ChatGPT 協助判斷可疑的訊息、電子郵件與網站。換句話說，「幫我看看這是不是詐騙」已經是一個規模化的真實使用情境，而不是示範用的假設題。

需求成長的訊號

公告引用的資料顯示，在美國，與 55 歲以上族群相關的訊息占比在一年內從 6% 成長到接近 10%。這個變化對做產品的人有兩層意義。第一，長者不是「未來的使用者」，他們已經在用了。第二，他們的使用動機偏向實用指引、找資訊與寫作，而不是探索模型能力。

如果你的產品把 AI 功能藏在多層選單、預設使用者熟悉 prompt 技巧，這群人會直接卡住。反過來說，把入口設計成「你現在遇到什麼麻煩」而不是「你想問什麼」，可能更接近他們的心智模型。

實體課的價值，在於暴露產品的破口

公告最後提到，參與者的問題、想法與經驗會用來形塑未來給長者的學習資源。這句話對產品團隊是個提醒：實體教學現場其實是最便宜的使用者研究。哪些步驟需要人解釋、哪些用詞被誤解、哪些安全提示被忽略，在教室裡會一次全部現形。

同樣的邏輯也出現在其他領域的導入經驗裡。像把銀行 API 上線流程拆成七個專責代理這類案例，談的也是把複雜流程拆成使用者能逐步完成的段落，而不是一次丟出全部能力。

可以帶走的一件事

這則公告沒有公布課程教材、完成率或後續成效數據，供給的 RSS 摘要也沒有說明各場次的報名狀況。能確認的是：OpenAI 選擇用實體、社區、在地組織的方式切入長者族群，並把防詐當成核心內容。

對正在做 AI 功能的團隊，實際可行的下一步不是照抄課程，而是檢查自己的 onboarding：第一次使用的長者，能不能在沒有旁人協助的情況下完成一件真實的小事？如果不行，問題通常不在模型，而在你怎麼問他問題。

參考來源

Helping older adults use AI in everyday life

Teaching AI to People Who Didn't Grow Up With It

Wed, 16 Sep 2026 00:00:00 GMT

Teaching AI to People Who Didn't Grow Up With It

Most AI product decisions get made by people who find new interfaces obvious. That assumption breaks the moment your user is 72 and has never been asked to phrase a request as a prompt.

On September 16, 2026, OpenAI Academy and Older Adults Technology Services (OATS) from AARP ran the Older Adults AI Skills Jam — a free, in-person workshop teaching older adults to use ChatGPT with more confidence and safety, according to OpenAI’s announcement. It’s part of a multi-year effort delivered through OATS’s Senior Planet program.

What the workshop actually covers

The framing is refreshingly concrete. The announcement lists trip planning, understanding a confusing letter or bill, checking whether something is a scam, picking up a new hobby, and staying in touch with family.

Safety gets its own block. Participants work through common warning signs — urgent language, secrecy, suspicious links — and a rule the announcement states plainly: pause, think, and ask. ChatGPT is positioned as an extra layer of scrutiny rather than a replacement for judgment.

That distinction matters for anyone building consumer AI. “Ask the model if this is a scam” is a very different product promise than “the model will protect you.” The first one keeps the user in the loop; the second one sets an expectation no model reliably meets.

The usage numbers behind the curriculum

OpenAI’s own data, cited in the same post, shows the share of US messages associated with people 55 and older grew from 6% to nearly 10% over a year. The announcement also says people ask ChatGPT for help evaluating suspicious messages, emails, and websites tens of millions of times a week.

Those two figures together explain why this program exists. Older adults are already using the tool for exactly the tasks the workshop teaches — the gap isn’t adoption, it’s fluency and risk awareness.

Ten locations, local partners

The Jam runs in 10 communities, each paired with a local organization: Senior Planet sites in Denver, Miami, San Antonio, Montgomery County, and Queens, plus the Mirowitz Center in St. Louis, Senior Community Services in the Twin Cities, Nashville Public Library with FiftyForward, Fresno EOC, and LEARN Idaho in Boise.

OpenAI Academy has run similar events for nonprofits, small businesses, and K–12 educators. The older-adult track is the newest, and the announcement says participants’ questions and experiences will feed back into future learning resources.

What this changes if you ship to older users

Three things stand out for builders.

First, onboarding is a product surface, not documentation. A workshop that teaches “pause, think, and ask” is doing work your empty state could also do. If your assistant’s first screen assumes the user knows what a good prompt looks like, you’ve outsourced that lesson to a library in Boise.

Second, scam-checking is a real use case with a real failure mode. When a user pastes a suspicious email, the answer needs to be legible and hedged appropriately — not a confident verdict. The trust patterns here resemble what we wrote about in Fyxer’s draft acceptance research: assistants earn trust by being right at the moments users can verify, not by sounding certain everywhere.

Third, in-person beats self-serve for this audience. Ten physical locations with trusted local partners is a distribution strategy, not a marketing stunt. If your product’s growth model assumes users will figure it out alone, that assumption is worth testing against a cohort that didn’t grow up with chat interfaces.

The supplied announcement doesn’t specify attendance numbers, curriculum length, or how outcomes will be measured. Those details would tell us more about whether this format works — and whether it’s worth copying.

Sources

Helping older adults use AI in everyday life

把 30 秒長鏡頭寫進 API：Seedance 2.5 的規格取捨與計費邏輯

Wed, 16 Sep 2026 00:00:00 GMT

把 30 秒長鏡頭寫進 API：Seedance 2.5 的規格取捨與計費邏輯

多數影片模型在 15 到 20 秒就收手，剩下的長度得靠剪接補。OpenRouter 在 2026 年 9 月 9 日發布的 Seedance 2.5 評測指出，ByteDance 這顆模型把單次生成拉到 30 秒，是目前該平台上最長的規格之一，只有 Wan 3.0 系列同級。

但這篇評測同時點出一件容易被忽略的事：新版並不代表規格全面往上。

長度換來的是連續性，不是畫質

Seedance 2.5 的規格是 4 到 30 秒、480p 或 720p、六種長寬比，支援首尾幀控制，音訊在同一次生成中產出。相較之下，Seedance 2.0 只到 15 秒，但能輸出 1080p 到 4K。

也就是說，如果你要交付的是 4K 素材，2.5 反而不適用，得回到同家族的 2.0，或轉向 Veo 3.1。OpenRouter 建議在動手之前先對照自己的交付格式，因為這是新版本比舊版本更窄的一項規格。

30 秒的價值在於不用拼接。需要一支完整場景或單一連續鏡頭時，少一次剪接就少一次連續性斷裂的風險。

計費單位是 token，不是秒

模型頁在 2026 年 9 月 3 日列出的價格是每秒 0.1028 美元起，這是 480p 換算出來的結果。實際計費按影片 token 計算，公式是（寬 × 高 × fps × 時長）除以 1024，24 fps 下每 token 0.0000107 美元。

因為 token 數同時隨輸出像素與時長變動，720p 的每秒成本會是 480p 的兩倍多，約 0.231 美元。這個換算關係對預算規劃的意義很直接：先確認最終交付解析度，再決定要不要用 480p 打草稿。

帶影片參考的請求，單價低約四成

Seedance 2.5 的 input_references 接受圖片、影片與音訊素材。當請求帶有影片參考且沒有指定幀圖時，每 token 降到 0.0000064 美元，比基準價低約 40%。換算到 720p，每秒從 0.231 美元降到 0.138 美元。

這代表最便宜的 30 秒 720p 取得方式，是延伸既有素材，而不是從零生成。要編輯或續接手上已有的片段時，這個請求形狀同時省錢又省去重新生成的麻煩。

音訊則不另計費。generate_audio 預設開啟，開與關的 token 單價相同，所以靜音輸出並不會省下任何成本。這點和 Veo 3.1、Seedance 1.5 Pro 不同，後兩者對無聲輸出都收得比較少。

從程式碼呼叫的形狀

影片生成不走 /chat/completions，而是非同步端點。流程是送出工作到 POST /api/v1/videos，拿到回應中的 polling_url 後輪詢，直到狀態變成 completed，再用 API key 下載結果。OpenRouter 提到生成通常需要 30 秒到數分鐘，30 秒輪詢一次是合理的預設值。

curl -X POST "https://openrouter.ai/api/v1/videos" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bytedance/seedance-2.5",
    "prompt": "A chef plates a bowl of ramen in a narrow shop at night.",
    "duration": 12,
    "resolution": "720p",
    "aspect_ratio": "16:9"
  }'

這類非同步、以工作為單位的呼叫方式，和把模型參數從程式碼抽出來管理的思路是同一條線。如果你正在整理多個模型的呼叫設定，用 OpenRouter Presets 管理 LLM 設定那篇談的組態即程式碼做法，可以一併參考。

什麼時候該換一顆模型

OpenRouter 列出的幾個轉向條件值得記下來：需要 1080p 或 4K、需要在相同片長下追求最低每秒單價、或需要逐幀完全可重現的輸出。

另外，frame_images 與 input_references 是互斥的模式而非疊加。若請求同時帶了兩者，幀圖優先，工作會被當成 image-to-video 處理，參考素材不會產生可見效果，而且按基準價計費。這是實作時容易誤觸、又直接影響帳單的一個細節。

至於模型頁提到的每次請求最多 50 個參考素材，OpenRouter 明確標示這是模型頁數字，而非自家端點公布的限制，所以當成回報值看待比較妥當。

Seedance 2.5 的定位其實很窄：長鏡頭，以及從既有素材出發的編輯與延伸。如果你的需求是短秒數、高解析度或嚴格可重現，這顆模型不是答案。先確認交付格式，再決定要不要為 30 秒的連續性付這個價。

參考來源

Seedance 2.5 Review: What It

Seedance 2.5: Long Takes, Reference Inputs, and the Per-Second Bill

Wed, 16 Sep 2026 00:00:00 GMT

Seedance 2.5: Long Takes, Reference Inputs, and the Per-Second Bill

Most video models force a choice: short clips you stitch together, or high resolution you pay for. Seedance 2.5, live on OpenRouter’s video API since August 7, 2026, picks a third option — longer single takes and cheaper work that starts from footage you already have. The tradeoff is that it stops at 720p.

The spec sheet, and where it narrows

According to OpenRouter’s review of Seedance 2.5, the model runs clips of 4 to 30 seconds at 480p or 720p, across six aspect ratios, with first and last frame control and audio generated in the same pass. The slug is bytedance/seedance-2.5.

The catch is resolution. Seedance 2.0 in the same family goes to 4K but caps at 15 seconds. So the newer model is narrower on one axis than the older one. If your delivery format needs 1080p or 4K, this isn’t the slug — check that before you build around it.

What the per-second number actually means

OpenRouter lists Seedance 2.5 from $0.1028 per second of generated video as of September 3, 2026, which is what 480p works out to. That figure is derived, not fixed: billing is per video token, and token count scales with output pixels as well as duration. A second of 720p costs a little over twice a second of 480p from the same model — roughly $0.231.

The formula OpenRouter publishes is (width x height x fps x duration) / 1024 video tokens at 24 fps, billed at $0.0000107 per token. That matters for budgeting because a 30-second 720p clip is not a linear multiple of a 5-second one in the way a flat per-second rate would suggest.

There’s a second rate worth knowing. A request carrying a video reference bills at $0.0000064 per token, about 40% below base. At 720p that’s $0.138 per second instead of $0.231. Extending existing footage is cheaper per second than generating cold.

Audio is included either way. OpenRouter prices video tokens identically whether generate_audio is on or off, so muting a generation saves nothing — unlike Veo 3.1, which charges $0.40 per second with audio against $0.20 without, and Seedance 1.5 Pro, which halves its rate for silent output.

Where the request shape gets interesting

input_references accepts image, video, and audio assets on Seedance generation 2 and newer. Image references carry a face, product, or style; a video reference gives the model footage to edit or extend; an audio reference gives it a track to work against. OpenRouter’s model page lists up to 50 reference assets per request, though the review notes that’s a model page figure rather than a limit the endpoint publishes.

Frame images and reference assets select different modes rather than combining. If both are sent, frame images take priority and the job is treated as image-to-video — the references have no visible effect and the request bills at the base rate. That’s an easy way to pay more than you intended.

frame_images accepts first_frame and last_frame, so you can pin both ends of a shot and let the model fill the motion between. Wan 3.0, the other 30-second model, lists first frame only.

Calling it is not a chat completion

Video generation runs on a dedicated asynchronous endpoint, not /chat/completions. You submit a job to POST /api/v1/videos, poll the returned polling_url until status reads completed, then download the result with your API key. Generation usually takes 30 seconds to a few minutes, and a 30-second polling interval is a reasonable default. Video models also don’t appear in the plain models list — use /api/v1/videos/models or the video model collection.

curl -X POST "https://openrouter.ai/api/v1/videos" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bytedance/seedance-2.5",
    "prompt": "A chef plates a bowl of ramen in a narrow shop at night.",
    "duration": 12,
    "resolution": "720p",
    "aspect_ratio": "16:9"
  }'

A 202 response carries { id, polling_url, status }. A status of failed, cancelled, or expired is terminal, with the reason in .error.

The practical routing decision

OpenRouter’s own guidance is to use a different model when you need 1080p or 4K, when you want the lowest price per second at the same clip length, or when you need frame-exact reproducibility. Seedance 2.0 Fast and Mini are the cheaper draft slugs at $0.0000042 and $0.0000035 per token.

The pattern that falls out: draft at 480p, finish at 720p, and prefer extension over cold generation when you already have footage. The two resolutions differ by more than a factor of two in price but not in how the prompt is written.

If you’re weighing whether a per-token video bill belongs in your pipeline at all, the same arithmetic question shows up in OpenRouter Presets and config-as-code for LLM calls — the cost model is only useful once the request shape is something you can version and review.

The limitation to hold onto: OpenRouter reports the 50-reference ceiling as a model page figure rather than a measured endpoint limit, and determinism isn’t guaranteed even when a seed is accepted. Treat both as reported, not verified.

Sources

Seedance 2.5 Review: What It

用 Amazon Bedrock prompt caching 把重複的 context 成本壓低 90%

Tue, 15 Sep 2026 00:00:00 GMT

用 Amazon Bedrock prompt caching 把重複的 context 成本壓低 90%

問題：重複的 context 正在吃掉你的預算

在 Amazon Bedrock 上，如果你把同一份 10,000 token 的合約文件傳給模型 50 次，每次搭配不同的使用者問題，你總共要為 500,000 個輸入 token 付全額費用——即使模型每次都重新處理幾乎相同的內容。AWS Machine Learning Blog 在 2026 年 9 月 15 日的文章中點出這個常見的浪費模式。

傳統的省錢方法各有取捨：縮短 prompt 可能降低 context 品質；縮小 context window 會限制模型推理完整資訊的能力；應用層的 response caching 只對完全相同的查詢有效，當同一份 context 配上不同問題時就幫不上忙。

解法：在基礎設施層快取 prompt 前綴

Amazon Bedrock 的 prompt caching 直接在基礎設施層處理這個問題。你在請求中放置一個 cachePoint 標記，Bedrock 會檢查標記之前的內容是否與現有快取條目相符。如果命中（cache hit），模型可以跳過重新處理這些 token，直接從快取狀態開始生成；如果未命中（cache miss），模型處理完整內容並將結果寫入快取，供未來請求使用。

這個機制帶來兩個直接好處：快取讀取的輸入 token 成本比標準輸入低 90%，而且 time-to-first-token（TTFT）會縮短，因為模型不用從頭處理整個前綴。

四個關鍵參數決定快取行為

實際使用時，有四個概念需要掌握：

快取範圍：快取條目限定在個別 AWS 帳戶和 AWS Region 內。
Token 門檻：每個 cache checkpoint 必須達到最低 token 數才會啟動。例如 Anthropic Claude Sonnet 4.5 和 Sonnet 4.6 要求每個 checkpoint 至少 1,024 token，Opus 模型則要求至少 4,096 token。
TTL：快取條目根據請求中指定的 TTL 過期。預設是 5 分鐘，部分模型支援最長 1 小時。
模型無關的語法：Converse API 的 cachePoint 語法在支援的模型系列中完全相同，包括 Anthropic Claude 和 Amazon Nova。

成本結構：寫入貴一點，讀取便宜很多

Prompt caching 在標準輸入和輸出 token 之外，新增了兩種 token 類別：

Token 類型	說明	與標準輸入相比的成本
`cacheWriteInputTokens`	寫入快取的 token（第一次請求）	高 25%
`cacheReadInputTokens`	從快取讀取的 token（後續請求）	低 90%
`cacheWriteInputTokens`（1 小時 TTL）	以 1 小時 TTL 寫入快取的 token	高 100%（2 倍）

對於重複 context 的工作負載，輸入 token 成本大約可省下 75%。舉例來說，如果你把一份 10,000 token 的文件配上 10 個不同問題，第一次請求會產生快取寫入成本，其餘九次請求每次都以低 90% 的成本從快取讀取，這樣對該文件 context 的輸入 token 成本淨省約 75%。前提是所有後續請求都在 TTL 時間窗內發生；如果請求在過期後才來，就會觸發新的快取寫入，降低淨省幅度。

實作模式：從基本到進階

AWS 的文章用 Converse API 示範了六種情境，從簡單到複雜：

訊息內容快取：快取長文件以進行多問題分析。
系統提示快取：跨對話快取 persona 定義和指令。
工具定義快取：為 agentic 工作流快取 tool schema。
混合 TTL 快取：為不同內容層級指定不同的快取生命週期。
租戶隔離：在多租戶應用中實作每個租戶的快取分離。
LangChain 整合：在 LangChain 框架中使用 prompt caching。

最基本的模式是把 cachePoint 放在靜態文件和動態問題之間：

content = [
    {"text": "<static document content>"},
    {"cachePoint": {"type": "default"}},   # 快取以上所有內容
    {"text": "<user question>"}             # 動態，每次請求不同
]

這個模式特別適合 RAG 應用、程式碼助理參考大型 codebase，或任何需要反覆查詢同一份參考資料的場景。

何時該用、何時該避開

Prompt caching 不是萬靈丹。如果你的請求每次都帶不同的 context，快取命中率會很低，你反而要為第一次寫入多付 25% 的成本。跨 Region 的 inference profile 也可能偶爾增加快取寫入頻率，因為請求會自動路由到不同 Region。

但如果你正在建構多輪對話、agent 工作流，或任何會重複使用同一份 system prompt、工具定義或知識庫文件的產品，這個功能值得認真評估。它讓你在不犧牲 prompt 品質或 context 完整性的前提下，直接降低基礎設施成本。

在設計這類快取策略時，可以參考我們先前討論過的流程編排執行模型——先想清楚哪些內容是靜態的、哪些是動態的，才能把 cachePoint 放在對的位置。

參考來源

Optimizing cost and latency with Amazon Bedrock prompt caching

Prompt Caching on Bedrock: Where the 90% Input Savings Actually Come From

Tue, 15 Sep 2026 00:00:00 GMT

Prompt Caching on Bedrock: Where the 90% Input Savings Actually Come From

Most cost-optimization advice for LLM apps focuses on trimming tokens or shrinking context. But if you’re sending the same system prompt, document, or tool schema with every request, you’re paying full input price for content the model has already processed. Amazon Bedrock’s prompt caching attacks that specific waste: cache the static prefix, and subsequent requests read from cache at up to 90% lower input cost, with a faster time-to-first-token (TTFT).

The mechanics: cache points and TTLs

Prompt caching in Bedrock works through a cachePoint marker in the Converse API. Everything before that marker gets snapshotted after the first request. On a cache hit, the model skips reprocessing those tokens and starts generation from the cached state. On a miss, it processes the full content and writes to cache.

Four constraints shape how you use it:

Scope: Cache entries are per AWS account and Region.
Token thresholds: Each checkpoint needs a minimum token count to activate. Claude Sonnet 4.5 and 4.6 require at least 1,024 tokens; Opus models need 4,096.
TTL: Entries expire based on the TTL you set. Default is 5 minutes; select models support up to 1 hour.
Syntax: The cachePoint syntax is identical across supported model families, including Anthropic Claude and Amazon Nova.

Pricing splits into three token categories: cacheWriteInputTokens cost 25% more than standard input (or 2x for 1-hour TTL), while cacheReadInputTokens cost 90% less. For a 10,000-token document queried with 10 different questions, the first request pays the write premium, and the next nine read at the discount—netting roughly 75% savings on input tokens, assuming all hits fall within the TTL window.

Where the savings actually show up

The AWS Machine Learning Blog walks through six scenarios, from basic to advanced. The first three cover the most common patterns:

Message content caching: Put a cachePoint between a static document and the dynamic user question. This is the RAG pattern—same reference content, many queries.
System prompt caching: Cache persona definitions and instructions across conversations. If your assistant’s system prompt is stable, this is free money.
Tool definition caching: Cache tool schemas for agentic workflows. Tool definitions rarely change between turns, so they’re a natural cache target.

More advanced scenarios include mixed TTL caching (assigning different lifetimes to different content tiers), tenant isolation for multi-tenant apps, and LangChain integration.

The implementation is straightforward. In Python with boto3, you structure content blocks like this:

content = [
    {"text": "<static document content>"},
    {"cachePoint": {"type": "default"}},
    {"text": "<user question>"}
]

The cache point sits between the stable prefix and the changing suffix. Everything above it gets cached; everything below it is processed normally each time.

The tradeoff you’re signing up for

Prompt caching isn’t free. The cache write costs 25% more than a standard input token, so you need repeated hits within the TTL to come out ahead. If your traffic pattern is one-shot queries with no shared prefix, caching will cost you more, not less.

TTL is the other lever. The default 5-minute window works for rapid-fire question sequences on the same document. The 1-hour option doubles the write cost but extends the hit window—useful for slower, session-based interactions. The AWS post notes that cross-Region inference profiles can occasionally increase cache write frequency, since requests may route to different Regions where the cache entry doesn’t exist.

This is the same infrastructure-level thinking behind model caching on HyperPod: move repeated computation to a cache layer, and the per-request cost drops. But prompt caching operates at the token level, not the model-weight level, so the integration point is your prompt structure, not your serving stack.

What to do next

Start by identifying the largest stable prefix in your requests. For most apps, that’s the system prompt or a long context document. Measure how often that prefix repeats within a 5-minute window. If the answer is “often,” add a cachePoint and watch the cacheReadInputTokens metric.

If your prefix is under the model’s minimum token threshold, caching won’t activate—you’ll pay the write premium with no read discount. The supplied AWS post uses Claude Sonnet 4.5 with a 1,024-token minimum, so a short system prompt won’t qualify. In that case, consider consolidating instructions or bundling tool definitions to cross the threshold.

Prompt caching is a structural optimization, not a prompt-engineering trick. It rewards you for knowing exactly which part of your request is static and which part changes. Get that split right, and the cost curve bends in your favor without touching model quality.

Sources

Optimizing cost and latency with Amazon Bedrock prompt caching

當 AI 走進國防與公部門：Anthropic 顧問團對產品團隊的三個現實提醒

Tue, 15 Sep 2026 00:00:00 GMT

當 AI 走進國防與公部門：Anthropic 顧問團對產品團隊的三個現實提醒

顧問團解決的是「誰來定義可接受的用途」

2025 年 8 月 27 日，Anthropic 宣布成立 National Security and Public Sector Advisory Council，成員包含前參議員，以及來自美國國防部、情報體系、能源部、司法部的前任主管，還有兩黨國會領袖的前國安顧問（Anthropic 公告）。

對做產品的人來說，重點不是名單有多漂亮，而是這個組織要產出什麼。公告寫得很清楚：顧問團要協助辨識與開發高影響力應用，範圍涵蓋資安、情報分析到科學研究；同時協助深化公私部門合作，並推動業界標準，讓國安應用形成「race to the top」。

換句話說，這是一個把「什麼算負責任的國安 AI 用途」寫下來的機制。當標準由外部資深實務者參與定義，你的產品若想進入這條線，就得跟著這套語言走。

已經在跑的不是願景，是既有部署

公告同時列出 Anthropic 過去幾個月的動作，這些是已發生的事實，不是規劃：專為美國國安客戶打造的 Claude Gov 模型、與國防部 2 億美元的frontier AI 原型合作、把 Claude 部署給 Lawrence Livermore National Laboratory 的 1 萬名科學家、與 National Nuclear Security Administration 合作開發 AI 核安防護措施，以及讓 Claude 以 1 美元提供給美國政府三個部門使用。

另外，Anthropic 表示過去一年自願與能源部核子專家合作，評估模型是否可能洩漏核武相關敏感資訊，並與美國 Center for AI Standards and Innovation 及英國 AI Security Institute 測試模型的生物、網路與 AI 研發能力。

這些項目透露一個模式：高風險領域的 AI 採用，是先有評估與測試管道，才有規模化部署。

對 builder 的實際影響：把「可被檢驗」當成設計需求

如果你的產品會碰到公部門、國防供應鏈，或任何被歸類為關鍵基礎設施的客戶，這則公告的訊號是：採購方會問你怎麼證明模型行為可被檢驗。

實務上可以先做三件事。第一，把模型能力評估與紅隊測試的紀錄當成產品文件的一部分，而不是上線前的一次性活動。第二，把資料流向與保留策略講清楚——這正是我們在零資料保留當成路由條件那篇談過的思路：把合規要求寫成可強制執行的技術條件，而不是合約裡的一句承諾。第三，區分「通用模型」與「特定客戶專用模型」的界線，因為公告裡的 Claude Gov 就是走專用路線。

還沒說清楚的部分

公告提到會在未來幾個月公布更多顧問團成員，但沒有說明顧問團的會議頻率、建議是否具約束力，也沒有交代標準制定的具體時程。這些在公告中都沒有進一步細節。

對讀者來說，合理的下一步不是等名單補齊，而是先盤點自己手上的 AI 功能：哪些會被客戶歸類為高風險用途、目前有哪些測試證據可以拿出來。這份清單比任何顧問團名單都更早決定你能不能進場。

參考來源

National Security and Public Sector Advisory Council

Anthropic's New Advisory Council: What Government-Facing AI Builders Should Watch

Tue, 15 Sep 2026 00:00:00 GMT

Anthropic's New Advisory Council: What Government-Facing AI Builders Should Watch

The Problem: Public Sector AI Needs More Than a Model

Shipping AI into government work is not the same as shipping it into a startup. The buyer is not one team. The requirements come from procurement, legal, security, and sometimes Congress. Anthropic’s announcement of its National Security and Public Sector Advisory Council is a direct response to that gap. The company says the council will help it support the U.S. government and allied democracies in maintaining technological advantages, and will help identify high-impact applications in cybersecurity, intelligence analysis, and scientific research.

That is a governance move, not a product launch. For builders, the useful question is what changes when a frontier lab formalizes advice from people who have run defense, intelligence, and energy programs.

Who Is on the Council and Why It Matters

The inaugural members include former Senators Roy Blunt and Jon Tester, former CIA Deputy Director David S. Cohen, former Acting Secretary of Defense Patrick M. Shanahan, and former National Nuclear Security Administration leaders Lisa E. Gordon-Hagerty and Jill M. Hruby. The list also includes Richard Fontaine of the Center for a New American Security, who is a member of Anthropic’s Long-Term Benefit Trust.

That mix matters for one practical reason: these are people who understand how government programs fail. They know acquisition cycles, classification boundaries, and the difference between a demo and a deployment. If you are building for public sector buyers, their presence signals that Anthropic is trying to shorten the distance between model capability and program office reality.

What This Changes for Builders

Anthropic already lists several public sector moves: custom Claude Gov models for U.S. national security customers, a $200 million partnership with the Department of Defense, deployment to 10,000 scientists at Lawrence Livermore National Laboratory, work with the National Nuclear Security Administration on nuclear safeguards, and Claude available for $1 to all three branches of government.

The council adds a layer above those efforts. It is meant to help develop standards and deepen public-private partnerships. For a builder, that translates into a few concrete considerations:

Compliance is not a checkbox. If a council is shaping standards, expect procurement language to reference them. Build audit trails and data handling into the architecture early, not as a retrofit.
Domain specificity wins. The council’s focus areas are cybersecurity, intelligence analysis, and scientific research. General-purpose assistants will struggle in these contexts without domain-tuned evaluation and guardrails.
Trust is a deployment artifact. The same trust problem shows up in commercial tools. Our earlier post on what a 53% draft acceptance rate changes for trustworthy AI assistants is a useful parallel: acceptance rates and oversight mechanisms are how trust gets measured, not asserted.

The Tradeoff: Speed Versus Scrutiny

There is a real tension here. Government work moves slowly because the consequences of failure are high. AI moves quickly because the models change every few months. A council of former officials can help bridge that gap, but it can also add process. The announcement does not specify how the council’s recommendations will be translated into engineering requirements, or whether those recommendations will be public.

The supplied RSS summary does not specify the council’s meeting cadence, decision authority, or how its advice will be documented. That missing detail matters if you are trying to plan around it. What is clear is that Anthropic is treating public sector engagement as a long-term commitment, not a one-off contract.

What to Do Next

If you are building for government or regulated industries, treat this as a signal about where the ecosystem is heading. The council’s existence suggests that frontier labs will increasingly compete on trust, standards, and public sector relationships, not just model benchmarks. Review your own compliance posture and ask whether your product can survive a procurement review that references industry standards you did not help write. That is the practical takeaway: the bar for public sector AI is being set now, and the builders who treat governance as part of the product will have an easier time clearing it.

Sources

National Security and Public Sector Advisory Council

讓搜尋爬蟲進來、訓練爬蟲出去：Cloudflare 把混合用途爬蟲拆成三種行為

Tue, 15 Sep 2026 00:00:00 GMT

讓搜尋爬蟲進來、訓練爬蟲出去：Cloudflare 把混合用途爬蟲拆成三種行為

問題不在「要不要擋 AI」，而在同一個爬蟲做兩件事

網站經營者長期卡在一個二選一：讓內容被拿去訓練模型，或是冒著在搜尋結果裡消失的風險。Cloudflare 在 2026 年 9 月 15 日的公告裡把成因講得很清楚——Applebot、Bingbot、Googlebot 這類 mixed-use crawler 用同一個爬蟲同時服務搜尋與 AI 訓練，你拒絕其中一種用途，就等於拒絕另一種。

這個取捨不是理論問題。Cloudflare 公布的站點數據顯示，不到 1% 的站點選擇封鎖搜尋爬蟲，但有 17% 的站點啟用了某種阻擋訓練的機制。換句話說，站長普遍認為搜尋帶來的好處值得保留，訓練則否——只是過去的工具沒辦法把兩者分開。

Disallow AI Training 實際做了什麼

新的 Disallow AI Training 設定，讓站點在 robots.txt 發布不訓練的偏好，同時讓 Accountable 的混合用途爬蟲繼續為搜尋收錄內容。Cloudflare 表示 Apple、Google、Microsoft 都符合或承諾在指定時程內符合 Accountable 資格。

這裡的關鍵是 Cloudflare 把爬蟲行為拆成三類控制：Search（建立搜尋索引）、Training（訓練或微調模型）、Agent（使用者導向的代理，例如 chat fetch bot 與 browser-use agent）。三者在網域層級套用。Disallow AI Training 只適用於 Training，不適用 Search 或 Agent。

值得注意的是「Block」的語意變了。過去 Block 與「Block on pages with ads」不套用於混合用途爬蟲，因為那會連帶影響搜尋；現在這兩個設定會套用到所有訓練爬蟲，包含混合用途爬蟲。也就是說，如果你真的想讓 Applebot、Bingbot、Googlebot 完全進不來，現在必須明確選 Block，搜尋收錄也會一起停掉。

為什麼 robots.txt 單獨不夠，以及各家承諾的落差

Cloudflare 對 robots.txt 的批評很直接：任何人都能發布指令，但它無法辨識誰在爬、為什麼爬，也擋不住不理會它的爬蟲。網路層的作法是自己發布偏好、辨識爬蟲身分、分類爬蟲意圖，再封鎖不遵守的對象，並在 Radar 上公開各業者的實際行為。

各家的支援程度並不一致，這對要下決定的團隊很重要：

Applebot 透過 robots.txt 的 Applebot-Extended 規則退出訓練，但目前還沒有 URL 層級的檢視工具。
Googlebot 透過 Google-Extended 退出訓練，並在 webmaster portal 提供排除生成式搜尋結果的開關，以及搜尋與 AI 摘要的指標；Google 表示 URL 層級透明化工具預計在數週內推出。
Bingbot 目前靠 NOARCHIVE meta tag 表達訓練偏好，Microsoft 正在建置讓 robots.txt 的網域層級 no-training 偏好也能被遵循的機制，目標是 2027 年初。在那之前，選 Disallow AI Training 不會自動把偏好傳達給 Bing。

三家公司都表示，拒絕訓練不影響搜尋排名。這是承諾，不是你可以自行驗證的結果，但至少是可追蹤的公開說法。

對產品與工程團隊的實務意義

如果你在維護有廣告或訂閱收入的站點，這次更新把「被找到」和「被訓練」正式拆成兩個獨立決策。多數既有客戶不需要動作，設定會自動移轉；先前 Training 選了 Block 或 Block on pages with ads 的網域，會移轉成 Disallow AI Training。新網域在 onboarding 時會依是否靠廣告營利，拿到兩套預設值，之後隨時可改。

有兩件事現在還做不到。第一，Disallow AI Training 沒有「只針對有廣告的頁面」版本，因為廣告頁清單太大且變動太快，無法寫進 robots.txt。第二，Agent 目前沒有對應的 Disallow 設定，因為還沒有成熟的標準指令；Cloudflare 說等 ai-prefs 這類標準成熟後會再處理。

如果你的產品本身會呼叫外部網頁——例如檢索、摘要或代理抓取——這次的分類也提醒你，Search、Training、Agent 是三種不同的意圖，站點會分別對待。這和我們在為代理挑選網頁搜尋 API時談到的思路一致：先定義任務與可接受的行為，再挑工具，而不是先選供應商。

下一步的觀察點是 AI Summaries。Cloudflare 說站點層級的 yes/no 太粗糙，因為「有多少內容出現在摘要裡」和「是否出現」一樣重要，目標是明年初讓站長在 Cloudflare 設定一次就能控制比例。供給的 RSS 摘要沒有說明這個控制項的具體介面，只提到它會是對混合用途爬蟲業者的要求之一。

參考來源

Have it both ways: stay discoverable in search while disallowing AI training

Cloudflare's Disallow AI Training Setting: What Changes for Your Crawl Policy

Tue, 15 Sep 2026 00:00:00 GMT

Cloudflare's Disallow AI Training Setting: What Changes for Your Crawl Policy

The tradeoff that forced a binary choice

For years, a site owner who wanted out of AI training had one blunt instrument: block the crawler. But the biggest crawlers — Applebot, Bingbot, Googlebot — do search and training in the same pass. Refuse one, and you refuse the other. Cloudflare calls these mixed-use crawlers, and they were the hard part of the training question.

On September 15, 2026, Cloudflare announced a Disallow AI Training setting that splits the two. The mechanism is a robots.txt preference published on your behalf, combined with network-level identification of who is crawling and why. Accountable mixed-use crawlers stay allowed for search; every other training crawler is blocked. Apple, Google, and Microsoft honor or have committed to honor the setting.

What actually changed on September 15

Block and “Block on pages with ads” now apply to mixed-use crawlers. That is a real behavior change: if you select Block, you stop Applebot, Bingbot, and Googlebot entirely, search included. If you want training stopped but search kept, Disallow AI Training is the setting to use.

“Block AI Bots” is deprecated in favor of separate Search, Training, and Agent controls. Managed Robots.txt is deprecated in favor of Bot Preference Sync, and existing customers migrate automatically. For most accounts, Cloudflare says there is nothing to do.

One caveat worth reading closely: Bingbot does not yet respect a no-training preference in robots.txt. Microsoft is building that mechanism, targeted for early 2027. Until then, Disallow AI Training does not automatically convey the preference to Bing — the same practical behavior as the old Training Block setting. For Bing today, the supplied material points to the NOARCHIVE meta tag or the Block URLs and Content Removal tools.

Why robots.txt alone was never enough

Anyone can publish a robots.txt directive. It cannot identify who is crawling, determine why, or stop a crawler that ignores it. Cloudflare’s argument is that a network can: publish the preference, classify the crawler’s behavior, block the ones that ignore it, and report what each operator does on Radar.

That distinction matters when you are choosing where to enforce policy. If your only lever is a text file, you are trusting compliance. If your lever sits in the request path, you are enforcing it. The same split shows up in agent-facing retrieval work, where the question is whether a crawler is fetching on behalf of a human or harvesting at scale — see this earlier post on choosing a web search API for agents for how that retrieval task shapes the tooling decision.

The numbers behind the granularity

Cloudflare reports that less than 1% of its sites choose to block Search bots, while 17% enable some mechanism to block training. That gap is the whole design rationale: site owners broadly want to be found, and a meaningful minority want training refused. A one-size-fits-all “Block AI” cannot express both preferences at once.

For new domains, Cloudflare now offers two presets depending on whether the site earns money from advertising. Ad-supported sites get the more restrictive configuration, on the reasoning that ad revenue depends on a human actually seeing the page, while training replaces that visit with an answer. Both presets are editable during onboarding or later.

What is still unresolved

AI summaries are the next target. Cloudflare argues a site-wide yes or no is too blunt there, because how much of your content appears in a summary matters as much as whether it appears. An opt-out for AI summaries is already a stated requirement for mixed-use crawler operators, and the goal is to let site owners control how much content is included from one place by early next year.

Agents have no Disallow setting yet. Cloudflare notes that agents do not create the same search-discoverability tradeoff, and no well-established directive exists for expressing preferences to them. That is a gap to watch if your product depends on user-directed agents reaching your pages.

The practical takeaway: audit your current setting before assuming it means what it used to. Block now stops search too, and Disallow AI Training is the only option that keeps you indexed while refusing training — with Bing as a known exception until Microsoft ships its robots.txt support.

Sources

Have it both ways: stay discoverable in search while disallowing AI training

把公司資料變成對話：Data agent 如何縮短從問題到答案的距離

Tue, 15 Sep 2026 00:00:00 GMT

把公司資料變成對話：Data agent 如何縮短從問題到答案的距離

問題不在資料，在於等待答案

每個部門都有資料可以回答的問題：為什麼銷售下滑？支出在哪裡上升？哪些大客戶的續約有風險？但傳統上，得到答案意味著等待報表，或請資料團隊幫忙跑分析。OpenAI 在 2026 年 9 月 10 日宣布推出 ChatGPT Work 的 Data agent，目標是讓更多人自己找到答案，而不需要寫查詢或學習新的分析工具。

這個 agent 連接公司核准的資料來源，包括 Amazon Redshift、Google BigQuery、Snowflake、MongoDB、Databricks 等，也能把 Google Drive 和 SharePoint 的檔案帶進分析。它使用組織的業務術語、指標定義和資料關係來解讀資料，這些脈絡來自 semantic layer 和可信來源，例如 Databricks Genie Ontology、dbt、Snowflake Horizon 和現有 BI 儀表板。

從問問題到產生行動

Data agent 不只是回答問題。使用者可以追問結果、檢視每個發現背後的證據，然後把分析轉成互動式儀表板，內建視覺化功能。團隊可以編輯、分享和更新儀表板，也可以提供品牌指南來調整輸出樣式。

更進一步，agent 可以建立並操作 Omni、Oracle BI、Power BI、Sigma、Tableau 和 ThoughtSpot 的儀表板。這表示分析工作可以留在團隊已經使用的工具裡，而不是強迫所有人切換到新平台。使用者可以要求 ChatGPT Work 建議下一步、指出需要參與的人，並透過 Slack 或 email 分享發現，在核准後透過連接的工具執行行動。

權限與治理是設計核心

企業管理員可以選擇哪些資料連線可用、哪些角色可以使用。查詢會強制執行連接帳戶的現有權限，包括表格、列和欄位的限制。這代表 Data agent 不是一個繞過治理的後門，而是把自然語言介面放在既有的存取控制之上。

OpenAI 內部也廣泛使用這套能力：幾乎所有產品團隊和超過三分之二的 GTM 組織用 data agents 分析公司資料。資料團隊建立共享的業務定義、設定存取規則，並為敏感資料加上保護措施。這個做法與我們之前討論過的把電子郵件拆成三十個小模型：Fyxer 如何讓 AI 助理值得信賴有相似之處：信任不是來自單一模型，而是來自明確的權限、定義和可稽核的流程。

對產品團隊的意義

Data agent 的出現改變了產品團隊與資料的關係。過去，產品經理或行銷人員要依賴分析師才能回答「哪個功能使用率最高」或「哪個客群流失最快」。現在，他們可以直接用自然語言提問，並在對話中反覆調整分析。

但這不代表分析師的工作會消失。相反地，分析師的角色會轉向建立和管理 semantic layer、定義指標、設定權限，以及確保資料品質。產品團隊需要思考：哪些資料應該開放給 agent？哪些指標需要標準化？如何避免不同部門對同一個名詞有不同解讀？

Alpha 計畫的客戶已經看到具體成果。ServiceTitan 用 Data agent 建立儀表板，發現使用 Atlas AI 助理的用戶啟動行銷活動的比率大約是非使用者的三倍，這個發現幫助他們簡化 onboarding。NTT DATA 讓非工程師，特別是銷售和企業功能部門的人，用自然語言建立和更新自己的儀表板。

下一步：從分析到行動

Data agent 目前的重點是查詢、分析和儀表板。但真正的價值在於把洞察轉成行動。OpenAI 提到可以透過連接的工具執行核准的行動，但具體的執行範圍和限制，來源資料沒有詳細說明。

對產品團隊來說，現在可以開始做的是：盤點公司內部的資料來源和 semantic layer，確認哪些指標已經有清楚的定義，哪些權限需要調整。然後挑一個明確的業務問題，讓一個非技術團隊成員試著用 Data agent 回答，觀察哪裡卡住、哪裡需要更多脈絡。這比急著全面導入更能看出這個工具的真實價值。

Data agent 把「問資料問題」的門檻降到接近零，但門檻降低不代表答案自動正確。治理、指標定義和權限設計，仍然是決定這個工具能否真正「把資料變成工作」的關鍵。

參考來源

Now everyone can put data to work

When the Data Agent Becomes the Interface, Your Semantic Layer Is the Product

Tue, 15 Sep 2026 00:00:00 GMT

When the Data Agent Becomes the Interface, Your Semantic Layer Is the Product

Most business questions already have answers sitting in a warehouse. The bottleneck is the queue: someone files a request, waits for an analyst, and gets a report built from last week’s numbers. On September 10, 2026, OpenAI introduced a Data agent in ChatGPT Work that aims to remove that queue by letting people ask in plain language and get analysis back in the same conversation.

What the agent actually connects to

The Data agent links to approved sources including Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB, and Snowflake, and can pull files from Google Drive and SharePoint into an analysis. It also reads your organization’s business terms, metric definitions, custom calculations, and data relationships, drawing that context from semantic layers and trusted sources such as Databricks Genie Ontology, dbt, GitHub, Snowflake Horizon, and BI dashboards.

That second part is the interesting one. The agent is not guessing what “active customer” means. It is reading the definition your team already agreed on. Administrators still choose which connections exist and which roles can use them, and queries enforce the connected account’s existing table, row, and column restrictions.

From question to dashboard to action

You can ask follow-ups, inspect the evidence behind a finding, and turn the result into an interactive dashboard with built-in visualizations that teammates can edit, share, and refresh. Brand guidelines can be applied to outputs. The agent can also build and interact with dashboards in Omni, Oracle BI, Power BI, Sigma, Tableau, and ThoughtSpot, so the work can land in the BI tool a team already uses. It can suggest next steps, identify who needs to be involved, and share findings through Slack or email, carrying out actions you approve through connected tools.

OpenAI says nearly all of its product team and over two-thirds of its GTM organization use data agents in ChatGPT Work to analyze company data themselves, and that its data team enabled this by creating shared business definitions, setting access rules, and adding safeguards for sensitive data. NTT Data, Thermo Fisher, ServiceTitan, and Zipline are among the organizations in the Alpha program using it.

The part that is actually your job

Strip away the interface and the dependency is unglamorous: the agent is only as good as the definitions it can read. If your metrics live in three conflicting spreadsheets and a dashboard nobody trusts, natural-language access just makes the disagreement faster. If your semantic layer is clean, the agent becomes a new front end onto work you already did.

This is the same lesson that shows up whenever an agent is handed a whole system: the integration surface, not the model, decides whether the result is trustworthy. That pattern is worth revisiting in what it takes to hand an agent the whole system, because the Data agent inherits exactly those constraints.

For builders, the practical move is to treat the semantic layer as a product with users, not as plumbing. Name owners for metric definitions. Decide which roles get which connections before someone asks. Test the agent against questions where you already know the right answer, so you can tell a confident wrong number from a correct one. The supplied material does not specify pricing, rollout limits, or how conflicts between two definitions are resolved, so those are open questions rather than settled ones.

The queue does not disappear on its own. It moves from “waiting for an analyst” to “waiting for someone to fix the definitions.”

Sources

Now everyone can put data to work

Grok 接上 Coinbase：當 agent 能直接動你的交易所帳戶

Tue, 15 Sep 2026 00:00:00 GMT

Grok 接上 Coinbase：當 agent 能直接動你的交易所帳戶

2026 年 9 月 9 日，Grok 的官方 X 帳號宣布推出 Coinbase 連接器：加上之後，可以直接在對話裡查帳戶餘額、分析持倉，並買賣 Coinbase 上的資產。把模型接上交易所「看」資料不算新聞，這次的新聞是它能「下單」——而且是 Grok 與 Coinbase 共同維護的原生連接器，不是早期那種第三方、唯讀的橋接。

連接器實際上做什麼

根據報導整理，啟用後可以查餘額、分析持倉、買賣 Coinbase 上市的資產、取消現有委託單。流程是把「分析這個投資組合」和「下單」放進同一個對話，中間不需要打開 Coinbase 的 App。

第三方整理提出兩個值得注意的地方。第一，官方說法是「任何可用資產」，不限比特幣或以太幣，但低流動性代幣會怎麼處理、報價滑點誰負責，目前沒有交代。第二，在官方技術文件發佈之前，合理假設是每筆交易都要人工確認——這是從 8 月底 MoonPay PayBox 合作的模式推測的，文件本身還沒出來。

啟用順序也因此有個務實做法：先只開查詢權限用幾天，確認行為符合預期，再考慮開交易權限。

這一步前面的鋪路

Coinbase 連接器不是憑空出現。4 月 Grok 開放自訂 MCP 連接器先接了金融資料，8 月底 MoonPay PayBox 能做跨鏈交易，9 月的 Coinbase 則是第一個券商等級的帳戶整合，一年內三步走到能動真錢。

產品線上還有 Grok Bot：8 月 11 日進入 beta、由 SpaceXAI 與 Cursor 共同開發的「AI 隊友」，每個 bot 有自己的雲端電腦，會像人一樣登入網站、全天候做事。當 bot 的賣點是「登入你現有的工具」，資金帳戶就是最後、也最危險的一塊拼圖。

承諾是一回事，條款是另一回事

8 月 27 日，X 用戶 Teslaconomics 貼文問有沒有人把 Grok Bot 接上銀行帳戶——讓它追蹤支出、繳帳單、標記異常扣款。馬斯克親自回覆：如果 bot 把錢弄丟了，他們會讓你「make you whole」（全額補償）。

問題在同一篇報導裡就寫著：Grok 的消費者條款以「現狀」提供輸出與代理行為，多數求償上限是「已付費用或 100 美元取其高」。bot 存取需要每月 30 美元的 SuperGrok 方案，一年的費用也就 360 美元。推文不能覆蓋書面契約，而自願授權存取造成的損失，銀行法規裡的詐欺保護未必涵蓋。

前車之鑑也已經有過：5 月一起透過惡意 NFT 的 prompt injection 攻擊，從 Grok 生態的 Bankr 錢包轉走約 15 萬美元，事後找回約八成。攻擊面不是模型本身，而是模型會讀的外部內容——這在接上真實帳戶後只會更致命。

對要給 agent 金流權限的團隊

不管你用的是 Grok 還是自架方案，判準是一樣的。讀權與寫權分開授予，寫權先限小額；每筆動作留完整日誌，事後可以回放；批准要有粒度，從「每筆確認」放寬到「白名單加限額」，而不是一次全開。

信任的依據是介入率與可逆性，不是示範影片，這個判準我們在行政助理 agent 的接受率分析談過。而如果你想看 Grok 生態在工程端的另一面，Grok Build 開源的 harness是互補的參考。

來源沒回答的部分

技術文件、批准流程的具體實作、單筆與單日限額、錯帳的賠償流程，目前都沒有正式文件。馬斯克的承諾也還停留在推文層級，沒有反映到條款。

在這些補齊之前，把「每筆交易都要我確認」當預設值，是唯一合理的設定。

參考來源

Grok Can Now Trade Your Coinbase Account in Chat

Tue, 15 Sep 2026 00:00:00 GMT

Grok Can Now Trade Your Coinbase Account in Chat

On September 9, 2026, Grok’s official X account announced a Coinbase connector: once enabled, you can check account balances, analyze holdings, and buy or sell assets on Coinbase without leaving the conversation. Letting a model read exchange data was old news. This announcement is about writing — placing live orders through a connector maintained by Grok and Coinbase directly, not the read-only third-party bridges that came before.

What the connector actually does

Per the early coverage, an enabled user can check balances, analyze a portfolio, buy and sell assets listed on Coinbase, and cancel open orders. The pitch is putting “analyze this portfolio” and “place the order” in the same conversation, with no trip to the Coinbase app.

Two caveats are worth flagging from the write-ups. First, the announcement says “any available asset,” which is not limited to Bitcoin or Ethereum; how low-liquidity tokens are handled, and who eats slippage, is unstated. Second, until official technical documentation ships, the reasonable assumption is that every trade requires explicit human confirmation — that is inferred from the MoonPay PayBox pattern Grok used in late August, not from published docs.

That suggests a practical rollout order: enable read access first, use it for a few days, and only then consider granting trade authority.

The road that led here

The Coinbase connector did not appear from nowhere. Grok opened custom MCP connectors for financial data in April, added MoonPay PayBox cross-chain transactions in late August, and now has a brokerage-grade account integration in September — three steps from reading money to moving it in under a year.

One product line over is Grok Bot, the “AI teammate” that entered beta on August 11, co-developed by SpaceXAI and Cursor. Each bot runs on its own cloud computer, signs into websites the way a person would, and works around the clock. When the selling point is “logs into your existing tools,” the money account is the last and most dangerous tile in that mosaic.

A promise is not the terms

On August 27, an X user named Teslaconomics posted asking whether anyone had connected Grok Bot to a bank account — tracking spending, paying bills, flagging odd charges. Musk replied personally: if the bot loses your money, they will “make you whole.”

The problem is in the same reporting: Grok’s consumer terms provide outputs and agentic actions on an as-is basis, capping most claims at the greater of fees paid or $100. Bot access requires the $30/month SuperGrok plan, so a year of fees totals $360. A reply on X does not override a written contract, and fraud protections in banking regulation may not apply when the customer voluntarily granted access in the first place.

There is also precedent for the attack surface. In May, a prompt-injection attack via a malicious NFT drained roughly $150,000 from a Grok-linked Bankr wallet; about 80 percent was later recovered. The vector was not the model itself but external content the model reads — and that surface only gets more sensitive behind a live brokerage account.

For teams granting agents money authority

The criteria do not change whether you are using Grok or a self-hosted stack. Separate read from write authority, and cap write authority at small amounts first. Log every action so it can be replayed. Make approval granular — start at “confirm every transaction” and relax toward “allowlist plus limits,” not the other way around.

The basis for trust is intervention rate and reversibility, not demo videos; we made the same argument in the Fyxer acceptance-rate analysis. For the engineering side of the Grok ecosystem, the open-sourced Grok Build harness is the complementary read.

What the sources do not answer

Technical documentation, the concrete approval flow, per-trade and daily limits, and the reimbursement process for a wrong order are all unpublished. Musk’s pledge still lives at the level of a reply, not the terms of service.

Until those exist, “every trade requires my confirmation” is the only sensible default.

Sources

把圖片編輯寫進程式碼：Nano Banana API 的請求形狀與取捨

Tue, 15 Sep 2026 00:00:00 GMT

把圖片編輯寫進程式碼：Nano Banana API 的請求形狀與取捨

一個請求，兩個欄位

OpenRouter 在 2026 年 9 月 9 日發布的教學，把「用文字指令改一張既有圖片」壓縮成一個 HTTP 請求：來源圖放進 input_references，修改指令放進 prompt，改好的圖以 base64 回傳在 data[0].b64_json。

這篇教學預設的模型是 google/gemini-3.1-flash-image，也就是 Nano Banana 2。OpenRouter 說明「Nano Banana」是 Google Gemini 圖像模型的暱稱，而這個 slug 是該家族中預設的快速模型。對產品團隊來說，真正有用的不是暱稱，而是請求形狀：同一個 endpoint 同時吃本地檔案與公開 URL，回傳格式也固定。

值得注意的是編輯與生成的差別。教學明確區分：編輯是改一張既有圖片，生成是從文字產生新圖；這份教學只涵蓋編輯，所以每個請求都必須帶來源圖。如果你要的是從零生成，得走另一份文件。

來源圖怎麼送：base64 或 URL

input_references 接受兩種輸入：base64 data URL，或一般的 HTTP(S) 連結。教學的建議很直接——圖片已經公開託管就用 URL，請求 body 會小得多；本機或私有檔案才用 base64 編碼。

教學列出 Gemini 可接受的輸入格式為 image/png、image/jpeg、image/webp、image/heic、image/heif，但同時提醒支援格式因模型而異，送之前要確認模型頁面。這類細節在 demo 階段很容易被忽略，到了正式流程就會變成隨機失敗。

回傳端也一樣單純：把 b64_json 解碼後寫入檔案即可。教學另外提到 OpenRouter SDK 有對應的 images resource，呼叫同一個 endpoint，不想自己處理原始 HTTP 的話可以改用。

編輯提示詞的寫法，以及為什麼要一次改一件事

教學對提示詞的建議是：先講要改什麼，再講什麼必須維持不變。它給的例子包括物件替換、換背景、風格轉換、改招牌文字，每一種都附帶「保留原本的某部分」這種約束。

它還提到可以把提示詞寫成一小段 JSON 文字，把 edit、preserve、style 分開。但教學說得很清楚：API 只把它當純文字處理，這不是特殊模式，只是可能幫助模型區分「要改」與「不要動」。要不要用，得在自己的圖上試。

多輪編輯的做法是把上一輪回傳的圖再當成下一輪的來源圖，一次只下一個指令。教學提醒模型不會記得先前的提示詞，所以每一輪都要重述該保留的部分。這個限制直接影響你的產品設計：如果你打算做「連續微調」的介面，狀態得存在你自己的系統裡，而不是期待模型記得。

換模型只改一個欄位，但前提是模型真的支援

教學裡最實用的一段，是換模型的方式：model 欄位改掉，來源圖、提示詞、回應處理程式碼都不用動。它列出同家族的四個選項——Nano Banana 2 當快速預設、Nano Banana 2 Lite 最便宜最快、Nano Banana Pro 較慢但品質較高、初代 Nano Banana 則是暱稱起源的舊模型。也可以換成其他供應商的模型來比較品質、成本與速度。

但這個「只改一個欄位」有前提：模型必須接受圖像輸入，且支援同樣的 input_references 形狀。教學反覆強調要先確認模型具備編輯能力，因為圖像目錄變動頻繁，今天釘住的 slug 之後可能被淘汰或改價。這種抽象層的價值，和我們在把模型參數移出程式碼談過的設定管理是同一件事：把會變的東西集中到一處，程式邏輯才不用跟著重寫。

錯誤處理與成本，才是能不能上線的分界

教學點出三種常見失敗：模型拒絕不支援的格式或連不到的 URL；圖片過大導致逾時，建議先縮圖；以及把提示詞寫成問句（例如「這張照片裡有什麼？」）會讓模型回文字而非圖片，API 會以 400 錯誤回傳，而不是空回應。最後一點對產品特別重要——錯誤要以 HTTP 狀態判斷，不能靠解碼結果猜。

成本方面，教學說回應會在 usage 資料可用時回報每次請求的美元成本，建議記錄下來追蹤支出。批次作業則要遵守速率限制，對 429 與 5xx 用遞增延遲重試，並限制同時進行的編輯數量；每張回傳的圖要先存檔再進行下一輪，避免單一失敗帶走已完成的工作。

這份教學沒有談到延遲數字、品質評測方法，也沒有談多使用者併發下的配額規劃——這些得靠你自己的測試補上。實務上的下一步很具體：拿一張自己的圖跑一次請求，把 usage 記下來，再決定要不要把編輯流程接進產品。

參考來源

Nano Banana API: Edit Images with Gemini in Code — OpenRouter Blog

Nano Banana API: What the Image Edit Request Shape Changes for Builders

Tue, 15 Sep 2026 00:00:00 GMT

Nano Banana API: What the Image Edit Request Shape Changes for Builders

Most image features start as a demo and then hit a wall: the moment you need to change one thing in a photo without regenerating the whole scene. OpenRouter’s September 9, 2026 tutorial on the Nano Banana API treats that wall as a request-shape problem, and the shape it lands on is small enough to fit on one screen.

One request, two fields that matter

The guide’s claim is that editing takes a single call. You put the source image in input_references and the instruction in prompt, then read the edited image from data[0].b64_json and decode it to disk. The default model is google/gemini-3.1-flash-image, which the tutorial identifies as Nano Banana 2, the default fast model in Google’s Gemini image family.

That is the whole contract. No separate upload step, no job polling, no asset ID to track between calls. For a builder, the interesting part is not the model name but the fact that the request body is the same in Python and TypeScript, and that the response is base64 you can write straight to a file.

Inputs: base64 or a plain URL

input_references accepts either a base64 data URL or an HTTP(S) URL. The tutorial recommends a URL when the image is already hosted publicly, because it keeps the request body small, and base64 for local or private files. Gemini accepts image/png, image/jpeg, image/webp, image/heic, and image/heif inputs, though the guide warns that supported formats vary by model, so check the model page before sending.

That split matters more than it looks. If your pipeline already stores images behind a CDN, you can skip encoding entirely. If it handles user uploads that never leave your infrastructure, base64 keeps them local.

Editing in steps instead of one big prompt

The tutorial’s most practical advice is to edit in small steps. Send each returned image back in as the next source, one instruction per call, so changes stack. The sample chains three calls: add a scarf, make it navy blue, then add soft morning light from the left.

There is a constraint worth internalizing: the model does not remember earlier prompts, so each new prompt has to repeat the parts that should stay the same. That is a real cost in prompt tokens and in review effort, but it also means each step is independently checkable and redoable. If step three comes back wrong, you still have step two on disk.

The guide also separates generation prompts from edit prompts. A generation prompt describes a whole new image; an edit prompt states the change first, then names what must stay the same. Its examples include an object swap, a background change, a style transfer, and a text fix. It notes you can write the prompt as a small JSON block with edit, preserve, and style keys, but the API treats that as plain text, not a special mode.

Swapping models and handling failures

Changing the editing model is a one-field change: replace the model value and keep the source image, prompt, and response handling identical. The tutorial lists four current members of the family, with google/gemini-3.1-flash-lite-image as the cheapest and fastest, google/gemini-3-pro-image as slower and higher quality, and the original google/gemini-2.5-flash-image still working with the same request shape. It also shows openai/gpt-5-image as a cross-provider comparison, with the caveat that this only works for models that accept image input and support the same input_references shape.

If you are already treating model choice as configuration rather than code, this fits the pattern described in Config-as-Code for LLM Calls, where per-environment model settings live outside the request logic.

The failure modes the guide flags are worth planning for. A model may reject an unsupported format or an unreachable URL. Oversized images can time out, so shrink the source first. And a question like “what’s in this photo?” can make the model answer in text instead of producing an image, which the API returns as a 400 error rather than an empty response. Write an instruction, not a question, and check the HTTP status before decoding.

Cost is reported per request in USD when usage data is available, so logging usage.cost gives you spend tracking without a separate meter. For batch jobs, the tutorial suggests retrying 429 and 5xx responses with growing delays, limiting concurrency, and saving each returned image before starting its next edit so one failure does not lose finished work.

What to take from this

The request shape is the useful part: one endpoint, one source image, one instruction, one image back. That makes image editing something you can wrap in a function and test like any other API call, rather than a separate subsystem. The limitation is that quality and format support still vary by model, and the supplied tutorial does not specify how the editing-capable catalog will change over time beyond noting that models are added, deprecated, and repriced. Pin a slug, but keep the model field easy to change.

Sources

Nano Banana API: Edit Images with Gemini in Code — OpenRouter Blog

Hermes Agent：記憶留在本機、會自己長出技能的開源助理

Tue, 15 Sep 2026 00:00:00 GMT

Hermes Agent：記憶留在本機、會自己長出技能的開源助理

2026 年的 agent 市場有一條清楚的主軸：記憶與執行放在誰的機器上。Nous Research 的 Hermes Agent 選了立場最鮮明的那一端——開源（MIT 授權）、自己架、記憶存在你自己的機器上。它在 2026 年 2 月 25 日推出，到 8 月中已是 OpenRouter 累積 token 用量第一的 agent。

它是什麼

Hermes Agent 是常駐的個人 agent：裝在自己的機器上，跨 session 記住你的專案與偏好，因為是全天候執行的程序，行為更像助理，而不是用完即棄的一次性指令。

叫它的介面不是網頁，是你本來就在用的訊息軟體：Telegram、Discord、Slack、WhatsApp、Signal、Email 都通，也有 CLI。排程用自然語言設定，每天早上產報告、夜間備份、每週稽核這類任務會在背景自己跑。需要分工時，它會開出隔離的子代理（subagent），每個子代理有自己的對話與終端，用 Python RPC 協調。

最特別的是技能會自己長出來：解決過的難題會被整理成可重用的技能，用得越多，累積越厚。官方的說法是「它學你的專案、自動生成技能」。

Desktop 公測：把終端機的東西搬進視窗

6 月 2 日起，官方推出 Hermes Desktop 公測，macOS 與 Windows 有一鍵安裝包，Linux 走終端機安裝。定位是「鏡像」而不是「取代」：命令列做得到的，Desktop 都做得到，再加上檔案瀏覽、預覽與外掛系統（工具、hook、主題、整合都能掛）。

基礎功能免帳號就能用；登入 Nous Portal 之後才多了雲端常駐 agent 與模型折扣。這個分界本身就是產品判斷：本體免費開源，營收掛在代跑與模型轉售上。

用量第一，但要會讀

8 月中的第三方統計給了一組抓眼球數字：OpenRouter 上的累積 token 消耗，Hermes Agent 以 35.7 兆排名第一，Claude Code 8.53 兆第二，Kilo Code 7.36 兆第三，年初爆紅的 OpenClaw 掉到 4.4 兆第四。Hermes 在 5 月 6 日第一次登上單日第一，當天消耗 2,710 億 token。

但同一篇文章自己也給了三個但書，值得原封不動搬過來。第一，Hermes 是 24/7 常駐程序，Claude Code 是 session 型工具，token 總量先天不可比。第二，Claude Code、Cursor、Copilot 的大部分流量根本不走 OpenRouter，這個榜只量得到 OpenRouter 一個通道。第三，榜單會隨生態變動——OpenRouter 本身正在被 Stripe 以 70 億美元以上的價格收購。

所以這組數字能證明的，是「有一大批人願意讓一個常駐開源 agent 長時間燒 token」，而不是「Hermes 打敗了 Claude Code」。

錢與生態

TechCrunch 在 7 月 13 日報導，Nous Research 正以 15 億美元估值洽談新一輪融資，由 Robot Ventures 領投、USV 等參與。對一家以開源模型起家的公司，這個估值直接掛在 Hermes Agent 的採用曲線上。

時間點也值得注意。Hermes 是在 OpenClaw 爆紅後進場的挑戰者之一，而 OpenClaw 這半年走了下坡：五個月內累積 138 個 CVE（其中一個 CVSS 9.9），創辦人在 2 月加入 OpenAI。開源 agent 的市場信任，很大一部分是靠競爭對手的安全事故襯托出來的——這正是我們在OpenClaw 兩次改名與安全疑慮一文談過的劇本。

真正的設計賭注

把記憶留在本機，得到的是資料主權，付出的是風險自負：沒有雲端廠商幫你擋更新、備份與漏洞。讓 agent 自己寫技能，得到的是越用越順手，付出的是技能品質沒有審核機制，一個錯誤的做法被固化成技能檔，之後每次都會照做一次。

對要選型的團隊，我會把「可攜的技能資產」視為這類產品最值得抄的部分。模型可以換、框架可以換，但解決問題的程序沉澱成開放格式的技能檔之後，那是帶得走的資產。這與整個產業把 agent 往本機搬的方向一致——LM Studio 的 Bionic和Meta 開放權重的 Muse Glimmer都在講同一件事。

參考來源

Hermes Agent: Self-Hosted AI That Writes Its Own Skills

Tue, 15 Sep 2026 00:00:00 GMT

Hermes Agent: Self-Hosted AI That Writes Its Own Skills

If the 2026 agent market has one dividing line, it is whose machine the memory and execution live on. Nous Research’s Hermes Agent picked the most emphatic side of that line: open source under the MIT license, self-hosted, with its memory stored on your own hardware. It launched on February 25, 2026, and by mid-August it was the top agent by cumulative token consumption on OpenRouter.

What it is

Hermes Agent is a persistent personal agent. It runs on your own machine, remembers your projects and preferences across sessions, and — because it is an always-on process rather than a disposable command — behaves more like an assistant than a one-shot tool.

The interface is not a web page but the messengers you already use: Telegram, Discord, Slack, WhatsApp, Signal, and Email all work, plus a CLI. Scheduling is set in natural language, so morning reports, nightly backups, and weekly audits run unattended in the background. When a task needs to be split, it spawns isolated subagents, each with its own conversation and terminal, coordinated over Python RPC.

The most distinctive trait is that its skills grow on their own: problems it has solved get distilled into reusable skills, and the layer thickens with use. The official phrasing is that “it learns your projects, auto-generates skills.”

Desktop beta: the terminal, in a window

Since June 2, an official Hermes Desktop beta has shipped, with one-click installers for macOS and Windows and a terminal install for Linux. The stated position is “mirror, not replace”: everything the CLI does is available in the app, plus file browsing, previews, and a plugin system for tools, hooks, themes, and integrations.

The base app needs no account. Signing into Nous Portal is what adds always-on cloud agents and model discounts. That boundary is itself a product decision: the core is free and open, and revenue attaches to hosted execution and model resale.

Number one in usage, if you read it right

Mid-August third-party numbers came with an attention-grabbing headline: by cumulative token consumption on OpenRouter, Hermes Agent leads at 35.7 trillion, ahead of Claude Code at 8.53 trillion, Kilo Code at 7.36 trillion, and the early-year viral hit OpenClaw, down at 4.4 trillion. Hermes first took the daily top spot on May 6, burning 271 billion tokens that day.

But the same article supplies three caveats worth repeating verbatim. First, Hermes is a 24/7 persistent runtime while Claude Code is session-based, so raw token totals are not comparable by construction. Second, most Claude Code, Cursor, and Copilot traffic never touches OpenRouter, so the ranking measures exactly one channel. Third, the landscape is moving — OpenRouter itself is being acquired by Stripe for north of $7 billion.

What the numbers do prove is that a large population is willing to let a self-hosted open-source agent burn tokens around the clock. They do not prove “Hermes beat Claude Code.”

Money and ecosystem

TechCrunch reported on July 13 that Nous Research is in talks for a new round at a $1.5 billion valuation, led by Robot Ventures with USV participating. For a company that built its name on open models, that valuation is pinned directly to Hermes Agent’s adoption curve.

The timing matters too. Hermes arrived as one of the challengers after OpenClaw went viral, and OpenClaw has spent the half-year since declining: 138 CVEs accumulated in five months, one of them CVSS 9.9, and its founder joined OpenAI in February. A meaningful share of trust in open-source agents is borrowed from competitors’ security incidents — the dynamic we walked through in OpenClaw’s two renames and the security concerns.

The design bets that actually matter

Keeping memory local buys data sovereignty and costs you self-insurance: no cloud vendor patches, backs up, or absorbs the breach for you. Letting the agent write its own skills buys compounding convenience and costs you review: a bad procedure, once fossilized as a skill file, gets repeated faithfully ever after.

For teams doing procurement, the portable skill asset is the part worth stealing. Models and frameworks come and go, but procedures distilled as open-format skill files are an asset you carry with you. It is the same industry direction as LM Studio’s Bionic and Meta’s open-weight Muse Glimmer: the agent is moving onto your machine.

Sources

把商品標籤交給小模型：SageMaker serverless 客製化的取捨

Tue, 15 Sep 2026 00:00:00 GMT

把商品標籤交給小模型：SageMaker serverless 客製化的取捨

商品目錄很少以乾淨的結構化欄位送到你手上。品名、描述、分類路徑來自不同來源，而且持續變動；搜尋、推薦與分類導覽都依賴一致的標籤，但人工為數千個 SKU 貼標既慢又難維持一致。

AWS Machine Learning Blog 在 2026 年 9 月 15 日發布的 walkthrough 提出一個明確的判斷：當分類體系穩定、輸出可以用程式評分時，客製化一個較小的開源權重模型，可能比用通用前沿模型加 prompt engineering 更合適。理由是這類高頻貼標工作的目標很窄——用正確的 schema 穩定回傳正確的屬性——你不需要為每次請求都付費購買用不到的通才能力。

這條流程把三件事拆開

根據這篇 walkthrough，整體工作流刻意分成資料準備、serverless 模型客製化、推論三個關注點。資料先轉成有版號的資產，SFT 教模型認識貼標 schema，RLVR 再針對可驗證的獎勵優化行為，最後把模型打包上線。

值得注意的是「serverless」在這裡只指訓練路徑。推論端用的是 Amazon SageMaker Asynchronous Inference，跑在 provisioned 的 ml.g6.2xlarge 上，適合批次式的目錄充實。這個區分對成本估算很重要：訓練容量由 AWS 挑選與釋放，但推論仍是你自己的執行個體。

從 SFT 到 RLVR：什麼時候需要第二步

流程先用 supervised fine-tuning 客製化 Qwen3-8B，再以 RLVR 搭配 GRPO 優化。AWS 的說明指出，SFT 預期帶來 schema 遵循度最大的躍升，因為它直接示範了期望的輸入輸出；RLVR 則用來處理剩下的品質取捨，而不是重新學格式。

RLVR 之所以可行，是因為貼標輸出是結構化的，可以直接和參考答案比對，不需要另一個 LLM 來評判每個 completion。獎勵函式是確定性的：檢查九類輸出格式，並以 0.5 門檻做模糊比對。文中給出的權重是 recall、precision、accuracy 各 0.30，match_quality 與 formatting 各 0.05，而且排程會隨訓練階段改變強調重點，早期偏向 recall，避免模型漏掉應該出現的標籤。

這裡的關鍵設計是：當你的評分方式可以寫成規則，客製化小模型就從「感覺比較便宜」變成「訊號可驗證」。

與舊做法的差別在哪

AWS 對比了兩種路徑。amazon-sagemaker-examples 裡先前的 Qwen3-8B 範例使用 SageMaker Training Jobs，由客戶挑選 GPU 執行個體並自備訓練映像；這次的 walkthrough 改用 Amazon SageMaker Python SDK v3 的 serverless 客製化 trainer（SFTTrainer 與 RLVRTrainer）。不提供 compute 設定時，SageMaker 會自行選擇並釋放訓練容量。

如果你正在評估同類工作，這個對比比模型選擇更值得先想清楚：你要自己管訓練基礎設施，還是把容量調度交出去，換取較少的控制權。

上線前要先確認的幾件事

這篇 walkthrough 列出的前置條件相當具體，而且多數和模型無關。你需要 SageMaker AI 權限來管理客製化任務、AI Registry 資料集與評估器、model package group、endpoints 與非同步推論；需要 S3 讀寫來源目錄、轉換後的訓練資料與模型產物；只有在自行建置與託管 vLLM 推論映像時才需要 ECR。

另外要確認所選 Region 與模型／技術組合支援 Qwen3-8B 的 SFT 與 RLVR，並保留足夠的 hosting quota 給 ml.g6.2xlarge 與非同步 endpoint。資料集部分，示範用 Kaggle 上的 Amazon Sales Dataset，超過 1,000 筆商品記錄；正式環境應改用自己核准的目錄與可信標籤。本機工具需要 Python 3.11+、AWS CLI v2、pandas、SageMaker Python SDK v3，以及建置映像時才需要的 Docker。驗證建議走 IAM Identity Center 或其他短期憑證流程，避免 root 與長效 access key。

這類「把重複的判斷交給受控流程」的思路，和我們先前談 Amazon Bedrock prompt caching 如何壓低重複 context 成本是同一個問題的不同切面：先辨識出工作裡真正重複、可預期的部分，再決定要為它付出多少推論成本。

實務上的下一步

如果你的目錄規模還小、分類體系仍在頻繁變動，這條路徑的前提就不成立——RLVR 的獎勵需要穩定的參考答案，schema 一直改就沒有可驗證的訊號。反過來說，當標籤類別固定、你能寫出評分規則、而且貼標量足以攤平客製化成本時，先做 SFT 拿到 schema 遵循度，再視漏標與多標的實際比例決定要不要進 RLVR，是比較容易驗證順序的做法。

需要提醒的是，這篇 walkthrough 的內容在獎勵函式設計段落後截斷，後續的評估與部署細節並未完整呈現；上述流程以已提供的部分為準。

參考來源

Build an AI-powered product tagging system with Amazon SageMaker serverless model customization

How Serverless Fine-Tuning Changes Product Tagging Economics

Tue, 15 Sep 2026 00:00:00 GMT

How Serverless Fine-Tuning Changes Product Tagging Economics

Retail catalogs rarely arrive as clean, structured attributes. Product names, descriptions, and category paths come from many sources and change continuously. Search, recommendations, and catalog navigation depend on consistent tags, but manually applying those tags across thousands of SKUs is slow and hard to keep consistent.

A general-purpose frontier model can generate tags with prompt engineering, but a high-volume tagging workflow usually has a narrower objective: return the right attributes in the right schema, consistently. When the taxonomy is stable and the output can be scored programmatically, customizing a smaller open-weight model can be a better fit. You teach the model the schema directly and optimize the trade-off between missing tags and unnecessary tags, avoiding paying for broad capabilities the workflow doesn’t need on every request.

Where serverless changes the training path

The AWS Machine Learning Blog walkthrough customizes Qwen3-8B with supervised fine-tuning (SFT), then optimizes it with reinforcement learning with verifiable rewards (RLVR) using Group Relative Policy Optimization (GRPO). Amazon SageMaker serverless model customization manages the training capacity, while the optimized model is deployed separately to SageMaker Asynchronous Inference for batch-oriented catalog enrichment.

The key difference from traditional SageMaker Training Jobs is that you don’t select GPU instances or build custom training images. The Python SDK v3 SFTTrainer and RLVRTrainer submit jobs without a compute argument, and AWS selects and releases the training capacity. This removes instance provisioning from the builder’s checklist, though the asynchronous inference endpoint still uses a provisioned ml.g6.2xlarge instance.

A two-stage customization that separates concerns

The workflow splits into three concerns: data preparation, serverless model customization, and inference. Data is transformed once into versioned assets registered in SageMaker AI Registry. SFT teaches the model the tagging schema. RLVR optimizes behavior against a deterministic reward.

SFT provides the largest jump in schema adherence because it directly demonstrates the desired I/O behavior. The walkthrough uses LoRA with rank 16, merges weights, and trains for three epochs on a 4K sequence length. The output is a model package ARN that becomes the starting point for RLVR.

RLVR continues from the SFT model package and uses a deterministic reward function to score candidate tag sets. GRPO generates eight completions per prompt (rollout_n=8), scores each independently, computes group-relative advantages, and uses KL regularization to limit drift from the SFT reference model. The reward function checks the nine-category output format and uses fuzzy matching at a 0.5 threshold to compare predicted tags with the reference — no separate judge model required.

What this means for builders

The serverless training path removes a meaningful operational burden for teams that need to fine-tune smaller models repeatedly. You still need to prepare data, design the reward function, and manage the inference endpoint, but you no longer need to think about training instance types or custom images. This fits a pattern we’ve seen with other managed services: the infrastructure fades, and the builder’s attention shifts to data quality and evaluation design. As covered in Prompt Caching on Bedrock: Where the 90% Input Savings Actually Come From, the economics of AI workflows often hinge on where you can avoid paying for unnecessary capacity — here, that’s the training compute.

The trade-off is that serverless training gives you less control over the training environment. If you need specific GPU types, custom kernels, or unusual memory configurations, traditional SageMaker Training Jobs remain the fallback. But for a structured tagging task with a stable taxonomy, the serverless path is a pragmatic default.

The walkthrough uses the public Amazon Sales Dataset with over 1,000 product records, but the same pattern applies to any private catalog that can be transformed into the prompt/target schema. The supplied AWS blog post does not report final accuracy or cost numbers, so builders should run their own evaluation against their catalog’s tag distribution before committing to this approach.

Sources

Build an AI-powered product tagging system with Amazon SageMaker serverless model customization

為代理挑選網頁搜尋 API：先定義任務，再比較六種工具

Mon, 14 Sep 2026 00:00:00 GMT

為代理挑選網頁搜尋 API：先定義任務，再比較六種工具

當你決定讓 AI 代理存取網頁時，只說「需要搜尋」是不夠的。代理可能需要語意相關的內容、監控特定網站、進行多步驟研究、產生有引用的答案，或只是取得最新資訊給另一個模型推理。Tavily 部落格在 2026 年 9 月 14 日發布的比較文章指出，雖然 Tavily、Exa、Parallel、Firecrawl、Perplexity 和 Brave 常被視為同類選項，但它們其實從不同的起點設計。

先釐清代理的搜尋任務

在比較平台之前，先定義 API 需要做什麼。Tavily 的文章建議從三個面向思考：

檢索任務：代理開始時知道什麼？從已知 URL 出發的工作流程，與從開放式問題出發的需求不同。
回傳內容：API 應該回傳連結和摘要、提取後的內容，還是整合好的答案？平台處理越多，你需要自己建構的就越少。
準確度、延遲與資訊密度：速度快不代表有用。結果是否準確、相關，且包含足夠細節，避免後續重新排序、重試或消耗模型 token？

此外，也要檢視來源、日期、地點、語言和內容格式的控制選項，以及針對 prompt injection、PII 洩漏和惡意來源的防護。

六種 API 的定位差異

每個平台都涵蓋網頁搜尋流程的多個部分，但重點不同。

Brave Search API 提供獨立網頁索引，適合廣泛覆蓋、快速查詢和傳統搜尋體驗。但 Tavily 的文章提醒，其廣泛結果可能引入雜訊，需要額外過濾或重試。

Exa 使用神經和語意搜尋，擅長探索相關概念和專業資料集。但語意強項不保證每個事實查詢都有最新或最直接的證據。

Firecrawl 是開源平台，專注於爬取、提取和監控已知網站。它最適合將特定網站轉為結構化資料，而非從問題出發尋找來源。

Parallel 結合搜尋與研究、提取、監控等 API，適合多步驟調查。但較快的模式可能回傳不完整結果，且其工作流程能力對單純檢索需求可能過重。

Perplexity 從消費者問答產品延伸出 Search API，並提供答案生成、模型和代理工作流程。採用更多平台功能可能讓 Perplexity 對資訊檢索和呈現有更多控制。

Tavily 專注於為生產環境中的 AI 代理提供快速、準確、資訊密集的檢索，並內建 prompt injection 偵測、PII 防護和零資料保留。

用實際查詢測試，而非只看功能表

Tavily 的文章強調，基準測試和功能列表只是起點。你應該用代理實際會收到的查詢建立測試集，包括簡單查詢、即時問題、小眾主題和複雜研究任務。在相同設定下執行每個 API，比較準確度、新鮮度、引用完整性、延遲、失敗率和資訊密度。

最好的選擇不一定是每個查詢都贏的平台，而是在對你應用最重要的查詢上表現一致，且需要最少額外工作的那個。計算成本時，也要納入提取、重新排序、重試、下游模型使用和工程時間。

這與我們之前討論的流程編排執行模型有相似之處：先決定誰能做決定，再談工具。選擇搜尋 API 時，也要先釐清代理的決策架構，才能找到最適合的檢索層。

從 Tavily Playground 開始驗證

如果你正在評估 Tavily，可以先在 Tavily Playground 執行自己的查詢，檢查回傳的來源，看看代理實際會收到什麼內容，再決定是否整合。免費方案即可開始測試。

參考來源

Tavily vs. Exa vs. Parallel vs. Firecrawl vs. Perplexity vs. Brave: Choosing the Right Web Search API for Each Use Case | Tavily Blog

Choosing a Web Search API for Agents: What the Retrieval Task Actually Demands

Mon, 14 Sep 2026 00:00:00 GMT

Choosing a Web Search API for Agents: What the Retrieval Task Actually Demands

When you’re building an AI agent that needs web access, the first question isn’t “which search API is best” — it’s “what does my agent actually need to retrieve?” A workflow that starts with a known URL needs different capabilities than one that starts with an open-ended question. A quick lookup requires a different approach than a multi-step research task. Tavily’s comparison of six popular web search APIs makes this distinction clear: each platform is designed around a different part of the retrieval process.

Start with the retrieval task, not the vendor

Before comparing platforms, define what you need the API to do. Consider what your agent knows when it begins. Does it have a specific URL to crawl, or does it need to discover sources from a vague query? Does it need links and snippets, extracted content, or a synthesized answer? The more processing the platform handles, the faster you can start testing — but you also give up control over how information is retrieved and presented.

Accuracy, latency, and information density matter more than raw speed. A fast result that requires extensive reranking or retries downstream isn’t actually fast. Tavily’s guide suggests evaluating whether the API returns accurate, relevant information quickly and with enough detail to avoid additional model tokens or engineering work.

Where each platform fits

Brave Search API gives developers access to an independent web index with options for web, news, image, video, and local search. It’s a strong fit for broad coverage, fast lookups, and traditional search experiences. But its broad results may introduce noise for production agent queries, leading to additional filtering or reranking. The key question: are you building a search experience, or an agent that needs context it can immediately reason over?

Exa uses neural and semantic search to find content based on meaning. It’s particularly useful for exploring related concepts and searching specialized datasets for people, companies, and research. That semantic strength doesn’t guarantee the freshest or most directly relevant evidence for every factual query, so teams building real-time applications should test consistency carefully.

Firecrawl is an open-source platform for scraping, crawling, extracting, and monitoring websites. It’s best suited for turning known sites into structured data, including scheduled crawls and change notifications. Firecrawl’s strength begins once you know which websites or URLs you want to explore — if your agent starts with a question and needs to find the right sources, a search-first retrieval platform may be a better fit.

Parallel combines search with APIs for research, extraction, monitoring, enrichment, and entity discovery. It’s a strong option when you want the platform to perform more of a multi-step investigation. Its search modes offer different balances of speed, cost, and depth, but its broader workflow capabilities may be more than a retrieval-focused application needs.

Perplexity began as a consumer answer product and later extended its search infrastructure into APIs for agents. Its Search API sits alongside broader APIs for answer generation, models, and agent workflows. That breadth offers platform convenience, but adopting more of the stack gives Perplexity greater control over how information is retrieved, interpreted, and presented.

Tavily retrieves, ranks, and extracts current web information for AI agents. It’s built to balance latency, accuracy, and information density, so agents receive useful context without extensive reranking or retry logic. Tavily prioritizes managed retrieval over self-hosted crawling, a traditional search experience, or a bundled model platform — and pairs that focus with prompt-injection detection, PII and malicious-source protections, SOC 2 Type II, ISO 27001, and zero data retention.

Test with your own queries, not benchmarks

Benchmarks and feature lists provide a starting point, but they can’t tell you how an API will perform in your production application. Tavily’s guide recommends building a test set from the queries your agent will actually receive — simple lookups, real-time questions, niche topics, and complex research tasks. Run the same queries through each API using comparable settings, then compare accuracy, freshness, source quality, citation completeness, latency, failure rate, information density, and the additional reranking or model tokens required.

The best choice isn’t the platform that wins every query. It’s the one that performs consistently on the queries that matter most to your application and requires the least additional work to produce a useful result. When comparing costs, include the entire workflow — extraction, reranking, retries, downstream model usage, and engineering time — not just the API request.

What this means for your agent architecture

Web access is becoming part of an agent’s reasoning architecture, not just a bolt-on feature. The quality of what an agent retrieves, and how quickly and safely it can use that information, shapes the answers and actions that follow. If you’re already thinking about how your orchestrator handles execution models, the tradeoffs between process orchestration approaches apply here too: the retrieval layer you choose determines how much trust you can place in the context your agent receives.

For production agents that need fast, accurate, source-backed web context while retaining control over models and outputs, Tavily’s focus on managed retrieval with built-in protections is a strong fit. But the right choice depends entirely on your retrieval task — and the only way to know is to test with your own queries.

Sources

Tavily vs. Exa vs. Parallel vs. Firecrawl vs. Perplexity vs. Brave: Choosing the Right Web Search API for Each Use Case | Tavily Blog

把「探索」當成一種工程紀律：Christina Koch 與 James Manyika 對談裡，產品團隊該帶走的三件事

Mon, 14 Sep 2026 00:00:00 GMT

把「探索」當成一種工程紀律：Christina Koch 與 James Manyika 對談裡，產品團隊該帶走的三件事

太空任務和產品開發看起來距離很遠，但兩者卡住的地方常常一樣：資訊不完整、風險不可逆，而且沒有人能先試跑一次。

2026 年 9 月 14 日，Google 發布了新一集 Dialogues on Technology and Society，由 NASA 太空人、工程師兼科學家 Christina Koch 與 Google 研究、Labs、技術與社會資深副總裁 James Manyika 對談。以下只根據這份發布內容整理，沒有補充影片以外的細節。

對談裡實際出現的內容

根據 Google 的發布說明，Koch 回顧了她的職涯：在國際太空站待了 328 天、執行史上第一次全女性太空漫步，以及參與 NASA Artemis II 任務繞行月球。

她與 Manyika 談到從 25 萬英里外看地球，像一艘「電藍色的救生艇」；也談到太空人、機器人與 AI 之間的合作關係。她另外觸及「我們是否孤單」這個大問題，並給未來探索者一個建議：去做讓你害怕的事。

發布說明到這裡就結束了。影片中 Manyika 具體問了什麼、Koch 怎麼回答 AI 在任務中的角色，這份發布內容並沒有交代。

為什麼「人、機器人、AI 的分工」值得產品團隊留意

把 Koch 的職涯拆開看，會發現她的工作本質上是一連串高風險的委派決策：哪些判斷留給人、哪些交給自動化系統、哪些必須兩邊互相確認。

這正是多數代理（agent）專案真正難的地方，而且難點通常不在模型能力。當你把一個步驟交給自動流程，你同時交出了觀察與否決的機會。太空任務的處理方式是保留人類在關鍵節點上的確認權；產品團隊常犯的錯，則是把「自動化」和「不用看」當成同一件事。

如果你正在設計代理的工作邊界，我們先前談過流程編排的三種執行模型，核心問題一樣：先決定誰能做決定，再談要用哪些工具。

對談沒有給你的東西

這是一支對談影片，不是技術文件。它不會告訴你 AI 在太空任務裡負責哪一層、準確率多少、失敗時怎麼回退。把這類對談當成方向感的來源可以，當成架構依據不行。

同理，「去做讓你害怕的事」是一句給人的建議，不是給系統的設計原則。把它套進產品流程之前，你得先想清楚：害怕的是什麼？是資料不足、是不可逆的部署，還是沒有人願意在出錯時按下停止鍵？這三個問題的解法完全不同。

可以立刻做的事

看完這類對談，比較有用的動作不是記下金句，而是拿它去檢查自己手上的專案：

列出目前全自動執行的步驟，標出哪幾個一旦出錯就無法回頭。
對這幾個步驟，指定一個明確的人類確認點，而不是「有問題再說」。
確認你的系統在自動流程失敗時，會留下足以判斷原因的紀錄。

Koch 的 328 天與繞月任務，靠的不是單一系統的完美，而是人與機器各自守住自己擅長的部分。產品團隊能借用的，大概就是這個分工紀律，而不是那句勵志的話。

參考來源

Watch astronaut Christina Koch and Google’s James Manyika discuss space, technology, and discovery.

What a 328-Day Mission Teaches Builders About Partnering With AI

Mon, 14 Sep 2026 00:00:00 GMT

What a 328-Day Mission Teaches Builders About Partnering With AI

Most conversations about AI and exploration start with what the model can do. The Dialogues on Technology and Society episode published September 14, 2026 starts somewhere more useful: what a human and a machine each bring to a place neither can reach alone.

The setup, briefly

NASA astronaut, engineer, and scientist Christina Koch sits down with James Manyika, Google’s Senior Vice President of Research, Labs, Technology & Society. Koch’s record includes 328 days aboard the International Space Station, the first all-female spacewalk, and a journey around the Moon on NASA’s Artemis II mission.

The supplied RSS summary describes the conversation covering Earth seen as an electric blue “lifeboat” from 250,000 miles away, the partnership between astronauts, robotics, and AI, the question “Are we alone?”, and her advice to future explorers: do what scares you, and support others.

The partnership framing is the part worth stealing

The summary’s phrase — astronauts, robotics, and AI as a partnership — is not a slogan. It is an operating model, and it maps onto how teams should think about agents.

Koch’s work is a case where the human is not supervising a tool that could do the job alone. The human is the one making judgment calls in an environment where the cost of a wrong call is extreme, while automation handles what humans are bad at: sustained precision, repeatable procedure, and monitoring that does not fatigue.

That is a different design brief than “replace the manual step.” It asks which decisions need a person in the loop because the context is ambiguous, and which ones need a machine because the context is boring. If you are building agent workflows, that split is the whole architecture. The same question shows up in execution models for orchestrators, where the choice of who holds state decides how much you can trust the system when something goes wrong.

“Are we alone?” is a search problem with a long horizon

The summary notes Koch explores that question in the episode. It does not specify how she or Manyika frame it, so treat the framing as theirs to watch rather than something to paraphrase.

What is clear from the summary is that the question sits alongside the robotics-and-AI partnership discussion. That pairing is the interesting bit for anyone building research or discovery tools: the hard part is rarely generating a candidate answer. It is deciding what counts as evidence, and staying honest about how little you have.

What this changes for a builder

Two practical takeaways, both modest.

First, if your product pairs a person with an automated system, write down the split explicitly. Which decisions require human judgment because the stakes or ambiguity are high, and which are delegated because consistency matters more than nuance? The episode’s framing suggests that split is the design, not an implementation detail.

Second, watch the episode if you want the primary source. The summary is thin on specifics — it does not detail the AI systems discussed, the mission timeline, or Manyika’s positions. The supplied RSS summary does not specify those, and that is not evidence they were left out of the conversation.

Koch’s advice in the summary — do what scares you, and support others — is the least technical line in the piece and probably the most reusable. Exploration programs work because people take on work at the edge of their competence with support around them. Teams shipping AI tools are running a smaller version of the same thing.

Sources

Watch astronaut Christina Koch and Google’s James Manyika discuss space, technology, and discovery.

DevFest 2026 回歸：開發者如何從 800 場實體活動中挑出對自己有用的 agentic AI 內容

Mon, 14 Sep 2026 00:00:00 GMT

DevFest 2026 回歸：開發者如何從 800 場實體活動中挑出對自己有用的 agentic AI 內容

DevFest 回來了。Google 在 2026 年 9 月 14 日宣布，這個全球開發者社群活動將再次舉辦，而且規模比以往更大——超過 800 場實體活動，主題圍繞著「在 agentic AI 時代建置、保護與擴展」。對產品開發者來說，這不只是另一個技術研討會，而是一個重新校準自己學習路徑的時機。

活動規模與主題焦點

根據 Google 官方部落格，DevFest 2026 的核心訊息很明確：開發者需要掌握 agentic AI 的建置方法、安全考量，以及如何讓應用程式真正擴展。這三個面向正好對應到目前 AI 產品開發最常卡關的地方——不是模型能力不足，而是如何把代理（agent）放進真實的產品流程，同時確保安全與效能。

超過 800 場活動意味著選擇很多，但也代表你需要更清楚自己要解決什麼問題。如果你正在思考如何把多個 AI 代理串成一個可靠的流程，可以參考之前討論過的流程編排執行模型——先決定誰能做決定，再談工具。DevFest 的實體工作坊通常會提供這類架構討論的實作機會。

對產品開發者的實際意義

DevFest 的價值不在於吸收所有內容，而在於找到與你目前產品痛點直接相關的場次。例如，如果你正在評估是否要把代理功能放進現有產品，安全與擴展這兩個主題就特別重要。agentic AI 的「安全」不只是防止 prompt injection，還包括代理在執行任務時的權限控管與錯誤處理；而「擴展」則牽涉到基礎設施、成本控制與觀測能力。

Google 的公告沒有詳細列出每一場活動的議程，但從主題設定可以看出，主辦方希望開發者帶著具體問題來參加，而不是只聽概念分享。這對產品開發者來說是好事——你可以在活動前先盤點自己團隊在 agentic AI 上的瓶頸，再挑選對應的場次。

如何規劃參與策略

800 場活動分布在全球，多數開發者只會參加一到兩場。與其隨機報名，不如先問自己三個問題：

我目前最需要解決的 agentic AI 問題是什麼？
哪一場活動的講者或工作坊最可能提供可操作的答案？
活動結束後，我能帶回什麼具體的下一步？

DevFest 的實體性質讓它比線上課程更有價值的地方在於：你可以直接與講者和同儕討論你遇到的實際問題。如果你正在開發需要多模型協作的產品，活動現場的交流往往能幫你避開一些文件上沒寫的坑。

下一步

DevFest 2026 的具體日期與報名方式在公告中並未詳細說明，但開發者可以透過 Google 官方部落格追蹤後續消息。對產品開發者來說，現在就可以開始整理自己的 agentic AI 問題清單，這樣等到活動細節公布時，你就能快速判斷哪些場次值得投入時間。

參考來源

DevFest is back

What DevFest 2026 Means for Building in the Agentic AI Era

Mon, 14 Sep 2026 00:00:00 GMT

What DevFest 2026 Means for Building in the Agentic AI Era

Google has announced that DevFest is back for 2026, with more than 800 global events planned. The focus this year is on helping developers build, secure, and scale in the agentic AI era. For product builders and AI tool learners, this is a chance to connect with local communities and get hands-on with the latest Google technologies.

Why Agentic AI Changes the Conversation

Agentic AI is shifting how we think about software. Instead of writing code that follows fixed rules, we’re building systems that can plan, act, and adapt. This requires new patterns for orchestration and trust. As I wrote earlier, execution models decide how much your orchestrator can be trusted. DevFest events are designed to help developers navigate these changes with practical sessions and peer learning.

What to Expect at DevFest 2026

According to the Google announcement, DevFest 2026 includes more than 800 events worldwide. The supplied RSS summary does not specify exact dates, locations, or session formats, but the theme is clear: building, securing, and scaling in the agentic AI era. This suggests content will cover agent frameworks, security best practices, and deployment at scale.

How to Get Involved

If you’re a product builder or learning AI tools, find a local DevFest event. These community gatherings are often free or low-cost and provide direct access to Google experts and fellow developers. The announcement encourages connecting with one of the global events, but the supplied RSS summary does not specify a registration link or process. Check the official Google blog or developer community sites for details.

A Practical Next Step

Don’t wait for the perfect agenda. Look up DevFest events in your region and mark your calendar. Even if you can’t attend in person, many communities share recordings or summaries afterward. The agentic AI shift is happening now, and these events are a low-friction way to stay current.

Sources

DevFest is back

把電子郵件拆成三十個小模型：Fyxer 如何讓 AI 助理值得信賴

Mon, 14 Sep 2026 00:00:00 GMT

把電子郵件拆成三十個小模型：Fyxer 如何讓 AI 助理值得信賴

多數專業人士的日常工作，就是同時追蹤信箱、會議、訊息和應用程式裡的對話與承諾。一旦脈絡斷掉，承諾就會漏接，專案和人際關係跟著受損。Fyxer 想解決的正是這個問題：打造一個能跨工具追蹤脈絡的 AI 行政助理，而且讓人願意信任它。

Fyxer 的系統結合了最新的 OpenAI 模型，以及超過 50 萬小時的行政助理工作流程資料，把工作拆給數十個專門模型，再透過真實使用者回饋持續改進。這套做法對產品開發者很有參考價值，因為它示範了如何把一個看似單純的任務，拆解成可訓練、可評估、可迭代的系統。

郵件不是一個任務，是一串預測

Fyxer 共同創辦人 Archie Hollingsworth 用 Moravec 悖論解釋這個挑戰：人類覺得容易的事，對電腦反而困難。同一封郵件，兩個人可能需要完全不同的回覆，取決於關係、過去發生過什麼，以及各自想達成什麼。

Fyxer 的解法不是叫一個大模型寫出好郵件，而是把流程拆成 30 到 50 個專門模型，每個模型只負責一小塊工作。當新郵件進來，一個「回覆決策模型」先分類：這封信需要回覆、需要排程，還是只需要讓使用者知道？如果需要回覆，其他模型接著分析郵件意圖、預測互動可能的結果，例如對話是否走向安排會議、解決請求，或延續一段長期關係。

記憶是整套系統的關鍵。Fyxer 必須決定哪些細節要跨對話保留，哪些在單次交流後就該消失。新郵件到達時，檢索模型會比對過去的互動，找出與這個人和這條對話最相關的記憶。OpenAI 模型負責從理解郵件內容、拉取並重新排序脈絡，到實際生成草稿的各個步驟。

從真人助理的判斷裡學

在推出 AI 產品之前，Fyxer 經營了好幾年真人行政助理服務，累積了超過 50 萬小時的標註工作流程資料。這些資料捕捉了優秀助理的細微判斷：什麼時候該快速回覆、什麼時候該等、哪段先前對話重要、同一個請求為什麼對不同人要有不同回應。

Fyxer 用監督式微調和 LoRA 在整個系統上建立任務專屬的模型變體，同時控制訓練成本。產品早期，團隊用 OpenAI 的微調平台處理需要高準確度的任務；後來則與 OpenAI 的 managed fine-tuning 團隊合作，把新的 checkpoint 推上生產。

任何模型部署前，Fyxer 都會在自家郵件任務的驗證集上評估，包括草稿、分類和優先排序。團隊同時權衡準確度、回應時間和成本，因為最佳選擇會因任務而異。

把使用者的編輯變成訓練訊號

模型上線後，Fyxer 靠真實使用者回饋繼續進步。當有人編輯草稿才送出，原始版本和最終版本的差異就顯示了使用者偏好哪種輸出。

Fyxer 用 Direct Preference Optimization (DPO) 把這些比較轉成訓練資料，不必手動標註每個例子，模型直接從成對輸出中學習：原始草稿和使用者編輯後的版本。每次草稿修改都會經過 A/B 測試，只有當新版本產生統計顯著的改善時才上線。以 Fyxer 的使用者量，有時一天內就能達到這個門檻。

目前 53% 的 AI 生成草稿被原樣接受，代表系統在真實對話中正確預測了意圖和語氣。2025 年，Fyxer 的年度經常性收入從 100 萬美元成長到 3,200 萬美元。但 Hollingsworth 認為更強的訊號是留存率：超過 90% 的使用者在第 90 天仍持續付費且每天使用。

對產品開發者的啟示

Fyxer 的做法呼應了我們先前討論過的流程編排取捨：先決定誰能做決定，再談工具。把郵件拆成小模型，本質上就是把決策權分散到可各自評估、各自微調的單元，而不是仰賴一個黑箱。

對正在打造高度脈絡化 AI 產品的團隊來說，Fyxer 提供了三條可參考的路徑：把複雜任務拆成小預測、用真實工作流程的資料訓練、把使用者編輯變成自動化的偏好學習迴圈。這不是什麼神奇架構，而是把產品開發的紀律套用在 AI 系統上。

Fyxer 的下一步是從草稿助理走向更主動的助理，管理更多溝通與協調工作。Hollingsworth 的願景是讓客戶不必打開電腦，就能信任 Fyxer 處理一切。這需要更豐富的關係、偏好和工作脈絡理解，也是信任能否延續的關鍵考驗。

參考來源

How Fyxer built an AI executive assistant people trust

What Fyxer's 53% Draft Acceptance Rate Changes for How You Build Trustworthy AI Assistants

Mon, 14 Sep 2026 00:00:00 GMT

What Fyxer's 53% Draft Acceptance Rate Changes for How You Build Trustworthy AI Assistants

Fyxer built an AI executive assistant that people actually trust—53% of its AI-generated email drafts are accepted as written. That number matters because email is deceptively hard: the same message can need completely different replies depending on the relationship, history, and goal. Fyxer’s approach shows what it takes to make an AI system feel like an assistant who already knows what matters.

Why one big model isn’t enough

Instead of treating email as a single text-generation task, Fyxer breaks it into 30–50 specialized models, each handling a narrow job. A reply-decision model classifies whether a message needs a response, a scheduling action, or just visibility. Intent and outcome models predict where the conversation is heading. Retrieval models pull relevant memories from past interactions.

“Breaking the problem into many smaller models works much better than asking one model to write a good email,” explains Fyxer co-founder Archie Hollingsworth. This mirrors a pattern we’ve explored before: execution models decide how much your orchestrator can be trusted. When each step is a focused prediction, you can evaluate and improve it independently.

Training data from real assistant work

Fyxer didn’t start with a blank slate. Before launching the AI product, the company ran a human-powered executive assistant service for years. That generated a dataset of more than 500,000 hours of annotated workflows—real examples of how professional assistants manage communication.

Those examples capture the small judgments behind a good response: when to answer quickly, when to wait, which earlier conversation matters. Fyxer uses supervised fine-tuning and Low-Rank Adaptation (LoRA) to create task-specific model variants while controlling training cost. OpenAI’s fine-tuning platform and managed fine-tuning team helped transfer that customer-specific learning into production models.

Turning user edits into a self-training loop

When someone edits a draft before sending it, the difference between the original and final email shows which output they preferred. Fyxer converts those comparisons into training data using Direct Preference Optimization (DPO). The model learns from pairs of outputs: the original draft and the user-edited version.

Every drafting change then goes through an A/B test. Fyxer ships the new version only when it produces a statistically significant improvement. With enough user volume, the team can sometimes reach that threshold within a day.

What the metrics actually tell you

Fyxer grew from $1 million to $32 million in annual recurring revenue in 2025. But Hollingsworth points to a different signal: “Over 90% of our users are still paying at the 90-day mark with us, and still using us every day.” Retention matters more than ARR because it shows the assistant is genuinely useful, not just sold.

The 53% draft acceptance rate is a strong baseline, but it also means nearly half of drafts still get edited. That’s not a failure—it’s the feedback loop working. Each edit becomes training data for the next iteration.

Fyxer’s vision is to get customers to a place where they never have to open their computer and can trust the assistant to manage all of it. That’s a long way off, but the path is clear: break the problem into specialized models, train on real workflows, and let user behavior drive continuous improvement.

Sources

How Fyxer built an AI executive assistant people trust

把銀行 API 上線流程拆成七個專責代理：Ninth Wave 在 Amazon Bedrock 上的多代理設計

Mon, 14 Sep 2026 00:00:00 GMT

把銀行 API 上線流程拆成七個專責代理：Ninth Wave 在 Amazon Bedrock 上的多代理設計

開放金融的整合瓶頸不在模型能力，而在每個銀行的 API 都有自己的欄位名稱、格式慣例，以及與 FDX 標準之間的落差。Ninth Wave 原本需要數週的人工驗證與對應，現在透過 Compass 這個 AI onboarding 助理，把流程變成一個多代理協作系統。

為什麼選擇多代理而不是單一 RAG

Ninth Wave 評估過三種做法：在 EC2 上自架模型、單一代理加 RAG、以及多代理架構。自架模型控制力最高但維運成本也高；單一代理較簡單，但在對應、分析、搜尋與互動問答等不同任務之間，準確度會互相稀釋。

多代理架構的前期複雜度較高，但每個代理只專注一種任務，有自己的 context 與指令。團隊在 AWS Machine Learning Blog 的文章中指出，這樣「沒有 prompt space 的競爭，準確度會隨著任務類型數量而擴展」。

實際的執行環境是 Amazon Bedrock AgentCore，負責託管與擴展這些代理；而 Strands Agents 框架處理意圖分類與路由。

三個關鍵設計決策

架構的核心是三個決策：

意圖路由：orchestrator 只分類一次，就把請求送給對應的專責代理。每個代理的 context window 保持乾淨，輸出也比較可預測。
依任務選模型：輕量模型處理高頻率任務，高推理模型處理對應、分析與互動問答。團隊是「把模型能力對齊任務複雜度，而不是把所有東西都丟給同一個模型」。
租戶範圍的 grounding：在呼叫代理之前，應用程式會先組裝該銀行自己的 context 到請求裡。這樣可以控制每個代理看到什麼，避免一家銀行的資料進入另一家銀行的 session。

七個專責代理與一個例外

Compass 的 Primary Agent 會把請求路由到七個 specialist：搜尋、文件問答、文件分類、欄位對應、分析、互動工作流程，以及 readiness 分析。

其中只有 readiness 分析會使用 Amazon Bedrock Knowledge Bases 做 RAG。這是刻意的範圍決策：其他代理完全在應用層做 grounding，讓團隊對檢索邏輯與排序有完整控制權。Readiness 分析需要綜合大量 FDX 參考文件，無法放進單一請求，所以 RAG 是那個特定代理的正確模式。

FDX readiness 分數則是在應用程式碼中，根據 OpenSearch 裡的必填欄位覆蓋率做確定性計算，而不是由模型估計。這種做法能滿足稽核要求，機率性的模型輸出做不到。

租戶隔離與可觀測性

因為 Compass 同時服務外部銀行開發者與內部使用者，每個請求在進入應用邏輯之前，都必須先限定到單一租戶。AWS WAF 提供邊緣層防護，應用程式授權則把每家銀行限制在自己的 onboarding workspace。

在可觀測性方面，ECS 會把每個代理的指標（呼叫次數、token 用量、延遲、成本）送到 CloudWatch，再觸發 SNS 警報並饋入 Grafana 儀表板。以代理為維度做指標，團隊可以在個別代理層級偵測回歸，而不是等到整個系統出問題才發現。

這種把 AI 工作負載與應用工作負載分離到不同 AWS 帳戶的做法，也呼應了我們先前討論過的流程編排執行模型：先決定誰能做決定，再談工具。Ninth Wave 在這裡的決定是，讓 orchestrator 只做分類，讓每個 specialist 在自己的範圍內做決定。

對產品建置者的啟示

Ninth Wave 的案例有幾個值得參考的取捨：多代理的複雜度換來的是每個任務的準確度與可維護性；租戶範圍的 grounding 是合規要求下的必要設計；而確定性評分則是把模型輸出與稽核需求分開處理。

如果你正在規劃一個需要處理多種任務、且對資料隔離有嚴格要求的 AI 產品，可以考慮把「每個代理只做一件事」當成預設架構，而不是等到 prompt 互相干擾之後再重構。

參考來源

How Ninth Wave built AI-powered open finance onboarding on Amazon Bedrock

What a Multi-Agent Onboarding Assistant Changes for Open Finance Integration

Mon, 14 Sep 2026 00:00:00 GMT

What a Multi-Agent Onboarding Assistant Changes for Open Finance Integration

Open finance onboarding is a grind of field mapping, API validation, and readiness scoring. Banks expose APIs with their own naming and gaps relative to the FDX standard, so every integration means weeks of specialist work. Ninth Wave built Compass, an AI assistant on Amazon Bedrock AgentCore, to turn that into a self-service portal where bank engineers and fintech partners collaborate in a shared workspace.

Why a single agent wasn’t enough

The team evaluated self-hosted models on EC2 and a single-agent RAG pattern. Self-hosting gave control but added overhead; a single agent was simpler but less accurate across mapping, analysis, search, and Q&A. The multi-agent route is more complex upfront, but each specialist keeps its own context and prompt. No competing for token space, and accuracy scales with task types.

Three design decisions matter here. Intent-based routing classifies once and sends the request to the right specialist. Per-task model selection matches lightweight models to high-volume tasks and higher-reasoning models to mapping and analysis. Tenant-scoped grounding assembles each bank’s own context before an agent runs, so one bank’s data never leaks into another’s session.

The architecture in practice

Compass runs seven specialist agents behind a primary orchestrator built on the Strands Agents framework. Search ranks portal docs, documentation Q&A answers grounded questions, document classification sorts uploads, field mapping aligns FDX fields to the bank’s API, analysis flags drift and formatting gaps, interactive workflows drive guided onboarding, and readiness analysis composes narratives using Amazon Bedrock Knowledge Bases.

Only readiness analysis uses RAG retrieval. The other six agents are grounded at the application layer, which gives the team full control over retrieval logic and ranking. Readiness analysis needs to synthesize across a corpus of FDX reference documents too large for a single request, so RAG fits there specifically.

The readiness score itself is computed deterministically in application code from field mapping coverage, not estimated by a model. That satisfies audit requirements in a way a probabilistic output cannot.

Security and observability as first-class concerns

Compass serves external bank developers and internal users on the same application, so every request is scoped to a single tenant before it reaches logic. Traffic passes through CloudFront and AWS WAF, then an internal load balancer. ECS on Fargate validates sessions against an OAuth2/OIDC provider with MFA, and the tenant identity flows downstream to scope every data query.

AI workloads run in a separate AWS account via a cross-account IAM role, which contains blast radius. Per-agent metrics go to CloudWatch, with alerts through SNS and dashboards in Managed Grafana. Dimensioning by agent lets the team spot regressions at the individual agent level rather than only system-wide.

What this means for builders

The pattern here is not “add an AI chatbot to onboarding.” It’s a deliberate split: deterministic scoring for auditability, RAG only where a corpus is too large to pass inline, and tenant-scoped grounding as a hard boundary. That’s a useful template for any regulated workflow where multiple parties share model infrastructure.

For teams thinking about agent orchestration, the tradeoff is real. Multi-agent systems cost more to build and operate than a single RAG endpoint. But when task types have different accuracy requirements and context windows are finite, separation pays off. The same logic applies to execution models for process orchestration: how much you can trust the orchestrator depends on how cleanly you’ve bounded what each component does.

The five-sprint delivery shows this doesn’t have to be a big-bang rewrite. Foundations first, then portal and automation, then agent integration, then hardening, then production rollout. Each phase built on the last without waiting for a perfect architecture.

Sources

How Ninth Wave built AI-powered open finance onboarding on Amazon Bedrock

把模型參數移出程式碼：用 OpenRouter Presets 管理 LLM 設定

Mon, 14 Sep 2026 00:00:00 GMT

把模型參數移出程式碼：用 OpenRouter Presets 管理 LLM 設定

你已經在網頁應用、批次腳本和筆記本裡重複貼上相同的模型名稱、系統提示詞和 temperature。現在想調整其中一個參數，就得同時改三個地方。OpenRouter 的 Presets 就是為了解決這個問題而設計的：把 LLM 呼叫的設定當成程式碼來管理，定義一次，處處引用。

什麼是 Preset？

Preset 是一個具名、有版本的設定檔，裡面儲存了模型選擇（單一模型或 fallback 陣列）、系統提示詞、provider 路由偏好、取樣參數（如 temperature、top_p），以及工具（包括 OpenRouter 的 server tools，例如網頁搜尋、圖片生成、advisors 和 subagents）。

你可以把它想成 .env 檔或 Terraform module：設定獨立於應用程式邏輯之外，用名稱參照，而不是複製進程式碼。差別在於存放位置和誰能修改。.env 檔跟著 repo 走，更新需要重新部署；Preset 存放在 OpenRouter dashboard，修改後立即套用到所有參照它的應用。

建立第一個 Preset

在 openrouter.ai/settings/presets 建立 Preset，選一個好記的 slug，之後在 API 請求中用 @preset/your-slug 參照。接著設定模型與路由：可以選單一模型，或加入有序的 fallback 清單，當第一個模型因 rate limit、outage 或 context 過長而失敗時，自動嘗試下一個。Provider 路由也能在此設定，例如依價格或延遲排序，或封鎖特定 provider。

加上系統提示詞與取樣參數後，這些就成為每個使用該 Preset 的請求的預設值。在 API 呼叫中，只要把 model 欄位設為 Preset slug 即可：

resp = client.chat.send(
    model="@preset/tech-writer",
    messages=[
        {"role": "user", "content": "Explain preset versioning."},
    ],
)

你也可以透過 API 建立 Preset，用 POST 請求到 preset endpoint，系統會儲存屬於 Preset 設定的欄位，忽略 messages、stream、prompt 等 transient 欄位。

覆寫與合併規則

每個請求都可以覆寫 Preset 的設定。如果請求 body 包含 temperature，該值會覆蓋 Preset 的值。合併是 shallow 的：請求欄位取代對應的 Preset 欄位，未指定的 Preset 欄位則保留。tools 是例外：Preset 的工具與請求的工具會合併，若名稱相同，請求的工具會取代 Preset 的工具。

你也可以用獨立的 preset 欄位（"preset": "@preset/tech-writer"）或合併形式（"model": "anthropic/claude-opus-4.8@preset/tech-writer"）。preset 欄位需要完整的 @preset/ 前綴，單獨的 slug 會被忽略。

實際應用：圖片提示詞增強與 Fusion 面板

Preset 不只是簡化參數管理，也能封裝較複雜的工作流程。例如，圖片模型通常需要詳細的提示詞才能產出好結果。你可以建立一個 Preset，內含一個文字模型、一段系統提示詞（將簡短請求擴展為包含主體、構圖、光線、色調和風格的完整視覺 brief），以及圖片生成工具。之後只要用 @preset/image-enhancer，所有應用都能享有相同的提示詞增強行為。

另一個例子是把 Fusion 設定釘選成 Preset。Fusion 會執行一個模型面板，讓主要模型參考面板的輸出撰寫最終答案。將整個設定（包括 openrouter:fusion 工具、analysis_models 面板和 analyst model）存入 Preset 的 tools，然後在任何地方用 @preset/fusion-panel 參照。你的網頁應用、評估工具和 Slack bot 都使用相同的面板，調整時只需在 dashboard 修改，不必編輯三個 codebase。這也讓 ML 工程師能用同一個穩定 slug 重複執行評估設定。

版本管理與團隊協作

每次用現有 slug 儲存 Preset，系統會建立新版本並設為 active。API 請求會使用 active 版本。在 dashboard 修改系統提示詞，所有使用該 slug 的應用在下一次請求時就會套用變更，無需重新部署。如果變更造成品質下降，可以在 dashboard 還原到較早版本。

對團隊而言，Preset 提供一個有版本的集中位置來管理模型選擇、路由和提示詞，取代散落在多個 repo 的常數。組織帳號的所有成員都能存取組織 Preset，方便分享最佳實務。

限制與注意事項

Preset 不改變 rate limit，每個模型的限制仍然適用。API 沒有全域預設 Preset，每個請求都必須明確指定 Preset。Chatroom 則有 Default Preset 設定，套用於新訊息。

如果你正在思考如何把設定從程式碼中抽離，Preset 是一個值得嘗試的方向。它與我們之前討論過的流程編排執行模型有相似的精神：把決策點從程式碼中拉出來，讓非工程角色也能調整行為，同時保持可追溯性。

建立第一個 Preset 後，可以參考 preset-enhanced images cookbook 進一步了解圖片生成的完整流程。

參考來源

How to Use OpenRouter Presets: Config-as-Code Guide — OpenRouter Blog

Config-as-Code for LLM Calls: What OpenRouter Presets Change About Shipping

Mon, 14 Sep 2026 00:00:00 GMT

Config-as-Code for LLM Calls: What OpenRouter Presets Change About Shipping

If you’ve copied the same model name, system prompt, and temperature into a web app, a batch script, and a notebook, you know the pain: change one parameter and you’re editing three places. OpenRouter’s presets address this by treating your LLM configuration as a named, versioned artifact that lives outside your application code.

What a preset actually stores

A preset bundles model selection (one model or an ordered fallback list), a system prompt, provider routing rules, sampling parameters like temperature and top_p, and tools such as web search or image generation. You reference it in any API request with "model": "@preset/your-preset-name". The config lives in the OpenRouter dashboard, not in your repo, so updating it doesn’t require a redeploy.

This is different from a .env file or a Terraform module in one key way: those still ship with your code and need a new build to change. A preset is stored server-side, so every app that references the slug picks up the new version on its next request.

Creating and using a preset

Start at openrouter.ai/settings/presets, pick a memorable slug, and configure your model, routing, prompt, and sampling settings. Then replace a verbose request body with a single reference:

resp = client.chat.send(
    model = "@preset/tech-writer",
    messages = [
        { "role": "user", "content": "Explain preset versioning." },
    ],
)

You can still override any field per request—request values win over preset values, and tools are merged rather than replaced. There’s no global default preset for the API; every request must name one explicitly.

Two patterns worth copying

Image prompt enhancement. Pair a text model with the image-generation tool inside a preset. The text model expands a short user prompt into a detailed visual brief covering subject, composition, lighting, palette, and style, then calls the image tool automatically. Every app using @preset/image-enhancer gets the same behavior without duplicating the system prompt or tool configuration.

Pinning a Fusion panel. If you run a Fusion setup—a panel of models alongside a primary model that writes the final answer—store the entire configuration in a preset’s tools. Your web app, evaluation scripts, and Slack bot all reference @preset/fusion-panel. Adjust the panel in the dashboard instead of editing three codebases. This also gives ML engineers a repeatable evaluation config under one stable slug.

Who benefits from this shift

Presets move configuration ownership from “anyone who can ship code” to “anyone with dashboard access.” A product manager can change a system prompt or swap a model without asking an engineer to edit code or trigger a deploy. For larger teams, a preset becomes the single versioned place for model choices, routing, and prompts—replacing constants scattered across repos.

This aligns with a broader pattern we’ve explored before: execution models decide how much your orchestrator can be trusted. Presets don’t change what your models can do, but they change how reliably you can reproduce and update the configuration that drives them.

The tradeoff to watch

Versioning is built in: saving an existing slug creates a new active version, and you can restore an earlier one if a change hurts quality. But there’s no API-level default preset, so every integration must name its preset explicitly. That’s a feature for explicitness, but it means you need discipline to use the same slug everywhere rather than hardcoding parameters in some places and referencing presets in others.

Start with one preset for your most repeated configuration—a system prompt plus model and temperature you use across multiple tools. Then see how much of your request body you can delete.

Sources

How to Use OpenRouter Presets: Config-as-Code Guide — OpenRouter Blog

當模型開始替你的系統做測試：Perplexity 把 GPT‑6 Astra 放進端到端流程

Mon, 14 Sep 2026 00:00:00 GMT

當模型開始替你的系統做測試：Perplexity 把 GPT‑6 Astra 放進端到端流程

Perplexity 共同創辦人兼首席策略官 Johnny Ho 在 OpenAI 於 2026 年 9 月 14 日發布的客戶案例中，描述了一個不少團隊都遇過的瓶頸：搜尋品質可以靠更好的模型持續改善，但要把這些能力接到真實系統上，難度是另一個層級。他的說法是，GPT‑6 Astra 讓他們能讓模型撰寫對外溝通內容、修改實際運作中的系統，並監控正式環境的軟體，這是前幾代模型做不到的事。

測試工作先被交出去

在 Ho 的用法裡，最實用的一塊是測試程式碼。他提到自己手動測試的時間有限，因此會請 GPT‑6 Astra 圍繞某個應用寫一個小型測試程式。

關鍵在於模型能產生逼真的回應，模擬另一個服務會送出的內容，例如語言模型 API 或某個 connector。由模型代替這些服務之後，就能觀察應用怎麼反應，並把整條 workflow 從頭到尾跑一遍。

這裡的訊號不是「模型會寫測試」這麼簡單，而是它被允許扮演系統邊界上的對手。對產品團隊來說，這正好對應到一個常見痛點：整合測試最貴的部分往往不是斷言，而是把外部依賴準備好。

信任的單位從單次輸出變成整條流程

Ho 的另一句話更值得注意：他們現在能把完整端到端系統交給模型負責，檢查的頻率比前幾代模型低很多。

這句話的份量在於「檢查頻率」。如果一個模型每次產出都要人逐行看過，它省下的只是打字時間；只有當團隊願意拉長檢查間隔，自動化才真的改變人力配置。案例把這個轉折歸因於 GPT‑6 Astra 的能力，而不是流程重新設計。

不過，案例沒有說明 Perplexity 用什麼方式界定可接受的檢查間隔，也沒有交代失敗時的回復流程。這些細節在提供的來源中並未出現，因此不應自行補上。

對正在導入 agent 的團隊意味著什麼

把這段經驗放回一般產品開發情境，有兩個可以立刻檢查的地方。

第一，你的 agent 有沒有被授權去「模擬別人」？很多團隊只讓模型產生程式碼，卻沒有讓它扮演外部服務、產生假回應來驗證流程。少了這一層，測試覆蓋率看起來很高，實際上邊界條件仍然空白。

第二，你怎麼定義「檢查頻率」？這其實是風險分級的題目。哪些系統改動可以低頻檢查，哪些必須每次人工確認，取決於改動的爆炸半徑，而不是模型當下的表現。先前我們在流程編排的三種執行模型談過，先決定誰能做決定，再談工具；同樣的順序在這裡也適用，只是這次被授權的對象換成了模型。

案例沒有回答的部分

這是一份客戶案例，不是技術白皮書。它沒有提供測試程式的實際結構、監控正式系統的具體做法，也沒有量化「檢查頻率降低」到底降了多少。Ho 的敘述是 Perplexity 自身經驗的轉述，不是可重複的實驗結果。

對正在評估類似做法的團隊，務實的下一步不是照抄，而是先挑一條邊界清楚、失敗成本可控的流程，讓模型同時負責產生模擬服務與驗證回應，並記錄人工介入的次數。等這個數字穩定下降，再考慮擴大授權範圍。

參考來源

Perplexity trusts GPT-6 Astra with end-to-end systems

What It Takes to Hand an Agent the Whole System

Mon, 14 Sep 2026 00:00:00 GMT

What It Takes to Hand an Agent the Whole System

The hard part of agent adoption was never getting a model to write a function. It is deciding how much of a live system you let it touch before someone has to look over its shoulder. Perplexity’s account of working with GPT-6 Astra is a useful data point on where that line is moving.

What Perplexity actually reports

In an OpenAI customer story published September 14, 2026, Perplexity cofounder and Chief Strategy Officer Johnny Ho describes using Astra to write communications, edit real-world systems, and monitor production software. He contrasts this with earlier generations, which he says could not operate at that level.

The most concrete example is testing. Ho says he asks Astra to build a small testing program around an application, generating realistic responses that stand in for another service, such as a language model API or a connector. The model then checks how the application responds and exercises the workflow end to end.

His summary of the shift: “We’re actually able to trust it with full end-to-end systems and check in on it much less frequently than previous generations of models.”

That is the whole claim. The supplied material does not include accuracy numbers, error rates, rollback procedures, or which systems are in scope. Treat it as a directional signal from one team, not a benchmark.

The testing detail is the interesting one

Most agent demos show the model producing output. This one shows the model producing the conditions under which output gets judged. Standing in for a downstream API means Astra is not just writing code, it is fabricating the environment that code runs against.

That is genuinely useful when manual testing time is the bottleneck, which Ho names as his constraint. It is also where the risk concentrates. A test double that the same model writes and then validates against is a closed loop. If the simulated connector drifts from the real one, the workflow passes and production fails.

Builders who copy this pattern should keep the simulation and the assertion separate. Let the model generate the fake service, but pin the expected behavior to something the model did not author, such as a recorded response or a contract test. Otherwise the check-in reduction is real but the coverage is not.

Why less frequent check-ins is a design decision

The quote that matters for planning is the one about checking in less often. That is not a model capability, it is a supervision budget. Every reduction in human review has to be paid for somewhere: narrower scope, better observability, or a cheaper way to undo damage.

The supplied material does not specify which of those Perplexity relies on. What it does suggest is that the trust was earned on bounded tasks, like building a test harness, rather than granted wholesale. Ho’s framing is about applying informational strengths to real-world systems, and the example he picks is a contained one.

This is the same question that shows up whenever an assistant is given real authority over a workflow. The Fyxer draft acceptance analysis makes a similar point from a different angle: acceptance rates and check-in frequency are the metrics that tell you whether trust is warranted, not the model’s benchmark scores.

A practical way to read this

If you are deciding how much autonomy to grant, the Perplexity example points at a sequence rather than a switch. Start where the model can generate its own test conditions and the blast radius is a failing test. Move to editing real systems only after you can see what it changed and reverse it. Monitoring production is the last step, because it is the one where a wrong action is hardest to distinguish from a right one.

None of that is stated in the source. It is the inference I would draw from a team that reports checking in less often on end-to-end systems while giving a testing workflow as its example.

The open question the supplied material leaves is what happens when the model’s simulated service and the real service disagree. That is the failure mode worth instrumenting before you widen scope.

Sources

Perplexity trusts GPT-6 Astra with end-to-end systems

Fable 5.1 的省錢關鍵不是模型，而是你的快取讀取比例

Sun, 13 Sep 2026 00:00:00 GMT

Fable 5.1 的省錢關鍵不是模型，而是你的快取讀取比例

為什麼兩個說法都對，但結論相反？

Anthropic 說 Fable 5.1 比 Fable 5 便宜 25%，有時甚至 45%。Artificial Analysis 卻量出每項任務成本上升 18%。Firecrawl 的 Richard Oliver Bray 在 2026 年 9 月 7 日的文章中，用 57 次 API 計費執行、總花費 26 美元，把這兩個看似矛盾的數字拆開來看。

關鍵在於計費方式。Anthropic 按 token 計費，四種 token 類型中只有一種降價：快取讀取從每百萬 1 美元降到 0.25 美元，降幅 75%。輸入、輸出、快取寫入的價格全部不變。Artificial Analysis 則按「完成一項任務的成本」計算，而 Fable 5.1 在他們的 Intelligence Index 上用了 1.4 億個輸出 token，比 Fable 5 的 8,300 萬多了 69%。輸出 token 是最貴的一種，每百萬 50 美元，所以每項任務成本從 3.14 美元升到 3.69 美元。

兩個數字都對，只是量的東西不同。Anthropic 量的是快取密集的長代理工作，Artificial Analysis 量的是幾乎不用快取的單次任務。你的帳單落在哪一邊，取決於你的工作負載。

快取讀取降價，但快取寫入沒降

Fable 5.1 的價格表只有一行變動：快取讀取從 1 美元降到 0.25 美元。快取寫入維持每百萬 20 美元，是輸入價格的兩倍。這設定了省錢的上限。

Firecrawl 在六個沙箱化的代理建置任務上實際看到帳單差異。一個 Fable 5.1 建置重新讀取 169 萬個快取 token，付了 0.42 美元；一個 Fable 5 建置重新讀取 134 萬個，付了 1.34 美元。省下的錢是帳單的 15% 到 30%，不是 25% 到 45%，因為快取寫入沒有折扣。

快取讀取折扣的效益，取決於同一個 context 被重讀的次數，而不是 context 的大小。如果你建立一個大快取但只讀兩次，幾乎省不到錢。長代理 session 才是這個折扣真正發光的地方。

輸出 token 變多，是隱藏的成本

Firecrawl 的 57 次執行中，Fable 5.1 在每個 effort level 都用掉更多輸出 token。低 effort 是 1.37 倍，高 effort 是 1.12 倍，max effort 是 1.30 倍。

在 max effort 下，多出來的 token 是推理，不是文字。推理 token 從 4,205 增加到 6,725，可見輸出從 3,522 降到 3,301。Fable 5.1 寫了少 6% 的文字，卻多付了 30% 的計費 token。

推理 token 以輸出價格計費，每百萬 50 美元，但它們永遠不會出現在你看到的回覆裡。Fable 5.1 的思考功能永久開啟，無法關閉，budget_tokens 參數會回傳 400 錯誤。你唯一能控制思考量的方式是 effort level。

任務規範的鬆緊，決定哪個模型便宜

Firecrawl 的測試揭露一個雙方都沒量到的變數：你怎麼規範任務。

當任務規範很緊時，Opus 5 在成本上每次都贏。當任務規範很鬆時，Opus 5 平均花 11.83 美元，Fable 5.1 只要 7.00 美元。這表示如果你給模型明確的步驟和限制，Opus 5 可能更划算；如果你丟一個開放式的簡報，Fable 5.1 的穩定性和較低的快取讀取成本會佔優勢。

這呼應了我們之前討論過的模型選擇不該只看每百萬 token 報價。真正的成本是每項成果的成本，而成果的定義取決於你的任務規範。

你該怎麼選？

先看你的帳單結構。如果你的工作負載是長時間的代理 session，重複讀取大量 context，Fable 5.1 的快取讀取折扣會直接反映在帳單上。如果你跑的是單次、快取很少的任務，Fable 5.1 可能因為輸出更多 token 而更貴。

再看你的 effort level。Anthropic 的省錢數字是在預設 effort 下量的，Artificial Analysis 的漲價數字是在 max effort 下量的。Claude Code 預設 High，Claude Cowork 和 Claude.ai 預設 Medium。如果你繼承了某個預設值而沒檢查，成本意外通常來自那裡，不是模型本身。

最後，如果你直接呼叫 API，注意 Fable 5.1 的 API 表面有變動：強制工具使用的行為不同、思考永久開啟、budget_tokens 回傳 400 錯誤。如果你透過 Claude Code 或託管產品建置，這些變動由 harness 處理。

Fable 5.1 不是全面降價，而是把省錢的槓桿移到快取讀取上。你的工作負載決定這個槓桿對你有沒有用。

參考來源

Fable 5.1 vs Fable 5: Is Fable 5.1 Cheaper Than Fable 5? We Measured 57 Runs

Fable 5.1's Cache Discount: Where the Bill Actually Moves

Sun, 13 Sep 2026 00:00:00 GMT

Fable 5.1's Cache Discount: Where the Bill Actually Moves

Anthropic says Fable 5.1 is cheaper than Fable 5, by 25% and sometimes 45%. Artificial Analysis measured it costing 18% more. Both are correct, and the reason is worth understanding before you switch models.

The rate card moved in one place

Fable 5.1 shipped September 1, 2026, less than three months after Fable 5’s June 9 release. It is a tuning pass over the same architecture, so the context window, max output, and headline input and output prices are unchanged. Input stays at $10 per million tokens and output at $50.

The one change is cache reads: $1.00 per million tokens on Fable 5, $0.25 on Fable 5.1. That is a 75% cut. Cache writes still cost $20 per million and are not discounted, which caps how much of the saving reaches your invoice.

If you are already thinking about how provider-side caching interacts with your routing and privacy choices, the same economics apply here: Zero Data Retention: Enforcing Provider-Side Privacy on AI API Calls covers what gets stored and where.

Why two measurements disagree

Firecrawl’s 57-run test on a Claude Team API account, billed at $26.00, found Fable 5.1 used more output tokens at every effort level. Ratios were 1.37x at low, 1.12x at high, and 1.30x at max. At max effort the extra tokens are reasoning, not text: reasoning went from 4,205 to 6,725 while visible output fell from 3,522 to 3,301. Fable 5.1 wrote 6% less text for 30% more billed tokens.

Artificial Analysis prices models by cost per completed task. Fable 5.1 needed 140 million output tokens to finish their Intelligence Index against Fable 5’s 83 million, and their evaluations use almost no caching. Cost per task rose from $3.14 to $3.69.

Anthropic’s figures come from production traffic at default effort, where cache-heavy agent sessions dominate. The two numbers measure different workloads, not different arithmetic.

What the discount looks like on a real bill

On six sandboxed agentic builds, the cache-read cut showed up. One Fable 5.1 build re-read 1.69M cached tokens for $0.42; a Fable 5 build re-read 1.34M and paid $1.34. The saving was 15% to 30% of the bill, not the headline 25% to 45%, because cache writes are charged at full price.

The discount scales with how many times a context gets re-read, not with how large the context is. Build a large cache and read it twice, and almost none of the saving reaches you.

Effort level is the lever most teams forget

Effort levels run from low to max, set with output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}. Artificial Analysis prices Fable 5.1 at $0.77 per task on low and $3.69 on max, a 4.8x range for eight points of Intelligence Index score.

Defaults differ by product. Claude Code defaults to High. Claude Cowork and Claude.ai default to Medium. Anthropic’s savings figures were measured at default effort; Artificial Analysis measured at max. Most cost surprises come from an inherited default, not a model choice.

Reasoning tokens bill at the same $50 per million as visible text and never appear in the response. On Fable 5.1 thinking is permanently enabled, the thinking parameter should be omitted, and budget_tokens is rejected with a 400 error. Skills and a trimmed global CLAUDE.md cut visible output, but neither changes how much the model thinks.

How to decide for your workload

Pull one recent run and compare cache_read_input_tokens against output_tokens in the usage fields the API returns. If cache reads dominate, Fable 5.1 is likely cheaper for you. If output dominates, the extra reasoning tokens will cost more per finished task.

The variable neither party measured is how tightly you specify the task. Tight spec, Opus 5 won on cost every time in the Firecrawl runs. Open brief, Opus 5 averaged $11.83 against Fable 5.1’s $7.00. That suggests the model choice matters less than how much room you leave for the model to think.

One caveat: the benchmark figures cited are vendor-run with production safeguards on, and Anthropic reports a standard error wide enough that any single row inside that band is a wash. Treat the direction as the signal, not the decimal.

Sources

Fable 5.1 vs Fable 5: Is Fable 5.1 Cheaper Than Fable 5? We Measured 57 Runs

把模型快取放進節點：HyperPod 推論冷啟動的實務取捨

Sun, 13 Sep 2026 00:00:00 GMT

把模型快取放進節點：HyperPod 推論冷啟動的實務取捨

冷啟動的痛點：兩段下載拖慢擴容

部署大型語言模型到 Amazon SageMaker HyperPod 時，從請求 Pod 到真正能服務流量之間，有兩段連續下載：先從 Amazon ECR 拉取推論伺服器容器映像，再從 Amazon S3、Amazon FSx for Lustre 或 HuggingFace Hub 下載模型權重。AWS Machine Learning Blog 指出，小模型可能只要幾分鐘，但像 DeepSeek-R1 這種 600 GB 以上的模型，光是權重下載就要 30 分鐘以上。

每次擴容都會重複這個循環。如果 HorizontalPodAutoscaler 因為流量尖峰而新增五個 Pod，這五個 Pod 會各自獨立下載，實際能接流量的時間被網路吞吐量卡住，而不是被排程速度卡住。

模型快取怎麼運作

AWS 在 2026 年 9 月 10 日發表模型快取功能，把權重和容器映像預先載入節點的本地 NVMe 儲存。Pod 啟動時直接從 NVMe 讀取，速度約 7 GB/s，而不是走網路下載。啟用後，Pod 通常可以在數秒內開始服務流量。

模型快取分成兩個獨立能力，可以分開或一起啟用：

權重快取：操作員會建立 ModelDataCacheConfig 資源，把權重從來源下載到所有目標節點的 NVMe。下載完成後，節點會被標記為 cache-ready，操作員會等到所有目標節點都準備好才建立推論部署。快取在 Pod 重啟後仍然保留，擴容時若新 Pod 落在已有快取的節點上，就能立即啟動。

映像快取：操作員建立 DaemonSet，把推論伺服器容器映像預先拉到所有目標節點。與權重快取不同，映像快取不會阻擋部署建立；Pod 啟動時若映像已快取，就跳過 ECR 拉取，省下 5 到 7 分鐘。多個部署若使用相同映像，會共用一份映像快取，操作員會追蹤引用，直到沒有部署引用時才清理。

兩種快取都採用「偏好排程」而非「強制排程」。Pod 會優先落在有快取的節點，但不會被卡住；若落在沒有暖快取的節點，就退回原本的下載流程，行為與未啟用快取時相同。

啟用方式與支援範圍

啟用模型快取很簡單：在既有的 InferenceEndpointConfig 或 JumpStartModel 資源中加入 modelCacheConfig 區段，不需要額外基礎設施。以下是一個 InferenceEndpointConfig 範例：

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: example-model
  namespace: default
spec:
  modelName: example-model
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: example-bucket
      region: us-west-2
      modelLocation: "models/example-model"
  modelCacheConfig:
    weightsCache:
      enabled: true
    imageCache:
      enabled: true
  instanceType: ml.g5.24xlarge
  worker:
    image: vllm/vllm-openai:latest
    modelInvocationPort:
      containerPort: 8000
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model
    resources:
      limits:
        nvidia.com/gpu: "4"

模型快取支援所有 HyperPod Inference 支援的模型來源，包括 Amazon S3、Amazon FSx for Lustre、HuggingFace Hub，以及 Amazon SageMaker JumpStart（含 gated 模型）。

效能數據與限制

AWS 的基準測試顯示，在 57 到 145 GB 的模型上，啟用權重快取後擴容速度快約 60%。映像快取可以移除超過兩分鐘的冷映像拉取時間，相較於每次 Pod 啟動都從 ECR 重新拉取，最高可減少 97%。模型越大，效益越明顯，因為省下的下載量更多。

不過有幾個限制要留意：

權重快取是每個節點一份，NVMe 消耗會隨節點數線性成長。
第一次啟用快取時，仍需從遠端來源下載一次，之後才從本地讀取。
NVMe 容量有限，模型大小不能超過執行個體的 NVMe 容量。例如 ml.g5.xlarge 只有 250 GB，放不下 300 GB 的模型。
來源更新不會自動偵測。如果你在相同的 Amazon S3 路徑更新權重檔，但沒有改 InferenceEndpointConfig spec，操作員會繼續服務快取版本。要取得新權重，必須更新 spec（例如改路徑或加版本後綴）。

對產品建置者的意義

模型快取解決的是推論擴容的「最後一哩」延遲。過去，即使 autoscaler 在幾秒內做出反應，實際能接流量的時間仍被下載卡住。現在把權重和映像預載到節點，讓擴容從「等網路」變成「等排程」。這對需要快速回應流量尖峰的產品特別有用，例如即時對話或批次推論服務。

如果你正在評估 SageMaker HyperPod 的推論部署，可以參考前綴感知路由：讓 KV cache 不再被隨機打散，那篇文章討論了另一個降低推論延遲的機制。兩者可以互補：模型快取處理冷啟動，前綴感知路由處理熱啟動時的 cache 效率。

實際採用前，建議先確認執行個體的 NVMe 容量是否足夠容納模型權重，並規劃好權重更新流程，避免快取造成版本不一致。

參考來源

Reduce inference cold starts on Amazon SageMaker HyperPod with model caching

Model Caching on HyperPod: What Changes When Weights Live on the Node

Sun, 13 Sep 2026 00:00:00 GMT

Model Caching on HyperPod: What Changes When Weights Live on the Node

An inference pod on Amazon SageMaker HyperPod doesn’t serve traffic the moment the scheduler places it. Two sequential downloads sit in front of it: the inference server container image from Amazon ECR, and the model weights from S3, FSx for Lustre, or HuggingFace Hub. The AWS Machine Learning Blog puts numbers on it — 5–7 minutes for a vLLM or LMI image, another 20+ minutes for a 145 GB model on S3, and upwards of 30 minutes for something like DeepSeek-R1 at 600+ GB.

The part that hurts isn’t the first deploy. It’s scale-out. If a HorizontalPodAutoscaler asks for five new pods during a traffic spike, all five repeat the same download sequence independently. The autoscaler reacts in seconds; the capacity arrives 25–30 minutes later. Your scaling policy and your actual serving capacity are running on different clocks.

Two caches, enabled separately

Model caching, launched September 10, 2026, pre-loads data onto nodes before pods are scheduled. It splits into two independent capabilities you can turn on together or alone.

The weights cache downloads model weights to local NVMe on each target node ahead of time. The HyperPod Inference Operator creates a ModelDataCacheConfig resource, downloads from your configured source, labels each node cache-ready when its download finishes, and waits for all target nodes before creating the inference deployment. Pods then read locally at roughly 7 GB/s. The cache survives pod restarts on the same node.

The image cache pre-pulls the container image via a DaemonSet. Unlike the weights cache, it does not block deployment creation — a pod that starts before the pull completes just pulls from ECR as usual. Multiple deployments sharing one image share a single cache resource, and the operator only cleans it up when nothing references it.

Fallback is preferred, not required

Both caches use preferred scheduling. Pods prefer warm nodes but are never blocked from starting on a cold one. During rapid scale-out past the number of cached nodes, the pod falls back to the original S3 or FSx source and a normal ECR pull. No failure, no intervention — just the download time you had before.

That design choice matters more than the benchmark numbers. It means enabling caching can’t make a deployment less reliable than it already was.

What the benchmarks actually claim

Across models from 57–145 GB, AWS reports around 60 percent faster scale-out with weights caching. The image cache removes over two minutes of cold pull time, described as up to a 97 percent reduction versus pulling fresh from ECR on every pod start. The benefit scales with model size, since there’s proportionally more data to move.

Treat these as vendor benchmarks on unspecified hardware and network conditions. The direction is credible — local NVMe beats network reads — but your own numbers will depend on instance type, storage backend, and how much of your traffic is genuinely bursty.

The constraints that decide your instance type

Weights caching is per-node. Every node keeps its own copy, so NVMe consumption scales with node count, not model count. If your model is 300 GB and your instance has 250 GB of NVMe, caching simply won’t work. AWS lists ml.g5.xlarge at 250 GB up to ml.p5.48xlarge at 30,000 GB, so the sizing question comes before the config question.

Two more limits worth planning around. The first cache population still pays the full remote download once. And source updates aren’t auto-detected: if you overwrite model files at the same S3 path without changing the spec, the operator keeps serving the cached version. You need to change the model path or add a version suffix to pick up new weights.

Where this fits next to routing work

Caching solves the cold-node problem. It doesn’t solve the warm-node problem — what happens when several pods are already serving and a request lands on the one holding the wrong KV cache. That’s a separate lever, and we looked at it in prefix-aware routing on SageMaker. The two compose: caching gets capacity online faster, routing decides which online capacity handles a given prompt.

Enabling it is a modelCacheConfig block on an existing InferenceEndpointConfig or JumpStartModel resource — no extra infrastructure. Before you flip it on, check NVMe headroom against your largest model and confirm you have a versioning habit for weight updates. Otherwise you’ll cache something and quietly keep serving it.

Sources

Reduce inference cold starts on Amazon SageMaker HyperPod with model caching