Posts on KnightLi Blog

Google I/O 2026 Summary: Gemini 3.5, Omni, Antigravity, and System-Level Agents

Thu, 21 May 2026 00:07:06 +0800

The main line of Google I/O 2026 is clear: Google is moving Gemini from “model” and “chat assistant” into a fuller Agent ecosystem. It is not only answering questions. It is entering Search, Android, developer tools, video creation, shopping, Workspace, hardware, and enterprise platforms to help users complete longer task chains.

This article summarizes the main Google I/O 2026 announcements from official releases and a developer perspective. For real development, always follow the official Google, Android Developers, and Gemini API documentation.

One-Sentence Summary

The keyword for Google I/O 2026 is agentic Gemini era.

Google announced or strengthened several lines:

Gemini 3.5 Flash: speed, action capability, and Agent workflows.
Gemini Omni: creating content from any input, starting with video creation and editing.
Gemini app: moving from chat assistant to proactive, always-on, task-capable personal Agent.
Google Antigravity 2.0: evolving from an AI coding tool into an Agent-first development platform.
Gemini API Managed Agents: creating hosted Agents through APIs that can reason, use tools, and execute code.
Google AI Studio: expanding to mobile, native Android support, and project export to Antigravity.
Search, Shopping, YouTube, Workspace, and Android: all gaining stronger Gemini and Agent capabilities.

In other words, Google is no longer only showing “how smart the model is.” It is showing how models enter products, tools, and systems to actually execute tasks for users.

Gemini 3.5 Flash: From Prompt to Action

Gemini 3.5 is Google’s new model family at I/O 2026, with Gemini 3.5 Flash as the first public focus.

Google does not position it as simply a “faster chat model,” but as a high-speed engine for real Agent workflows. Google’s developer article describes 3.5 Flash as combining frontier intelligence and high speed to support the shift from prompt to action.

Its main significance:

Optimized for Agent and coding scenarios.
Supports longer task chains and tool use.
Available through Antigravity, Gemini API, Google AI Studio, Android Studio, Gemini Enterprise, and other entry points.
Better suited for applications that need fast responses, multi-turn execution, and frequent tool calls.

For developers, Gemini 3.5 Flash is not just another model option. It is one of the default engines for Google’s new Agent toolchain.

Gemini Omni: Video and World-Model Capabilities

Gemini Omni is another core I/O 2026 announcement. Google describes it as creating content from any input, with the current focus starting from video.

Its highlights fall into three areas:

Multimodal input: text, images, video, audio, and more can be used as references.
Video editing: users can modify video over multiple turns with natural language instead of stopping after one generation.
World understanding: it emphasizes consistency in physics, scenes, actions, narrative, and audiovisual output.

This means AI video tools are moving from “enter one prompt to generate a clip” toward “revise step by step as if talking to an editor.” For creators, the real value is not one-shot generation, but a controllable, traceable, and iterative editing process.

Gemini App: From Chat Assistant to Always-On Personal Agent

Google is also pushing Gemini app in a more Agent-like direction. Official posts describe Gemini app as becoming more proactive, offering daily briefs and always-on assistance.

Key points include:

Gemini 3.5 Flash entering Gemini app.
A new UI and more dynamic interaction.
Personal AI Agent concepts such as Gemini Spark.
Proactive daily briefs that organize what users need to know each day.
More emphasis on 24/7 background assistance instead of waiting for the user to start every chat.

This is the part that affects ordinary users most. Gemini used to feel more like a “you ask, I answer” assistant. After I/O 2026, Google wants it to feel more like a personal Agent that follows up on tasks, proactively reminds users, and works across products.

Antigravity 2.0: Developer Tools Become Agent-First

One of the most important developer-side announcements is Google Antigravity 2.0.

Google positions Antigravity as an agent-first development platform. After I/O 2026, it is not only helping developers write code. It is meant to help developers move from ideas and prototypes to Agent orchestration and production delivery.

Core changes listed by Google include:

Antigravity 2.0 standalone desktop app.
Multi-Agent parallel orchestration.
Dynamic subagents.
Background scheduled tasks.
Integration with Google AI Studio, Android, Firebase, and related ecosystems.
Antigravity CLI for terminal users.
Antigravity SDK for custom Agent behavior and deployment.

This shows that AI coding tools are entering the next stage after “code completion / conversational generation”: developers will manage multiple executable Agents, not just one chat window.

Gemini API Managed Agents: Hosting Agents as API Capabilities

Google also introduced Managed Agents in the Gemini API.

According to the official description, these Agents can be created with a single API call. They can reason, use tools, and execute code in an isolated Linux environment, supported by the Antigravity agent harness.

This matters to developers:

You do not need to build the full Agent runtime yourself.
You can get a persistent, isolated execution environment.
Multi-turn interactions can preserve files and state.
Agents can be extended with markdown skills, custom instructions, and templates.
They are available through Interactions API and Google AI Studio.

If this line matures, Agent platforms will increasingly look like cloud services: developers will not only call models, but call Agents with state, tools, execution environments, and security boundaries.

Google AI Studio: From Prompt Playground to App Generation Entry Point

At I/O 2026, Google AI Studio also moves further.

Key changes include:

Google AI Studio mobile app for capturing ideas and generating prototypes on mobile.
Workspace API integration, making it easier for Agents to access Google Workspace.
Project export to Antigravity, carrying context into local development and production work.
Native Android support, allowing users to build Android apps from prompts.
Google Play Console integration to publish apps to test tracks.

This turns AI Studio from “a place to tune prompts and test models” into an entry point from idea to app. Its relationship with Antigravity is clearer too: AI Studio is good for fast ideation and generation, while Antigravity is better for continued development, orchestration, debugging, and delivery.

Android and AppFunctions: Key Interfaces for Mobile Agents

Android system-level Agents are worth watching on their own, but they need to be understood through accurate interfaces and product boundaries.

The most important current piece is Android’s official AppFunctions. The official documentation describes AppFunctions as an Android platform API with Jetpack libraries that lets apps expose their capabilities to agents, assistants, and other authorized callers. It also simplifies Android MCP integration.

Its significance is that mobile automation no longer has to rely only on screenshots, OCR, simulated taps, and UI control positioning.

Traditional mobile automation looks like:

Recognize the screen.
Find the button.
Simulate a tap.
Wait for the page to change.
Retry after errors.

The AppFunctions direction is:

Apps declare what they can do.
Agents call those capabilities with authorization.
The system handles permissions, call boundaries, and security constraints.

This will affect Android app design. Future apps will not only need human-facing UIs, but also core capabilities designed as Agent-callable interfaces.

Search, Shopping, and Content Products Are Becoming Agentic Too

Google I/O 2026 changes are not limited to models and developer tools. Search and consumer products are changing at the same time.

Official I/O summaries mention:

Search entering a new AI Search stage.
Information agents appearing in Search.
Gemini Spark and Daily Brief entering Gemini app.
Universal Cart making shopping carts smarter.
Ask YouTube enabling conversational queries and navigation over video content.
Gemini capabilities expanding to more products and form factors.

These announcements show that Google’s Agent direction is not a single product. It is spreading horizontally across search, video, shopping, productivity, mobile, and hardware scenarios.

Practical Impact for Developers

The biggest impact of Google I/O 2026 for developers is not “another model.” It is that the development target is changing.

Developers used to mainly build:

Apps.
Websites.
APIs.
Plugins.
Automation scripts.

Next, they will also build:

App capabilities callable by Agents.
Multi-Agent workflows.
Stateful tool execution environments.
Auditable automation flows.
Human-in-the-loop confirmation mechanisms.
Integrations with MCP, AppFunctions, Workspace API, Playwright, Firebase, and other tools.

Software will increasingly look like a set of capabilities, not only a set of interfaces. Products that expose their capabilities clearly, reliably, and safely to Agents will be more likely to enter users’ automation task chains.

Impact on Mobile Automation

Mobile automation will gradually move from “GUI first” to “API first, GUI as fallback.”

In the short term, screenshot recognition, OCR, simulated taps, and browser automation still matter because many older apps have no standard interface.

In the long term, if Android AppFunctions, MCP, and system-level permission models mature, stable task execution will lean toward:

First calling capabilities declared by apps.
Then calling system interfaces when needed.
Then using GUI automation as a fallback.

This will change RPA, mobile Agents, testing tools, and app ecosystems. Apps that expose capabilities are easier for system-level Agents to call. Apps that do not may still only be operated by the old “look at screen, tap screen” approach.

Security, Permissions, and Auditing Become Hard Requirements

The stronger Agents become, the higher the risk.

If an Agent can execute tasks across apps, make payments, change settings, access files, and read context, it needs clear security boundaries:

Permission levels.
Explicit user authorization.
Secondary confirmation for sensitive actions.
Sandbox isolation.
Operation logs.
Reversibility and rollback.
Enterprise auditing and compliance.

This is why Google emphasizes isolated environments for hosted Agents, permission requirements for AppFunctions, enterprise platforms, and controlled deployment. The future of Agents is not “do anything without limits,” but executable, traceable, and governable behavior inside security boundaries.

Summary

The main content of Google I/O 2026 can be summarized in one sentence: Google is turning Gemini into an Agent platform spanning models, apps, systems, developer tools, and hardware.

Gemini 3.5 Flash provides speed and action capability. Gemini Omni pushes multimodal creation toward video and world understanding. Gemini app becomes a proactive personal assistant. Antigravity 2.0 and Managed Agents push developer tools toward Agent-native development. AppFunctions lets Android apps begin exposing capabilities to intelligent agents.

For developers, the next thing to watch is not only model parameters, but how to structure application capabilities, connect to Agent toolchains, design permissions and auditing, and make products safely and reliably callable in a system-level Agent ecosystem.

References:

What Is PageIndex? A Reasoning-Based RAG Document Index Without Vector Databases

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex is an interesting RAG project. Instead of starting with “build another vector database,” it first organizes long documents into a tree structure similar to a table of contents, then lets an LLM perform reasoning-based retrieval along that tree.

Project link: VectifyAI/PageIndex

At the time of writing, the GitHub page shows about 31.8k stars and 2.7k forks, with an MIT license. The README positions it as Vectorless, Reasoning-based RAG: RAG without a vector database, based on reasoning.

What Problem It Tries to Solve

The common path for traditional RAG is: chunk the document, vectorize the chunks, store them in a vector database, then retrieve passages by similarity search. This approach is simple, general, and mature, but it often runs into several problems with long professional documents:

Similarity is not the same as true relevance.
Document structure is broken apart by chunking, and section relationships are lost.
Retrieval results are hard to explain, making it difficult to say why a passage was selected.
For financial reports, regulatory filings, legal documents, and technical manuals, questions often require reasoning across sections.

PageIndex takes the opposite route: first organize the document into a semantic tree, then let the model search it like a human reading a table of contents, jumping into sections, and narrowing down to details.

The Basic PageIndex Workflow

The README describes PageIndex retrieval in two steps:

Generate a Table-of-Contents-like tree index for the document.
Perform reasoning-based retrieval through tree search.

This tree is not just a file directory. It is a document structure designed for LLM use. Nodes can contain titles, page ranges, summaries, child nodes, and other metadata. When answering a question, the model does not need to face a pile of fragmented chunks immediately. It can first decide which section to enter, then continue searching downward.

This method is better suited to documents that are well structured but very long, such as:

Financial reports and SEC filings.
Regulatory and compliance documents.
Academic textbooks and papers.
Legal documents.
Technical manuals and product documentation.
Large PDFs that exceed the model context window.

How It Differs From Traditional Vector RAG

PageIndex’s main selling points can be summarized in five areas.

First, it does not require a Vector DB. It relies on document structure and LLM reasoning to locate content, rather than only using vector similarity search.

Second, it does not use traditional chunking. Documents are organized by natural sections instead of fixed-length text fragments.

Third, explainability is stronger. The retrieval path can map back to pages, sections, and tree nodes, making it easier to trace than “this text was hit by vector similarity.”

Fourth, retrieval is context-aware. The question, conversation history, and domain background can all affect the tree search path.

Fifth, it is closer to how human experts read documents. People usually do not cut an entire document into small chunks and calculate similarity; they first inspect the table of contents, locate sections, and then read details.

This does not mean vector databases have no value. A more accurate view is that PageIndex fits scenarios where “semantic similarity is not enough, and structure plus reasoning need to participate” in long-document retrieval.

How to Run It Locally

The README provides a local self-hosting path. First install dependencies:

`1`	`pip3 install --upgrade -r requirements.txt`

Then create a .env file in the project root and write your LLM API key. The project supports multiple models through LiteLLM:

`1`	`OPENAI_API_KEY=your_openai_key_here`

Generate a PageIndex structure for a PDF:

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

Markdown is also supported:

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

Common optional parameters include:

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

The README also notes that the local open-source version uses standard PDF parsing. For complex PDFs, the project’s cloud service provides enhanced OCR, tree building, and retrieval pipelines.

Agentic Vectorless RAG Example

The project also provides an agentic vectorless RAG example using self-hosted PageIndex and OpenAI Agents SDK. Install the optional dependency and run it:

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

The value of this example is that it pushes PageIndex from “generate a document tree” to “let an Agent use the document tree for retrieval.” If you are building an enterprise knowledge base, financial report Q&A, regulatory Q&A, or technical documentation Agent, this example is more worth running than only reading the README.

Cloud Service, MCP, and API

PageIndex is not just a GitHub repo. The project page also lists several entry points:

Self-hosting: run the open-source code locally, suitable for experiments and controlled deployments.
Chat Platform: a ChatGPT-style document analysis platform.
MCP / API: useful for integrating with existing Agents or automation workflows.
Enterprise: for private or on-premises deployment.

This shows that its positioning is not a simple demo. It aims to turn “reasoning-based document retrieval” into an integrable document intelligence infrastructure.

Suitable Scenarios

PageIndex is suitable for tasks such as:

Long PDF Q&A.
Financial reports, annual reports, prospectuses, and regulatory filing analysis.
Legal and compliance document retrieval.
Technical manual Q&A.
Multi-section textbook or paper retrieval.
Enterprise knowledge bases that need explainable retrieval paths.
Providing structured document context to Agents.

If your material is short, has little structure, or is just a normal FAQ, traditional embedding + vector DB may already be enough. PageIndex’s advantages are more likely to appear in long documents, strong structure, professional domains, and questions that require reasoning.

Things to Watch

First, PageIndex still depends on LLMs. Tree building, summaries, and retrieval quality are affected by model capability, prompts, and document parsing quality.

Second, the local version uses standard PDF parsing. Complex scanned documents, chart-heavy PDFs, or messy layouts may require OCR and stronger preprocessing.

Third, vectorless does not mean zero cost. Tree building itself also consumes model calls and time, especially for large-scale document collections.

Fourth, PageIndex is more like a document structure indexing and reasoning retrieval framework. It does not directly replace every RAG stack. In production, it may also be combined with vector retrieval, keyword retrieval, permission control, caching, and audit systems.

Summary

What makes PageIndex interesting is that it shifts RAG from “text similarity retrieval” toward “document structure + LLM reasoning.” For long and professional documents, this direction is worth watching.

If you are building enterprise document Q&A, financial report analysis, regulatory retrieval, or technical manual Agents, PageIndex is a new RAG architecture reference: give documents structure first, then let the model reason along that structure, instead of breaking everything into chunks and putting it all into a vector database from the beginning.

References:

GitHub: VectifyAI/PageIndex

Windows Secure Boot Certificates Expire in 2026: How Users and Admins Should Update

Wed, 20 May 2026 23:15:08 +0800

Microsoft has updated its guidance on Windows Secure Boot certificate expiration and CA updates. The key point is not that “the PC will stop booting when the certificate expires.” The real issue is that a set of Secure Boot certificates issued in 2011 will start expiring in June 2026, and Windows devices need to move to the new 2023 certificates to keep receiving future early-boot security protection updates.

Original article: Microsoft Support: Windows Secure Boot certificate expiration and CA updates.

What This Update Is About

Secure Boot is a security feature in UEFI firmware. Before the operating system starts, it verifies the signatures of bootloaders, UEFI drivers, Option ROMs, and other components, helping block bootkits, rootkits, and other early-boot malware.

This validation depends on several databases and keys stored in firmware:

KEK: the key enrollment key, used to authorize updates to Secure Boot databases.
DB: the allowed signature database, which decides which boot components can be trusted.
DBX: the revoked signature database, used to block components that are known to be untrusted or risky.

Microsoft notes that a group of 2011 certificates used by Windows devices for many years is approaching expiration, and corresponding new certificates now exist in 2023 versions. These include the KEK certificate used to sign DB / DBX updates, the Windows UEFI CA used to sign Windows Boot Manager, and the UEFI CA used for third-party bootloaders, EFI applications, and Option ROMs.

Will It Affect Booting?

The question most users care about is: after the certificates expire in 2026, will the PC suddenly fail to boot?

Microsoft’s answer is fairly clear: devices that have not received the new 2023 certificates can still boot and run normally, and standard Windows updates will continue to install. The problem is that these devices will no longer be able to receive new protections related to the early boot process, such as Windows Boot Manager updates, Secure Boot database updates, revocation list updates, and mitigations for newly discovered boot-level vulnerabilities.

So this is more like an aging security chain than a simple “the system is immediately obsolete” problem. In the short term, the machine may keep working. In the long term, its protection against new bootkits, boot-chain vulnerabilities, and revoked components will decline.

What Ordinary Users Should Do

Ordinary users do not need to manually edit Secure Boot keys, and should not casually delete, reset, or import certificates in BIOS / UEFI.

The safer approach is:

Keep Windows Update enabled and install cumulative updates.
Install firmware, BIOS, UEFI, and driver updates from the PC manufacturer.
Do not keep Secure Boot disabled long term just to work around temporary compatibility issues.
If BitLocker is enabled, make sure the recovery key is available before firmware or Secure Boot changes.
Use msinfo32 to check “Secure Boot State” and confirm that Secure Boot is enabled.

For home PCs, the main risk is usually not “not knowing what to do,” but leaving firmware outdated for too long. Many Secure Boot-related changes on laptops and branded PCs ultimately still depend on OEM firmware support.

What Enterprise Admins Should Watch

In enterprise environments, the hard part is not one machine. It is the mix of device models, firmware versions, encryption policies, deployment tools, and third-party boot components.

Start with four things:

Inventory device models, Windows versions, Secure Boot state, firmware versions, and BitLocker state.
Test on representative models first, then expand deployment gradually.
Put Windows updates, OEM firmware updates, recovery key backup, and PXE / MDT / ConfigMgr / Intune workflows into one change plan.
Validate whether recovery media, imaging tools, third-party security software, and dual-boot bootloaders still boot normally.

Microsoft’s documentation also provides paths for IT-managed devices through registry settings, Group Policy, WinCS API, Intune, and monitoring examples. For enterprises, this certificate update should not be treated as an ordinary patch. It should be tested, rolled out in stages, and paired with rollback planning as a firmware-level change.

Dual-Boot and Third-Party Boot Tools Need Extra Care

If a device uses Linux dual boot, a third-party bootloader, custom-signed EFI applications, old recovery media, or offline deployment tools, this update deserves early validation.

The reason is that Microsoft has split parts of the original trust model more finely. For example, trust for third-party bootloaders and Option ROMs is no longer fully bundled together. This helps narrow the trust scope, but it also means older boot components, outdated shim / GRUB builds, old recovery media, or custom boot tools may be more likely to run into signature trust problems in the future.

The rule is simple: do not wait until after the certificates expire to discover that your recovery USB cannot boot either. Important machines should have a real recovery flow tested at least once in advance.

What Not to Do

This kind of issue looks like a “certificate expired” problem, so it is tempting to go into BIOS and manually change keys. Unless the vendor or Microsoft documentation clearly requires it, that is not recommended.

Do not leave Secure Boot disabled long term. Do not clear Secure Boot keys directly on production devices. Do not copy firmware settings from one device to a different model batch. And do not update Windows only, skip OEM firmware, and assume the issue is fully handled.

A better way to think about it is: Windows updates handle the operating system side, OEM firmware updates handle the platform side, and enterprise deployment policy handles consistency at scale. If any of the three is missing, the result may later become a hard-to-debug boot problem.

Summary

The real impact of this Windows Secure Boot certificate expiration is not that every PC suddenly stops booting on a single day in 2026. The real issue is that devices with old certificates will gradually lose the ability to receive future Secure Boot security updates.

Individual users should keep Windows and firmware updated and avoid casually disabling Secure Boot. Enterprise admins should start inventory, testing, and phased deployment as soon as possible. The closer it gets to June 2026, the less time remains for firmware compatibility testing, recovery flow validation, and bulk rollback planning.

How to Use Gemini 3.5 Flash and Gemini Omni for Free: Entry Points for Users and Developers

Wed, 20 May 2026 23:13:35 +0800

After Google released Gemini 3.5 Flash and Gemini Omni, the practical question is not the benchmark score, but how ordinary users and developers can actually use them, which entry points are free, and which ones are only low-friction trials.

The short version:

For chat, writing, image understanding, and everyday Q&A: use Gemini app first.
To test Gemini 3.5 Flash parameters, prompts, and multimodal input: use Google AI Studio.
To call Gemini 3.5 Flash from code: create an API key in AI Studio.
To try it from the terminal for free: look at Gemini CLI.
To try Gemini Omni video editing: start with Gemini app and Google Flow.
For real production use: do not rely on free quotas; move to a paid API or Vertex AI.

Note: free quotas, regional availability, subscription tiers, and model menus change over time. This article was written on May 20, 2026. Before official use, always check Google’s current pages.

Free Gemini 3.5 Flash Method 1: Gemini App

The simplest entry point is Gemini app:

https://gemini.google.com/

The basic flow is straightforward:

Open Gemini.
Sign in with a Google account.
Look for 3.5 Flash in the model selector.
Start chatting.

This entry point is best for ordinary users. You can use it for writing, summarization, image understanding, file analysis, everyday Q&A, and simple planning. According to public reports, Gemini 3.5 Flash has been made available to users globally and can be selected from Gemini’s model dropdown.

The limits are also clear: free users usually face daily message, regional, and feature limits. If you exceed the limit, you need to wait for the quota to refresh or upgrade your subscription.

Free Gemini 3.5 Flash Method 2: Google AI Studio

If you want more than chat, and need to tune prompts, inspect parameters, or test structured output, Google AI Studio is a better fit:

https://aistudio.google.com/

Basic flow:

Sign in to Google AI Studio.
Create a new prompt.
Select gemini-3.5-flash in the model dropdown.
Enter the prompt and run it.

AI Studio gives you more control. You can adjust temperature, system instructions, structured output, and multi-image input, and you can export a working prompt into code or an API call.

For developers, AI Studio is a free testing bench. Tune the prompt and input format here first, then move into API integration to avoid wasting quota.

Free Gemini 3.5 Flash Method 3: Free API Key

Developers care most about the API. AI Studio can create a Gemini API key for calling gemini-3.5-flash.

Basic flow:

Open Google AI Studio.
Find Get API key.
Select or create a project.
Create an API key.
Save the key to a local environment variable.

Python example:

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Explain in three sentences what Gemini 3.5 Flash is best suited for."
)

print(response.text)

Node.js example:

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "Explain in three sentences what Gemini 3.5 Flash is best suited for."
});

console.log(response.text);

curl example:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"Hello Gemini 3.5 Flash"}]}]}'

Public information suggests that the AI Studio free tier usually gives Gemini Flash models a daily request allowance. The exact numbers can vary by time, region, and account status. Common claims include around 1,500 requests per day, per-minute request limits, and token limits. Do not bake those numbers into a production plan; check Google’s current pricing and limits pages before launch.

Free Gemini 3.5 Flash Method 4: Gemini CLI

If you like the command line, look at Gemini CLI. It is useful for temporary scripts, repository summaries, file reading, and quick Q&A in the terminal.

Installation is usually:

`1`	`npm install -g @google/gemini-cli`

Then run:

gemini

The CLI is better suited to personal developer workflows than production integration. Production should still use API keys, service accounts, permission controls, and auditable calling patterns.

Free or Low-Friction Gemini Omni Access: Gemini App and Google Flow

Gemini Omni is a multimodal model for video creation and editing. Its core capability is not ordinary text Q&A, but multi-turn video editing with natural language while referencing image, text, video, and audio inputs.

The Google DeepMind page lists these entry points:

Gemini app.
Google Flow.
YouTube Shorts.

The page also notes that a Google AI subscription is required, and that features vary by subscription tier and region. So “free access” to Gemini Omni should be understood more carefully: some entry points may let free users see or try part of the experience, but full video editing may require a subscription, regional availability, or product rollout access.

If you only want to try it, use this order:

Open Gemini app first and check whether Gemini Omni or a related video editing entry is available.
Then open Google Flow: https://flow.google/
If you make short-form content, watch for Omni-related editing features in YouTube Shorts.

If the entry point is not visible, it usually does not mean you did something wrong. Your account, region, subscription tier, or rollout group may simply not qualify yet.

How Gemini Omni Is Best Used

Gemini Omni is more suitable for creators than for ordinary chat.

You can try these directions:

Upload or select a video and ask it to change the style.
Make a specific action in the video more exaggerated.
Use a reference image to replace an object or character in the scene.
Modify camera, action, environment, and style over multiple turns.
Combine sketches, reference images, audio, or video into a new output.

You can write prompts as if giving instructions to an editor:

Keep the original person and room structure unchanged. Change the effect after touching the mirror into liquid ripples. The motion should feel natural, and the lighting should not change abruptly.

For multi-turn editing, do not pack too many requirements into one request. A safer approach is:

Change the main action first.
Then change the style.
Then adjust the camera angle.
Finally tune sound, text, and rhythm.

This makes consistency easier to maintain and helps you identify which step caused a problem.

Common Pitfalls When Using Free Access

First, free quota is not production quota. A free API key is suitable for testing, personal tools, and prototypes, not for promising a stable service.

Second, do not send sensitive data to free or third-party entry points. This includes private code, customer data, contracts, keys, financial spreadsheets, and internal documents.

Third, check data-use settings. Free tiers may have different data-use policies, so review the settings in AI Studio or your Google account before use.

Fourth, video capabilities are usually more restricted than text capabilities. Gemini Omni-style video editing may be limited by subscription, region, queueing, duration, resolution, and content safety policies.

Fifth, be careful with third-party “unlimited free API” services. Many gateways rate-limit, forward requests, keep logs, or use opaque payment methods. Sensitive work should not go through these entry points.

Which Entry Point Should You Choose?

If you are an ordinary user:

Gemini 3.5 Flash: use Gemini app.
Gemini Omni: check Gemini app first, then Google Flow.

If you are a creator:

Use Google Flow to try Omni video workflows.
Use Gemini app for scripts, storyboards, prompts, and material descriptions.

If you are a developer:

Use AI Studio to debug prompts.
Use an API key to integrate gemini-3.5-flash.
Use Gemini CLI for personal terminal workflows.
For production, consider Vertex AI or the paid API.

If you are an enterprise:

Do not rely on free quotas.
Focus on permissions, logs, audits, data residency, compliance, and key management.
For video generation and editing, add watermarking, content review, and copyright processes.

Summary

Gemini 3.5 Flash has relatively clear free access paths: Gemini app, Google AI Studio, AI Studio API key, and Gemini CLI can all serve as low-friction entry points. It is suitable for chat, writing, coding, agent prototypes, and multimodal testing.

Gemini Omni focuses on video editing and multimodal creation. Its main entry points are Gemini app, Google Flow, and YouTube Shorts, but full capabilities are more likely to depend on subscription and region. It is best for creators to start with trials and concept validation, not to plan around it as a stable production service from day one.

The safest strategy is: test text and code tasks first with the Gemini 3.5 Flash free tier; validate video creation effects with Gemini Omni in Gemini app or Flow; when you need to launch something real, move to a formal setup with auditability, billing, and controlled permissions.

References:

What Is Gemini Omni? A Complete Look at Google's AI Video Multi-Turn Editing Model

Wed, 20 May 2026 23:11:58 +0800

Google DeepMind has published a page for Gemini Omni. Its positioning is direct: create content from any input, with the current focus starting from video.

If Nano Banana is more about image generation and editing, Gemini Omni feels more like a multimodal editing model for video. Users can modify a video step by step with natural language, with each later change building on the previous one, while trying to keep scenes, people, actions, and visual logic consistent.

Project page: https://deepmind.google/models/gemini-omni/

The Core Problem It Tries to Solve

Traditional video editing often requires timelines, layers, masks, keyframes, color grading, audio tracks, and a lot of manual work. AI video generation tools can already create clips from prompts, but they often run into two problems:

A generated result is hard to refine precisely.
During multi-turn edits, characters, scenes, styles, and actions can drift.

Gemini Omni is aimed at the second step: not just generating a video, but letting users keep asking for changes as if they were talking to an editor.

The project page describes it as a way to edit any video through natural, step-by-step conversation. Each edit builds on the prior result, with the goal of maintaining a coherent and unified scene.

Main Capabilities

Gemini Omni’s capabilities can be grouped into several areas.

The first is natural-language video editing. Users can directly ask the model to change a video’s aesthetic style, motion, or effects. For example, it can make a mirror ripple like liquid, turn a person into line art, a felt toy, or a transparent holographic wireframe, or transform an entire environment into 3D voxel art.

The second is action reconstruction. It can change what happens in a video, such as enlarging a hand-formed hole, making a toy produce the corresponding animal sound, or making building lights react to music.

The third is editing real video based on reference images. Users can provide an image reference and ask the model to place a building, sun, aircraft, or other object into a real video scene.

The fourth is maintaining consistency across multi-turn edits. The page shows a continuous editing flow: moving a violinist into a reference-image environment, removing the violin, and then changing the shot to an over-the-shoulder angle. This is closer to an actual creative process than a one-shot prompt.

The fifth is multi-input reference. Gemini Omni can combine image, text, video, and audio inputs into one output, supporting tasks such as style transfer, motion transfer, character replacement, and sketch-to-video generation.

Why It Emphasizes World Knowledge

Google repeatedly emphasizes that Gemini Omni is not only about making visuals look realistic. It also uses Gemini’s world knowledge, physical intuition, history, science, and narrative logic.

That matters. If a video model only optimizes for visual quality, it can easily produce illogical motion, confused object relationships, or mismatches between text and image. Gemini Omni’s goal is for video to look right while also being more coherent in story, physics, and meaning.

Examples on the page include:

A marble rolling through a chain-reaction track.
A claymation explanation of protein folding.
A stop-motion style explanation of how the hippocampus works.
Letters appearing in sync with objects in the scene.
On-screen words appearing one by one to the rhythm.

These examples suggest that Gemini Omni is not just a short-video effects tool. It tries to combine knowledge expression, storytelling, and audiovisual generation.

How It Relates to Veo, Flow, and Nano Banana

In Google’s current product lineup, Gemini Omni looks like a layer for multimodal creation and editing.

Veo is more focused on the video generation model itself, emphasizing cinematic video and audio generation. Google Flow is an AI creative studio for creators, suitable for organizing shots, assets, and video projects. Nano Banana is more focused on image creation and detailed editing. Gemini Omni emphasizes multimodal editing from any input to a consistent output, especially multi-turn natural-language control for video.

A simple way to understand it:

To generate high-quality video, watch Veo.
To organize video projects in a creative workflow, watch Google Flow.
To edit images, watch Nano Banana.
To modify video conversationally while referencing images, text, video, and audio, watch Gemini Omni.

Access Points

The page lists these access points:

Gemini app.
Google Flow.
YouTube Shorts.

However, it also notes that a Google AI subscription is required, and availability depends on subscription tier and region. In other words, not every user in every region can immediately access the full feature set.

For creators, Google Flow may be the most important entry point because it is closer to a complete creative workspace. For general users, Gemini app and YouTube Shorts may be lower-friction ways to try it.

Safety and Content Labels

The Gemini Omni page specifically mentions safety work. Gemini Omni Flash was developed in collaboration with internal safety and responsibility teams, with automated evaluations, human evaluations, human red teaming, automated red teaming, and pre-launch ethics and safety reviews.

For content transparency, the page says content created or edited with Omni in Gemini app, Google Flow, or YouTube will include imperceptible SynthID digital watermarks and C2PA Content Credentials. Users can verify content in Gemini app, with expansion to Chrome and Search planned later.

This is especially important for video models. The more realistic video generation and editing becomes, the more important source labeling, abuse prevention, and verification tools become.

Who It Is For

Gemini Omni is suitable for several types of users:

Content creators who want to modify video quickly with natural language.
Design teams that need to combine sketches, reference images, audio, and video assets into a finished clip.
People making short videos, ad concepts, educational explainers, and product visual drafts.
Creators building AI video workflows in Google Flow.
Developers and researchers watching the boundaries of multimodal video editing.

But it is not ideal for every scenario. Serious commercial films, brand key visuals, film production, and product launch videos still require human review, copyright checks, fact-checking, and asset management. AI can clearly speed up concept generation and first-draft iteration, but it should not replace final review.

How to Read Gemini Omni

The significance of Gemini Omni is that it moves AI video from “one-shot generation” toward “conversational editing.” That is closer to real creative workflows than simply improving visual quality.

If it performs reliably in multi-turn editing, consistency, reference control, audio-video synchronization, and content labeling, the way people use AI video tools will change. Users will no longer only write one long prompt and hope for the best; they will revise scenes, actions, styles, and narratives step by step like directors, editors, and designers.

What still needs to be observed is actual availability, pricing, regional limits, video length, resolution, copyright policy, and commercial-use rules. For ordinary creators, the most practical question is whether Gemini Omni can reliably handle multi-turn video editing inside Google Flow and Gemini app.

References:

Google DeepMind: Gemini Omni

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

Several high-profile local security issues have appeared in the Linux ecosystem recently. Individually, they involve different areas: crypto interfaces, network and IPsec paths, page cache handling, and ptrace access checks. Together, they point to the same operational lesson: once an attacker has a low-privilege local execution point, the risk to Linux hosts, container nodes, CI machines, and multi-user servers increases sharply.

This article does not repeat all technical details of each vulnerability. Instead, it summarizes their practical impact and links to four separate articles on this site for deeper reading.

What the Four Events Affect

The four risks worth tracking are:

Copy Fail (CVE-2026-31431): a low-privilege local user may affect the page cache through kernel crypto-related paths and expand privileges.
Dirty Frag (related to CVE-2026-43284 / CVE-2026-43500): risk centers on xfrm/ESP, RxRPC, and related network and kernel data paths, making it dangerous in post-compromise scenarios.
Fragnesia (CVE-2026-46300): close to Dirty Frag, involving XFRM ESP-in-TCP, shared fragments, and page-cache write risk.
ssh-keysign-pwn (CVE-2026-46333): not a direct root-shell bug, but a local information disclosure risk that may expose SSH host private keys, /etc/shadow, and other sensitive files.

The entry points differ, and so do the mitigations. Fixing Copy Fail does not automatically cover Dirty Frag or Fragnesia. Disabling some network modules does not automatically remove the information disclosure risk around ssh-keysign-pwn.

Copy Fail: High Priority for Containers and CI Nodes

The key impact of Copy Fail is not an application crash. It is that low-privilege execution may be turned into root privileges. It is especially sensitive in these environments:

CI/CD nodes that allow users to upload or run code.
Container hosts running untrusted workloads.
Development machines, jump hosts, and shared servers.
Cloud hosts running older kernels with slower patch cycles.

The danger is that Copy Fail has a relatively low exploitation threshold and combines easily with container scenarios. Many teams treat containers as a strong isolation boundary, but ordinary containers still share the host kernel by default. If an attacker gets a shell inside a container, a kernel LPE can turn a container issue into a host issue.

Detailed analysis: Copy Fail CVE-2026-31431: Container Escape Risk in a Linux Kernel File-Copy Path.

Dirty Frag: A Post-Compromise Amplifier

Dirty Frag is more like a privilege amplifier after an attacker has entered a system. It is not a typical remote unauthenticated vulnerability. The usual prerequisite is that the attacker already has local execution through a weak password, WebShell, low-privilege service account, container task, or another foothold.

Its practical impact appears in several places:

A compromised low-privilege account may become root.
A low-privilege execution point inside a container may threaten the host.
Systems using IPsec, ESP, RxRPC, or related kernel networking capabilities need careful patch and mitigation review.
Security teams should look beyond perimeter defense and include post-compromise privilege escalation chains.

Dirty Frag reminds operations teams that local privilege escalation may not be the first entry point, but it can decide how far an intrusion goes. Once a low-privilege foothold exists, attackers will look for kernel bugs to push privileges to the highest level.

Detailed analysis: Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide.

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

Fragnesia matters because it shows that the attack surface near Dirty Frag is not an isolated one-off issue. Even if one bug is fixed, neighboring paths, similar data structures, and related module combinations may still contain new exploitable points.

Its operational impact is mainly:

Do not handle only the vulnerability name once. Keep checking by attack surface.
esp4, esp6, rxrpc, XFRM, and ESP-in-TCP should be evaluated against actual business dependencies.
If a system does not depend on the related network capabilities, temporary disabling may be considered, but it must be tested first to avoid breaking VPN, IPsec, tunnels, or internal networking.
Page-cache pollution risks can create detection blind spots where files appear unchanged, but the execution path is affected.

For enterprises, the biggest lesson is that patch management should not look only at a single CVE. A safer approach is to build an inventory around subsystems and attack surfaces, then identify which machines expose the relevant capabilities and which services truly need those modules.

Detailed analysis: Fragnesia (CVE-2026-46300): Linux Kernel Local Privilege Escalation Impact and Mitigation.

ssh-keysign-pwn: Not Direct Root, Still Dangerous

ssh-keysign-pwn differs from the previous three. It is more of a local sensitive information disclosure issue than a direct root-shell vulnerability. But in real attacks, sensitive information disclosure can quickly become a larger incident.

The main impacts include:

Leaked SSH host private keys may damage host identity trust.
Access to files such as /etc/shadow can lead to offline cracking and account takeover.
Multi-user servers, jump hosts, build machines, and shared development machines carry higher risk.
Even without immediate privilege escalation, attackers may obtain credential material useful for lateral movement.

This type of issue is easy to underestimate because it does not look as dramatic as a direct root shell. In enterprise environments, however, key and password-hash exposure often means a longer cleanup cycle: rotating SSH host keys, reviewing trust relationships, checking account passwords, and auditing login logs.

Detailed analysis: ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk.

Shared Impact: Containers Are Not a Strong Boundary by Default

Taken together, these four events make one point clear: ordinary container isolation is not virtual-machine isolation.

Docker, containerd, and Kubernetes use namespaces, cgroups, capabilities, seccomp, AppArmor, and SELinux to reduce attack surface, but they usually still share the host kernel. If the vulnerability is in the shared kernel, a low-privilege execution point inside a container can become an entry point.

High-risk environments should check:

Whether untrusted code is allowed to run on shared hosts.
Whether containers run as root by default.
Whether unnecessary capabilities are granted.
Whether seccomp policies are too broad.
Whether multi-tenant workloads should move to gVisor, Kata Containers, Firecracker microVM, dedicated virtual machines, or dedicated nodes.

CI/CD platforms deserve special attention. Build jobs naturally run external code, dependency install scripts, test scripts, and temporary binaries. If these jobs share hosts with long-running services, one local privilege escalation can affect much larger infrastructure.

Shared Impact: Patches Must Reach the Running Kernel

A common Linux kernel patching mistake is assuming that an installed package means the machine is running the fixed kernel.

At minimum, operations teams should verify three things:

`1`	`uname -a`

Check the currently running kernel.

`1`	`dpkg -l \| grep linux-image`

Or on RHEL-family distributions:

`1`	`rpm -qa \| grep kernel`

Check installed kernel packages.

Finally, confirm that the machine has rebooted into the fixed kernel. For core services that cannot reboot immediately, evaluate livepatch, hot patching, or short-term isolation, but do not treat temporary mitigation as the final fix.

Shared Impact: Attack Surface Reduction Must Be Specific

These vulnerabilities remind us that Linux hardening cannot stop at “update the system” and “enable a firewall.”

More specific checks include:

Whether AF_ALG / algif_aead is used by business workloads.
Whether XFRM, ESP, ESP-in-TCP, and IPsec are required by VPNs, tunnels, or security gateways.
Whether RxRPC is needed.
Whether unprivileged user namespaces must be enabled.
Whether containers can create overly broad socket types.
Whether ptrace access policies are too loose.

If the business does not need certain capabilities, evaluate disabling modules, adjusting sysctl settings, tightening seccomp, and reducing capabilities. Do not blindly copy commands into production. Inventory dependencies first, then roll out changes gradually.

Suggested Response Order

First, prioritize machines where local code execution is exposed:

Container hosts.
CI/CD runners.
Jump hosts.
Multi-user servers.
Hosts running external-facing services.
Systems running untrusted plugins, scripts, or extensions.

Second, confirm distribution advisories and the actual running kernel. Do not rely only on upstream version numbers. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler, and other distributions may backport security fixes.

Third, tighten container runtime policies. Prefer non-root users, minimal capabilities, no-new-privileges, read-only filesystems, and explicit seccomp plus AppArmor or SELinux policies.

Fourth, review key and credential exposure. Especially for environments affected by ssh-keysign-pwn, evaluate whether SSH host keys, /etc/shadow, jump-host credentials, and CI secrets need rotation.

Fifth, improve monitoring. Watch for abnormal root shells, suspicious local LPE PoCs, critical file changes, abnormal ptrace behavior, container processes accessing host paths, and unusual network connections from CI nodes.

Conclusion

The point of these four events is not “Linux is insecure.” The point is that default trust is no longer enough.

Linux remains transparent, fixable, configurable, and hardenable. But in environments where containers, CI, multi-tenancy, and AI-driven code execution are increasingly common, a low-privilege execution point can no longer be treated as a minor issue. If the kernel contains exploitable local privilege escalation or sensitive information disclosure bugs, a partial intrusion can become host control, credential exposure, or lateral movement.

A more realistic approach is to treat these four events as a reminder: patch quickly, confirm rebooted kernels, enable modules only when needed, tighten containers, make key rotation possible, and reassess isolation levels for multi-tenant workloads.

Gemini 3.5 Is Here: Flash Leads as Google Focuses on Agents and Long-Running Tasks

Wed, 20 May 2026 22:51:31 +0800

Google officially released the Gemini 3.5 series on May 20, 2026. The first model available is Gemini 3.5 Flash. Its positioning is not just chat, but agents, code generation, and long-running complex task execution.

The message is clear: Google wants Gemini 3.5 to answer questions, but also to plan, execute, check results, and keep work moving across multi-step workflows.

Gemini 3.5 Flash Comes First

Gemini 3.5 Flash is already available to several groups:

General users can try it in the Gemini app and AI Mode in Google Search.
Developers can use it through Google Antigravity, Google AI Studio, and the Gemini API in Android Studio.
Enterprise users can access it through Gemini Enterprise Agent Platform and Gemini Enterprise.

Google also said Gemini 3.5 Pro is still in development, already being used internally at Google, and expected to launch next month.

This means the 3.5 series will continue the Flash and Pro split: Flash emphasizes speed, cost, and scalable execution, while Pro will likely target more complex and higher-capability use cases.

The Focus Is Agents and Coding

Google describes Gemini 3.5 Flash as one of its strongest models for agents and coding. The announcement says it beats some Gemini 3.1 Pro results on coding and agent benchmarks such as Terminal-Bench 2.1, GDPval-AA, MCP Atlas, and CharXiv Reasoning.

Most users do not need to care about every benchmark number. The more important point is that Google is pushing model capability toward executable workflows: not only writing code, but also migrating old projects, developing complex apps, organizing financial reports, analyzing data, and running repeated tests.

In the Antigravity development framework, Gemini 3.5 Flash can use multiple collaborating subagents to handle large tasks. Google showed examples such as reading the AlphaZero paper and building a playable game, converting legacy code to Next.js, and generating cityscapes and UI options in parallel.

The direction is clear: AI coding tools are moving from “generate a piece of code” toward “coordinate multiple agents to complete a project.”

Stronger Multimodal UI and Graphics

Gemini 3.5 Flash builds on Gemini 3’s multimodal foundation. Google says it can generate richer web UIs, interactive animations, and visual content.

The announcement includes examples such as:

Creating interactive animations for research papers.
Turning text descriptions into interactive hardware models.
Generating a complete brand concept for a school fundraiser.
Producing multiple UX options for a checkout flow in a short time.

This matters for developers and product teams. The model is no longer only writing explanations. It can participate in frontend prototypes, interaction design, and visualization work.

Enterprise Use: Automating Time-Consuming Workflows

Google listed several partner examples. Shopify uses subagents to analyze complex data and forecast merchant growth. Macquarie Bank is testing 3.5 Flash on documents over 100 pages to accelerate account-opening workflows. Salesforce is integrating it into Agentforce. Ramp uses it to improve OCR for complex invoices. Xero uses AI agents for administrative workflows. Databricks uses automated workflows to monitor data anomalies and suggest fixes.

These examples point to the same trend: enterprise adoption of large models is moving from one-off Q&A to workflow automation. Whether a model is inexpensive, fast, and stable over long tasks can matter more than whether one answer looks impressive.

Gemini Spark: A Personal AI Agent

Google also announced Gemini Spark, a personal AI agent powered by Gemini 3.5 Flash. Its goal is to run over long periods and proactively perform tasks under user guidance.

Gemini Spark has started rolling out to trusted testers. Google plans to open a beta next week to Google AI Ultra subscribers in the United States.

This is worth watching. Google Search, the Gemini app, Android, Workspace, and browser-related ecosystems already touch many parts of personal digital life. If a personal agent can connect with these entry points, its impact may be larger than a standalone chatbot.

Safety Moves Further Upstream

Google says Gemini 3.5 was developed under its Frontier Safety Framework, with strengthened protections for information security and CBRN-related risks. The announcement also mentions interpretability tools that help examine and understand model reasoning before responses are delivered.

This shows that frontier model releases are no longer only a capability race. The more a model emphasizes agents, autonomous execution, and long-running tasks, the more important safety controls, false refusal rates, harmful-output prevention, and interpretability become.

How to View Gemini 3.5

Gemini 3.5 Flash is not just another model launch. It looks more like Google’s bet on the next shape of AI products: models that can call tools, split tasks, coordinate execution, generate UIs, and enter personal and enterprise workflows.

For developers, the important things to watch are the real experience in Google Antigravity, AI Studio, the Gemini API, and Android Studio. For enterprises, the question is whether it can reliably reduce manual work in real workflows, not just score well on benchmarks.

Gemini 3.5 Pro is not publicly available yet. Once Pro ships, the differences between Flash and Pro in capability, price, speed, and context handling will decide which production scenarios each model fits best.

References:

Google Blog: Gemini 3.5

agentmemory: Persistent Memory for Claude Code, Codex, Cursor, and Other Coding Agents

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory is a persistent memory system for AI coding agents. Its goal is straightforward: Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode, and similar tools should not have to relearn the project background, architecture decisions, and historical problems every time a new session starts.

Project URL: https://github.com/rohitg00/agentmemory

At the time of writing, the GitHub API showed about 13k stars, TypeScript as the main language, and an Apache-2.0 license. The README describes it as “Persistent memory for AI coding agents.”

What Problem Does It Solve

A common pain point for coding agents is memory fragmentation. You may ask an agent to fix an authentication issue today, then open a new conversation tomorrow, and it no longer knows:

Why a certain architecture decision was made.
Which files are sensitive and should be changed carefully.
What bugs were fixed before.
What commands, tools, or local services the project uses.
Which conventions the team follows.

Static notes help, but they are often forgotten or not connected to the active workflow. agentmemory tries to provide a shared memory layer that can be used across different AI coding tools.

Supported Agents

The README lists support for Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode, and other MCP-compatible tools. The core idea is to expose memory through a local service, MCP, hooks, and integrations, so multiple assistants can share the same project context.

This is especially useful for teams that switch between tools. One developer may use Cursor, another may use Claude Code, while automation runs through Codex CLI. A shared memory layer reduces repeated explanation.

Quick Start

Install globally:

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

Or run with npx:

`1`	`npx @agentmemory/agentmemory`

The local service is available at:

`1`	`http://localhost:3113`

In practice, the first step is usually to start the memory service, connect the coding assistant, and then let the agent read or write project memories during development.

How It Differs From Static Memory Files

Many teams already maintain AGENTS.md, CLAUDE.md, README notes, or local documentation. These files are useful, but they are static. They do not automatically capture session history, task outcomes, or recurring decisions.

agentmemory is closer to a persistent context service. It can store and surface memories that are relevant to the current project or task. The goal is not to replace documentation, but to make working context easier to reuse.

Typical Scenarios

Useful scenarios include:

Remembering project setup steps and common commands.
Recording why a risky refactor was avoided.
Keeping notes about flaky tests or local services.
Sharing domain terminology across coding assistants.
Helping agents continue work after a new session starts.

This is particularly valuable for long-running products, monorepos, and projects with many hidden conventions.

Things To Watch Out For

First, memory quality matters. If old or wrong information is written into memory, future agents may repeat the mistake. Teams should keep important memories short, clear, and reviewable.

Second, privacy matters. Do not store secrets, API keys, customer data, or sensitive production information in a memory system unless the security model is clear.

Third, memory is not a substitute for tests. It helps agents understand context, but the final guarantee still comes from code review, tests, and verification.

Who It Is For

agentmemory is suitable for developers who use multiple AI coding tools, teams working on large codebases, and users who often need agents to continue previous work. It is less necessary for very small one-off scripts.

Summary

agentmemory is interesting because it treats memory as infrastructure for AI coding, not as a small prompt trick. If coding agents are becoming part of daily development, persistent project memory is a practical missing piece.

Let AI Operate Your Computer? UI-TARS-desktop Connects Desktop, Browser, and Tools

Tue, 19 May 2026 10:56:50 +0800

bytedance/UI-TARS-desktop is ByteDance’s open source multimodal AI agent project. It is not just a single desktop app, but an agent stack. The current README mainly contains two directions: Agent TARS and UI-TARS Desktop.

Project URL: https://github.com/bytedance/UI-TARS-desktop

Official site: https://agent-tars.com

At the time of writing, the GitHub API showed about 34k stars, TypeScript as the main language, and an Apache-2.0 license. The README describes it as an “Open-Source Multimodal AI Agent Stack.”

Difference Between Agent TARS and UI-TARS Desktop

The README places the two projects in one comparison table:

Agent TARS: a general multimodal AI agent stack that connects GUI agents, vision, terminal, browser, and product workflows.
UI-TARS Desktop: a desktop application based on UI-TARS models, providing native GUI agent capabilities for operating local or remote computers and browsers.

Simply put, Agent TARS is more like a general agent runtime, while UI-TARS Desktop is the desktop GUI operation entry point.

What Agent TARS Can Do

Agent TARS mainly provides a CLI and Web UI. Its goal is to let multimodal models complete task flows closer to human operation through MCP and various tools.

Core capabilities listed in the README include:

One-command CLI startup, supporting headful Web UI and headless server.
Hybrid browser agent control through GUI Agent, DOM, or mixed strategies.
Event Stream for tracing and debugging data flows.
MCP integration for mounting MCP Servers and real tools.

Quick start:

`1`	`npx @agent-tars/cli@latest`

Global installation:

`1`	`npm install @agent-tars/cli@latest -g`

Run with a model provider:

1
2

agent-tars --provider volcengine --model doubao-1-5-thinking-vision-pro-250428 --apiKey your-api-key
agent-tars --provider anthropic --model claude-3-7-sonnet-latest --apiKey your-api-key

What UI-TARS Desktop Can Do

UI-TARS Desktop is a desktop GUI Agent. Based on UI-TARS and Seed-1.5-VL / 1.6 model families, it focuses on letting the model understand the screen and execute mouse and keyboard operations.

Capabilities listed in the README include:

Natural language control.
Screenshots and visual recognition.
Precise mouse and keyboard control.
Cross-platform support for Windows, macOS, and browsers.
Real-time feedback and status display.
Local processing with an emphasis on privacy and security.

Example tasks include changing VS Code settings, checking GitHub issues, and operating remote computers or browsers.

Why GUI Agents Matter

Traditional automation depends on APIs, DOM, or scripts. A GUI Agent starts from the interface: it sees buttons, input boxes, menus, and state, then operates through mouse and keyboard.

This has two values. First, many applications do not have stable APIs, or APIs do not cover the full workflow. A GUI Agent can interact from the same surface a human uses.

Second, multimodal models can handle screenshots, documents, web pages, and app interfaces, combining visual understanding with execution.

The limitation is also clear. GUI operations are affected by resolution, language, layout changes, pop-ups, and network latency. Production workflows still need permission control, confirmation steps, and rollback plans.

Relationship With MCP

Agent TARS emphasizes MCP integration. MCP is useful because it gives agents a unified way to call browsers, files, command lines, databases, internal services, and other tools.

For complex tasks, GUI clicking alone is not stable enough. A better pattern is often:

Use APIs where APIs are available.
Use vision when page state must be understood.
Use browser control when real web interaction is needed.
Use GUI Agent when local software must be operated.

Projects like UI-TARS-desktop are exploring how to place these capabilities in one agent stack.

What To Watch Out For

First, desktop agents have execution risk. They can operate mouse, keyboard, and browser, so permissions must be limited to avoid accidental file changes, account operations, payment, or production system actions.

Second, remote computer and remote browser control needs a clear security boundary. Do not expose unauthenticated control endpoints to the public internet.

Third, multimodal models can misread interfaces. Critical operations should require human confirmation, especially delete, submit, pay, publish, trade, or other irreversible actions.

Who It Is For

UI-TARS-desktop is suitable for developers exploring GUI agents, teams building AI assistants for desktop workflows, and researchers comparing browser, DOM, MCP, and visual-control strategies. It is not a simple consumer assistant yet.

Summary

UI-TARS-desktop is worth watching because it moves AI agents from “answering in chat” toward “seeing the screen and operating tools.” Its value is not only in desktop control, but in combining GUI, browser, terminal, and MCP capabilities in one stack.

Too Many Platforms to Post To? AiToEarn Wants AI Agents to Help Creators Save Time

Tue, 19 May 2026 10:56:50 +0800

yikart/AiToEarn is an AI content marketing project for creators, brands, and one-person companies. It tries to put content creation, publishing, engagement, and monetization into one agent workflow, covering platforms such as Douyin, Xiaohongshu, Kuaishou, Bilibili, WeChat Channels, TikTok, YouTube, Facebook, Instagram, Threads, X, Pinterest, and LinkedIn.

Project URL: https://github.com/yikart/AiToEarn

Official site: https://aitoearn.ai/

At the time of writing, the GitHub API showed about 15k stars, TypeScript as the main language, and an MIT license. The README describes it as a content marketing agent platform for OPCs, creators, brands, and enterprises.

Positioning

AiToEarn is not just a copywriting generator or a scheduled posting tool. It breaks content marketing into four agent capabilities:

Monetize: content monetization.
Publish: cross-platform content publishing.
Engage: content interaction and community operations.
Create: content creation.

That positioning fits the current creator workflow. The hard part for many teams is not only “can AI write a post”, but what happens after that: scheduling, distribution, replies, review, and connecting content to business tasks.

Core Features

Monetize: Making Money From Content

AiToEarn provides monetization capabilities around promotional tasks. The README mentions three settlement models:

Model	Full name	Meaning
CPS	Cost Per Sale	Settlement by sales
CPE	Cost Per Engagement	Settlement by engagement
CPM	Cost Per Mille	Settlement by impressions or views

This part is closer to a content task marketplace that connects brand promotion needs with creator distribution.

Publish: Content Publishing Agent

Publish distributes content across multiple platforms and reduces the repeated work of posting manually. The README covers mainstream short video, graphic, and social platforms in China and overseas.

Its practical value is unified scheduling and management. For account matrices, cross-platform distribution, and global content teams, this is often more useful than a single AI copywriting feature.

Engage: Content Engagement Agent

Engage uses a browser extension to support automated engagement operations such as likes, saves, follows, comment replies, and brand monitoring.

This capability should be used carefully. Automated engagement can trigger platform risk controls, so teams need to check account permissions, frequency limits, platform terms, and internal compliance rules.

Create: Content Creation Agent

Create handles content generation. The README mentions video generation models, video translation, video editing, image generation, and batch creation tasks.

This is useful for large-scale content production, but human review is still necessary. Brand content, ad materials, and multilingual assets need factual accuracy, copyright checks, and tone consistency.

Five Ways To Use It

Method	Best for	Deployment needed
Use the website directly	All users	No
Use it in OpenClaw	OpenClaw users	No
Use it in Claude / Cursor and other AI assistants	AI tool users	No
One-click Docker deployment	Teams that want self-hosting	Server needed
Source development	Developers	Development environment needed

MCP support is a notable point. It means Claude, Cursor, or other MCP-compatible agents can call AiToEarn as an external capability.

A common MCP configuration contains:

1
2

MCP URL: https://aitoearn.ai/api/unified/mcp
Auth Header: x-api-key: your-API-Key

Self-hosted users should replace it with their own service URL.

Docker Deployment

The README provides a Docker deployment path:

1
2
3

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

Then visit:

`1`	`http://localhost:8080`

For teams that care about data control, private deployment, or custom workflows, Docker is more practical than only using the hosted website.

Who It Is For

AiToEarn is suitable for creators who publish across many platforms, small teams running content operations, one-person companies, brands that need creator collaboration, and developers who want to connect content workflows to AI agents.

It is less suitable if you only need a simple text generator. Its value is in connecting creation, publishing, engagement, and monetization.

Notes Before Use

First, automated posting and engagement must respect platform rules. A tool can improve efficiency, but it cannot remove the need for account safety and compliance.

Second, generated content still needs human review. Ads, brand posts, and cross-language content can all carry factual, copyright, or tone risks.

Third, monetization features involve commercial tasks, so settlement rules, disclosure requirements, and platform policies should be checked before use.

Summary

AiToEarn is worth watching because it treats content operations as a workflow, not just a writing task. For creators and small teams, the attractive part is saving repeated work across platforms. For developers, the interesting part is MCP and agent integration.

What Is AI-Trader? A Platform Where AI Agents Publish Trading Signals and Run Paper Trading

Tue, 19 May 2026 10:56:50 +0800

HKUDS/AI-Trader is a trading platform project for AI Agents. The README positions it as an “Agent-Native Trading Platform”, aiming to let AI Agents connect to the platform, publish trading signals, join discussions, copy trades, and use market data.

Project URL: https://github.com/HKUDS/AI-Trader

Platform URL: https://ai4trade.ai

At the time of writing, the GitHub API showed about 18k stars and Python as the main language. The repository API did not return a clear license value, so users should confirm licensing terms before formal use.

This article is only an introduction to the open source project and is not investment advice. Automated trading involves real capital risk. No strategy, signal, or agent output can guarantee returns.

Positioning

The core idea of AI-Trader is simple: humans have trading platforms, and AI Agents may also need their own trading platform.

According to the README, any AI Agent can read the platform Skill file and register quickly:

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

After connection, agents can publish trading signals, join community discussions, copy strategies from high-performing traders, sync signals to multiple brokers, and accumulate points through prediction performance.

Main Features

The README lists capabilities including:

Instant Agent Integration: quick access for AI Agents.
Collective Intelligence Trading: multiple agents discuss and collaborate on trading ideas.
Cross-Platform Signal Sync: sync trading signals across platforms.
One-Click Copy Trading: follow selected traders or agents.
Universal Market Access: stocks, crypto, FX, options, futures, and more.
Three Signal Types: strategy, action, and discussion signals.
Reward System: earn points through signals and attention.

From a product perspective, it is not just a local quantitative backtesting framework. It combines agents, signals, discussion, copy trading, and paper trading in one platform layer.

Two Types of Users

The README divides users into two groups.

The first group is Agent Traders. AI Agents read the Skill document, connect to the platform, install required components, and publish signals.

The second group is Human Traders. Regular users can visit the platform, create accounts, browse signals, or follow better-performing traders.

Together, this forms a structure where AI Agents produce signals, and humans or other agents consume those signals.

Architecture

The README shows the project structure as:

AI-Trader (GitHub - Open Source)
念岸岸 skills/              # Agent skill definitions
念岸岸 docs/api/            # OpenAPI specifications
念岸岸 service/             # Backend & frontend
岫   念岸岸 server/         # FastAPI backend
岫   弩岸岸 frontend/        # React frontend
弩岸岸 assets/              # Logo and images

The repository puts agent skills, API documentation, backend, and frontend in one place. The backend uses FastAPI and the frontend uses React. The README update notes also mention that the web service and backend workers have been separated so pricing, historical performance, settlement, and market intelligence jobs can run in the background without affecting pages and health checks.

Why It Is Worth Watching

AI-Trader is worth watching not because “AI can automatically make money”, but because it makes the interface between agents and financial scenarios more explicit.

There are several interesting points:

First, it uses a Skill document as the agent access point. This is close to how Codex, Claude Code, OpenClaw, and other agent tools work.

Second, it places trading signals, discussion, copy trading, and a reward system at the platform layer instead of only providing a local script.

Third, it provides OpenAPI documentation, making the platform interfaces easier for developers to understand.

Fourth, it supports paper trading. For research on agent decision-making, a simulated environment is much safer than giving agents direct access to real money.

Risks and Boundaries

Automated trading is a high-risk scenario.

First, signals generated by agents are not investment advice. Models can hallucinate, overfit, misread news, or fail to understand extreme market conditions.

Second, copy trading has contagion risk. If a wrong signal is widely followed, losses may concentrate.

Third, real capital access must be strictly isolated. Do not give agents unlimited order permissions.

Fourth, licensing and compliance need to be confirmed before commercial or production use, especially when brokers, financial data, and user accounts are involved.

Who It Is For

AI-Trader is suitable for researchers studying agent decision-making, developers exploring financial agent interfaces, and teams interested in paper trading or signal collaboration. It is not suitable for users looking for guaranteed profit tools.

Summary

AI-Trader is a signal and paper-trading platform designed around AI Agents. The useful way to read it is not “AI helps you earn money”, but how agents should connect to financial workflows, publish signals, and operate inside controlled risk boundaries.

What Is CloakBrowser? A More Realistic Browser for Playwright and Puppeteer

Tue, 19 May 2026 10:56:50 +0800

CloakHQ/CloakBrowser is an open source project for browser automation. It is not just a Playwright configuration file or a small JavaScript patch. The project is built around a custom Chromium binary, aiming to make browser fingerprints, WebGL, Canvas, audio, fonts, GPU, screen data, WebRTC, and network timing look closer to a normal browser environment.

Project URL: https://github.com/CloakHQ/CloakBrowser

At the time of writing, the GitHub API showed about 15k stars, Python as the main language, and an MIT license. The README positions it very directly: a Stealth Chromium launcher that can replace the default Playwright or Puppeteer browser launcher.

What Problem Does It Solve

Many automation scripts expose obvious automation signals when they run in a regular Headless Chromium environment, for example:

navigator.webdriver.
Headless user agent traces.
Unnatural plugin, font, screen, and GPU fingerprints.
CDP behavior that does not match real user input.
Temporary profiles without normal browsing traces.

CloakBrowser moves part of this work into the Chromium source and binary layer, instead of relying only on runtime configuration or JavaScript patches. For Playwright users, the API still feels close to familiar browser automation, but the underlying browser is replaced with the custom build provided by the project.

This type of tool is suitable for compliant automation testing, site compatibility checks, anti-abuse system self-testing, and agent browser environment experiments. It should not be used for unauthorized access, account abuse, bypassing platform risk controls, or violating service terms.

Basic Usage

Python installation:

`1`	`pip install cloakbrowser`

JavaScript / Node.js installation:

`1`	`npm install cloakbrowser playwright-core`

The Python example in the README looks close to Playwright:

from cloakbrowser import launch

browser = launch()
page = browser.new_page()
page.goto("https://protected-site.com")
browser.close()

The JavaScript usage is also straightforward:

import { launch } from 'cloakbrowser';

const browser = await launch();
const page = await browser.newPage();
await page.goto('https://protected-site.com');
await browser.close();

Browser Profile Manager

CloakBrowser also provides a Browser Profile Manager. It is meant for managing browser profiles, testing environments, and repeated automation tasks more conveniently.

`1`	`docker run -p 8080:8080 -v cloakprofiles:/data cloakhq/cloakbrowser-manager`

After starting it, open:

`1`	`http://localhost:8080`

The value of a profile manager is that the browser environment does not have to be a disposable temporary profile every time. For long-running tests, compatibility checks, and agent experiments, stable profiles are often easier to debug.

How It Differs From Regular Playwright

Regular Playwright focuses on reliable browser control. CloakBrowser focuses on making the browser environment itself look more natural.

In practice, the difference is:

Playwright provides the automation API.
CloakBrowser provides a custom browser runtime.
Playwright is suitable for general testing and automation.
CloakBrowser is more focused on realistic browser behavior and fingerprint consistency.

This does not mean CloakBrowser can magically solve all detection problems. Websites can still use behavior, frequency, account reputation, network environment, and business rules to judge risk.

What To Watch Out For

First, compliance matters. A more realistic automation environment does not mean unrestricted use. Automated access should respect authorization, rate limits, robots or platform rules, and service terms.

Second, the project depends on a custom Chromium build. Teams should pay attention to version compatibility, security updates, and whether the binary source is acceptable for production use.

Third, realistic browser behavior is only one part of the picture. If the script performs unnatural operations, sends requests too frequently, or uses accounts in abnormal ways, the result will still be risky.

Who It Is For

CloakBrowser is more suitable for developers and teams already using Playwright, Puppeteer, browser agents, QA automation, or web compatibility testing. It is less suitable for users who just want a no-code browser automation product.

Summary

CloakBrowser is interesting because it moves browser automation from “just control a headless browser” toward “use a browser environment closer to real users.” For testing, agent experiments, and controlled research, it is worth watching. For real-world use, the important boundary is still compliance, authorization, and risk control.

llama.cpp b9196 Update: Windows Prebuilt Binaries Support CUDA 13.1, Vulkan, HIP, and SYCL

Mon, 18 May 2026 23:20:00 +0800

The recent Windows release of llama.cpp is much friendlier for local LLM users. In the past, running GGUF models on Windows often meant dealing with environment issues: CUDA version mismatches, missing DLLs, incompatible drivers, failed CMake builds, wrong environment variables, or complicated Vulkan / HIP / SYCL setup.

Now the official Release page provides several Windows prebuilt packages. In many cases, users no longer need to compile from source. Download the right build, unzip it, place the model file, and you can start a local inference service directly.

What llama.cpp Is Good For

llama.cpp is one of the most commonly used local GGUF model inference frameworks. It is lightweight, cross-platform, can run on CPU or GPU, and has a large ecosystem of GGUF model resources.

Common model families include:

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

As GGUF quantized models become more common, many open source models now provide GGUF versions suitable for local deployment. For regular users, the value of llama.cpp is simple: you do not need a full complex inference stack to run a usable chat service on your own machine.

How to Choose a Windows Prebuilt Build

Windows users can choose different builds based on their hardware:

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

If you use an NVIDIA GPU, the CUDA build is usually the first choice. Cards such as RTX 3060, 4060, 4070, 4080, and 4090 are better suited to the CUDA route.

If you use an AMD GPU, try HIP or Vulkan. In practice, Vulkan can sometimes be easier than HIP, especially if you do not want to set up a full ROCm environment.

If you use Intel integrated graphics or an Arc GPU, try SYCL or Vulkan. Performance is usually behind NVIDIA CUDA, but it is already enough to test many small and medium GGUF models.

The CPU build is suitable for users without a discrete GPU, or for those who only want to verify a model or run small models. It will not be fast, but deployment is the simplest.

Start a Regular GGUF Model

Assume you have downloaded the llama.cpp Windows prebuilt package and placed your model in the models directory. Enter the extracted llama.cpp directory and run:

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

Here, -m points to the GGUF model file, and -ngl 999 tells llama.cpp to load as many layers as possible onto the GPU. The actual number depends on VRAM size, model size, and quantization format.

After startup succeeds, open this address in your browser:

`1`	`http://127.0.0.1:8080`

You will enter the local web chat interface.

If VRAM is not enough, switch to a smaller model or a lower quantization version, such as Q4 or Q5 GGUF files. Do not only look at parameter count; also check quantization format and context length settings.

Start a Multimodal Vision Model

Multimodal vision models usually need more than the main model file. They also need an mmproj vision projection file. Start them by specifying both:

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

Common uses include:

OCR recognition
Screenshot understanding
Webpage screenshot analysis
Image Q&A
Simple visual content judgment

For example, Qwen2-VL / Qwen2.5-VL models are useful for Chinese screenshot understanding, OCR, and image-text Q&A. Make sure the main model and mmproj file match; version mismatches can easily cause loading failures or abnormal output.

Use a bat Script to Manage Multiple Models

If you keep multiple models locally, you can write a simple .bat script to switch between them. The following example needs your own path and model names:

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

Save it as UTF-8, then change the extension to .bat. Double-clicking the script lets you choose different models by number.

Three Things to Check When Choosing Models

First, check hardware. More VRAM means you can run larger models. If VRAM is limited, do not force a large model; start with 7B, 8B, or a lower quantization version.

Second, check the use case. For everyday Q&A, summarization, and rewriting, small models or medium quantization are often enough. For coding, long-document analysis, or multimodal understanding, you need stronger models and more VRAM.

Third, check licenses and safety boundaries. Many community-modified models have different capabilities, restrictions, and licenses. Before downloading, confirm the source, license, intended use, and risks. Do not hand production work directly to models from unclear sources.

Common Issues

If startup reports missing DLLs, first confirm that the downloaded package matches your GPU route. NVIDIA users should not download the HIP build by mistake, and AMD users should not download the CUDA build.

If model loading is slow, the model may be too large, the disk may be slow, or part of the model may be falling back to CPU due to insufficient VRAM.

If the web page does not open, check whether the command line service started successfully, then confirm the port is 8080. If the port is occupied, check llama-server parameters and change the port.

If a multimodal model behaves incorrectly, first check whether the mmproj file matches the main model instead of only changing prompts.

Summary

The value of these Windows prebuilt packages is that they lower the entry barrier for local AI. Many users previously got stuck at compilation and dependency setup. Now they can move faster into downloading models, starting a service, and testing results.

For Windows users, the route can be summarized simply:

NVIDIA: prefer CUDA.
AMD: try Vulkan first, then HIP.
Intel: try SYCL or Vulkan.
No discrete GPU: use the CPU build for small models.

Before real use, still confirm model source, license, VRAM needs, and actual results. Local AI gives you control, offline operation, and low latency, but it is not free of cost: model management, hardware resources, and output quality are still your responsibility.

Source: https://www.freedidi.com/24211.html

A Survey of Mainstream AI PPT Tools: How to Choose Between Auto Generation, Web Slides, PPTX, and Image-Based Workflows

Mon, 18 May 2026 22:29:43 +0800

AI for PPT is no longer just “enter a title and apply a template.” In AI coding environments such as Claude Code, Codex, and Cursor, PPT generation is becoming a set of installable, reusable Agent Skills: some output web presentations, some generate truly editable .pptx files, some use image models to turn each slide into a visual draft, and some let AI operate PowerPoint files through MCP.

This article looks at a group of mainstream PPT-related Skills. The useful part is not only the list itself, but the way these tools can be separated by delivery format. Before choosing a tool, ask one question first: who will edit the final deliverable, where will it be presented, and does it need ongoing collaboration?

Several Routes

1. HTML Web Presentations

Representative projects include frontend-slides, guizang-ppt-skill, and html-ppt-skill.

The strength of this route is visual expressiveness. CSS animations, Canvas, WebGL, and responsive layouts are all available. The result can be opened directly in a browser, making it suitable for technical talks, product launches, Demo Day presentations, and talks with a strong personal style.

The trade-off is also clear: after delivery, it is not ideal for clients who need to edit text line by line. If the client receives HTML instead of a PowerPoint file, later changes often need to go back through the generation workflow.

If you only care about HTML presentations, frontend-slides feels like a high-star general entry point, guizang-ppt-skill is stronger in aesthetic constraints and themed style, and html-ppt-skill stands out for its number of themes, layout options, and presenter mode.

2. Native PPTX

Representative projects include mckinsey-pptx, ppt-agent-skills, claude-office-skills, and ppt-master.

This is the most stable route for business delivery. As long as the client asks to “edit text, change images, and apply a company template in PowerPoint,” the final output needs to land in .pptx.

ppt-master is especially worth a separate look. Its idea is to have the LLM generate SVG first, then convert it into native PowerPoint DrawingML objects. The goal is to keep text boxes, shapes, and charts editable inside PPTX. It also supports generating PPTX from PDF, DOCX, URL, and Markdown, as well as template replication, animation, narration, and local preview.

This route works well for consulting deliverables, company reports, white paper presentations, and turning long reports into PPT decks. The downside is that the visual ceiling is usually limited by PowerPoint itself, so complex effects are not as free as HTML or image-based routes.

3. AI Image-Driven Workflows

Representative projects include NanoBanana-PPT-Skills, gpt_image_2_skill, and ppt-image-first.

This route treats each slide as a visual image first, then places the images into PPTX or another container. Its advantage is a high level of visual completion, especially for covers, social media graphics, visual proposals, and communication-oriented content.

The problem is poor editability. A page is essentially an image. If you later need to change a title, replace a paragraph, or move an icon, you may need to regenerate it. It is good for “it needs to look good,” but not for “the client will revise it repeatedly.”

4. MCP / Protocol Layer

Representative projects include Office-PowerPoint-MCP-Server and PPTAgent.

These tools do not necessarily generate a complete PPT directly. Instead, they give AI an interface for operating PowerPoint. After connecting through MCP, the model can read, modify, and write .pptx files.

This route fits workflows where a PPT file already exists and AI is needed to help revise it. Examples include batch format changes, rearranging pages based on feedback, or asking the model to check whether each slide matches the goal. PPTAgent emphasizes reflective generation, meaning it checks back after generating each slide. That direction is useful for reducing the “AI PPT feels rough” problem.

5. Integrated Design Platforms

Representative projects include open-design and docsagent.

These projects go beyond PPT generation itself. open-design is more like a local-first design platform that can generate prototypes, slides, images, and videos, with support for multiple export formats. docsagent is not a PPT tool, but it can index and chat with local documents, making it useful as a material organization layer before generating PPT.

If your need is not a one-off PPT, but a fuller workflow from materials, design, and prototypes to delivery, this type of platform is more worth watching.

Skill Metadata

Star counts come from the original crawl result on 2026-05-15. They are only useful as a popularity reference. Before actual use, open the repositories again to confirm maintenance status, README, and LICENSE.

Skill	Author	Links	Star	Language	Route
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	HTML web presentation
guizang-ppt-skill	@op7418 (Guizang)	Site article: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	HTML web presentation
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	HTML web presentation
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	Native PPTX
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	Native PPTX
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	Native PPTX
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	Native PPTX
NanoBanana-PPT-Skills	@op7418 (Guizang)	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	AI image-driven
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	AI image-driven
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	AI image-driven
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / protocol layer
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / protocol layer
open-design	@nexu-io	Site article: open-design GitHub: nexu-io/open-design	40,822	TypeScript	Integrated design platform
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	Integrated design platform

How to Choose

If the client needs to continue editing, prioritize the native PPTX route, especially ppt-master, mckinsey-pptx, and ppt-agent-skills.

If you are presenting yourself and visual expression matters more than later editing, prioritize the HTML route, especially frontend-slides, guizang-ppt-skill, and html-ppt-skill.

If the goal is a poster-like, cover-like, or shareable visual, prioritize the image route, such as ppt-image-first, gpt_image_2_skill, and NanoBanana-PPT-Skills.

If you already have a PPT file and only want AI to help read, edit, and rearrange it, look at the MCP route.

For explicit scenarios such as academic talks, marketing, translation, or compressing long reports into slides, you can also look for vertical Skills instead of forcing a general-purpose PPT generator to do everything.

Final Notes

Open source projects should not be judged by Star count alone. Before actual use, confirm three things:

Whether the LICENSE allows your use case.
Whether the generated output meets delivery requirements, especially editability.
Whether the cost is acceptable, including model calls, image generation, large-context models, and possible cloud service fees.

These tools change quickly. Star counts will change, and project maintenance status will change too. But the selection logic is relatively stable: decide the delivery format first, then look at specific tools. Whether a PPT is for speaking, editing, or viewing often narrows the choices by more than half.

wx-cli Explained: Query Local WeChat Chat History from the Command Line

Mon, 18 May 2026 21:02:21 +0800

wx-cli is a local WeChat data command-line tool written in Rust. Its goal is to let you query your own WeChat sessions, chat history, contacts, group members, favorites, Moments, official account articles, attachments, and statistics from the terminal.

It is not a cloud-based WeChat sync service, and it is not a chatbot. It is closer to a local read-only data retrieval layer: WeChat still runs on your machine, the data still stays on your machine, and wx-cli decrypts, caches, and queries local databases on demand before returning YAML or JSON output for humans or agents.

Two points make this project worth watching. First, it turns local WeChat data access into a cross-platform CLI. Second, it explicitly considers AI Agent workflows for tools such as Claude Code, Cursor, and Codex, providing a SKILL.md file and structured output with meta fields.

What wx-cli Can Do

According to the project README, wx-cli covers a fairly complete set of features:

View recent sessions and unread sessions.
Query chat history for a contact or group.
Search keywords across the whole local database.
View newly arrived messages.
Query contacts, group members, and group nicknames.
Query favorites.
Query Moments notifications, timelines, and post bodies.
Query official account article pushes.
List and extract image attachments from chats.
Generate chat statistics.
Export chat history as Markdown or JSON.

These capabilities make it more than a “chat history search” tool. It turns local WeChat data into a searchable, analyzable, and exportable personal knowledge source.

Why It Fits AI Agents

Many CLI tools are designed only for people: their output is just a block of text. wx-cli clearly takes agent consumption into account.

The README notes that commands such as history, search, sessions, unread, new-messages, stats, and attachments include meta information. That metadata contains result status, unknown shards, the latest timestamp in matched data, the latest session timestamp, and similar fields.

This is useful for agents. AI does not only need to know “what was found”; it also needs to know whether the result is fresh, whether messages may be missing, and whether it should run init again. For example:

status can indicate whether the result is ok or possibly_stale.
unknown_shards can indicate whether there are database shards for which the daemon currently has no key.
chat_latest_timestamp tells the agent the latest message time in the matched data.
session_last_timestamp helps determine whether the local session record is clearly newer than the query result.

This kind of metadata reduces AI misjudgment and makes tools such as Claude Code, Cursor, and Codex more reliable when working with WeChat data.

Installation

The project recommends cross-platform installation via npm:

`1`	`npm install -g @jackwener/wx-cli`

It also supports curl installation on macOS / Linux:

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

On Windows, run this in an administrator PowerShell:

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

If you want to build from source, you can use Rust directly:

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

The build artifact is target/release/wx, or wx.exe on Windows.

Relationship with Agent Skills

wx-cli also provides a Skill for AI Agents. You can install it into Claude Code, Cursor, Codex, and other Skills-compatible environments through the skills CLI:

`1`	`npx skills add jackwener/wx-cli`

Install it globally:

`1`	`npx skills add jackwener/wx-cli -g`

After installation, the agent reads the repository’s SKILL.md and learns how to install, initialize, and call wx-cli.

That means you can ask an agent to help with local information organization tasks such as:

Find keywords discussed in a group chat during a specific period.
Summarize recent unread messages.
Export recent chat history from a specific session.
Search official account article links.
Analyze posting statistics in a group chat.

The premise is unchanged: the data must be your own WeChat data on your own machine.

Basic Usage

Before initialization, keep WeChat running. Requirements differ by platform.

On Linux:

`1`	`sudo wx init`

On Windows, use an administrator PowerShell:

wx init

macOS is more involved. The README explains that, with the default path, you first need to ad-hoc sign WeChat so the tool can scan process memory. After re-signing, you also need to clean old TCC authorization records, otherwise permissions such as screen capture, video calls, and microphone access may look enabled while actually being denied. The project documentation also warns that re-signing may cause macOS to repeatedly prompt for access to other apps’ data.

After initialization, verify the setup with:

`1`	`wx sessions`

If you can see recent sessions, the basic path is working. The daemon starts automatically on the first call.

Common Command Examples

View recent sessions:

`1`	`wx sessions`

View unread sessions:

`1`	`wx unread`

Show only human unread sessions while filtering out official accounts and folded entries:

`1`	`wx unread --filter private,group`

View recent chat history for a session:

`1`	`wx history "张三"`

Fetch more history:

`1`	`wx history "张三" -n 2000`

Query a group chat by time range:

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

Search the whole database:

`1`	`wx search "关键词"`

Search for a keyword inside a group:

`1`	`wx search "会议" --in "工作群" --since 2026-01-01`

Export chat history:

1
2

wx export "张三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

These commands are well suited for scripts or agents, especially when combined with --json.

Moments and Official Account Articles

wx-cli does not only query chats.

Moments-related commands are split into notifications and posts:

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "关键词"

Note that Moments data only covers content that has appeared locally. The WeChat client downloads data on demand; if something has never appeared locally, the tool cannot retrieve it out of thin air.

Official account articles are queried through separate commands:

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

It returns fields such as account name, title, URL, summary, cover image, and timestamp. This is useful for people who organize references, collect articles, or build local knowledge bases.

Attachment Extraction

Image attachments in WeChat chats are usually not ordinary readable image files. They are often .dat files under xwechat_files/<wxid>/msg/attach/....

wx-cli provides a two-step flow:

1
2

wx attachments "张三"
wx attachments "AI群" --kind image -n 100

After getting an attachment_id, extract it:

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

The output report includes fields such as md5, dat_path, dat_size, output, format, and decoder. The README says it supports decoding modes such as legacy XOR, V1 fixed-AES, and V2 AES + XOR, while image key extraction differs across platforms.

This capability is powerful, but it requires extra care: only process your own data, and do not use it for unauthorized data access.

Why the Daemon Architecture Matters

The performance story of wx-cli comes from its daemon.

The README describes the structure roughly as:

wx (CLI) ──Unix socket──▶ wx-daemon (background process)
                              │
                    ┌─────────┴──────────┐
               DBCache               contact cache
           (mtime-aware reuse)

After the first decryption, the daemon persists database and mtime information under ~/.wx-cli/cache/. If the database file mtime has not changed, later calls can reuse the cache without decrypting everything again.

This is important for command-line queries and agent loops. An agent may query several sessions, search multiple keywords, then run statistics and exports. If every call had to rescan and decrypt everything, the experience would be poor. The daemon cache makes it feel closer to a local query service.

A Brief Look at the Principle

The project README explains the principle directly: WeChat 4.x encrypts local databases with SQLCipher 4, and WCDB caches the derived raw key in process memory.

wx-cli uses platform-specific methods to scan WeChat process memory, match key patterns, extract the key, and then let the daemon decrypt and cache databases on demand.

The underlying mechanism differs by platform:

macOS uses the Mach VM API.
Linux uses /proc/<pid>/mem.
Windows uses VirtualQueryEx and ReadProcessMemory.

These details explain why initialization usually requires elevated permissions, and why macOS involves signing and privacy authorization.

Boundaries and Risks

Tools like this must start with boundaries.

The wx-cli README disclaimer is clear: the tool is only for learning and research, for decrypting your own WeChat data, and it requires users to comply with applicable laws and regulations. It must not be used for unauthorized data access.

In practice, it is also wise to keep these points in mind:

Use it only on your own computer and your own WeChat account.
Do not casually upload exported chat history to cloud models.
When using an agent to analyze chat history, first confirm the API provider and cross-border data risks.
After exporting Markdown / JSON, pay attention to file permissions and backup locations.
On company or shared devices, confirm compliance and authorization first.

A local tool does not mean there is no privacy risk. It reduces the default path for data to leave your machine, but if you hand the output to a cloud model, cloud drive, or third-party script, the risk comes back.

Who It Is For

wx-cli fits these scenarios:

Quickly search your own historical WeChat messages locally.
Export a session as Markdown or JSON.
Analyze posting activity in a group chat over a time range.
Let Claude Code, Cursor, Codex, and similar agents organize local WeChat material.
Collect official account article links into a local knowledge base.
Study WeChat’s local database structure and decryption flow.

It is less suitable for these scenarios:

You want cloud-based WeChat sync.
You want to bypass someone else’s device or account permissions.
You want a point-and-click GUI and do not want to touch the command line.
You do not want to deal with macOS permissions, Windows administrator rights, or Linux sudo.

Summary

The value of wx-cli is not merely “searching WeChat chat history from the command line.” More precisely, it turns local WeChat data into a local data source that can be queried, exported, and consumed by agents.

Its daemon architecture solves repeated decryption and query performance issues; the meta wrapper helps AI Agents judge whether results are fresh; and SKILL.md lets tools such as Claude Code, Cursor, and Codex understand how to install and use it.

If you often need to find information in WeChat, organize group chats, export records, or build a personal knowledge base, wx-cli is worth watching. But one bottom line should always remain clear: only process your own data, and manage exported results carefully.

References

jackwener/wx-cli GitHub repository

Open Design Explained: Turning Claude Code and Codex into AI Design Tools

Mon, 18 May 2026 18:57:16 +0800

Open Design is an open-source AI design project from nexu-io. Its positioning is local-first and open-source, as an alternative direction to Claude Design and Figma.

The problem it targets is clear: Claude Design showed that large models can generate design artifacts directly, but if this capability only exists inside a closed, cloud-only, single-model product, users cannot easily self-host, connect their own agents, swap models, build private design systems, or put outputs into a local workflow.

Open Design does not try to build a new foundation model. Instead, it connects the coding-agent CLIs already installed on your computer into a design workspace. Claude Code, Codex, Cursor Agent, Gemini CLI, OpenCode, Qwen, Copilot CLI, Kimi, DeepSeek TUI, and similar tools can become its design engine.

What is Open Design?

Open Design can be understood as a combination of three parts:

A Web UI for chat, preview, project management, and export.
A local daemon that schedules agents, manages files, stores projects, and provides APIs.
A set of Skills, Design Systems, and templates that guide agents toward design-quality artifacts instead of generic AI pages.

After the user enters a request, Open Design does more than pass a sentence to a model. It first asks the user to refine the design brief, choose the scenario and direction, then injects project metadata, the active design system, Skill files, templates, and checklists into the agent’s context. The agent reads and writes files inside a real project folder and produces an artifact that can be previewed in a sandboxed iframe.

This makes it closer to an AI design workflow than a one-shot webpage generator.

Why it differs from ordinary AI webpage generation

Many AI tools can generate an HTML page. Open Design’s focus is not “make the model write a page,” but “make the model follow a design workflow to deliver artifacts that can be previewed, exported, and iterated.”

It emphasizes several design choices:

Ask questions before generating. A new design brief starts with an interactive question form to lock down audience, tone, brand context, constraints, and visual direction.
Skills are files, not black-box plugins. Each Skill is made of SKILL.md, assets/, and references/, so it can be read, replaced, and extended.
Design Systems are Markdown, not fixed theme JSON. Color, typography, spacing, components, motion, brand voice, and anti-patterns can be written into DESIGN.md.
The agent works in a real project directory. It can read templates, write files, generate images, and output .pptx, .pdf, .zip, and other files.
Artifacts are previewed in a sandboxed iframe, reducing the risk of directly executing uncontrolled code.

The goal is to make AI behave more like a design collaborator with rules, assets, and checklists.

Which agents does it support?

One highlight of Open Design is that it treats agents as the runtime instead of locking into one model vendor.

The README lists support for Claude Code, Codex CLI, Devin for Terminal, Cursor Agent, Gemini CLI, OpenCode, Qwen Code, Qoder CLI, GitHub Copilot CLI, Hermes, Kimi, Pi, Kiro, Kilo, Mistral Vibe, DeepSeek TUI, and more. It detects these CLIs from PATH and lets users switch between them.

If no local CLI is available, it can also use an OpenAI-compatible BYOK proxy. Users provide baseUrl, apiKey, and model name, and the daemon normalizes streaming output into the same chat stream.

This design brings several benefits:

It does not lock users into one model.
It can reuse agents users have already installed and configured.
Local file reads and writes are managed by the daemon, making the permission boundary clearer.
For enterprises and advanced users, it is easier to connect custom models and API providers.

Skills and Design Systems are the core assets

Open Design bundles many Skills and Design Systems. The README says the built-in Skills cover web prototypes, SaaS landing pages, dashboards, mobile apps, gamified apps, social carousels, magazine posters, decks, weekly updates, finance reports, HR onboarding, invoices, kanban boards, OKRs, and more.

Design Systems provide brand-grade visual constraints for the agent. The repository description mentions sources such as Linear, Stripe, Vercel, Airbnb, Tesla, Notion, Apple, Anthropic, Cursor, Supabase, Figma, Xiaohongshu, and others.

The relationship is simple:

Skill decides what kind of artifact should be delivered.
Design System decides what brand style the artifact should follow.

Without these two layers, AI can easily produce generic pages that look familiar but lack judgment. With Skills and Design Systems, the model has clearer task boundaries, visual references, and review rules.

What can it generate?

Open Design is not limited to web prototypes.

According to the README, it covers web, desktop, mobile prototypes, slides, images, videos, HyperFrames, and more. It also supports export formats such as HTML, PDF, PPTX, ZIP, and Markdown. Media generation is included in the same design loop, covering posters, avatars, infographics, illustrated maps, short videos, and HTML-to-MP4 motion graphics.

This gives it a wide range of use cases:

Startup teams can create pitch decks quickly.
Product teams can generate landing pages or functional prototypes.
Operations teams can create campaign pages, social media images, and weekly reports.
Designers can use it for moodboards, visual directions, and first-pass layouts.
Developers can turn requirements into runnable frontend artifacts.

Its value is not just generating one page, but bringing multiple content forms into the same agent workflow.

What local-first means

Open Design emphasizes local-first. It does not hand everything to a remote SaaS backend. Instead, it runs a local daemon and project workspace.

The architecture described in the README roughly looks like this:

The frontend uses Next.js, React, and TypeScript.
The local daemon uses Node, Express, SQLite, and SSE.
Projects, sessions, messages, tabs, and templates are stored in local SQLite and .od/projects/<id>/.
Agents are started through child_process.spawn and read/write inside project artifact folders.
Preview is rendered through a sandboxed iframe.
Export includes HTML, PDF, PPTX, ZIP, and Markdown.

This structure is better for users who want design outputs to stay on their machine, local agents to be connected, API keys to remain under their control, and private workspaces to be maintained.

However, local-first does not mean fully offline. Actual generation still depends on the agent and model you use. If you use a cloud model API, content still goes to that provider. A more accurate description is that Open Design brings workspace, scheduling, files, and preview back to local control, while leaving the model layer to the user.

Relationship with Claude Design and Figma

Open Design explicitly describes itself as an open-source alternative direction to Claude Design and Figma, but it is not a traditional Figma clone.

Figma is a professional tool for manual design editing, collaboration, and delivery. Open Design is more agent-native: users drive agents through natural language, forms, Skills, and design systems to produce runnable artifacts.

It combines several ideas:

Claude Design’s artifact-first experience.
Figma’s design-system awareness.
File reading, writing, and execution from agents such as Claude Code and Codex.
Local daemon project management and sandboxed preview.

So it may not replace the full professional design workflow, but it is well suited as a fast path from idea to previewable prototype.

Who is it for?

Open Design is better suited for:

Developers already using Claude Code, Codex, Cursor, Gemini CLI, and similar agents.
Users who want AI design outputs managed inside local project folders.
Startup teams that need web prototypes, decks, posters, and marketing assets quickly.
Advanced users who want to customize Skills, Design Systems, and prompt stacks.
Teams that do not want to be locked into a single model or cloud product.

It is less suitable for:

Lightweight users who only want to open a webpage, type one sentence, and download an image.
Users who do not want to touch Node, pnpm, daemons, CLIs, or local configuration.
Professional Figma workflows that need mature collaboration, design review, and vector editing.

In short, Open Design is more of a tool for agent users and technical design teams than a lightweight design SaaS for everyone.

Things to watch

The README marks the project as 0.8.0-preview and notes that it is still evolving quickly. That energy is valuable, but it also means APIs, data directories, desktop migration, Skills structure, and export flows may change.

Before using it seriously:

Do not treat it as a fully stable enterprise design platform.
Try the workflow with test projects before importing important materials.
Back up .od/ before migration, and make sure the daemon and desktop app are stopped.
When using BYOK, pay attention to API keys, proxy addresses, and local private-network access risks.
Review generated designs manually, especially for brand, copyright, copy, and visual consistency.

The benefit of an open-source project is that it can be inspected, modified, and contributed to. The cost is that you need to accept some engineering friction.

Summary

The interesting part of Open Design is not just that it is an open-source Claude Design alternative. What matters is how it organizes Agent CLIs, Skills, Design Systems, a local daemon, and sandboxed preview into one design workflow.

It pushes design generation from a single prompt toward a more structured process: ask questions, choose direction, load a design system, read the Skill, write real files, preview the artifact, then export the result.

If you already use Claude Code, Codex, or Cursor for coding work, Open Design is worth watching. It represents a new product shape: AI is not only drawing one picture for you, but working inside a local project space, following design systems and task skills to generate design artifacts that can keep evolving.

References

nexu-io/open-design GitHub repository

DeepSeek-V4 KV Cache Explained: Why 1M Context Uses Less VRAM

Mon, 18 May 2026 18:38:26 +0800

The real cost of long-context models is often not whether they can accept one million tokens, but how much VRAM the KV Cache consumes during inference.

During Transformer decoding, every newly generated token needs access to the Key and Value states of previous tokens. The longer the context, the larger the KV Cache. A larger KV Cache puts pressure on VRAM, memory bandwidth, time to first token, and throughput.

DeepSeek-V4 is interesting because it does not only reduce cache along the attention-head dimension. It pushes compression into the sequence-length dimension. According to Hugging Face’s discussion of DeepSeek-V4, in a 1M-token setting, DeepSeek-V4-Pro’s KV Cache is about 10% of DeepSeek-V3.2, and about 2% of a common bf16 GQA architecture.

That is the key difference: DeepSeek-V4 does not merely store each KV entry in a smaller format. It reduces the number of KV entries that must be kept and searched over long history.

Several generations of KV Cache optimization

KV Cache optimization has evolved through several routes.

The first is traditional MHA, or Multi-Head Attention. Each Query head typically has its own Key/Value heads. The structure is direct, but under long context the cache grows linearly with sequence length, making VRAM pressure heavy.

The second is GQA, or Grouped Query Attention. Multiple Query heads share fewer Key/Value heads. Many modern models such as LLaMA, Mistral, and Qwen use similar ideas. It significantly reduces KV head count and is now a common long-context optimization.

The third is MLA, or Multi-head Latent Attention. DeepSeek-V2 and DeepSeek-V3 use this route, compressing Key/Value into low-rank latent representations and further reducing cache along the attention-head dimension.

The fourth is DeepSeek-V4’s hybrid compressed attention. It focuses on sequence length: instead of only reducing how much KV each token stores, it compresses multiple historical tokens into fewer KV entries and retrieves them through sparse or dense attention.

Roughly:

MHA: every head remembers separately.
GQA: multiple Query heads share memory.
MLA: each token’s KV representation is compressed into a latent vector.
DeepSeek-V4: many historical tokens are aggregated into fewer compressed memory blocks.

Key change: from head compression to sequence compression

GQA and MLA mainly optimize how much KV each token stores. That works well, but when context reaches 1M tokens, the token count itself becomes the problem.

DeepSeek-V4 compresses old context into blocks. The model does not necessarily preserve full KV for every distant token. Instead, multiple tokens form compressed entries.

It is a bit like reading a very long book: you remember recent pages in detail, while earlier chapters are stored more as summaries, themes, and key clues. DeepSeek-V4’s attention design follows a similar split: keep detail nearby, use compressed representation farther away.

CSA: 4x compression plus sparse retrieval

CSA stands for Compressed Sparse Attention. It is the finer-grained long-context compression mechanism.

In CSA, the model compresses neighboring tokens into fewer KV entries. The Hugging Face Transformers documentation gives a default compression ratio of m=4, meaning roughly every four tokens become one compressed entry.

But it is not simple averaging. CSA uses a learned compression pool and overlapping windows so the model can preserve more useful information. After compression, the query does not attend to all compressed blocks directly. It first uses a Lightning Indexer to score them, selects the most relevant top-k compressed blocks, and then performs the core attention computation.

This gives two benefits:

The number of historical KV entries becomes smaller.
Each query only looks at a relevant subset of compressed blocks.

CSA is suitable for long-range context where details still matter, such as codebases, long documents, and tool-call histories.

HCA: 128x compression plus dense attention

HCA stands for Heavily Compressed Attention, and it is more aggressive.

The Transformers documentation gives a default compression ratio of m'=128. HCA compresses a much longer context span into one compressed entry. Because the compressed sequence becomes very short, it does not need sparse top-k retrieval like CSA. The query can simply perform dense attention over all HCA compressed entries.

HCA acts more like a global summary. It does not try to preserve every detail. Instead, it covers very long history at extremely low cost, helping the model stay aware of global context, long-range topics, and far-away information.

If CSA is “searchable compressed notes,” HCA is closer to a “global table of contents and summary.”

Sliding window: recent context keeps details

DeepSeek-V4 does not compress everything.

In addition to CSA and HCA, it keeps a sliding-window branch for the most recent uncompressed context. The Transformers documentation notes that DeepSeek-V4 attention blocks concatenate long-range compressed branches with sliding-window K/V.

This matters. When generating the next token, the nearest context is often the most important: variable names, function signatures, the current sentence, fresh tool outputs, or the user’s latest instruction. If recent context were over-compressed, output quality would suffer.

So the design is:

Nearby context: preserve uncompressed details.
Mid-to-long context: use CSA for searchable compression.
Farther context: use HCA for heavily compressed global summary.

Hybrid layer stack: different layers use different attention

DeepSeek-V4 does not use one attention mechanism in every layer.

The Hugging Face DeepSeek-V4 article notes that V4-Pro’s 61-layer structure uses HCA in the first two layers, alternates CSA and HCA afterward, and uses a sliding-window MTP block at the end. The Transformers documentation also describes V4-Pro as using two HCA bootstrap layers followed by alternating CSA/HCA layers.

This shows that DeepSeek-V4 treats attention as a layered system. Different layers handle different information roles: some favor global compression, some favor sparse retrieval, and some preserve local windows.

Compared with using one attention type everywhere, this hybrid structure is more complex but better suited to 1M-token context.

FP8 and FP4 further reduce cache cost

DeepSeek-V4’s savings do not come only from compression ratio.

The Hugging Face article notes that most KV entries in V4 use FP8 storage, RoPE-related dimensions remain BF16, and the Lightning Indexer in CSA uses FP4. Compression ratio, low-precision storage, and sparse retrieval together create very low KV Cache usage.

This is a reminder: do not only look at the headline context length. Deployment feasibility is determined by VRAM usage, bandwidth pressure, latency, and implementation quality under long context.

Differences from other models

Compared with traditional MHA, DeepSeek-V4 no longer keeps full attention memory for every token in long history, so cache pressure drops sharply.

Compared with GQA, DeepSeek-V4 does not merely reduce the number of KV heads. It also reduces the number of KV entries for long history. GQA still accumulates cache linearly with sequence length; V4 compresses distant context into blocks.

Compared with DeepSeek-V3’s MLA, V4 extends optimization from “making each token representation more compact” to “compressing the number of historical token entries.” MLA already lowers per-token KV cost significantly, but under million-token context, sequence length remains a bottleneck.

Compared with ordinary sparse attention, CSA compresses first and then performs sparse retrieval over a shorter compressed sequence. HCA goes further, using 128x compression so dense attention becomes cheap.

What it means for agents and long tasks

Agent workflows are especially hungry for long context. They read files, call tools, receive tool results, generate plans, revise plans, and call tools again. The longer the context, the more likely KV Cache becomes the bottleneck.

DeepSeek-V4’s cache design may help in several ways:

Easier handling of long codebases, long documents, and multi-round tool histories.
Less pressure on time to first token and throughput from KV Cache.
Longer context or more concurrent requests on the same hardware.
Million-token context becomes closer to practical deployment, not just a benchmark number.

But compressed attention is not free. Compressing historical tokens into blocks involves information trade-offs. The model must balance saving VRAM with preserving retrievable details. Real performance depends on the task: code navigation, legal documents, long-form QA, and agent toolchains all have different detail-recall needs.

Do not read 2% as 2% of all cost

“KV Cache is about 2% of GQA” is easy to misread.

It mainly refers to KV Cache memory size. It does not mean total inference cost drops to 2%, or that every scenario becomes 50x faster. Inference still includes model weight reads, MoE routing, feed-forward networks, attention computation, scheduling, and communication overhead.

The Hugging Face article separates two numbers: in 1M-token context, DeepSeek-V4-Pro’s per-token inference FLOPs are 27% of DeepSeek-V3.2, while KV Cache is 10%. Cache and compute are different dimensions.

The safer statement is: DeepSeek-V4 greatly reduces KV Cache pressure for ultra-long context, improving deployment feasibility for million-token scenarios. Actual latency and throughput still depend on implementation, hardware, batching, quantization, and inference framework.

Summary

The biggest difference between DeepSeek-V4 and other large models is that it moves KV Cache optimization from the attention-head dimension into the sequence-length dimension.

GQA stores fewer KV heads. MLA makes each token’s KV representation more compact. DeepSeek-V4 further aggregates distant tokens into compressed blocks and combines CSA, HCA, sliding windows, and low-precision storage so million-token context is not immediately blocked by KV Cache.

This is not a single trick. It is a long-context inference architecture: preserve details nearby, compress distant context, retrieve details when needed, and summarize globally when possible.

For developers and agent applications, the meaning is direct: long context is not just about accepting more input. It must be runnable, stable, and affordable. That is what DeepSeek-V4 changes.

References

Claude Code Token-Saving Guide: How Models, MCP, CLAUDE.md, and Skills Affect Cache

Mon, 18 May 2026 18:30:24 +0800

In long Claude Code tasks, Prompt Cache hit rate directly affects cost and speed. Many users know that caching can save tokens, but not which actions make the cache suddenly miss.

The simplest mental model is a left-to-right context chain:

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

The farther left something sits, the more stable it should be and the larger the cache benefit. If a left-side section changes, everything after it may need to be recalculated. If a right-side section changes, the impact is smaller.

So optimizing Prompt Cache in Claude Code is not guesswork. The rule is simple: before a task begins, prepare the model, MCP servers, Skills, CLAUDE.md, and other base context. Once the task starts, change as little of that fixed context as possible.

Prompt Cache does not cache plain text

Prompt Cache is not just a string cache for prompts. In Transformer inference, what matters is the Key/Value state calculated by attention layers from the prefix context, usually called KV cache.

That means two things:

If the prefix stays stable, part of the previous computation can be reused.
If the model, tool definitions, system prompt, or prefix messages change, old cache entries may no longer match.

Anthropic’s documentation summarizes the invalidation hierarchy as tools -> system -> messages. Changes to tool definitions can invalidate the whole cache; system changes affect system and messages; message changes mainly affect message cache.

Claude Code adds more context sources such as CLAUDE.md, Skills, MCP, plugins, and subagents, so it is easier to accidentally break cache reuse.

Cache killer 1: switching models mid-task

Switching models is one of the most expensive changes.

Prompt Cache is isolated by model. Opus, Sonnet, and Haiku have different architectures and weights, so the KV cache calculated from the same text is not interchangeable. If you build a long context in Opus and then switch to Sonnet, Sonnet cannot reuse Opus’s cache.

This creates a counterintuitive result: switching models mid-task to save money may make the previous cache useless. Context that could have been read at cache-read price may need to be written and computed again.

A steadier pattern is:

Keep the main conversation on one model.
Use a subagent for side tasks that can run on a cheaper model.
Let the side agent search, explore, or summarize, then hand a concise result back to the main conversation.

This keeps the long main-context prefix stable and improves cache hit consistency.

Cache killer 2: adding MCP or reloading plugins mid-task

MCP provides tools to Claude Code. When you add an MCP server, the tool list changes, and tool definitions sit at the far left of the context chain.

From a Prompt Cache perspective, when the tool list changes, the system and messages that follow may need to be recalculated. If you use many MCP servers, the tool definitions themselves can be large, so the cost of invalidation becomes obvious.

One detail matters: Claude Code usually reads MCP configuration at session startup. Changing config mid-session may not affect the current session immediately. The dangerous moments are restart, resume, plugin reload, or anything that rebuilds the tool list.

Recommended practice:

Install required MCP servers before starting a long task.
Avoid discovering missing tools halfway through and then reloading.
Reduce default-enabled MCP servers when possible.
Do not keep rarely used MCP servers always enabled.

Stable tool definitions are the foundation of stable Prompt Cache hits.

Cache killer 3: editing CLAUDE.md mid-session

CLAUDE.md is Claude Code’s project memory file. It is useful for build commands, test commands, architecture conventions, code style, and project-specific constraints.

It is helpful, but it also enters the context. Claude’s help documentation explains that CLAUDE.md is read at session start and delivered as a user message. It also benefits from Anthropic Prompt Cache: the first request pays full input price, while later requests can hit the lower cache-read price if the cache is still valid.

The catch is that CLAUDE.md is content-addressed. Once the file changes, the old cache no longer matches.

So avoid frequently editing CLAUDE.md during a long task. Better practices:

Check whether CLAUDE.md is sufficient before the task starts.
Put stable rules in the file and temporary instructions in the current conversation.
Do not edit long-term memory for one-off instructions.
If you must change it, treat the next stage as a new session or new phase.

CLAUDE.md should be stable project guidance, not a scratchpad that changes every round.

Cache killer 4: installing or updating Skills mid-task

Skills are also part of the context. Installing a new Skill, updating a Skill, or changing the Skill list changes what gets injected into the session.

These changes often do not fully take effect until reload, resume, or a new session. Once messages are rebuilt, old cache entries may no longer match.

The same advice applies:

Decide which Skills are needed before starting.
Keep the Skill set stable for the same kind of task.
Avoid installing Skills in the middle of a long task.
If you install a new Skill, treat it as the beginning of a new stage.

For repeatable workflows such as content production, review, deployment, and translation, keeping a fixed Skill set helps keep the context structure stable.

Cache killer 5: idle time exceeding TTL

Prompt Cache does not last forever. A common default TTL is on the order of minutes, and Claude Code-related documentation often refers to roughly a five-minute cache window. After TTL expires, even the same request may need to rebuild the cache.

This explains a common feeling in long tasks: everything was cheap and fast, then after a coffee break the token cost jumps again.

Long tasks hit this easily. You may review Claude Code output, inspect files, run tests, or think about the next step. Five minutes can disappear quickly.

If your environment supports it, you can request a one-hour Prompt Cache TTL before long tasks:

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

In Windows PowerShell:

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

One-hour cache writes usually cost more than five-minute cache writes. It is not always worth it for short tasks, but for large codebases, long conversations, and complex multi-step development, it may be cheaper than repeated cache expiration.

A token-saving Claude Code workflow

A steadier long-task setup looks like this:

Choose the model before the task starts and avoid frequent switching.
Enable the MCP servers you need and disable the ones you do not.
Keep CLAUDE.md short, stable, and focused on durable rules.
Prepare the Skills needed for this task in advance.
For complex tasks, consider one-hour TTL.
Split the task into phases, but keep context structure stable within each phase.
Use subagents or separate sessions for side exploration instead of disturbing the main conversation.

The goal is not to prevent every cache miss. It is to avoid the high-cost misses that are easy to overlook.

A simple rule of thumb

Ask one question:

Does this operation change the model, tool definitions, system context, or fixed messages near the start of the session?

If yes, it probably affects Prompt Cache. The farther left it is in the context chain, the greater the impact.

Common operations:

Switch model: high risk, model caches are isolated.
Add MCP or reload plugins: high risk, tool list changes.
Edit CLAUDE.md: medium-high risk, project memory changes.
Install Skills: medium-high risk, injected context changes.
Continue normal conversation: low risk, mostly appends messages.
Idle past TTL: high risk, server-side cache expires.

Summary

Prompt Cache optimization in Claude Code is about keeping the session prefix stable.

Do not switch models casually. Do not install MCP servers and Skills halfway through. Do not use CLAUDE.md as a temporary scratchpad. For complex tasks, consider a longer TTL. Once these basics are stable, token cost and response speed become much more predictable.

The most practical sentence is: configure before you start, change less after you start.

References

Midjourney vs Stable Diffusion: Which AI Image Tool Should You Choose?

Mon, 18 May 2026 18:23:50 +0800

Midjourney and Stable Diffusion are two of the most frequently compared AI image-generation tools today. Both can create high-quality images, but their product logic is very different.

Midjourney feels like a well-tuned high-end camera: closed, cloud-based, paid, and easy to use. You type a few sentences and often get images with strong aesthetics. Stable Diffusion is more like a customizable professional studio: open, locally deployable, deeply configurable, but it expects you to understand models, parameters, workflows, and hardware.

So the question is not simply which one is stronger. The better question is what you need. If you want fast output and stable aesthetics, Midjourney is easier. If you need precise control, batch production, private deployment, or customizable workflows, Stable Diffusion gives you more room.

Short answer

If you are a blogger, independent designer, illustrator, or creator who needs covers, posters, concept images, or moodboards quickly, start with Midjourney.

If you need ecommerce product images, AI model try-ons, architecture renders, game art assets, batch generation, private deployment, or automation APIs, Stable Diffusion is usually the better choice.

If you just want to try AI image generation without dealing with computers and parameters, Midjourney has a much lower learning curve.

If you are willing to learn ComfyUI, LoRA, ControlNet, Checkpoints, and you have a good NVIDIA GPU, Stable Diffusion has the higher ceiling.

Core difference: product vs ecosystem

Midjourney is first of all a complete product. You use it through the website or Discord. Models, compute, queues, styles, parameters, and video features are maintained by the official team. Its strengths are strong default output, stable aesthetics, and fast ideation. Its limits are that you cannot truly modify the model internals or move the entire workflow onto your own machine.

Stable Diffusion is more like an open ecosystem. You can run SDXL, SD3.5, Flux, and many community models through WebUI, ComfyUI, local scripts, or third-party platforms. Its strengths are control, training, batch generation, and private deployment. Its cost is setup time: GPU, models, extensions, parameters, and workflow management.

That shapes the experience:

Midjourney reduces choices in exchange for stronger default taste.
Stable Diffusion gives you more choices and more complexity.

Image quality: Midjourney gets attractive first drafts faster

Midjourney is especially good at first-impression images. You can write “cinematic portrait”, “futuristic city poster”, or “luxury perfume ad”, and it will usually fill in lighting, composition, material, and atmosphere on its own. For people without a photography or design background, that default taste is extremely helpful.

Stable Diffusion can also produce excellent images, but the base model alone is not always enough. You often need the right model, LoRA, sampler, prompt, negative prompt, and post-processing to reach the same level of polish.

In simple terms:

Midjourney has a higher average floor.
Stable Diffusion has a very high ceiling, but it needs setup and experience.

For social covers, blog images, moodboards, and quick visual ideas, Midjourney usually saves more time.

Control: Stable Diffusion is better for production workflows

The hardest part of AI image generation is not making something beautiful. It is making the model draw the right thing.

You may need a character to keep the same face, a pose to follow a skeleton, a product not to deform, a clothing pattern to stay intact, a sketch to become an architectural render, or the same character to appear across many panels. These tasks require control.

Stable Diffusion is much stronger here. ControlNet can guide pose, line art, depth maps, and edge maps. LoRA can train a specific person, product, outfit, or style. ComfyUI can connect generation, upscaling, cutouts, inpainting, face replacement, virtual try-on, and batch processing into one pipeline.

Midjourney also has style references, character references, image references, and local editing. Recent versions have improved prompt understanding and detail retention. But it is still better for creative exploration than highly constrained industrial workflows.

Prompt logic: aesthetics vs engineering

Midjourney tends to understand aesthetic intent. You write natural language and it fills in many things that make the result look good. For ordinary users, that is a feature: you do not need to specify every lighting, lens, texture, and composition detail.

Stable Diffusion behaves more like a parameterized system. You can describe the image in natural language, but you can also specify model, resolution, sampling steps, CFG, ControlNet inputs, LoRA weights, and inpainting regions. It is not one button. It is a toolbox.

That is why many people find Stable Diffusion hard at first. It is not a single app; it is a stack.

Character and style consistency

Midjourney now offers character and style reference features. They are useful for keeping a general character feel, clothing direction, and visual style. For short visual projects, poster series, and social content, they may be enough.

But if you are making long comics, game character assets, virtual models, or ecommerce brand visuals, Stable Diffusion’s trainability matters more. With LoRA or DreamBooth, you can lock in a specific character, product, outfit, or art style across many images.

The difference is:

Midjourney is good at “looking like the same person.”
Stable Diffusion is better at “being this exact person or product.”

Text and layout

AI image models used to be poor at generating text. They are improving, but they are still not professional layout tools.

Midjourney’s newer versions handle short English text, title lettering, and poster-style typography better, but long text, Chinese layout, and multi-line commercial copy can still fail.

In the Stable Diffusion ecosystem, newer models such as SD3.5 use stronger text encoders and handle longer prompts better. Even so, the safest commercial workflow is still: generate the image with AI, then finish text and layout in Photoshop, Illustrator, Figma, or Canva.

Video

Midjourney includes image-to-video capabilities. You can turn an image into a short video and extend it. The entry point is simple, which is useful for social clips, atmosphere videos, and dynamic covers.

Stable Diffusion also has AnimateDiff, SVD, and ComfyUI video workflows, but setup and tuning are harder. It is better for users willing to work with nodes, VRAM, models, and frame consistency.

If you just want to animate one image, Midjourney is easier.

If you want to integrate video generation into your own automated workflow, the Stable Diffusion ecosystem is freer.

Hardware and cost

Midjourney is a cloud subscription service. You do not need a GPU. A phone, tablet, or thin laptop is enough. The main costs are subscription fees and generation quotas.

Stable Diffusion can run locally, and many models and tools are free, but hardware is not free. For a good experience, you usually want an NVIDIA GPU with enough VRAM. SDXL, SD3.5, Flux, video workflows, upscaling, and batch generation all consume VRAM. You can start with 8GB, but 12GB, 16GB, or more is much more comfortable.

Cost-wise:

Low-frequency use: Midjourney is usually cheaper and easier.
High-volume production: local Stable Diffusion can be cheaper long term.
No GPU: choose Midjourney or a cloud SD platform.
Good GPU already available: Stable Diffusion is worth exploring.

Commercial use: creative images vs production line

Midjourney is excellent for early concept exploration: brand direction, ad mood, covers, game scene ideas, and character concept sketches.

Stable Diffusion is better once you enter production: ecommerce model try-ons, batch background replacement, sketch-to-render workflows, character LoRA training, private enterprise image generation, and API automation. It can become part of scripts, databases, backend jobs, and internal tools.

In other words:

Midjourney is an inspiration accelerator for creative teams.
Stable Diffusion is an image-production system that technical teams can build.

How to choose in 2026

Choose Midjourney if:

You want high-quality images from a few sentences.
You do not want to learn GPUs, models, nodes, or parameters.
You mainly make covers, illustrations, posters, concept images, or moodboards.
You are willing to pay a subscription for convenience.
You do not need extreme precision.

Choose Stable Diffusion if:

You need to control pose, product shape, line structure, or layout.
You want to train your own characters, products, brand style, or custom model.
You need batch generation or integration into websites, software, or workflows.
You care about local deployment, privacy, and control.
You are willing to learn ComfyUI, LoRA, ControlNet, and related tools.

The most practical combination

Many professional users eventually use both.

A common workflow is to explore style and composition in Midjourney, then use Stable Diffusion for precise control, character consistency, product consistency, and batch production. Finally, traditional design tools handle text, layout, and retouching.

That is more practical than arguing which tool is stronger.

Midjourney helps you see possibilities faster. Stable Diffusion turns those possibilities into controllable workflows. The first improves creative speed; the second improves production certainty.

Summary

The difference between Midjourney and Stable Diffusion is the difference between automated aesthetics and controllable workflows.

Midjourney is best for most people who want beautiful images quickly. It lowers the barrier to AI art and lets non-technical users start creating immediately.

Stable Diffusion is for people who need control, training, batching, privacy, and automation. It has a higher learning curve, but once the workflow is built, it can become real image-production infrastructure.

If you do not yet know what you need, start with Midjourney.
If you already find yourself saying, “This image looks great, but it does not follow my requirements,” it is time to learn Stable Diffusion.

References

Anthropic Founder’s Playbook Explained: How Claude Helps Startup Teams Move Faster

Mon, 18 May 2026 18:02:58 +0800

Anthropic published The Founder’s Playbook on the official Claude blog, aimed at founders. Its core question is direct: how can an AI-native startup move faster from insight to product, launch, and scale?

The playbook is not simply a feature list for Claude. It breaks the startup journey into four stages: Idea, MVP, Launch, and Scale. The point is not to let AI replace founders’ judgment, but to hand repetitive work such as market research, copy drafts, code scaffolding, operations workflows, and sales materials to Claude first, so founders can spend more time on judgment, taste, trade-offs, and trust.

What this playbook is about

AI startups increasingly face a kind of compression race: product cycles are shorter, competitors are more numerous, and users expect speed and quality at the same time. Work that once required a multi-person team can now often be drafted by AI first, then reviewed, corrected, and advanced by the founding team.

Anthropic’s framework is clear: do not try to make the entire company “AI-powered” on day one. Instead, find one process that is time-consuming, repetitive, and low in creative density. Let Claude generate the first draft, script, research summary, or execution checklist. Founders remain responsible for defining goals, calibrating direction, judging quality, and connecting useful output to real business work.

Stage 1: Idea

The Idea stage is not about coming up with a cool concept. It is about validating whether the idea deserves further investment.

Claude can help founders at this stage by mapping markets, summarizing user pain points, comparing competitor positioning, proposing possible wedges, and turning vague ideas into clearer value propositions.

But the most important part is still human judgment. AI can help you see more possibilities faster, but it cannot take responsibility for whether a market truly has strong demand. Founders still need to talk to real users, observe whether they are willing to change existing workflows, and see whether they are willing to pay.

Stage 2: MVP

The MVP stage is where Claude Code can be especially useful.

For small teams, the scarcest resource is often not ideas, but the speed of turning ideas into something users can try. Claude Code can help generate scaffolding, write scripts, fill in components, check edge cases, and produce technical plan notes, helping teams get to a testable version faster.

The key is not asking AI to write a perfect product in one pass. It is reducing the friction from zero to first version. Founders and engineers still need to review architecture, security, data handling, and user experience, but they do not need to spend as much time on mechanical first drafts.

Stage 3: Launch

The Launch stage tests narrative, distribution, and feedback speed.

Many startup teams underestimate how complex a launch can be: website copy, product demos, emails, social media content, user interviews, sales scripts, investor updates. Every item needs to clearly explain why this product is needed now.

Claude can act as a high-frequency collaborator here: generating different positioning variants, rewriting introductions for different user groups, simulating user questions, organizing the launch rhythm, and turning early feedback into the next round of product and market actions.

Stage 4: Scale

The Scale stage shifts the focus from “building it” to “growing repeatably.”

Once a company has stable users and revenue, the founding team gets pulled into operations, sales, support, data analysis, and internal coordination. Agent-like capabilities such as Claude Cowork are better suited to more complete tasks: conducting market research, designing campaigns, organizing fundraising strategy, summarizing growth metrics, or turning an operations process into repeatable steps.

This is also where the difference between AI-native companies and traditional software companies begins to appear. The real change is not simply that employees use AI tools. It is that company processes are designed around AI collaboration from the beginning: which tasks require humans to define standards, which tasks should be drafted by AI first, which outputs must be reviewed, and which workflows can become reusable templates.

What Claude Code, Claude Cowork, and Chat are best for

Based on the official blog post, Anthropic wants founders to think about Claude across three kinds of use cases.

Claude Code is more engineering-oriented. It is suited for writing code, generating scripts, analyzing edge cases, producing component specs, and drafting technical documentation. It helps move ideas toward something that can run.

Claude Cowork is closer to a delegatable work agent. It fits tasks that require continued execution, such as market research, campaign design, fundraising strategy, and operations analysis. It helps push a relatively complete business task through a first pass.

Claude Chat is better suited for founder judgment moments: thinking through go-to-market strategy, stress-testing product positioning, comparing roadmap priorities, and refining key narratives. It is not an execution machine, but a thinking partner that can support rapid iteration.

What is actually useful for startup teams

The value of this playbook is not that it tells founders “AI is important.” That is no longer new.

Its more useful contribution is shifting AI use from scattered tool calls into a company-building method. Each stage has different bottlenecks, and each bottleneck can be broken into parts where AI can participate.

At the Idea stage, AI expands the search space. At the MVP stage, it compresses implementation time. At the Launch stage, it accelerates messaging and distribution experiments. At the Scale stage, it helps turn processes into repeatable workflows.

This logic is especially important for small teams. Small teams do not have enough people to cover every function, but they can use AI to create a first version of a capability, then spend limited human energy on the parts that most require judgment and relationship building.

Pitfalls to watch for

The first pitfall is treating AI-generated output as a conclusion. Market research, competitor analysis, user personas, and growth strategies all need to be validated against real data and user feedback.

The second pitfall is underestimating review cost. AI can significantly reduce the cost of first drafts, but code quality, legal risk, brand expression, commercial promises, and security issues still need human accountability.

The third pitfall is automating too early. A process that has not yet worked manually should not be handed to an agent for automatic execution. A steadier approach is to let AI participate in one small part of the workflow, observe output quality, and then gradually expand the scope.

Summary

The signal from Anthropic’s Founder’s Playbook is clear: the advantage of an AI-native startup is not merely that it can use AI to write code. It is that from day one, AI becomes a collaboration layer across product, engineering, marketing, sales, and operations.

For founders, the most practical starting point is not building a grand AI workflow. It is choosing one task that consumes too much time, repeats too often, and slows progress the most, then letting Claude produce the first version. Real competitiveness comes from human founders’ control over direction, quality, and trust, and from whether the team can embed this collaboration pattern into everyday work.

References

The founder’s playbook for the age of AI

Figure AI's Humanoid Robots Sort Packages Nonstop: What the Livestream Proves

Mon, 18 May 2026 17:58:10 +0800

Figure AI has pushed humanoid robots back into the center of the conversation.

Starting on May 14, 2026, Figure AI placed three F.03 humanoid robots in a logistics sorting scene and streamed the process continuously. Viewers nicknamed the robots Bob, Frank, and Gary. Beside a conveyor belt, they identify packages, pick them up, rotate them, scan barcodes, and place them back on the belt as required.

At first glance, the livestream looked like a public response to skepticism. If humanoid robots want to prove real utility, edited short clips are not enough. They need to survive full shifts, repetitive tasks, and long-running operation.

By the time The Paper reported on the stream, Figure AI had been broadcasting for five days and claimed that the robots had sorted more than 100,000 packages. The livestream can still be viewed on YouTube: F.03 Livestream.

Why this livestream matters

The humanoid robot industry has long had one recurring problem: demo videos are too short.

A few minutes of footage can show that a robot “can do” something, but it rarely proves that it can keep doing it. In real logistics, manufacturing, and warehousing, the key question is not whether one grasp succeeds. It is whether the system stays stable over long periods, handles exceptions, follows a maintainable rhythm, and makes economic sense per unit of work.

By choosing a livestream, Figure AI put the hard questions on the table:

Can the robots work continuously for hours or even days?
Do they require remote human control?
Can they handle battery, handoff, and maintenance needs?
Is the error rate acceptable in repetitive work?
Can they stay stable with soft parcels, rigid boxes, and packages of different sizes?

Compared with an edited clip, a long livestream exposes problems more easily. Dropped packages, failed grasps, short pauses, and changes in conveyor rhythm are all visible to viewers.

That is also its value. It does not prove the robots are perfect. It gives outsiders a more direct view of how far humanoid robots still are from reliable industrial use.

What is Figure F.03 doing?

The task is not complex, but it is typical.

The robot needs to observe packages on a conveyor belt, identify the barcode position, pick up the package, adjust its orientation, and place it back with the barcode facing down. It looks like a simple “pick up and put down” routine, but for a robot it involves several hard problems:

Recognizing packages with different shapes, materials, and sizes.
Estimating grasp points and weight changes.
Avoiding deforming soft parcels or pushing boxes off the belt.
Moving arms within limited space.
Maintaining rhythm without slowing the conveyor.
Recovering after a failure instead of freezing.

Figure AI founder Brett Adcock said the robots average about three seconds per package, close to human speed. He also stressed that the system is not scripted, but reasons and controls directly from camera pixels.

That point matters. The claim is not that the robot can repeat a preset motion, but that it can adjust grasping and placement strategies from real-time visual input.

Helix-02 is the core story

Figure AI emphasized that F.03 runs on its in-house Helix-02 system.

According to public descriptions, Helix-02 is not a traditional industrial robotics pipeline with neatly separated perception, planning, and control layers. It is closer to an end-to-end full-body autonomy system. It integrates vision, touch, proprioception, and whole-body control into one model framework so the robot can adjust its actions in real time.

You can think of it as three layers of capability:

Low-level control: keeping balance and executing joint movements.
Visuomotor policy: turning camera and tactile input into grasping, moving, and placing actions.
Semantic reasoning: understanding task goals, scenes, and abnormal states.

This is also where humanoid robots differ from traditional automation equipment.

Traditional sorting systems are usually optimized for fixed processes. They can be highly efficient, but changing the scene often means redesigning the line. Humanoid robots try to enter existing environments with human-like form factors and perform multiple tasks without rebuilding too much equipment.

The direction is tempting, but difficult. A robot’s hands, eyes, body, and “brain” must work together. If any part is unstable, the final result suffers.

The livestream also exposed problems

The stream was not flawless.

Based on reports from The Paper and other observers, the robots sometimes made short mistakes: inaccurate grasp judgments, shifted package positions, or even pushing packages off the conveyor.

These issues may be edited out of a demo video, but they cannot be ignored in real work.

Logistics environments care deeply about accuracy. One dropped package may be a small mistake. If the same pattern happens frequently in a large warehouse, it creates manual review, delays, damage, and responsibility issues.

U.S. robotics expert Ayanna Howard has raised a similar concern: the demonstration looks more like a science project than a mature commercial service. Speed matters, but in real deployment, accuracy, exception handling, and supervision cost matter just as much.

Are sorting workers about to lose their jobs?

In the short term, this livestream should not be read as “sorting workers are about to be replaced.”

Figure AI demonstrated a relatively controlled, repetitive, clearly bounded task. It shows that humanoid robots are approaching usability for some logistics motions, but it does not prove they can seamlessly take over a full warehouse workflow.

Real logistics sites face many more complications:

Damaged packages, liquid leaks, and unusual shapes.
Dirty barcodes or barcodes that are not visible.
Stacked, blocked, or jammed packages.
Temporary human intervention.
Equipment alarms and conveyor pauses.
Safety rules and liability boundaries.

Human workers are good at these non-standard exceptions. For commercial deployment, robots need to prove not only that they can approach human speed on standard actions, but also that they can handle long-tail problems reliably.

The more realistic change may not be full replacement. Robots may first take over part of the repetitive, boring, night-shift, or high-intensity work, while humans move toward supervision, maintenance, exception handling, and process optimization.

What it means for the industry

The livestream matters because it shifts the benchmark for humanoid robots from “can it perform an action?” to “can it keep working?”

In the past, the industry often compared isolated abilities: walking, moving boxes, folding clothes, cooking, washing dishes. Now Figure AI is trying to prove that humanoid robots can run for long periods in a real task while letting the public watch the process.

That creates pressure for competitors.

If other companies continue to release only edited clips, observers will naturally ask: Why not livestream it? Why not run it for eight hours? Why not disclose the error rate? Why not let the robot work at something closer to an industrial rhythm?

Of course, livestreaming is not the final answer. Commercialization still depends on:

Robot sale price and rental cost.
Maintenance frequency and battery life.
Deployment and tuning cost.
Throughput per unit time.
Error rate and accident rate.
Integration with existing warehouse systems.
Whether customers are willing to pay for a humanoid form factor.

If these numbers do not work, even a popular livestream is still just an impressive technology demonstration.

Summary

Figure AI’s F.03 package-sorting livestream is an important signal on the road to commercial humanoid robots.

It shows that humanoid robots are no longer limited to lab prototypes performing a few isolated motions. They are beginning to attempt long-running, repetitive, industrial tasks. The end-to-end full-body autonomy approach represented by Helix-02 also moves robots from “fixed-motion machines” toward “labor tools that understand scenes.”

But it still does not prove that humanoid robots are ready to replace warehouse workers at scale.

Speed, accuracy, exception handling, cost, safety, and maintenance remain open questions. The real thing to watch is not how exciting a livestream looks, but whether these robots can work for months at real customer sites with controllable costs.

If they can, the next stage of logistics automation may really be arriving.

Livestream Link

Figure AI F.03 Livestream - YouTube

References

Why Is Sulphur 2 Popular? Open AI Video Generation, Uncensored Debate, and Local Deployment Barriers

Mon, 18 May 2026 00:27:37 +0800

Sulphur 2 has recently triggered a lot of discussion in the AI video generation community.

It is not an online commercial product like Sora, Runway, or Pika, and it is not a brand-new architecture trained from scratch. More accurately, Sulphur 2 is an open-weights video generation model fine-tuned from LTX 2.3, aimed at local generation, controllable workflows, and more open prompt responsiveness.

What really makes it interesting is not just that it can generate video. It brings an old question back to the front: should AI video models have their content boundaries set uniformly by platforms, or should local users take responsibility within legal limits?

The Relationship Between Sulphur 2 and LTX 2.3

Sulphur 2 is built on Lightricks’ open LTX 2.3.

LTX 2.3 is already a relatively complete video generation model line, supporting text-to-video, image-to-video, variable frame rates, first-frame and last-frame control, audio synchronization, and more. Its ecosystem is also easier to connect to local workflows such as ComfyUI.

Sulphur 2 does not change that basic structure. Instead, it fine-tunes LTX 2.3 for a more specific direction. The original article notes that the development team trained it with more than 125,000 video samples and provides different versions such as BF16, FP8 mixed, and Distill LoRA, so users can choose according to their hardware.

That means Sulphur 2 is more like a derivative model package in the LTX 2.3 ecosystem than a completely independent new platform.

If you care about local deployment, VRAM requirements, and ComfyUI workflows, you can also read the earlier deployment note on this site: Can Sulphur 2 Run on 8GB VRAM? Notes on Local Deployment of an LTX 2.3 Video Model.

Why It Is Called “Uncensored”

The most controversial label around Sulphur 2 is uncensored.

The word is easy to misunderstand. It should not be interpreted as “it can generate anything”, and it certainly does not mean it can be used for illegal content, infringement, harassment, impersonation, or non-consensual imagery. A more accurate understanding is that, compared with many commercial video generation platforms, Sulphur 2 is less likely to reject prompts about sensitive but legal topics outright.

Commercial platforms usually take a conservative approach. To reduce legal, brand, and compliance risks, they may block many prompts in gray areas. This can reduce misuse, but it can also affect normal creative scenarios such as:

Medical education.
Historical topics.
News reconstruction.
Artistic experiments.
Niche style creation.
Serious documentary material planning.

Sulphur 2’s approach is to give more judgment back to local users while keeping a baseline filter for illegal content. That direction creates more creative freedom, but also requires more responsibility.

Technically, It Is More Than “Removing Limits”

It is incomplete to describe Sulphur 2 as simply “LTX 2.3 with the censorship layer removed”.

Based on public information, it provides a set of LTX 2.3-related model weights and tools, including:

A BF16 full-precision version for hardware with more VRAM.
An FP8 mixed version that trades some precision for better usability on lower VRAM.
A Distill LoRA version for balancing speed and quality.
ComfyUI workflows for testing text-to-video and image-to-video.
A Prompt Enhancer that expands short descriptions into prompts better suited to video generation.

Video generation is different from image generation. A video prompt involves not only subject and style, but also camera movement, character motion, temporal continuity, frame-to-frame consistency, shot scale, and pacing. If the prompt is too short, the model often fills in unstable details.

That is why the Prompt Enhancer matters. The user provides a simple idea, a smaller model expands it into a description better suited to the video model, and then the Sulphur 2 workflow generates the video.

Actual Experience: More Obedient, Not Omnipotent

Based on community feedback, one obvious feature of Sulphur 2 is that it is more willing to follow prompts.

Because there are fewer restrictions, it is less likely to suddenly reject, degrade, or route around user intent for certain legal topics. This is attractive to users who need precise control, especially for local creation, experimental video, concept shorts, and niche subjects.

But it is not the final answer to video generation.

Current open video models still commonly suffer from:

Unnatural human motion.
Deformed limbs and hands.
Weak long-shot consistency.
Confusion in multi-subject interactions.
Overly literal understanding of complex scenes.
Images that match the prompt but lack visual taste or editing sense.

These problems are not unique to Sulphur 2. They are common to current AI video generation models. Sulphur 2 can improve part of the prompt-following problem, but it cannot eliminate the core technical difficulty of video generation.

Hardware Requirements Still Matter

Sulphur 2 is an open model, but open does not mean it runs casually on any normal computer.

To get good results, you still need a reasonably strong GPU. The original article notes that the FP8 version lowers VRAM requirements, but stable use still usually requires substantial VRAM. The BF16 version has higher hardware requirements and is better suited to high-end GPUs or cloud GPUs.

This means Sulphur 2’s “popularization” is not the same as one-click web-tool popularization. It is popularization in the open-source community sense:

Weights can be downloaded.
Workflows can be modified.
Users can run it locally.
Developers can fine-tune it further.
Communities can share parameters and node configurations.

It lowers the barrier to control, but not necessarily the hardware barrier.

The Core Debate: Openness and Safety

The controversy around Sulphur 2 is not really about whether one model’s parameters are good. It is about governance for open AI video generation.

Supporters argue that open models should not make overly broad judgments on behalf of users. As long as the content is legal, users should be able to explore artistic, educational, research, and creative boundaries in a local environment.

Critics worry that video can cause more real-world harm than images. More open models may be used for forgery, harassment, infringement, misleading distribution, or other forms of misuse. Even if developers keep illegal-content filters, it is hard to fully prevent secondary modification and malicious use.

Neither view should be dismissed casually.

Open models need freedom, but they also need responsibility. A more workable direction is not to lock models down completely, nor to leave everything unbounded, but to build clearer community norms, model card disclosures, usage restrictions, provenance tools, and reporting mechanisms.

Who Should Pay Attention

Sulphur 2 is more suitable for:

Users already familiar with ComfyUI or local video generation workflows.
Developers studying LTX 2.3 derivative model behavior.
Creators who need stronger prompt responsiveness.
Teams that want controllable experiments in a local environment.
Model enthusiasts working on fine-tuning, LoRA, or workflow optimization.

If you only want to quickly generate a short video for social media, online products may still be easier. The value of Sulphur 2 is not “one click to finished video”, but giving more control to people willing to tinker.

Summary

Sulphur 2 is not meaningful simply because it adds one more AI video generation model.

It is more like a response from the open video generation community to the conservative policies of commercial platforms: as models become stronger, who should define content boundaries?

Technically, it is based on LTX 2.3 and provides multiple precision versions, LoRA, ComfyUI workflows, and a Prompt Enhancer, making it suitable for local generation and further development.

From an ecosystem perspective, it also reminds us that openness in video generation brings more creative freedom and higher misuse risk at the same time. Whether open AI video models can develop healthily will depend on whether technical capability, community norms, and user responsibility can all keep pace.

References

Behind Cerebras' IPO Surge: Can Wafer-Scale AI Chips Challenge Nvidia?

Mon, 18 May 2026 00:19:51 +0800

Cerebras Systems has finally entered the public market.

The company, known for its “wafer-scale AI chips”, began trading on Nasdaq on May 14, 2026 under the ticker CBRS. According to Cerebras’ official announcement, the IPO price was $185 per share, with 34.5 million shares of Class A common stock offered, including the underwriters’ full exercise of a 4.5 million share over-allotment option.

On its first trading day, Cerebras opened sharply higher and briefly approached $386. Based on the IPO price, the company raised more than $5.5 billion, making it one of the most closely watched AI hardware IPOs in the U.S. market in 2026.

That is why many media outlets call it an “Nvidia challenger”. But it is not accurate to simply describe Cerebras as “the next Nvidia”. What makes it unusual is that it has chosen a technical path very different from traditional GPUs.

Cerebras Is Not Building a Normal GPU

Cerebras’ core product is WSE, short for Wafer-Scale Engine.

Traditional chip manufacturing cuts a whole wafer into many small chips, then packages, tests, and ships them. Cerebras takes the opposite approach: it tries to turn an entire wafer directly into one giant chip.

The advantages of this route are straightforward:

Larger chip area.
More on-chip compute units.
On-chip SRAM closer to compute cores.
Shorter data movement inside the chip.
Better fit for certain AI inference and training workloads.

In AI computing, moving data is often harder to optimize than raw computation. Cerebras’ idea is to keep compute and storage on the same piece of silicon as much as possible, reducing the latency and energy cost caused by data repeatedly leaving the chip.

That is the most attractive part of the WSE approach. Instead of scaling along the same GPU path, it uses a much larger single chip to pursue higher on-chip bandwidth and lower data movement cost.

Why the Market Got Excited

The AI chip market is currently highly dependent on Nvidia. Whether companies are training large models, deploying inference services, or building AI data centers, Nvidia GPUs remain the mainstream choice.

That makes the market naturally interested in two kinds of companies:

Companies that can reduce dependence on Nvidia’s supply chain.
Companies that can offer higher performance or lower cost for certain AI workloads.

Cerebras fits both narratives.

It is not building a general-purpose CPU or an ordinary accelerator card. It designs systems directly around AI training and inference. The company has also repeatedly emphasized that its wafer-scale chips and cloud inference platform can deliver very high throughput in certain model inference scenarios.

This kind of story is easy for the market to amplify in 2026. AI infrastructure is still expanding, and enterprises, cloud providers, and model companies are all looking for more compute sources. If a chip company can prove that it is not just “another small GPU” in some scenarios, the market will pay attention.

The OpenAI Partnership Expands the Upside Story

Another reason Cerebras is closely watched is its relationship with OpenAI.

According to media reports, Cerebras signed a cooperation agreement with OpenAI worth more than $20 billion. The original Sohu article noted that, as of the end of 2025, the remaining performance obligations from that agreement reached $24.6 billion.

For a newly listed AI hardware company, such long-term agreements are important. They suggest that the company has not only a technical story, but also demand from major customers.

Still, long-term orders are not the same as realized revenue. AI data center deployment depends on manufacturing capacity, packaging, power supply, delivery schedules, customer budgets, and changes in model strategy. For chip companies, winning orders is only the first step. Delivering on time, scaling reliably, and building margins are harder.

Customer Concentration Remains a Major Risk

Cerebras also has an obvious risk: high customer concentration.

The Sohu article noted that G42 contributed 85% of Cerebras’ revenue in 2024, falling to 24% in 2025, while Mohamed bin Zayed University of Artificial Intelligence contributed 62% of revenue in 2025. This means that even after G42’s share declined, Cerebras’ revenue still depended heavily on a small number of large customers.

For AI infrastructure companies, customer concentration has two sides.

The benefit is that large customers can bring rapid growth, long-term contracts, and order visibility.

The risk is that if customers cut budgets, change technical direction, delay data center construction, or face regulatory changes, revenue volatility can be significant.

That is why Cerebras should not be judged only by its IPO pop. The first-day stock price reflects enthusiasm and expectations. Long-term valuation will still depend on revenue structure, delivery capability, margins, and customer diversification.

The Technical Limitation: Memory Capacity

WSE has clear strengths, but its limitations are also clear.

The Sohu article noted that the WSE-3 chip has 44GB of SRAM, while Nvidia’s B200 has 192GB of memory. Cerebras places a large amount of compute and SRAM on the same wafer, which reduces data movement, but also limits available memory capacity.

For large models, memory capacity directly affects context length, batch size, and deployment architecture. Context windows are getting longer, and flagship models are increasingly moving toward million-token context windows. In that trend, on-chip SRAM capacity becomes a real constraint.

Traditional GPUs can continue expanding memory through HBM stacking, packaging expansion, and multi-GPU interconnects. Cerebras’ wafer-scale approach is harder to expand in a simple way because the wafer area is already occupied by compute units and SRAM. Adding more SRAM may mean sacrificing compute area.

This does not mean the Cerebras architecture has failed. It means it is an architectural choice optimized for specific workloads. It may be very strong in certain inference scenarios, but it does not necessarily cover every AI training and inference need.

Can It Replace Nvidia?

In the short term, Cerebras is unlikely to replace Nvidia.

Nvidia’s advantage is not only GPU performance. It also includes the CUDA ecosystem, developer tools, system integration, networking, full-stack server solutions, cloud provider support, and customer migration costs. AI companies often choose Nvidia not because one chip wins on one metric, but because the entire ecosystem is the most stable.

Cerebras’ more realistic opportunity is to become a complementary option for specific AI workloads:

High-throughput inference.
Specific large-model services.
Tasks sensitive to latency and on-chip bandwidth.
Customers that want to reduce dependence on a single GPU supply chain.
Model companies willing to test new architectures for performance.

In other words, it is not an “Nvidia killer”. It is more like an aggressive alternative path in the AI compute market.

Summary

Cerebras’ IPO surge shows that capital markets are still willing to pay a high premium for AI infrastructure stories.

Its wafer-scale chip architecture is genuinely distinctive, separating it from ordinary AI accelerator companies. Together with major customer relationships such as OpenAI, Cerebras has a strong market narrative.

But the risks are just as real: customer concentration, delivery pressure, memory capacity limits, ecosystem barriers, and the system-level gap with Nvidia will all determine how far it can go.

For ordinary readers, the most interesting part of Cerebras is not how much the stock rose. It is that the company proves AI compute competition will not have only one GPU path. Future large-model infrastructure may include GPUs, wafer-scale chips, in-house accelerators, and cloud-based specialized inference platforms at the same time.

References

Which Free AI Image Generator Is Best? A Comparison Guide to Free AI Art Tools

Sun, 17 May 2026 23:10:43 +0800

Looking for a good free ai image generator is no longer a question of whether such tools exist. The harder question is which one to choose.

Free AI image generators on the market can roughly be divided into three groups: local open-source tools, web tools with free credits, and high-quota or free entry points from major tech companies. They can all generate images, but their ideal users, learning curve, copyright boundaries, and controllability differ a lot.

One thing should be clear from the start: free does not necessarily mean permanently free, unlimited, or commercially safe. Web platforms may change free credits, queue rules, watermarks, resolution limits, and commercial terms. Local open-source tools may be free as software, but you still need GPU hardware, model files, time, and an understanding of model licenses.

Local Open Source: Best for Long-Term Free Use and Deep Control

If you have a reasonably capable NVIDIA GPU, such as an RTX 3060, 4060, or better, local deployment is still the closest thing to “unlimited free” image generation. It does not charge per image, and you do not need to upload prompts or assets to a third-party platform. It is especially suitable for heavy users, designers, and workflows that require privacy.

Stable Diffusion WebUI / ComfyUI

The Stable Diffusion ecosystem is one of the most mature open-source AI image generation ecosystems. Common entry points include Stable Diffusion WebUI and ComfyUI.

Stable Diffusion WebUI feels more like a traditional software interface and is suitable for quickly getting started with text-to-image, image-to-image, inpainting, and upscaling. ComfyUI uses a node-based workflow. It has a higher learning curve, but much stronger controllability, making it suitable for complex workflows such as batch generation, ControlNet, reference-image constraints, multi-model combinations, and automation pipelines.

Their biggest advantage is not just being free, but the ecosystem: Checkpoints, LoRA, ControlNet, VAE, workflow templates, and plugins are abundant. You can generate realistic portraits, anime characters, ecommerce product images, architectural concepts, game asset sketches, and iteratively refine a consistent style.

The trade-off is also clear. You need to install the environment, manage models, learn parameters, and pay attention to the license terms of different models. For beginners, it is not the easiest free ai image generator, but it is the best option for long-term experimentation and deep customization.

Fooocus

Fooocus can be understood as a more beginner-friendly local tool based on Stable Diffusion XL. It hides many parameters behind the scenes, so users mainly enter prompts and choose styles to generate good-looking images.

If ComfyUI feels too engineering-heavy and Stable Diffusion WebUI has too many parameters, Fooocus is a friendlier starting point. It is suitable for style exploration, cover drafts, character concepts, product visuals, and social media images. Its controllability is weaker than a full ComfyUI workflow, but for many people that simplicity is exactly the benefit.

Web Tools With Free Credits: Best for Lightweight Daily Use

If you do not have a discrete GPU, or only need to generate a few images occasionally, web-based tools are easier. They usually provide free usage through daily credits, free tokens, queue-based generation, or slower modes.

The key evaluation criteria are not only “how many free credits”, but also whether the quota is stable, whether image quality is good enough, whether Chinese is supported, whether image-to-image and local editing are available, whether high-resolution downloads are possible, and whether commercial use is allowed.

SeaArt AI

SeaArt AI is a fairly complete web-based AI art platform. It integrates many Stable Diffusion-style models and commonly supports text-to-image, image-to-image, conditional control, upscaling, outpainting, and a model community.

Its strengths are fast onboarding, many styles, and a Chinese-friendly interface. You can use it for anime characters, realistic photography, tech-style posters, product concepts, or quickly reproducing certain visual styles through existing models.

The important caveat is that platform points, daily tasks, and free credits can change with operating strategy. It is safer to treat it as a web tool for light daily free use, rather than assuming any specific quota will last forever.

Leonardo.ai

Leonardo.ai leans toward creative production and game-art workflows. It often performs well in image texture, lighting, concept design, and 3D-like styles, making it suitable for game concept art, character design, scene concepts, brand visuals, and product rendering drafts.

It usually provides a free plan or free credits, but the quota may vary by region, account status, and product policy. For users who do not want local deployment but still want high visual quality, Leonardo.ai is a web-based free ai image generator worth trying.

Clipdrop

Clipdrop belongs to the Stability AI ecosystem. Besides text-to-image generation, it offers useful tools such as background removal, image upscaling, object cleanup, relighting, and doodle-to-image.

It feels more like an AI image toolbox than just a drawing entry point. For people who edit existing images, process visuals quickly, or generate material drafts, Clipdrop’s value often lies in the post-processing tools after generation.

Free users may encounter limits on usage count, queueing, watermarks, or resolution. Always check the platform’s current rules.

Major-Company Entry Points: Best for Simplicity and Language Understanding

AI image tools from major companies tend to be stable, easy to use, and strong at understanding prompts. When you want to describe a complex scene in natural language, or generate posters, covers, and illustrations with text, they can be easier than many open-source models.

Microsoft Designer / Bing Image Creator

Microsoft Designer and Bing Image Creator are connected to OpenAI’s DALL-E image capabilities. Their strengths are strong prompt understanding, good reconstruction of complex scenes, and better handling of English text, poster titles, and design-like composition inside images.

If your need is “describe a cover in Chinese or English and get a fairly finished image”, Microsoft’s entry points are often a good fit. They work well for article covers, social posters, event images, creative illustrations, and lightweight commercial visual drafts.

Free usage may involve boost credits, queues, or speed differences. Actual quotas and restrictions should be checked on Microsoft’s current pages.

Adobe Firefly

Adobe Firefly is not positioned exactly like a normal AI art website. It emphasizes design workflows, Generative Fill, smart expansion, text effects, and integration with the Adobe ecosystem.

If you already use Photoshop, Illustrator, or Express, Firefly’s advantages become more obvious. It is suitable for retouching, outpainting, background replacement, design material generation, and creative edits based on existing images.

Firefly is often discussed in the context of “commercial safety” because Adobe emphasizes data sources and licensing boundaries. But whether you can use output commercially, whether a paid plan is required, and how free credits are counted still depends on Adobe’s current terms and account plan.

How to Choose: Start With Use Case, Not Fame

If you want easy cover images, posters, or creative images with text, start with Microsoft Designer or Bing Image Creator. They understand natural language well and often produce finished-looking images quickly, especially for non-specialists.

If you want to explore styles such as realism, anime, game concept art, product rendering, or tech visuals, try SeaArt AI or Leonardo.ai. They are good for quick style exploration and for users without local GPUs.

If you want to edit existing images rather than only generate new ones, look at Adobe Firefly and Clipdrop. Firefly is closer to design production, while Clipdrop is more like a lightweight AI image toolbox.

If you are willing to learn and have suitable hardware, Stable Diffusion WebUI, ComfyUI, and Fooocus remain the most worthwhile long-term free options. Their ceiling is higher and their marginal cost is lower, but you need to handle the learning and maintenance cost.

Common Traps in Free AI Image Tools

First, free quotas change. The number of credits available today may not be the same next month. Before building a workflow around a tool, check the latest platform rules.

Second, free does not mean commercially usable. Many tools allow free generation, but commercial rights, copyright ownership, training-data disputes, and restrictions on brand materials require separate review.

Third, output quality depends on more than the model. Prompts, reference images, resolution, post-processing, inpainting, and image selection all affect the final result.

Fourth, local open source still has licensing issues. Open-source software does not mean every model can be used commercially. When downloading Checkpoints, LoRA, or workflows, read the author’s license notes.

Summary

If you only need a free AI image generation entry point, Microsoft Designer, Bing Image Creator, SeaArt AI, Leonardo.ai, Clipdrop, and Adobe Firefly are all worth trying.

If you want to generate many images in a stable, low-cost way over the long term, the local Stable Diffusion ecosystem is closer to the “ultimate free” answer.

The best free ai image generator is not necessarily the one with the most free credits. It is the one that best matches your use case, copyright requirements, and learning cost.

References

Stable Diffusion WebUI: https://github.com/AUTOMATIC1111/stable-diffusion-webui
ComfyUI: https://github.com/comfyanonymous/ComfyUI
Fooocus: https://github.com/lllyasviel/Fooocus
SeaArt AI: https://www.seaart.ai/
Leonardo.ai: https://leonardo.ai/
Clipdrop: https://clipdrop.co/
Microsoft Designer: https://designer.microsoft.com/
Bing Image Creator: https://www.bing.com/images/create
Adobe Firefly: https://www.adobe.com/products/firefly.html

What Is Vercel AI SDK? A Unified Toolkit for TypeScript Developers Building AI Apps

Sun, 17 May 2026 23:07:38 +0800

vercel/ai is the open-source AI SDK maintained by Vercel.

Its positioning is clear: it gives TypeScript developers a unified toolkit for building AI applications and AI Agents. It comes from the team behind Next.js, but it is not limited to Next.js. It also supports React, Svelte, Vue, Angular, and runtimes such as Node.js.

Project link: https://github.com/vercel/ai

If you are building a chat app, AI writing tool, RAG application, tool-calling Agent, streaming interface, or a product that needs to connect multiple model providers behind one application, Vercel AI SDK is worth a close look.

The Core Problem It Solves

When building AI apps today, one of the biggest headaches is not whether you can call a model. It is that different model providers have different APIs, streaming formats, tool-calling conventions, error behavior, and frontend state-management needs.

For example:

OpenAI has its own SDK and response formats.
Anthropic has its own message structure.
Google, xAI, Mistral, DeepSeek, Groq, and others all differ.
Streaming output requires chunk handling.
Tool calling requires structured requests initiated by the model.
Chat UI also needs messages, loading states, cancellation, retry, and error display.

If every provider gets its own handwritten adapter, the project becomes complex very quickly.

Vercel AI SDK tries to hide those differences behind a unified API. Developers write the app against one interface and connect different models through Providers.

Unified Provider Architecture

One key feature of Vercel AI SDK is that it is provider-agnostic. It is not tied to one model vendor.

It can access OpenAI, Anthropic, Google, and other model providers through a unified API. The project README also notes that AI SDK uses Vercel AI Gateway by default, making it easier to reach multiple mainstream providers.

That is useful in real engineering projects.

Many AI products eventually depend on more than one model:

Some tasks need strong reasoning models.
Some tasks need cheap, fast models.
Some tasks require multimodal models.
Some tasks require long context.
Some tasks require local or private deployment.

A unified provider architecture makes model switching, gray releases, cost control, and fallback strategies easier.

Streaming Output Is Key to Frontend UX

One major UX difference between AI apps and traditional APIs is that responses can be long.

If users must wait for a full answer before seeing anything, chat tools, writing tools, and coding assistants feel slow. Streaming output lets text appear gradually, so users see progress sooner.

Vercel AI SDK provides fairly complete abstractions for streaming generation. Developers do not need to handle low-level event streams from scratch. They can use the SDK’s generation and streaming APIs to connect model output to frontend UI.

This is especially convenient for Next.js and React applications.

An AI chat interface looks simple, but in practice it must handle:

Message lists.
User input.
Server requests.
Streaming token display.
Loading states.
Error states.
Stopping generation.
Regeneration.

These are exactly the kinds of repetitive work AI SDK tries to reduce.

Tool Calling and Agent Scenarios

As AI apps move from “chatting” to “doing things”, tool calling becomes increasingly important.

The model may need to call external functions instead of only returning natural language:

Query a database.
Search documents.
Call business APIs.
Read order status.
Generate charts.
Create calendar events.
Modify project files.

Vercel AI SDK supports tool-calling capabilities, allowing developers to define tools, parameters, and execution logic, then let the model request those tools when appropriate.

This is one reason it has evolved from a “chat UI SDK” into a broader toolkit for AI apps and Agents.

Still, tool calling is not magic. Real projects must also handle:

Parameter validation.
Permission boundaries.
Tool-call logs.
Idempotency.
Timeouts and retries.
Human confirmation.
Restrictions for sensitive actions.

AI SDK can help with interfaces and flow, but developers still need to design the safety boundaries.

UI Integration

Vercel AI SDK is friendly to frontend frameworks.

It provides not only core generation APIs, but also abstractions around chat, completion, message state, and streaming UI. For teams using Next.js and React, this can remove a lot of boilerplate.

But it is not only for Vercel deployments.

If your project is built with TypeScript, or your backend runs on Node.js, AI SDK can still serve as the model-calling and streaming layer. Whether you deploy to Vercel depends on your architecture, team habits, and infrastructure choices.

Skill for Coding Agents

The vercel/ai README includes an interesting suggestion: if you use coding agents such as Claude Code or Cursor, you can add the AI SDK skill to your repository.

The example command is:

`1`	`npx skills add vercel/ai`

This shows that Vercel understands AI SDK users are not only human developers, but also coding agents.

When an agent modifies a project that uses AI SDK, a dedicated skill in the repository can help it understand SDK conventions, common APIs, project structure, and best practices, reducing the chance of messy code changes.

This direction is worth watching.

In the future, open-source projects may provide not only README files and docs, but also structured skill instructions for AI coding agents. For complex SDKs, that could become a new developer-experience entry point.

Suitable Projects

Vercel AI SDK is a good fit for:

AI chat apps based on Next.js or React.
Writing, Q&A, support, and coding assistants that need streaming output.
AI products that need multiple model providers.
Teams building quick RAG or document Q&A prototypes.
Apps that need tool calling, function calling, or lightweight Agent capabilities.
Teams already using TypeScript and Node.js.

It is especially suitable for frontend and full-stack developers. The hard part of many AI apps is not only calling a model, but turning model output into a stable, smooth, interactive product experience.

What It Is Not For

If your project is mainly a Python backend, deep-learning training workflow, model fine-tuning system, or low-level inference service, Vercel AI SDK may not be the core tool.

It is an application-layer SDK, not a model-training framework.

If you need to:

Train your own model.
Manage GPU inference clusters.
Run low-level batch inference.
Deeply control tokenizer behavior, KV cache, quantization, and inference engines.

Then you should look at PyTorch, vLLM, SGLang, TensorRT-LLM, llama.cpp, or cloud inference services.

Vercel AI SDK is closer to the application layer that connects model capabilities to products.

What to Watch For

First, do not assume a unified API means all providers are identical.

Different providers still differ in capabilities, context length, tool-calling formats, streaming details, error types, and pricing. A unified SDK reduces engineering friction, but it does not erase model differences.

Second, control costs.

Once an AI app is online, streaming chats, retries, tool calls, RAG retrieval, and multi-model fallbacks can all increase cost. Rate limits, caching, logs, and budget monitoring are necessary.

Third, handle safety boundaries.

If a model can call tools, you must restrict what those tools can do. Do not let the model directly execute high-risk operations, and do not expose secrets, database write permissions, or production operations to it without controls.

Fourth, keep observability.

When an AI app fails, frontend errors are not enough. You need to know the user input, selected model, tool calls, response time, token usage, error type, and final output.

Summary

vercel/ai is not a new model, and it is not just a chat component.

It is closer to infrastructure for TypeScript AI application development: unified Providers, streaming output, tool calling, frontend state management, and Agent scenarios all live inside one open-source SDK.

For teams already using Next.js, React, TypeScript, and Node.js, it can significantly reduce the engineering cost of going from “the model API runs” to “the product experience works”.

But it is not a universal layer. Model selection, permission design, cost control, logging, monitoring, and business safety still belong to the developer.

If you want to build AI applications rather than train models, Vercel AI SDK is a toolkit worth trying early.

References

Is QuillBot AI Detector Accurate? How AI Text Detection Works, Who It Helps, and What to Watch For

Sun, 17 May 2026 23:05:51 +0800

QuillBot AI Checker, often called QuillBot AI Detector, is an AI content detection tool from QuillBot.

Its purpose is straightforward: it helps users estimate how likely a piece of text is to have been generated by AI.

One point is worth clarifying first. QuillBot’s text AI Detector analyzes text, not images, videos, or other rich media. QuillBot also offers a separate AI Image Detector for checking whether an image looks more like it was photographed or drawn by a person, or generated by an AI image model. Both belong to QuillBot’s detection ecosystem, but they handle different input types.

What QuillBot AI Checker Can Do

The core function of QuillBot AI Checker is text AI detection.

Users can paste text into the detection box, and depending on account permissions, may also upload files. The tool analyzes textual patterns and returns an AI probability score or risk signal.

It usually focuses not on a single word, but on the overall language pattern, such as:

Whether sentence structures are too uniform.
Whether word choices are highly predictable.
Whether paragraphs advance in a template-like way.
Whether expressions repeat too often.
Whether the tone is too smooth and lacks natural variation.
Whether the logic resembles a generic answer from a large language model.

The final result is usually shown as a percentage or risk level, helping users judge whether the text may be seen as AI-generated.

Why Sentence-Level Highlights Matter

AI detection tools often provide more than an overall score. They may also mark parts of the text locally.

For example, some sentences in an article may be marked as more AI-like, others as more human-written, and some as possibly rewritten or polished by AI.

The value of this highlighting is not to chase a mechanical 0% AI score. It is to help locate weak spots.

If a paragraph is flagged heavily, it is worth checking:

Whether it sounds too much like a manual.
Whether it is too generic.
Whether it lacks concrete examples.
Whether every sentence has the same length and rhythm.
Whether it lacks real experience, reasoning, or detail.

For writers, this is more useful than looking only at a total score. The goal should not be to “hide from the detector”, but to make the content more specific, better reasoned, and more aligned with its real writing purpose.

QuillBot Also Has an AI Image Detector

Besides text detection, QuillBot also provides a separate AI Image Detector.

That tool is for images. It tries to estimate whether an image was photographed or drawn by a human, or generated by an AI image model. It is often discussed alongside tools such as Midjourney, DALL-E, and Stable Diffusion.

But the text AI Detector and AI Image Detector are different tools:

The text detector analyzes writing.
The image detector analyzes images.
Both provide probability-based judgments, not forensic proof or absolute conclusions.

If you need to check both an article and its images, use the corresponding tool for each input type.

Typical Use Cases

QuillBot AI Checker is commonly used in three scenarios.

The first is student self-checking.

Many schools use Turnitin or other academic integrity tools to check essays, reports, and assignments. Students may use an AI Detector before submission to understand whether their writing might be misread as AI-generated.

This requires caution. An AI detector is not the final judge, and it cannot guarantee that a school system will produce the same result. A low AI score also does not automatically mean the work is safe. A better habit is to keep drafts, sources, revision history, and writing notes.

The second scenario is teachers and educators reviewing assignments.

Teachers can treat an AI Detector as a signal tool for spotting unusual text. But it is risky to judge misconduct based only on one score. A better process combines classroom performance, writing records, oral explanation, sources, and version history.

The third scenario is content creators, editors, and site operators reviewing external submissions.

If a site receives many guest posts, SEO articles, or outsourced drafts, an AI Detector can help screen low-quality, template-like, mass-generated content. This is especially useful for content sites and media editors who want to avoid publishing large volumes of AI-assembled material with no experience, no viewpoint, and no fact checking.

Still, the detector is only an aid. What matters most is whether the content is original, accurate, useful, and trustworthy, not whether it achieves a specific score.

Relationship With Paraphraser and AI Humanizer

One of QuillBot’s best-known products is Paraphraser, its rewriting tool. It also offers AI Humanizer, which is designed to make AI-generated text read more like human writing.

These tools are often used together:

A user drafts text with ChatGPT, Claude, or another model.
They use QuillBot Paraphraser to rewrite sentences.
Or they use AI Humanizer to adjust tone.
Then they paste the result into AI Checker to see the detection score.

This workflow is common, but it can easily go in the wrong direction.

If the only goal is to lower the AI probability, the result may become mechanical rewriting. The text can become more awkward, less natural, or even less accurate.

A healthier approach is:

Use Paraphraser to improve clarity.
Use Humanizer to adjust tone and rhythm.
Use AI Checker to find overly template-like passages.
Let a human verify facts, logic, and writing intent at the end.

In other words, AI Checker should not mainly serve “detection evasion”. It should serve content quality.

False-Positive Risks in AI Detectors

All AI content detectors can produce false positives.

The reason is simple: they are not reading the author’s identity. They are estimating text patterns. Human writing that is very regular, standardized, or template-like may be misclassified as AI. Conversely, AI-generated writing that has been carefully edited and enriched with specific details and personal judgment may look more human.

Content that is easy to misclassify includes:

Academic abstracts.
Official notices and formal documents.
Product descriptions.
Standardized reports.
Polished English by non-native writers.
Concise text that has been edited many times.

Students, teachers, and editors should not treat an AI detection score as the only evidence.

A safer judgment looks at the evidence chain:

Are there drafts and revision records?
Can the author explain the writing process?
Are real sources cited?
Does the text include specific experience, observation, and judgment?
Are there factual errors, fake citations, or obvious templates?

Usage Advice

If you only want to self-check an article, treat QuillBot AI Checker as an auxiliary reminder.

When you see a high score, do not rush to “wash” the text. Look at the content itself first:

Are the claims too empty?
Are there too few examples?
Are facts unsupported?
Are paragraphs repetitive?
Is the sentence rhythm too consistent?
Is real context missing?

If you are a teacher or editor, do not make a conclusion from a screenshot of one score. AI detection results are better used as a starting point for further review, not as a final verdict.

If you review website content, combine AI Detector with human editing, plagiarism checks, fact checking, and source review. It can help spot low-quality bulk content, but it cannot replace editorial judgment.

Summary

QuillBot AI Checker is a convenient AI text detection tool for making an initial judgment about whether content looks AI-generated. It can provide an overall probability and help locate sentences or paragraphs that look more AI-like.

But it is not an absolute judge.

The value of an AI detector is not that it can tell you “this article was definitely written by AI”. Its value is that it can point out places that may be too template-like, too smooth, or lacking real detail.

Reliable content review still depends on writing history, factual sources, human judgment, and contextual evidence. Used as an aid, QuillBot AI Checker can be useful. Used as a final conclusion, it can easily harm normal writers.

References

Midjourney May 2026 Update: Conversational Mode, AI-Assisted Development, and SREF Organization

Sun, 17 May 2026 20:20:51 +0800

The most important signal from Midjourney’s May 14, 2026 Office Hours is not a single model parameter. It is that the product is continuing to move from “type a prompt and generate an image” toward a more conversational, organized, and iterative creative system.

The information comes from a Japanese summary of Midjourney’s recent Q&A, covering conversational mode, AI-assisted development, website redesign, SREF and tag organization, Omni-reference, multi-character consistency, and how the team itself uses Midjourney.

In one sentence: Midjourney is making image generation feel more like a creative system that can be discussed with, organized, and iterated over.

Conversational mode is becoming more important

The most direct change is Conversational Mode.

In the past, using Midjourney still depended heavily on parameters and fixed syntax. You had to remember rules for aspect ratio, image references, style references, model parameters, and then write them into prompts or adjust them in the interface.

The direction of the new conversational mode is to let users describe these settings in more natural language.

For example, users can specify by voice or text:

Default parameters.
Aspect ratio, such as 16:9.
Image references.
Style references, or --sref.
Omni-reference in V7.

This shows Midjourney is not only improving generation quality. It is also reducing the operational cost of parameters.

For ordinary users, the biggest change is that they do not have to memorize commands all the time. For heavy users, if conversational mode becomes stable enough, it may become the main entry point for adjusting generation settings with natural language.

AI-assisted development is changing Midjourney’s iteration speed

Another interesting point is that the Midjourney team is using AI-assisted development at large scale internally.

The source notes that the team can now fix small bugs, interface friction, and workflow issues much faster. There was even an example where a product bug was identified during a user call, fixed in real time with AI assistance, reviewed, and deployed quickly.

This is more interesting than simply saying “AI helps engineers write code.”

It shows that AI development tools are starting to influence how AI products themselves iterate:

User feedback can enter the fix pipeline faster.
Small experience issues are easier to address.
Engineers can spend more energy on architecture, review, design decisions, and testing.
Product teams can clean up edge cases more frequently.

Midjourney has many creative paths, parameter combinations, mobile experiences, search features, and organization workflows. Many issues are not about the core model failing to generate images, but about an entry point being awkward, an operation taking one extra step, or an edge state being unpleasant.

AI-assisted development is especially good at accelerating these many small improvements.

The website redesign is about workflow, not removing features

The Office Hours also mentioned a large website redesign.

The goal is not to remove complex features, but to make the creative flow more intuitive, make onboarding easier, and organize tools and features more clearly.

That matters.

Midjourney’s problem is not a lack of features. As features grow, entry points, collections, organization, references, exploration, and reuse become more complex. For light users, the hard question is “where do I start?” For heavy users, the hard question is “how do I manage many styles, references, and experiment results?”

Possible rollout strategies include:

Offering old and new interfaces in parallel.
Starting with an alpha test.
Moving gradually to avoid disrupting heavy users.

These strategies suggest the team understands that Midjourney is not just a casual image toy. Many users have already integrated it into real creative workflows, so interface changes cannot casually break existing habits.

SREF, styles, and tags remain pain points

SREF and style organization were among the most interesting topics in the Q&A.

Users want better organization systems, especially for:

Random SREF.
Style references.
Saved aesthetics.
Tags and colored tags.
Stronger filtering, grouping, and reuse.

But the team also raised a question: if the current folder system already lets one image belong to multiple folders, supports unlimited folders, and offers filtering and sorting, what exactly do tags provide that folders cannot?

That question is practical.

Many products add tags because users say they want tags. But a poorly designed tag system becomes another messy classification layer. If folders, tags, favorites, search, filters, projects, and style libraries have unclear boundaries, the system becomes harder to manage.

So the Midjourney team wants concrete workflow examples: in which scenario do users need tags? Why are folders not enough? Is it for combining styles quickly, reusing across projects, filtering by theme, color tone, photography style, or character relationship?

For Midjourney, the organization system may become as important as the generation model. Once users create long-term projects, the hard part is not generating one image, but managing thousands of images, hundreds of style directions, and repeated experiments.

Omni-reference points toward more complex character control

The source also mentioned that future Omni-reference / subject reference systems may support multiple character references at once and better separation of different subjects.

This maps directly to a long-running pain point in AI image generation: character consistency and multi-character relationships.

Keeping one character consistent is already difficult. Multiple characters are harder. Common problems include:

Character A’s traits leaking onto character B.
Identity confusion between multiple people.
Clothing, hair, and facial features changing across images.
Reference images influencing the whole style too strongly instead of controlling only the subject.

If Omni-reference can handle subject separation better, Midjourney becomes more useful for comics, storyboards, advertising visuals, character design, game concept art, and continuous narratives.

This is one of the areas worth watching after V7.

Midjourney is rethinking prompts

The summary includes a useful idea: language is an imperfect compression layer for imagination.

That sentence explains Midjourney’s product direction well.

Many users assume AI image generation is mainly about writing longer and more precise prompts. But in real creative work, image references, style references, moodboards, SREF, variations, regeneration, and post-processing are often more useful than a very long text prompt.

Team member Duncan’s workflow reflects this. He reportedly treats Midjourney as a sketchbook, combining moodboards, SREF, short prompts, high --r regeneration, strong and subtle variations, Photoshop retouching, and external upscaling workflows.

This shows mature Midjourney users do not work only through “magic prompts.”

A more realistic process is:

Use a small amount of language to set direction.
Use image references to provide visual context.
Use SREF to narrow the style.
Use many variations to explore the space.
Use human taste to select results.
Use external tools for post-processing.

Prompts still matter, but they are not everything.

What this means for users

If you only generate images occasionally, the most direct impact is that conversational mode should become easier to use. In the future, you may be able to describe desired aspect ratio, references, style, and parameters more naturally instead of memorizing commands.

If you are a heavy user, three areas deserve attention.

First, organization.

How SREF, styles, folders, favorites, and tags evolve will directly affect long-term creative efficiency.

Second, the website redesign.

If the new interface can connect exploration, organization, reuse, and export, Midjourney will feel more like a professional creative tool instead of a single generator.

Third, character and subject reference.

If Omni-reference can reliably handle multiple characters and subject separation, Midjourney becomes better suited for continuous projects rather than only single images.

Summary

The key point from Midjourney’s May 2026 Office Hours is not one flashy parameter. It is that the product is continuing to evolve toward a creative system.

Conversational mode lowers the input barrier. AI-assisted development increases iteration speed. The website redesign aims to reorganize workflows. SREF and tag discussions point to long-term asset management. Omni-reference relates to character consistency and complex subject control.

For AI image generation tools, model capability is obviously important. But once generation quality reaches a certain level, what determines whether users stay long term is often workflow, organization, controllability, and iteration speed.

Midjourney is filling in those pieces.

References

Midjourney 最新ニュース（2026年5月14 日）｜アキスケ

How OpenClaw Creator Peter Steinberger Sees AI Software Development: From OpenClaw to Closed-Loop Coding

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger’s career is a useful lens for understanding what is changing in AI software development.

He is not a newcomer who suddenly became visible because of AI. Before OpenClaw, he was already the founder of PSPDFKit, a company focused on PDF rendering, document processing, and developer tools. Products like that are hard to win with concept packaging alone. They have to deal with performance, compatibility, API design, enterprise customers, and long-term maintenance.

So when Steinberger later built OpenClaw with AI tools and shared views around AI agents, personal automation, and AI coding, the point was not simply that “one person wrote a lot of code.” The more interesting part is how he combined years of software engineering experience with a new generation of AI coding agents and rethought the development process.

AI coding is not a magic button

Discussions about AI coding often fall into two extremes.

One side says AI can already write code, so programmers are almost obsolete.

The other side says AI-generated code is unreliable, so real engineering still has to be hand-written by people.

Steinberger’s experience points to a third view: AI changes the unit of operation in software development, but it does not remove engineering judgment.

In the past, developers mainly worked around editing code. Requirements breakdown, architecture decisions, implementation, testing, and bug fixing all revolved around manual code changes.

Once AI coding agents enter the workflow, developers increasingly manage an execution system:

Explain the goal.
Provide context.
Set boundaries.
Let the agent modify code.
Run tests and checks.
Iterate based on results.

This is not simply handing the keyboard to a model. It is moving humans from “typing every line” toward “defining direction, designing feedback, and judging results.”

Why he is skeptical of calling it vibe coding

One phrase that often appears around Steinberger is vibe coding.

The term originally described a new style of development: developers describe ideas in natural language, let AI generate large amounts of code, then keep adjusting based on runtime results and feedback.

But Steinberger is not entirely sold on the phrase. Public coverage has noted that he sees vibe coding as potentially dismissive, implying that AI-assisted development is just “generating by feel” while ignoring the skill, judgment, and experience behind it.

That criticism makes sense.

Effective AI coding is not about typing a casual sentence and trusting the model’s output. It requires:

Breaking vague requirements into executable tasks.
Detecting when the model misunderstands the goal.
Designing tests and acceptance criteria.
Judging whether the code structure will remain maintainable.
Knowing when to stop generating and switch to human review.

In other words, AI reduces the friction of writing code, but it does not reduce the responsibility of understanding the system.

The loop is the key

One idea often associated with Steinberger’s interviews and writing is the importance of the loop.

Letting AI generate code is open-loop.

Letting AI generate code, run it, read errors, fix problems, and run tests again is closer to closed-loop development.

That difference matters.

Open-loop generation easily creates software that looks usable on the surface. The page opens, features appear to exist, and there is plenty of code. But once it enters a real environment, problems with state management, permissions, exception handling, edge cases, and deployment quickly appear.

Closed-loop development means output must be constrained by feedback. The simplest loop is:

Write down the goal clearly.
Let AI modify the code.
Automatically run tests, type checks, lint, or a build.
Feed errors back to AI.
Repeat until it passes.
Let a human review the critical path.

This is where AI software development can truly improve efficiency. Not because the model gets everything right the first time, but because it can participate quickly in a cycle of generation, validation, and repair.

More experience makes AI more useful

One of the easiest misconceptions about AI coding is that experience no longer matters.

Steinberger’s case suggests the opposite: experience becomes more important, but its role changes.

An experienced engineer is better at deciding:

Which tasks are suitable for an agent.
Which modules need tests first.
Which changes are too risky for broad AI refactoring.
Which generated code merely looks plausible.
Which problems should be solved through architecture rather than more patches.

AI can generate many candidate solutions. The more candidates you have, the more judgment you need. An inexperienced person may be impressed by “it runs.” An experienced engineer asks: can it be maintained? Can it scale? Does it break a security boundary? Can we debug it when something goes wrong?

That is why AI coding agents do not turn software engineering into pure chat. They outsource part of the execution work while amplifying planning, review, validation, and trade-off decisions.

OpenClaw matters beyond the project itself

OpenClaw drew attention not only because it is an open-source AI agent, and not only because it grew quickly.

It is also a signal: developers increasingly want AI to do more than answer questions. They want it to connect to real tools and perform real actions.

Traditional chatbots stay inside the chat box. They can explain code, write drafts, and give advice, but people still need to copy, paste, open software, and run commands.

The agent direction connects models to tools:

File systems.
Browsers.
Terminals.
Email.
Calendars.
Third-party services.
Project repositories.

Once models can use those tools, the boundaries of software development shift. AI is no longer just code completion. It can participate in project reading, task decomposition, file editing, test execution, PR preparation, and workflow automation.

That is also why Steinberger’s move to OpenAI drew attention. He represents not just a single developer story, but a product direction: personal agents moving from demos into everyday work.

What this means for ordinary developers

For ordinary developers, Steinberger’s experience is not something everyone can copy directly.

Not everyone can manage multiple agents at once. Not every project is suited to heavy AI generation. Not every team accepts a workflow of “generate first, iterate quickly.”

But several lessons are useful.

First, write tasks clearly.

AI is sensitive to vague goals. If you say “optimize this,” it may change style, structure, features, and logic. If you say “change the login failure message from English to Chinese without altering the authentication flow,” the result is usually more controllable.

Second, standardize validation commands.

If a project has no tests, no build command, and no lint, AI has trouble forming a loop. Even basic commands like npm test, go test ./..., pytest, or hugo are better than relying only on visual inspection.

Third, control the scope of changes.

Having AI handle one module, one bug, or one page at a time is usually more reliable than asking it to “refactor the whole project.”

Fourth, keep human review.

For authentication, payments, permissions, data deletion, deployment scripts, database migrations, and security configuration, do not lower the review bar just because the code was generated by AI.

Fifth, review prompts and failure patterns.

If AI often misunderstands a certain type of task, write those constraints into project rules, agent instructions, or skill files. AI coding capability comes not only from the model, but also from the work environment you build around it.

Where AI software development is going

Steinberger’s story suggests that AI software development is moving from “helping write code” toward “organizing software production workflows.”

Early AI coding tools were mainly useful for function completion, error explanation, and template generation. The shift now is that agents can work across files, call tools, run checks, and continue fixing based on feedback.

This points to several trends.

First, the productivity ceiling for individual developers will rise.

One person can push more prototypes, scripts, internal tools, and small products. But higher output does not automatically mean higher quality. The faster code is generated, the more validation matters.

Second, project structure becomes more important.

The clearer the code, tests, and documentation, the easier it is for AI to make correct changes. Messy projects are hard for humans and hard for AI.

Third, software engineers will look more like workflow designers.

In the future, what matters will not only be whether someone knows a programming language, but whether they can organize requirements, context, tools, tests, deployment, and permissions into a controlled loop.

Fourth, security boundaries become more sensitive.

If an agent can do things, it can also do the wrong things. If it can read files, run commands, and access services, then permissions, audit, and rollback become infrastructure for AI development environments.

Summary

The most valuable part of Peter Steinberger’s view of AI software development is not how much code AI generated. It is the development posture he demonstrates.

Humans are no longer only typing line by line inside an editor. They are designing goals, managing agents, building feedback loops, reviewing results, and adjusting the system. Code remains important, but it is no longer the only center of labor.

If traditional software development emphasized “writing the code correctly,” AI software development increasingly emphasizes “making the system continuously produce verifiably correct results.”

This is not just about lowering the engineering barrier. It changes the shape of engineering ability: from manual implementation toward task decomposition, context management, tool orchestration, automated validation, and final judgment.

References

How to Use Hugo aliases: Old URL Redirects and 404 Fix Guide

Sun, 17 May 2026 20:00:17 +0800

Hugo aliases create redirects for old page URLs.

When you change an article URL, merge pages, migrate a blog, or want to fix a common mistaken URL, you can add aliases in the article’s Front Matter. Hugo generates redirect pages for those old addresses and sends visitors to the current page, avoiding unnecessary 404 errors.

What aliases are useful for

There are three common scenarios.

The first is improving article URLs.

For example, your old article URL might be:

`1`	`/posts/tech/2023-01-01-hello/`

Later you may want to shorten it to:

/hello/

In that case, add the old URL as an alias on the new page. Search engines, external references, and social links can still reach the content.

The second scenario is merging or migrating pages.

If you merge several old posts into a new one, or migrate from Hexo, Typecho, WordPress, or another platform to Hugo, the old URL structure often differs from the new site. aliases can point those old addresses to the new pages one by one and reduce post-migration 404s.

The third scenario is fixing spelling mistakes.

Some URLs may have been written incorrectly, or external sites may already link to the wrong path. If that wrong link receives traffic, you can create a dedicated alias for it and still guide users to the correct page.

Basic syntax

Add an aliases field in the article Front Matter.

YAML example:

---
title: "New Article Title"
date: 2026-05-17T12:00:00+09:00
url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/
  - ../old-version/
---

Here /old-path/old-article/ is a site-relative path. ../old-version/ is relative to the current page.

In practice, site-relative paths that start with / are usually easier to reason about. They are clearer and less likely to break when the article directory structure changes.

Relationship with the url field

url defines the new address of the current page.

aliases defines which old addresses redirect to that new address.

For example:

1
2
3

url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/

After the site is built, visitors to /old-path/old-article/ will be redirected to /new-path/my-new-article/.

If the article does not explicitly set url, Hugo generates the current page URL from the site’s permalinks configuration, the article date, slug, and other rules. aliases will still point to that final generated page.

How Hugo implements redirects by default

By default, Hugo generates a separate HTML file for each alias.

That HTML file usually uses:

`1`	`<meta http-equiv="refresh">`

This makes the browser automatically redirect from the old address to the new one.

This approach is simple, portable, and works well on ordinary static hosting. But it is a browser-side redirect, not a server-side 301 or 302 redirect.

For small sites, this is often enough. As long as the old address opens and eventually reaches the new article, it avoids obvious 404 problems.

When to consider server-side redirects

If your site is hosted on Netlify, Cloudflare Pages, Vercel, or another platform that supports redirect rules, server-side redirects may be a better option.

Server-side redirects have several advantages:

They respond more directly without returning an intermediate HTML redirect page.
They make it easier to use explicit 301 or 302 status codes.
They centralize large migration rule sets for easier review and maintenance.
They give you more control over SEO migrations.

A common approach is to disable Hugo’s default alias page generation and output the redirect rules required by the hosting platform instead. Netlify commonly uses _redirects; Cloudflare Pages can use _redirects or platform-level rules.

If you choose this route, study Hugo’s disableAliases setting and custom output formats. Do not simply remove aliases, or the old links will turn into 404s.

Things to watch out for

First, do not use aliases as an excuse to change URLs casually.

Once a URL is public, it enters search engines, RSS feeds, social platforms, bookmarks, and external references. Frequent URL changes create maintenance costs. aliases are better for fixing historical problems than for encouraging constant path changes.

Second, avoid redirect loops.

Old addresses should point to the current page’s new address. Do not make A redirect to B while B redirects back to A, and do not let multiple pages claim the same alias.

Third, be careful with language prefixes on multilingual sites.

Hugo multilingual sites often handle language paths automatically. If you write an alias inside a language-specific version, you may not need to manually add prefixes such as /en/ or /zh-tw/. Otherwise, you may generate duplicated paths such as /en/en/.... Always verify the local build result.

Fourth, check the generated output after changes.

After adding an alias, build the site and check whether the old path’s index.html appears under public. Also confirm that the redirect target inside that file is correct.

A practical check workflow

After editing the article Front Matter:

Confirm the current article’s new URL.
Add the old URL to aliases.
Run a Hugo build.
Check whether public contains the old URL’s index.html.
Open the generated HTML and confirm that it redirects to the new URL.
For multilingual pages, check especially for duplicated language prefixes.

This catches most path mistakes before deployment.

Summary

aliases are Hugo’s lightweight tool for preserving old links.

They are best suited for article URL changes, blog migrations, page merges, and incorrect-path fixes. Ordinary static sites can directly use Hugo’s default HTML redirect pages. Larger sites, or sites with stricter SEO migration requirements, can move further toward server-side redirect rules.

The real point is not only making new URLs look cleaner. It is also taking care of old URLs that already exist. A site that smoothly carries old URLs to new pages is much less likely to lose historical traffic during migrations and redesigns.

References

APT45 Uses AI to Validate Vulnerabilities at Scale: The Barrier to Zero-Day Attacks Is Falling

Sun, 17 May 2026 19:52:39 +0800

Google Threat Intelligence Group published a new AI Threat Tracker on May 11, 2026. The important point is not simply that attackers are using AI. The more important shift is how they are using it: moving from writing, translation, and reconnaissance into vulnerability research, PoC validation, malware obfuscation, and automated attack orchestration.

Two points are easy to mix together, so they should be separated first.

First, Google said it identified what it believes is the first zero-day exploit developed with AI assistance. That case involved an unnamed cybercrime group. The target was a popular open-source web-based system administration tool, and the vulnerability could bypass 2FA when the attacker already had valid credentials. Google said it worked with the affected vendor on responsible disclosure and may have prevented a mass exploitation event.

Second, APT45 was not attributed as the actor behind that zero-day case. GTIG separately noted that APT45, a North Korea-linked threat group, was observed sending large volumes of repetitive prompts to AI models to recursively analyze different CVEs and validate PoC exploits. In other words, APT45 is using AI as a vulnerability research and exploit arsenal management tool, not merely as a phishing-email assistant.

What the AI zero-day case shows

This zero-day was not a typical memory corruption bug, input filtering error, or simple misconfiguration. GTIG described it as a high-level semantic logic flaw: the developer hardcoded a trust assumption inside an authentication flow, creating a contradiction between 2FA enforcement logic and its exceptions.

These bugs are hard for traditional scanners. Static analysis and fuzzing are better at finding crashes, dangerous sinks, input-output paths, and known patterns. They are not always good at understanding what the developer intended to guarantee and where an exception quietly breaks that guarantee.

That is where large language models become risky. They may not be stronger than expert security researchers, but they are good at reading context, explaining intent, comparing similar code paths, and pointing out inconsistent business logic. Once attackers connect that ability to automation, logic flaws that used to require long manual review may become easier to screen at scale.

GTIG also noted several AI-generation traces in the exploit code, including educational docstrings, a hallucinated CVSS score, and a textbook Python style. Google also said it does not believe Gemini was used, while expressing high confidence that the actor used some AI model to support discovery and weaponization.

Why APT45 deserves long-term attention

APT45 has long been tracked as a North Korea-linked threat group with activity spanning espionage, financial gain, and strategic intelligence. What GTIG emphasized this time was its AI workflow: large, repetitive, recursive CVE analysis, PoC validation, and the accumulation of more reliable exploit capabilities.

That is different from asking AI to write a short script.

If an organization can connect AI to vulnerability triage, PoC validation, payload adjustment, and test environments, its human bottleneck changes. In the past, the number of vulnerabilities a team could study at the same time depended on researcher count, experience, and time. Now AI can absorb part of the repetitive reading, summarization, variant testing, and first-pass judgment, leaving humans to focus on target selection, exploitability verification, and delivery.

For defenders, this means the window for known vulnerabilities gets shorter.

After a CVE is disclosed, attackers do not need to manually read the advisory, inspect patch diffs, build test environments, and fix PoCs from scratch. AI can help them understand impact, generate test ideas, troubleshoot failures, and summarize version differences. Even if human correction is still required, the overall throughput improves.

This does not mean AI can hack everything by itself

This should not be read as proof that AI can independently complete full intrusions.

GTIG’s report is more precise: multiple parts of the attack chain are being accelerated by AI. Vulnerability research, malware obfuscation, reconnaissance, social engineering, information operations, mobile UI automation, and supply-chain abuse all show signs of AI involvement.

But AI still fails. It can hallucinate vulnerabilities, misjudge exploitability, generate broken code, or get lost in complex enterprise authorization logic. The real danger is not that AI is perfect. The danger is that attackers can now try cheaply. When large-scale trial and error becomes cheap enough, bad outputs can be filtered away and usable outputs can move into operations.

That is why cases like APT45 matter. State or state-adjacent groups have targets and patience. If AI reduces repetitive labor, they can spend more resources on high-value targets.

Defenders should focus on shrinking the exposure window

Many organizations used to divide risk into two buckets: known vulnerabilities are handled by patch management, while zero-days are handled by defense in depth. As AI enters vulnerability research, that boundary becomes less clean.

The more practical questions are:

After a new CVE is disclosed, how long does it take external attackers to produce a usable exploit?
Can your asset inventory tell you the same day which systems are affected?
Can WAF, EDR, logs, and identity systems detect abnormal attempts?
Do high-risk systems use MFA, least privilege, and network isolation by default?
Are open-source components, AI agent plugins, and third-party connectors included in supply-chain review?

AI zero-days do not make basic security obsolete. They punish environments where basic security has been neglected for too long.

If patch cycles are slow, asset inventories are unclear, internet exposure has no owner, logs are hard to search, and account privileges are excessive, AI only changes attacker efficiency. The underlying problem was already there.

The AI supply chain is also an attack surface

GTIG also highlighted attacker interest in the AI software ecosystem itself, including agent skills, third-party data connectors, open-source wrapper libraries, and automation frameworks. The risk does not necessarily come from the model being compromised. It can come from poisoned tools around the model.

This matters for anyone using AI coding tools, AI agents, and automation plugins.

A malicious skill, backdoored dependency, or over-permissioned connector can turn an AI system from a helper into an attacker-controlled execution path. When an agent can access files, browsers, terminals, cloud accounts, or enterprise data, supply-chain review has to extend beyond traditional applications.

At minimum:

Do not install agent skills and plugins from unclear sources.
Isolate tools that can execute commands, read files, or access secrets.
Do not run unreviewed AI-generated scripts directly in production.
Scan dependencies, GitHub Actions, PyPI / npm packages, and AI project components.
Apply least privilege and leakage monitoring to model API keys, cloud secrets, and GitHub tokens.

Practical advice for security teams

First, move vulnerability response earlier. High-risk CVEs should not wait for a monthly patch window, especially for VPNs, gateways, system administration panels, identity systems, CI/CD, and remote management tools.

Second, build a queryable asset inventory. If AI helps attackers locate targets faster, defenders must be able to answer quickly: do we run this system, which version, and where is it exposed?

Third, use behavior detection to supplement signature detection. AI-generated exploits and malware may change surface features, but authentication bypass, abnormal logins, bulk probing, failed request patterns, and privilege escalation still leave behavioral traces.

Fourth, bring AI tools into security governance. Internal coding agents, browser agents, document agents, automation scripts, and plugin marketplaces need approval, review, logging, and rollback paths.

Fifth, do not reduce AI defense to buying a security model. The useful work is putting AI into vulnerability prioritization, log analysis, patch impact assessment, code review, and configuration baseline checks so defensive speed can rise too.

Summary

GTIG’s report sends a clear signal: AI is accelerating the pace of offense and defense.

The AI-assisted zero-day case shows that logic bugs and authentication bypasses may become easier for models to surface. APT45 shows that mature threat groups are already using AI to analyze CVEs and validate PoCs at scale. PROMPTSPY, AI-generated obfuscation, and agent supply-chain abuse show that AI is becoming part of the attack toolchain.

This is not doomsday, but it is not ordinary news either.

For organizations, the practical response is not panic. It is faster, clearer, and more verifiable work on patching, assets, logging, identity, supply chain, and AI tool permissions. AI improves attacker trial speed. Defenders must improve discovery, judgment, and remediation speed as well.

References

Scientific Agent Skills: a skill library that gives AI Agents scientific workflows

Sun, 17 May 2026 17:52:04 +0800

K-Dense-AI/scientific-agent-skills is an Agent Skills collection for scientific and research work.

Its goal is not to create yet another chatbot. Instead, it turns common research tasks such as reading documentation, querying databases, writing analysis scripts, processing files, creating charts, and preparing reports into skills that an AI Agent can discover and call.

Project: https://github.com/K-Dense-AI/scientific-agent-skills

As of 2026-05-17, the GitHub API showed about 23.4k stars, 2.5k forks, an MIT license, and a latest push time of 2026-05-11. The README says the repository contains 135 ready-to-use scientific and research skills, while the scientific-skills directory currently shows 137 entries through the GitHub API. The difference may come from counting rules, recent additions, or README lag.

Bottom line

Scientific Agent Skills is useful if you already use Codex, Claude Code, Cursor, Gemini CLI, or another tool that supports the Agent Skills standard.

Its value is mainly in three areas:

It writes scientific toolchain usage into SKILL.md, so the agent does not have to guess how a library works every time.
It organizes common scientific databases, Python packages, document processing, scientific writing, and visualization workflows into one skill collection.
It makes an AI Agent feel more like a workflow-capable research assistant, not just a concept-answering bot.

But it is not a magic button that automatically does science after installation. Skills can help an agent choose the right tools and generate more reliable code and workflows, but data quality, experimental design, statistical assumptions, clinical decisions, and research conclusions still require human judgment.

What it includes

The README describes the project as a skill collection for research, scientific computing, engineering, analysis, finance, and writing. Major areas include:

Bioinformatics and genomics.
Cheminformatics and drug discovery.
Proteomics and mass spectrometry.
Clinical research and precision medicine.
Healthcare AI and clinical machine learning.
Medical imaging and digital pathology.
Machine learning and AI.
Materials science and chemistry.
Physics and astronomy.
Engineering simulation and optimization.
Data analysis and visualization.
Geospatial science and remote sensing.
Laboratory automation.
Scientific writing, literature review, peer review, and citation management.

The point of these skills is not to limit an agent to specific libraries. The README also says the agent can still write Python and call any available API or package. The skills provide curated documentation, examples, best practices, and integration paths.

In other words, it is closer to a collection of “scientific tool manuals + workflow templates + agent calling conventions.”

Database and Python package coverage

The most attractive part for researchers is the coverage of scientific databases and the Python ecosystem.

The README mentions:

Unified access to 78 public databases through database-lookup.
Coverage of PubChem, ChEMBL, UniProt, COSMIC, ClinicalTrials.gov, FRED, USPTO, and more.
Dedicated access skills for DepMap, Imaging Data Commons, PrimeKG, U.S. Treasury Fiscal Data, Hugging Science, and others.
More than 70 optimized Python Package Skills.

The directory includes many familiar names:

rdkit
scanpy
biopython
bioservices
pydeseq2
scvelo
scvi-tools
pymatgen
qiskit
pennylane
openmm
mdanalysis
scikit-learn
statsmodels
matplotlib
seaborn
networkx
sympy
pytorch-lightning
transformers
timesfm-forecasting

For developers, these libraries are not surprising by themselves. What matters is that an agent can read library-specific constraints, examples, workflows, and caveats while doing a task. That is more stable than relying only on old model memory.

Typical scenarios

Scientific Agent Skills is better suited to multi-step research tasks than single-turn Q&A.

For drug discovery, an agent might query ChEMBL for EGFR inhibitors, analyze structure-activity relationships with RDKit, run virtual screening with DiffDock, search the literature, and generate a report.

For single-cell analysis, it might load 10X data into Scanpy, perform QC, integrate datasets, identify cell types, run differential expression, and do pathway enrichment.

For multi-omics, it might connect RNA-seq, mass spectrometry, metabolites, protein interactions, clinical trials, and statistical modeling.

Without skills, these tasks can easily become “the agent knows the general direction, but you have to remind it at every step.” The value of a skill library is to preserve these high-frequency paths so the agent takes fewer wrong turns.

Installation

The README recommends the standard Agent Skills tool:

`1`	`npx skills add K-Dense-AI/scientific-agent-skills`

If you use GitHub CLI v2.90.0+, you can also install with gh skill:

`1`	`gh skill install K-Dense-AI/scientific-agent-skills`

Install a specific skill:

`1`	`gh skill install K-Dense-AI/scientific-agent-skills scanpy`

Target a specific agent:

gh skill install K-Dense-AI/scientific-agent-skills --agent codex
gh skill install K-Dense-AI/scientific-agent-skills --agent cursor
gh skill install K-Dense-AI/scientific-agent-skills --agent claude-code
gh skill install K-Dense-AI/scientific-agent-skills --agent gemini

For reproducibility, pin a release tag or commit SHA:

1
2

gh skill install K-Dense-AI/scientific-agent-skills --pin v1.0.0
gh skill install K-Dense-AI/scientific-agent-skills --pin abc123def

This matters in research. The worst situation is “it ran last week, the result changed this week, and nobody knows why.” If a skill participates in analysis, record the skill version, dependency versions, and data version together.

Runtime requirements

The README lists:

Python 3.11+, with 3.12+ recommended.
uv for installing Python dependencies.
A client that supports the Agent Skills standard.
macOS, Linux, or Windows with WSL2.

Windows users should pay attention to the WSL2 detail. Many scientific computing libraries can run on native Windows, but dependency chains, compilers, binary wheels, and path behavior are more likely to cause trouble. The README’s “Windows with WSL2” wording suggests a Unix-like research computing environment is the better target.

How this differs from a prompt collection

A regular prompt collection usually tells the model how to answer. Scientific Agent Skills goes further: it describes tools, libraries, databases, and workflows as discoverable skills.

The practical differences are:

A skill can contain structured instructions and example code.
A skill can be maintained around a specific library or database.
An agent can choose relevant skills by task instead of stuffing every rule into the system prompt.
A team can install only the skills it needs and reduce context noise.
Skills can be versioned, reviewed, and updated with the repository.

For complex research work, this is easier to maintain than copying one giant universal prompt. Models change, databases change, and Python packages change. Capturing those changes in skills is more controllable than scattering them across personal prompt documents.

Security and trust boundaries

The README’s security warning is direct: Skills can execute code and affect coding-agent behavior.

That matters. Research skills may:

Install Python dependencies.
Access network databases.
Read and write local files.
Run analysis scripts.
Process sensitive experimental or clinical data.
Generate reports that people may later cite.

So do not blindly install every skill. A safer approach is:

Install only the skills required for the current task.
Read the relevant SKILL.md before installation.
Check which packages, APIs, files, and external services the skill may call.
Be extra careful with community-contributed skills.
Run data-processing and code-execution tasks in an isolated environment.
Keep human review for research conclusions, clinical suggestions, and statistical results.

The README also mentions Cisco AI Defense Skill Scanner and suggests local scanning of third-party skills. Scanning does not replace human review, but it shows that the maintainers are aware of skill supply-chain risk.

Who it is for

This project is most useful for people who:

Already use AI coding agents daily.
Often process scientific data, papers, charts, and reports.
Need to move frequently across the Python scientific ecosystem.
Want an agent to execute multi-step analysis instead of just explaining concepts.
Want a team to turn research workflows into reusable skills.
Want to study how the Agent Skills standard applies to professional domains.

It is less suitable if:

You only want AI to explain a paper once in a while.
You do not have a local Python environment or do not want to manage dependencies.
You do not yet control data privacy, network access, and code-execution boundaries.
You need a strictly compliant clinical or production decision system without human review and validation.

For one-off analysis, asking the agent to write a script may be lighter. If you repeat similar research workflows often, the skill library becomes more valuable.

Usage advice

Do not start by installing the entire repository and handing every task to the agent.

A more practical path is:

Choose a low-risk task, such as literature organization, chart generation, or public-data exploration.
Install only relevant skills, such as literature-review, scientific-writing, scanpy, or rdkit.
Ask the agent to explain the plan before running code.
Preserve input data, scripts, environment, and skill versions.
Review outputs manually.
If the workflow stabilizes, write it into your team’s SOP or custom skill.

The key to a research agent is not automating everything. It is handing repetitive, tedious, documentation-heavy work to tools while leaving judgment, assumptions, and conclusions to humans.

Summary

Scientific Agent Skills matters because it pushes Agent Skills from general programming into research.

Scientific work is naturally multi-tool, multi-database, multi-file, and multi-step. Chat-style prompts alone rarely cover these details reliably. This project turns common scientific libraries, data sources, and research workflows into skills, making it easier for an AI Agent to enter real research workflows.

But the stronger it is, the more it needs boundaries. Skills can affect agent behavior, run code, access the network, and process files. Read the skill before installing it, isolate execution, and never skip human validation of research conclusions.

If you already use Codex, Claude Code, Cursor, or Gemini CLI for research and data analysis, Scientific Agent Skills is worth a careful look. Even if you do not install it wholesale, its way of splitting skills is a useful reference for building team research AI workflows.

References:

Bun: JavaScript runtime, package manager, test runner, and bundler in one tool

Sun, 17 May 2026 17:42:25 +0800

Bun is an open source JavaScript / TypeScript all-in-one toolchain from oven-sh.

It is not just trying to be a faster Node.js replacement. It puts the runtime, package manager, script runner, test runner, and bundler behind the same bun command. For frontend and Node.js developers, the appeal is simple: install fewer tools, wait less during installation and builds, and complete many common tasks with one command.

Project: https://github.com/oven-sh/bun

Bottom line

Bun is best for people who want to simplify the JavaScript toolchain.

It can:

Run JavaScript, TypeScript, JSX, and TSX.
Act as a Node.js-compatible runtime.
Replace npm / yarn / pnpm for package management.
Run scripts from package.json.
Execute tests.
Bundle frontend or backend code.
Use bunx to run commands from npm packages.
Provide built-in APIs such as Bun.serve, bun:sqlite, Bun.sql, Bun.redis, and Bun.s3.

Its clearest value is developer experience: fast installs, fast startup, unified commands, and TypeScript / JSX that work out of the box.

But Bun is not something every project should switch to immediately. Large Node.js applications, projects with many native extensions, and production services with strict stability requirements still need careful compatibility, build, test, and deployment validation.

What Bun is

According to the official README, Bun is an all-in-one toolkit for JavaScript and TypeScript applications. It ships as a single executable named bun.

At its core is the Bun runtime: a fast JavaScript runtime intended as a drop-in replacement for Node.js. Bun is written in Zig, built on JavaScriptCore, and optimized for startup time and memory usage.

That means you can run:

`1`	`bun run index.tsx`

TypeScript and JSX can run without extra setup.

The same bun command also includes:

test runner
script runner
Node.js-compatible package manager
bundler
package runner

Common commands include:

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

A typical project may otherwise include node, npm, pnpm, tsx, jest, vitest, webpack, esbuild, and ts-node. Bun tries to absorb many of those high-frequency paths into one tool.

Installation

Bun supports Linux, macOS, and Windows on x64 and arm64.

The official install script is:

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows:

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

It can also be installed through npm:

`1`	`npm install -g bun`

macOS Homebrew:

1
2

brew tap oven-sh/bun
brew install bun

Docker:

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Linux users should note the kernel requirement. The README strongly recommends Linux kernel 5.6 or newer, with 5.1 as the minimum.

Upgrade to the latest version:

`1`	`bun upgrade`

Upgrade to canary:

`1`	`bun upgrade --canary`

Canary is usually not a good choice for production unless you are validating a new feature or investigating a specific bug.

Why Bun is fast

Bun’s speed comes from several layers.

First, runtime startup is fast. Many CLI tools and development scripts are not limited by long CPU work, but by process startup, module loading, TypeScript transpilation, and dependency resolution. Bun optimizes these paths.

Second, package management is fast. bun install aims to replace npm / yarn / pnpm installation workflows. It uses a global cache and its own lockfile, which can noticeably reduce waiting time in dependency-heavy projects.

Third, TypeScript / JSX work out of the box. Many projects only need to run a .ts or .tsx script. Traditional Node.js setups need tsx, ts-node, Babel, or a build step. Bun can run these files directly and reduces glue tooling.

Fourth, built-in tools reduce process and configuration switching. Testing, scripts, bundling, and runtime execution all live in one tool.

Still, “Bun is fast” does not mean every project will be faster. Real results depend on dependency types, script logic, test framework, build configuration, Node.js API usage, and CI cache strategy.

Package management: replacing npm / yarn / pnpm

Bun can install dependencies directly:

`1`	`bun install`

Add a dependency:

`1`	`bun add react`

Add a development dependency:

`1`	`bun add -d typescript`

Remove a dependency:

`1`	`bun remove react`

Explain why a dependency exists:

`1`	`bun why react`

Security audit:

`1`	`bun audit`

When migrating from npm or pnpm, check:

Whether bun.lock is committed.
Whether CI uses bun install --frozen-lockfile.
Whether private registries and .npmrc are compatible.
Whether workspace behavior matches expectations.
Whether lifecycle scripts introduce security risk.
Whether pnpm-specific monorepo behavior can migrate smoothly.

Small projects can try it directly. Large monorepos should not switch everything at once; start with one package or a non-blocking CI job.

Running scripts and TypeScript

Bun can run scripts from package.json:

`1`	`bun run start`

It can also run files directly:

1
2

bun run index.ts
bun run index.tsx

This is useful for tool scripts such as:

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

With Node.js, these often require a TypeScript loader or precompilation. Bun’s direct execution makes those scripts lighter.

If a script depends on Node.js-specific behavior, especially loaders, ESM/CJS edges, native modules, child processes, file watching, or edge APIs, it still needs testing.

Test runner

Bun includes a test runner:

`1`	`bun test`

It is suitable for small projects that want less Jest / Vitest configuration, and for moving some unit tests, tool tests, or library tests to a lighter runner.

When migrating tests, pay attention to:

expect behavior.
mock API differences.
snapshot behavior.
DOM test environment.
test discovery rules.
coverage output.
CI reporter support.

If a project deeply depends on Jest features, such as custom matchers, complex mocks, jsdom, babel-jest, or ts-jest, migration should be gradual. Let new modules use bun test while old suites remain on the existing framework.

Bundling and builds

Bun also provides a bundler:

`1`	`bun build ./src/index.ts --outdir ./dist`

It can be used for frontend bundles, backend scripts, CLI tools, and libraries. Bun’s docs also cover loaders, plugins, macros, CSS, HTML, HMR, minifier, and single-file executables.

Good early candidates:

Small frontend tools.
Node.js CLI projects.
Internal scripts.
Single-file services.
Projects that do not depend on complex webpack loaders.

Be careful with:

Complex webpack plugin chains.
Large Vite plugin setups.
Deep Babel transformations.
Special CSS / asset pipelines.
Micro-frontends and module federation.
Projects with strict requirements for hashes, chunks, and compatibility.

Bun’s bundler is attractive, but migrating build tools is usually riskier than changing the package manager. Validate it separately.

Running HTTP services

Bun provides Bun.serve for HTTP services:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

This is convenient for small APIs, internal services, webhook receivers, and edge-style services. Bun also provides APIs such as WebSockets, Workers, Streams, SQLite, PostgreSQL, Redis, S3, and TCP/UDP sockets.

If you already use Express, Fastify, NestJS, Next.js, Hono, Elysia, or another framework, check their Bun compatibility before rewriting anything.

A practical path is:

Use Bun first for development scripts and package management.
Then try Bun for tests.
Only later evaluate whether the production runtime should move to Bun.

Runtime migration needs the most care because it directly affects production behavior.

Relationship with Node.js

One of Bun’s goals is to be a drop-in replacement for Node.js, but compatibility is not the same as complete equivalence.

The Node.js ecosystem has accumulated many subtle behaviors around:

CJS / ESM interop.
Node built-in modules.
Native extensions.
npm lifecycle scripts.
Filesystem edge behavior.
stream and Buffer details.
worker / child_process.
debugging and profiling.

Bun is improving compatibility quickly, but production migration should be judged by tests.

Practical questions:

Do your tests pass under Bun?
Do key dependencies support Bun?
Are build artifacts equivalent?
Are CI and local behavior consistent?
Do you have monitoring and rollback in production?
Are Docker images and deployment scripts stable?

Replacing only the package manager is lower risk. Replacing the production runtime is much higher risk.

Suitable projects

Bun fits well for:

New small JavaScript / TypeScript projects.
Internal tools and scripts.
CLI projects.
CI jobs that need faster dependency installation.
Frontend projects that want less toolchain complexity.
Scripts and services where startup speed matters.
Developers who want TypeScript to run out of the box.

Use more caution with:

Very large monorepos.
Projects deeply tied to pnpm workspace behavior.
Services with many Node.js native extensions.
Frontend builds with highly customized pipelines.
Backends that require strict production runtime consistency.
Test suites deeply tied to Jest.

A conservative but practical strategy is to treat Bun as a development tool first, not as an immediate replacement for every production runtime.

Migration advice

To try Bun in an existing project:

Install Bun locally.
Run bun install and inspect dependency installation.
Commit or temporarily keep bun.lock to avoid lockfile confusion.
Try bun run <script> on common scripts.
Migrate a small number of tests with bun test.
Add a non-blocking Bun job in CI.
If compatibility looks good, consider changing the main install flow.
Evaluate production runtime migration last.

For team projects, keep a rollback path:

Preserve the old npm / pnpm / yarn flow during migration.
Run both flows in CI for a while.
Do not change runtime, package manager, test framework, and bundler in the same change.
Split migration into small, verifiable steps.

This is slower, but it avoids mixing too many problems together.

Common commands

Install:

`1`	`curl -fsSL https://bun.com/install \| bash`

Upgrade:

`1`	`bun upgrade`

Install dependencies:

`1`	`bun install`

Add a dependency:

`1`	`bun add lodash`

Run a script:

`1`	`bun run dev`

Run TypeScript directly:

`1`	`bun run scripts/build.ts`

Test:

`1`	`bun test`

Bundle:

`1`	`bun build ./src/index.ts --outdir ./dist`

Run a package command:

`1`	`bunx cowsay 'Hello, world!'`

Summary

Bun’s value is not just “faster than Node.js.” More importantly, it pulls many scattered JavaScript / TypeScript development tools into one bun command: runtime, package manager, script runner, test runner, and bundler.

For new projects and internal tools, this integrated experience can be pleasant: fast installs, fast startup, less configuration, and direct TypeScript / JSX execution. For large existing projects, Bun is better introduced through low-risk areas first, such as package installation, scripts, and selected tests, before validating builds and runtime behavior.

If Node.js toolchain installation speed, configuration fragments, and slow test startup often bother you, Bun is worth a serious try. But production migration still comes back to basic engineering judgment: do tests pass, are dependencies compatible, is CI stable, and do you have rollback?

References:

RuView: an open source platform for camera-free spatial sensing with WiFi signals

Sun, 17 May 2026 17:34:08 +0800

RuView is an open source WiFi spatial sensing platform from ruvnet.

Its idea is ambitious: instead of using cameras or wearables, it relies on ordinary WiFi signals and low-cost ESP32-S3 sensing nodes to extract presence, motion, breathing, heart rate, activity patterns, room state, and pose-estimation signals from Channel State Information, or CSI.

Project: https://github.com/ruvnet/RuView

Bottom line

RuView is worth watching, but it needs a cool head.

It is not a regular web app, and it is not a finished monitoring system that can “see through walls” as soon as you start a Docker container. More accurately, it is a research-oriented open source platform around WiFi CSI, ESP32-S3, edge inference, spatial sensing, and multimodal fusion.

It is suitable for:

Learning WiFi CSI sensing and wireless signal processing.
Building ESP32-S3 prototypes for presence detection, activity detection, and vital-sign sensing.
Researching camera-free spatial sensing.
Exploring edge sensing for elder care, healthcare, smart buildings, retail traffic, security, and robot safety.
Testing non-video sensing in privacy-sensitive spaces.

It is not yet suitable for:

Replacing medical devices just by buying a board.
High-precision indoor 3D localization with a single ESP32 node.
Identifying each person accurately in any room without tuning or calibration.
Getting full CSI capability from ordinary RSSI on a laptop.
Direct deployment of a beta project into high-risk production scenarios.

The README also makes the limits clear: RuView is still beta software; APIs and firmware may change; ESP32-C3 and the original ESP32 are not supported; single-ESP32 deployments have limited spatial resolution; and camera-free pose estimation still has obvious accuracy limits.

What RuView is

RuView treats WiFi signals as spatial sensors.

WiFi routers continuously emit radio waves through a room. Human movement, breathing, sitting down, and standing up all cause tiny changes in those signals. Traditional WiFi mainly cares whether the connection works and how strong the signal is. RuView looks at lower-level Channel State Information.

CSI can be understood as fine-grained wireless-link state across subcarriers and time points. Compared with ordinary RSSI, it carries much more information and can help analyze:

Whether a room is occupied.
Roughly where someone is.
Whether someone is walking, sitting, or falling.
Whether breathing frequency looks abnormal.
Whether heart-rate signals can be estimated.
Whether the room’s RF fingerprint has changed.
Whether multiple nodes provide enough spatial relationship for finer localization.

RuView tries to turn raw wireless signals into usable spatial intelligence.

What it can sense

According to the project README, RuView focuses on:

Presence and occupancy: detecting people, occupancy changes, entries, and exits.
Vital signs: contactless breathing-rate and heart-rate estimation.
Activity recognition: walking, sitting, gestures, falls, and similar activities.
Environment mapping: room RF fingerprints, furniture movement, and new-object changes.
Sleep quality: nighttime monitoring, sleep-stage direction, and apnea screening research.
Pose estimation: human keypoint estimation based on WiFi CSI.

The easiest parts to land are presence detection, activity changes, and coarse occupancy judgment. Breathing, heart rate, and pose estimation place much higher demands on hardware placement, environment, signal quality, models, and calibration.

So it is better not to treat every feature as equally mature. Running a research pipeline and operating stably for months in a real home, hospital, hotel, or warehouse are very different engineering problems.

Why ESP32-S3

RuView recommends ESP32-S3 as the low-cost CSI collection node.

The README notes:

ESP32-C3 is not supported.
The original ESP32 is not supported.
The reason is limited single-core compute and insufficient capacity for CSI DSP workloads.
A single ESP32 deployment has limited spatial resolution.
Better results need two or more nodes, or Cognitum Seed.

This matters. “WiFi sensing” can make people assume that any laptop, router, or ESP32 board can do the full job. In practice, full CSI capability depends on hardware, firmware, and how data is collected.

The project describes several hardware paths:

Docker simulated data: no hardware needed, good for evaluating the processing pipeline.
ESP32-S3 nodes: low-cost real-time collection, suitable for prototypes.
ESP32 mesh: multiple nodes improve spatial resolution.
ESP32-S3 + Cognitum Seed: persistent memory, kNN, witness chain, and AI integration.
Research NICs such as Intel 5300 / Atheros AR9580 for fuller CSI research.
Ordinary WiFi laptops: usually limited to RSSI, with very limited sensing ability.

Quick trial

If you only want to see the interface and simulated data, start with Docker:

1
2

docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest

Then open:

`1`	`http://localhost:3000`

For real ESP32-S3 hardware, you need to flash firmware and configure WiFi:

1
2
3

python -m esptool --chip esp32s3 --port COM9 --baud 460800 \
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin \
  0xf000 ota_data_initial.bin 0x20000 esp32-csi-node.bin

Configure the network and target address:

1
2

python firmware/esp32-csi-node/provision.py --port COM9 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20

The project also provides real-time processing scripts, for example:

1
2
3

node scripts/rf-scan.js --port 5006
node scripts/snn-csi-processor.js --port 5006
node scripts/mincut-person-counter.js --port 5006

These commands are for developers who can follow the README and validate the pipeline step by step. Users without wireless signal-processing or embedded-development experience will face a real learning curve.

Processing pipeline

The basic RuView pipeline can be understood as:

WiFi signals pass through the room.
Human bodies and objects change the propagation paths.
ESP32-S3 mesh nodes collect CSI.
Multi-band, multi-subcarrier, and multi-node links are fused.
Signals are cleaned and features are extracted.
RuVector / AI Backbone performs representation, compression, retrieval, and modeling.
Neural networks output body keypoints, vital signs, and room models.
Upper-layer applications use the results for alerts, statistics, visualization, or automation.

This involves CSI amplitude and phase, multipath propagation, Fresnel-zone geometry, breathing and heart-rate filtering, Hampel filter, SpotFi, BVP, spectrograms, graph algorithms, attention, spiking neural networks, mesh nodes, and cross-view fusion.

That is why RuView is closer to a research platform than a small IoT utility.

Use cases

The README lists many possible scenarios.

For elder care and healthcare support:

Presence detection in an elder’s room.
Fall detection.
Night activity monitoring.
Breathing-rate observation during sleep.
Auxiliary breathing and heart-rate monitoring for non-critical beds.

These scenarios are attractive because they avoid cameras and do not require people to wear devices. But anything medical must be treated carefully. A research project should not be used as a medical device.

For smart buildings and commercial spaces:

Occupancy of desks and meeting rooms.
HVAC control based on real presence.
Hotel-room vacancy and energy saving.
Restaurant queues and table turnover.
Retail foot traffic, dwell time, and heat maps.

These are closer to occupancy and behavior statistics. They may be easier to deploy first because they require less centimeter-level precision, but they still need privacy controls.

For safety and industrial sites:

Perimeter intrusion detection.
Warehouse safety zones.
Forklift proximity alerts.
Presence in enclosed spaces.
Construction-site fall detection and headcounting.

These need low latency and reliable alerts, but false positives, missed detections, and liability boundaries must be handled.

For robotics and difficult environments:

Human sensing when cameras are limited.
Detecting people behind smoke, fog, occlusions, or shelves.
Searching for breathing signals in disaster rescue.
Underground, mining, ship, or other places where optical sensors struggle.

These are valuable research directions, but the engineering difficulty is higher.

Privacy benefits and new risks

RuView’s important selling point is that it does not need a camera.

In elder care, hospitals, schools, offices, hotels, restaurants, and bathrooms, cameras create obvious privacy pressure. WiFi sensing does not record images and does not require wearables, which reduces many visual privacy issues by design.

But “no camera” does not mean “no privacy risk.”

WiFi sensing can still infer:

Whether someone is in a room.
When people enter and leave.
Sleep, breathing, and activity patterns.
Falls or long periods of stillness.
Behavioral patterns in a space.

These are sensitive data too. Deployments still need clear notice, access control, retention rules, encrypted storage, minimal collection, and audit trails.

Compared with cameras, PIR, and millimeter-wave radar

Cameras provide rich, intuitive, explainable information, but they have the highest privacy pressure and depend on lighting and line of sight.

PIR sensors are cheap and easy to deploy, but they mainly sense heat changes. They can miss stationary people and have limited spatial resolution.

Millimeter-wave radar works well for contactless vital signs and presence detection and can be more stable, but it usually requires extra hardware and costs more than reusing WiFi infrastructure.

WiFi sensing has several advantages:

WiFi infrastructure is already common.
Signals can pass through some walls and occlusions.
It does not collect images.
ESP32-S3 nodes are inexpensive.
It can integrate with existing network environments.

The weaknesses are also clear:

Signals are strongly affected by the environment.
Node placement, node count, and wall materials matter.
Multi-person scenarios are harder.
High-precision pose and vital-sign estimation remain difficult.
Engineering validation is harder than ordinary camera deployments.

Current limits

The README already lists several key limits:

The project is still beta software.
APIs and firmware may change.
ESP32-C3 and the original ESP32 are not supported.
A single ESP32 deployment has limited spatial resolution.
Two or more nodes, or Cognitum Seed, are recommended.
Current camera-free pose-estimation accuracy is limited.
Camera-supervised training pipelines exist, but data collection and evaluation are still in progress.
The Docker example uses simulated data and does not represent real hardware performance.

This type of project is easy to oversell through headlines. WiFi sensing has strong technical potential, but real results depend on hardware, environment, deployment density, models, calibration, and application tolerance.

For prototyping, start with presence detection and simple activity recognition. Do not start by demanding high-precision pose, heart rate, and multi-person 3D tracking.

How to start

A practical learning path is:

Run Docker with simulated data to understand the UI and pipeline.
Read the README and architecture docs.
Prepare ESP32-S3, not ESP32-C3 or the original ESP32.
Start with single-node CSI collection and verify stable data flow.
Add two to four nodes and observe changes in spatial resolution.
Validate basic presence, movement, and breathing first.
Then try pose estimation, edge modules, and multimodal fusion.

For productization, also consider installation location, network security, encryption and retention, alert false-positive rates, user notice and consent, hardware maintenance, behavior during network or power loss, OTA updates, and firmware rollback.

Summary

RuView is an ambitious WiFi CSI spatial sensing project. It combines low-cost ESP32-S3 hardware, wireless signal processing, edge AI, vital-sign estimation, pose recognition, and camera-free spatial monitoring in one platform.

Its most valuable contribution is making the idea that “WiFi can be a spatial sensor, not just a networking tool” into runnable open source engineering. For researchers, hardware developers, smart-building teams, and privacy-sensitive product prototypes, it is worth studying.

But it is still beta. The README’s feature list should not be treated as stable product capability. Single-node results are limited, hardware matters, real environments add noise, and multi-person or high-precision pose estimation remains hard. Treat RuView as a WiFi sensing experimentation platform, start with simulated data and basic presence detection, and validate its usefulness in your actual space step by step.

References:

Next.js High-Severity SSRF CVE-2026-44578: Impact Scope and Upgrade Guidance

Sun, 17 May 2026 17:27:13 +0800

Next.js disclosed a high-severity SSRF vulnerability in May 2026: CVE-2026-44578.

According to the GitHub / Vercel advisory GHSA-c4j6-fc7j-m34r and the NVD record, the issue affects self-hosted Next.js applications that use the built-in Node.js server and are exposed to malicious WebSocket upgrade requests. An attacker may cause the server to proxy requests to arbitrary internal or external destinations, exposing internal services or cloud metadata endpoints.

Vercel-hosted deployments are not affected. The fixed versions are 15.5.16 and 16.2.5.

Short Version

If you run Next.js on your own servers, containers, Kubernetes, ECS, VPS, bare metal, or a self-managed PaaS, check this first.

Affected ranges:

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

Unaffected or lower-risk cases:

Applications deployed on Vercel.
Applications upgraded to 15.5.16, 16.2.5, or later.
Deployments that do not expose the built-in Node.js server.
Environments where reverse proxies or load balancers already block unnecessary WebSocket upgrades and outbound access is restricted.

Recommended response order:

Confirm the next version actually running in production.
Upgrade self-hosted applications to a patched version as soon as possible.
If you cannot upgrade immediately, block unnecessary WebSocket upgrades at the reverse proxy or load balancer.
Restrict application servers from reaching cloud metadata, internal admin panels, and sensitive internal services.
Review recent WebSocket upgrade requests and internal access logs.

What the Vulnerability Is

CVE-2026-44578 is a Server-Side Request Forgery vulnerability, or SSRF.

The core risk of SSRF is that an attacker does not access internal systems directly. Instead, they make your server send requests on their behalf. Servers often sit closer to private networks, cloud platforms, and internal services, so if a server becomes a proxy, it may reach resources the attacker could not otherwise access.

In this Next.js case, the issue is in the WebSocket upgrade handling path. The advisory says that self-hosted applications using the built-in Node.js server can be made to proxy requests to arbitrary internal or external destinations through crafted WebSocket upgrade requests.

Risk areas include:

Internal HTTP services.
Admin panels.
Cloud metadata endpoints.
Container or cluster-internal services.
Internal APIs that only the server can reach.

The CVSS v3.1 score is 8.6 High, with this vector:

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

That means the attack is network reachable, low complexity, requires no privileges or user interaction, and primarily affects confidentiality.

Why Self-Hosting Is Riskier

The advisory explicitly states that Vercel-hosted deployments are not affected.

The focus is self-hosted deployments. Their network environments vary widely: some expose the origin server directly, some sit behind Nginx, Traefik, Ingress, Cloudflare, ALB, or a custom gateway, and some run in cloud VMs, container networks, or Kubernetes clusters.

If outbound traffic is not restricted, the Next.js process may be able to reach:

Cloud metadata addresses such as 169.254.169.254.
Private IP ranges.
Services exposed only inside a VPC.
Internal Redis, Elasticsearch, Prometheus, Grafana, and similar components.
Kubernetes Services, Pods, or management endpoints.

So the danger is not only in Next.js itself. It depends on what the Next.js server can access from its network position.

How to Check Exposure

First, check the next version.

Run this in the project directory:

`1`	`npm ls next`

Or:

`1`	`pnpm why next`

You can also inspect:

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

If the version falls in these ranges, you need to act:

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

Second, check the deployment model.

Pay close attention to:

Production services started with next start.
Custom Node.js servers hosting Next.js.
Docker images that start a Next.js server directly.
Kubernetes / ECS / VPS / bare-metal self-hosting.
A Next.js origin still reachable behind a reverse proxy.
Application networks that can reach internal services or cloud metadata.

If the application is deployed on Vercel, the official advisory says it is not affected by this vulnerability. Still, keep Next.js updated, because adjacent releases may contain other security fixes.

What Version to Upgrade To

The official patched versions are:

15.5.16
16.2.5

Upgrade example:

`1`	`npm install next@15.5.16`

Or, if you are on 16.x:

`1`	`npm install next@16.2.5`

pnpm:

`1`	`pnpm add next@15.5.16`

Or:

`1`	`pnpm add next@16.2.5`

Then rebuild and redeploy:

1
2

npm run build
npm run start

Or follow your CI/CD process to rebuild and publish the Docker image.

If your project is pinned to 14.x or 15.x, do not rush into a major upgrade to 16.x just for this fix. A safer path is to upgrade to the 15.5.16 patch line first, test and release, then plan a major-version migration separately.

Temporary Mitigations

If you cannot upgrade immediately, the advisory’s core guidance is: do not expose the origin server directly to untrusted networks; block WebSocket upgrades at the reverse proxy or load balancer if they are not required; and restrict outbound access from the origin where possible.

Consider these mitigations:

Do not expose the Next.js origin server directly.
Filter unnecessary WebSocket upgrades at Nginx, Ingress, ALB, Cloudflare, or similar entry points.
If the business does not use WebSockets, reject requests with upgrade semantics.
Apply egress restrictions to block access to cloud metadata and sensitive internal ranges.
Use safer cloud metadata modes where available, such as token-required metadata services.
Add authentication and network isolation around admin panels, databases, caches, and monitoring systems.

Reverse proxy rules are temporary mitigations, not a replacement for upgrading. Framework vulnerabilities should ultimately be fixed by moving to patched versions.

Operational Review

Because this issue mainly affects confidentiality, the key question is whether the server was used to reach internal resources.

Review:

Web logs for abnormal Upgrade, Connection, Host, paths, and source IPs.
Reverse proxy or load balancer logs for unusual WebSocket upgrade requests.
Abnormal outbound connections near the Next.js service.
Cloud metadata access logs or credential usage records.
Unusual access to internal admin services, monitoring, caches, or search systems.
Abnormal IAM temporary credential, access key, or token usage.
Suspicious processes, downloads, or lateral movement on containers or hosts.

If exploitation is suspected:

Preserve logs and evidence.
Rotate potentially exposed cloud credentials, API keys, database passwords, and session secrets.
Review recent cloud account API calls.
Check internal service access records.
Rebuild affected containers or hosts.
Revisit egress controls and metadata protection.

Not the Same as the React/Next.js RCE

One common source of confusion: CVE-2026-44578 is a Next.js WebSocket upgrade SSRF, not the earlier React Server Components RCE.

Its core impact is making the server request attacker-chosen internal or external addresses. The main risk is information exposure and internal resource probing.

React Server Components RCE issues are code execution risks, with different consequences and patch ranges.

So do not stop at the headline “Next.js has a vulnerability.” Map the exact CVE to the affected versions, deployment model, and fixed versions.

Teams That Should Prioritize This

Highest priority:

Self-hosted Next.js production sites.
Deployments on cloud VMs, containers, Kubernetes, or internal networks.
Application servers that can access cloud metadata services.
Application servers that can reach internal admin panels, databases, caches, or monitoring systems.
Directly exposed next start origin servers.
Older next versions with unclear upgrade ownership.

Lower priority:

Applications fully deployed on Vercel.
Applications already upgraded to patched versions.
Origins not directly exposed, with entry layers blocking unnecessary WebSocket upgrades.
Strict outbound network control preventing access to sensitive internal resources.

Lower priority does not mean “do not upgrade.” Next.js is a high-exposure framework, and long-stale framework versions accumulate risk quickly.

Developer Checklist

Use this checklist:

Confirm the next version in every repository.
Identify all self-hosted deployments, not only Vercel projects.
Mark services using next start or the built-in Node.js server.
Upgrade to 15.5.16, 16.2.5, or later.
Rebuild and publish production images.
Block unnecessary WebSocket upgrades at the entry layer.
Restrict application server access to cloud metadata and sensitive internal ranges.
Review recent abnormal upgrade requests and outbound access.
Rotate credentials that may have been exposed.
Add Next.js security updates to the dependency update process.

Summary

CVE-2026-44578 is a high-severity Next.js SSRF vulnerability that deserves prompt attention.

It does not affect Vercel-hosted deployments, but it covers a broad range of self-hosted Next.js applications: from 13.4.13 up to before 15.5.16, and from 16.0.0 up to before 16.2.5. The trigger is the WebSocket upgrade handling path. An attacker may cause the server to proxy requests to internal or external addresses, potentially exposing internal services or cloud metadata endpoints.

The direct fix is to upgrade to 15.5.16 or 16.2.5. Temporary mitigations are to avoid exposing the origin server directly, block unnecessary WebSocket upgrades, and restrict outbound access from the application server.

For operations teams, the important point is not only the CVE score. It is what your Next.js server can reach from its network position. With SSRF, the real impact often depends on internal resources and cloud permissions behind the server.

References:

ai-goofish-monitor: An Open-Source AI Monitoring System for Goofish Listings

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor is an open-source Goofish product monitoring system from Usagi-org.

Its goal is clear: automate Goofish search, filtering, product analysis, result logging, and notifications, so users can find matching second-hand listings faster. The project uses Playwright for browser automation and connects to image-capable AI models to judge product information more intelligently.

Project link: https://github.com/Usagi-org/ai-goofish-monitor

The Short Version

ai-goofish-monitor is closer to a “Goofish purchasing intelligence dashboard” than a simple keyword alert script.

It has several notable traits:

A complete web admin UI for managing tasks, accounts, AI criteria, logs, and results.
Concurrent multi-task monitoring, where each task can define keywords, price range, filters, and AI Prompt.
Playwright-based page automation, useful for scenarios that require login state and page interaction.
AI-based product judgment, not just keyword matching.
Notifications through ntfy.sh, WeCom, Bark, Telegram, Webhook, and other channels.
Cron scheduling, multi-account management, proxy rotation, retry handling, and Docker deployment.

It fits users who often search Goofish for specific items, such as second-hand electronics, cameras, GPUs, hard drives, game consoles, musical instruments, appliances, and collectibles. But it is not an “automatic bargain hunter.” Goofish search results change, login states may expire, and platform risk controls can affect automation stability. Treat it as an assisted filtering tool, not a replacement for human judgment.

What Problem It Solves

Finding second-hand products on Goofish often has several pain points:

There are too many listings to browse manually.
Titles and descriptions are inconsistent, so keywords can miss or misclassify listings.
Good prices appear briefly and may be gone by the time you see them.
The same product may differ by region, price, condition, and seller.
Low-priced listings can include accessories, damaged goods, refurbished items, or misleading titles.
Watching multiple keywords continuously is hard to sustain manually.

Basic keyword alerts solve only part of this. Searching for “ThinkPad X1” may mix in accessories, broken screens, empty boxes, or disassembled parts. Searching for “Sony A7C” may return lens bundles, rentals, clickbait titles, or abnormal prices.

ai-goofish-monitor’s idea is to use automation to collect candidate listings, then let AI apply your criteria, and finally push the results worth attention.

Core Features

The project README lists a fairly complete feature set:

Visual web management: task management, account management, AI criteria editing, run logs, and result browsing.
AI-driven workflow: create tasks with natural language and analyze products with multimodal models.
Concurrent tasks: each task can define keywords, prices, filters, and AI Prompt independently.
Advanced filters: free shipping, newly listed time range, and province / city / district filtering.
Instant notifications: ntfy.sh, WeCom, Bark, Telegram, Webhook, and more.
Scheduled execution: Cron-based periodic tasks.
Account and proxy rotation: multi-account management, task-account binding, proxy pool rotation, and retry handling.
Docker deployment: containerized deployment support.

Together, these cover the full chain from creating a monitoring task to receiving a matching alert.

Workflow

A typical workflow looks like this:

Deploy the service and open the Web UI.
Import Goofish account login state.
Create a monitoring task.
Set keywords, price range, region, newly listed window, and other filters.
Write criteria or let AI generate them.
Run the task in real-time or on a schedule.
Playwright opens pages and extracts product information.
AI checks title, description, images, and Prompt against your needs.
Matching results are written to SQLite.
The system sends notifications through configured channels.
You review results, logs, and price history in the Web UI.

AI matters most at step 8. It can understand natural language criteria like “good condition, reasonable price, no accessories, no repaired units, preferably local pickup,” which is more flexible than simple keyword rules.

Docker Deployment

The project recommends Docker deployment:

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

The default Web UI address is:

`1`	`http://127.0.0.1:8000`

The official image is:

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

If the image pulls slowly, the README also gives an accelerated mirror example:

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

The Docker image includes Chromium, so the host does not need an extra browser. Default persistent directories include:

data/: main SQLite storage for tasks, results, and price history.
state/: login-state cookie files.
prompts/: task prompts.
logs/: runtime logs.
images/: product images and temporary task image folders.

If you change SERVER_PORT in .env, also update the port mapping in docker-compose.yaml.

Minimum Configuration

The minimum configuration mainly covers the AI model and Web UI login:

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

The first three are required for AI model access:

OPENAI_API_KEY: model API key.
OPENAI_BASE_URL: OpenAI-compatible endpoint.
OPENAI_MODEL_NAME: model name that supports image input.

WEB_USERNAME and WEB_PASSWORD are used for Web UI login. The README mentions the default credentials admin/admin123; change them in production.

First Use

The first-use flow is roughly:

Open http://127.0.0.1:8000.
Log in to the Web UI.
Go to Goofish account management.
Use the provided Chrome extension to export Goofish login-state JSON.
Paste the login state into the system.
The state file is saved to state/, for example state/acc_1.json.
Return to task management, create a task, and bind an account.
Run the task and check results.

The key part is login state. Goofish does not provide a standard open API for arbitrary third-party scraping, so the project uses browser login state to simulate normal page access. Expired login state, risk controls, captchas, and account anomalies can all affect task execution.

AI Tasks and Keyword Tasks

The project supports two task creation modes.

The first is AI判断.

You can enter detailed requirements, and the system asynchronously generates analysis criteria. This fits complex needs, for example:

Only the main unit, no accessories.
Alert only when the price is clearly below market.
Good condition, with no water damage, repair, or hidden defects in the description.
Prefer local listings and face-to-face pickup.
Images should show serial number, packaging, or key accessories.

The second is 关键词判断.

This is closer to traditional rule-based monitoring: create tasks directly from keywords, prices, regions, and other conditions without AI generation. It fits simple rules where some false positives are acceptable.

In practice, you can mix both: keywords handle initial filtering, AI reduces false positives.

What the Web UI Does

The Web UI is a major difference between this project and ordinary scripts.

The task management page can configure:

AI-created tasks.
Keyword rules.
Price ranges.
Newly listed windows.
Region filters.
Account binding.
Scheduling rules.

The account management page can:

Import Goofish account login state.
Update login state.
Delete accounts.
Assign accounts to tasks.
Let the system choose accounts automatically.

Results and logs pages can:

View matching products.
Export results.
Search history.
Inspect task execution.
Troubleshoot login expiration, risk controls, and AI call issues.

The system settings page can:

View system status.
Edit Prompt.
Adjust proxy and rotation configuration.

For long-term monitoring, the Web UI is important. Without it, many tasks quickly make configuration, logs, results, and notifications hard to maintain.

Data Storage

The current online primary storage is SQLite, with the default path:

`1`	`data/app.sqlite3`

Docker mounts the SQLite main database by default:

`1`	`./data:/app/data`

On startup, the app creates tables automatically and tries to import historical data once from old config.json, jsonl/, and price_history/.

Note that state/, prompts/, logs/, and images/ remain filesystem directories and are not stored in SQLite. Product images are temporarily saved to directories like:

`1`	`images/task_images_<task_name>/`

They are cleaned up by default after the task ends.

This structure fits personal or small-team deployments: SQLite is lightweight and easy to migrate, while files keep login state, images, and logs easy to inspect.

Notification Channels

The project supports multiple notification channels. Common configuration items include:

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

Notifications are central to the experience. If a monitor only writes results to a backend, users still need to keep checking the page. With push notifications, matching listings reach the user immediately.

A practical setup is to tier notifications by item value:

Normal keyword hits are written only to the backend.
High-confidence AI results are pushed to the phone.
High-value items are pushed to WeCom or Telegram.
Enable more logs during debugging, then reduce noise after stabilization.

Developer Run

Without Docker, local development requires:

Python 3.10+
Node.js + npm
Playwright CLI
Chromium or Chrome / Edge browser

Basic commands:

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

One-command startup:

1
2

chmod +x start.sh
./start.sh

start.sh checks Playwright CLI and browser conditions, installs dependencies, builds the frontend, copies build artifacts, and starts the backend.

Start the backend manually:

`1`	`python -m src.app`

Or:

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

Frontend development:

1
2
3

cd web-ui
npm install
npm run dev

Testing and build:

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

Who It Fits

ai-goofish-monitor fits users who:

Frequently watch Goofish for specific models.
Want to monitor second-hand electronics, cameras, game devices, hardware parts, and similar goods.
Want to automate “keyword search + manual screening.”
Have an OpenAI-compatible model API and accept AI judgment costs.
Are comfortable with Docker or basic command-line deployment.
Need matching results pushed to phone, WeCom, or Telegram.

It is less suitable if you:

Know nothing about deployment and only want a ready-to-use app.
Do not want to handle login state, captchas, or account risk controls.
Need official authorization and strongly compliant data APIs.
Want large-scale high-frequency platform scraping.
Expect AI to automatically judge trading risk and place orders for you.

Risks and Boundaries

Tools like this need clear boundaries.

First, follow platform rules.

Goofish has its own terms, risk controls, and account security mechanisms. Automation may trigger restrictions. Do not scrape at high frequency, bypass risk controls, harass sellers, bulk-collect private information, or disrupt platform order.

Second, protect account login state.

Files in state/ are login-state cookie files. They are effectively account access credentials. Do not commit them to Git, and do not put them on untrusted servers. If the server is exposed to the public internet, change the default Web UI password and place it behind a VPN, reverse-proxy authentication, or an internal network.

Third, AI judgment is not a factual guarantee.

AI can reduce false positives, but it cannot guarantee product authenticity, seller trustworthiness, reasonable pricing, or transaction safety. You still need to review product details, seller reputation, chat history, shipping method, and payment process.

Fourth, watch cost.

If every candidate listing is analyzed by a multimodal model, costs can rise quickly. Use keyword, price, and region filters first, then send a smaller candidate set to AI.

Fifth, protect privacy.

Product screenshots, chat-related content, account state, and notification content may all contain sensitive information. Protect notification Webhooks, log directories, and databases carefully.

Difference from Ordinary Scripts

Ordinary Goofish monitoring scripts usually do three things:

Search keywords.
Check prices.
Send notifications.

ai-goofish-monitor goes further:

Manage tasks and accounts through Web UI.
Express complex buying criteria with AI Prompt.
Use multimodal models to inspect product images and descriptions.
Store results and price history in SQLite.
Use log pages to diagnose task failures.
Improve stability through proxy rotation and multi-account mechanisms.
Support long-running schedules with Cron.

Because it does more, it also costs more to deploy and maintain. For normal users, Docker is the easiest path. For developers, the Web UI, FastAPI, Playwright, and SQLite structure is also friendly for secondary development.

How to Use It

A practical approach is to start with small tasks.

For example, if you want a second-hand camera, create a task like this:

Keywords: A7C, 索尼 A7C
Price range: set an upper limit based on market price
Region: prefer same province or local city
Newly listed window: last day or last few hours
AI criteria: exclude lens-only listings, repaired units, obvious accessories; pay attention to shutter count and condition
Notification: push only results that pass AI judgment

After it runs stably, gradually add more tasks. Do not start with dozens of keywords, multiple accounts, and high-frequency Cron. First check login stability, false-positive rate, AI cost, and notification noise, then tune parameters.

Summary

ai-goofish-monitor moves Goofish monitoring from a “keyword script” to a manageable AI monitoring system. It uses Playwright for page automation, AI for complex judgment, Web UI for tasks and results, SQLite for storage, and multiple notification channels for delivery.

It is best for individuals or small teams monitoring specific products, especially second-hand electronics, hardware, and cameras where prices fluctuate, timing matters, and descriptions are noisy.

But it must be used carefully: protect login state, change default passwords, keep scraping frequency restrained, review AI results manually, and respect platform rules and privacy boundaries. As an assisted filtering tool, it can be valuable. As a fully automated trading system, it is easy to overestimate.

References:

OpenKB: Compiling Documents into a Continuously Updated LLM Knowledge Base

Sun, 17 May 2026 17:15:08 +0800

OpenKB is an open-source LLM knowledge base tool from VectifyAI.

It is not a traditional RAG system that chunks documents, vectorizes them, and then stitches context back together at query time. Instead, it first compiles raw documents into a structured wiki: document summaries, concept pages, cross-references, follow-up queries, and lint checks. In other words, it feels more like a knowledge-base CLI that keeps organizing your material over time.

Project link: https://github.com/VectifyAI/OpenKB

The Short Version

OpenKB is worth watching for three reasons:

It outputs the knowledge base as ordinary Markdown files instead of locking it inside a dedicated database.
It uses PageIndex for long PDFs, focusing on vector-database-free retrieval for long documents.
It emphasizes “knowledge compilation”: the LLM generates summaries, concept pages, and cross-links instead of retrieving from scratch on every question.

That makes OpenKB better suited to long-term knowledge accumulation: paper reading, project documentation, internal company materials, technical standards, product research, and personal knowledge bases.

It is not a universal replacement. If you need high-concurrency online Q&A, complex permissions, a web admin console, enterprise audit trails, or large-scale multi-tenancy, OpenKB currently looks more like a developer tool and knowledge-base prototype than a complete enterprise knowledge platform.

What OpenKB Is

OpenKB stands for Open Knowledge Base.

It works as a CLI: it converts, organizes, summarizes, and writes documents into a set of wiki files. The official README describes it directly: OpenKB uses LLMs to compile raw documents into a structured, interlinked wiki-style knowledge base, with PageIndex providing vectorless long-document retrieval.

Supported input formats include:

PDF
Word
Markdown
PowerPoint
HTML
Excel
Plain text
Other formats that markitdown can convert

The generated knowledge base lives under wiki/ and mainly includes:

index.md: knowledge base overview
log.md: operation timeline
AGENTS.md: knowledge base structure and maintenance instructions
sources/: converted source text
summaries/: summaries for each document
concepts/: cross-document concept pages
explorations/: saved query results
reports/: lint reports

The biggest benefit of this design is transparency. You can open the Markdown files directly instead of only receiving answers through a black-box retrieval interface.

How It Differs from Traditional RAG

A typical traditional RAG pipeline looks like this:

Chunk the documents.
Generate embeddings.
Store them in a vector database.
Retrieve relevant chunks at query time.
Feed those chunks to the LLM to generate an answer.

That workflow is mature and works well for Q&A systems. But it has one problem: the knowledge itself does not really accumulate. Every question repeats the work of finding chunks, assembling context, and generating an answer.

OpenKB is closer to “organize first, ask later”:

Documents enter raw/.
Short documents are converted to Markdown with markitdown.
Long PDFs go through PageIndex to produce tree indexes and summaries.
The LLM generates document summaries.
The LLM reads existing concept pages and creates or updates cross-document concepts.
The knowledge base index, log, and cross-links are updated.

As a result, adding one document does more than create another searchable file. It may update a dozen wiki pages. Knowledge is written into concept pages and connected to existing material.

This is closer to how humans maintain knowledge bases: when new material arrives, you do not just archive it; you update topic pages, summarize differences, and add references.

What PageIndex Solves

Long documents have always been difficult for RAG and LLM knowledge bases.

If you simply split a long PDF into many chunks, several problems appear:

Chapter relationships are lost.
Tables, images, and footnotes are hard to handle.
Retrieved snippets are too fragmented, so answers lack global structure.
Even a large context window is not ideal for stuffing an entire document into the prompt.
Long summary chains can compress away important details.

OpenKB uses PageIndex for long PDFs. According to the project description, PageIndex builds tree indexes and summaries for long documents, letting the LLM reason over the document tree instead of reading the whole document directly.

The focus is not “the few text snippets with the highest vector similarity.” It is about helping the model use document hierarchy to find relevant content. For research reports, papers, manuals, prospectuses, and compliance documents, this direction makes a lot of sense.

OpenKB can use the open-source PageIndex locally by default. If you need OCR, complex PDF handling, or faster structure generation, you can configure PAGEINDEX_API_KEY to use PageIndex Cloud.

Install and Quick Start

Install OpenKB with pip:

`1`	`pip install openkb`

Or install the latest GitHub version:

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

For editable source installation:

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

Create a knowledge base directory:

1
2

mkdir my-kb && cd my-kb
openkb init

Add documents:

1
2

openkb add paper.pdf
openkb add ~/papers/

Ask a question:

`1`	`openkb query "What are the main findings?"`

Start an interactive chat:

`1`	`openkb chat`

If you want OpenKB to process new files automatically, use watch mode:

`1`	`openkb watch`

After that, drop files into raw/, and OpenKB will update the wiki automatically.

LLM Configuration

OpenKB uses LiteLLM to support multiple model providers, including OpenAI, Claude, and Gemini.

You can set the model during initialization, or configure it in .openkb/config.yaml:

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

Model names follow LiteLLM’s provider/model format. OpenAI models can omit the provider prefix:

`1`	`model: gpt-5.4`

Models such as Anthropic and Gemini are usually written like this:

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

Put the API key in .env:

`1`	`LLM_API_KEY=your_llm_api_key`

If you enable PageIndex Cloud, add:

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

Common Commands

OpenKB’s commands are developer-friendly:

openkb init: initialize a knowledge base.
openkb add <file_or_dir>: add a file or directory.
openkb remove <doc>: remove a document and clean up related wiki pages, images, registry entries, and PageIndex state.
openkb query "question": ask a one-off question against the knowledge base.
openkb chat: enter a multi-turn conversation.
openkb watch: monitor raw/ and update automatically.
openkb lint: check knowledge base structure and content health.
openkb list: list indexed documents and concepts.
openkb status: show knowledge base statistics.

openkb chat is better than openkb query for continuous exploration. It supports session resume, session listing, deletion, and slash commands such as /status, /list, /add <path>, /save, and /lint.

Why a Markdown Wiki Matters

Many knowledge-base tools are painful because of migration cost.

Once material enters a proprietary database, index, or format, it becomes hard to inspect, edit, back up, or migrate directly. OpenKB writes the result as ordinary Markdown, which makes it naturally compatible with existing tools.

The most direct use is opening wiki/ in Obsidian:

Summary pages can be read directly.
Concept pages can connect through [[wikilinks]].
Graph view can show relationships between knowledge items.
Query results can be saved to explorations/.
AGENTS.md can define how the knowledge base should be maintained.

That makes OpenKB more than a Q&A tool. It can become a knowledge-organizing pipeline for individuals or teams.

Best-Fit Scenarios

OpenKB is especially useful for:

Reading papers and technical reports.
Organizing project documentation.
Building product research archives.
Creating documentation knowledge bases around open-source projects.
Organizing internal policies, meeting notes, and explanatory documents.
Maintaining a personal Obsidian knowledge base automatically.
Structuring long PDFs, PPTs, Word files, and web materials.

If you often face piles of documents and want more than “ask one question, get one answer,” OpenKB’s direction is a good fit: it gradually turns material into a browsable, reusable, and traceable knowledge base.

What to Watch Out For

First, OpenKB depends on LLM quality.

Summaries, concept pages, and cross-links are generated by models. Stronger models usually produce more stable knowledge compilation; weaker models may struggle with concept extraction, contradiction detection, and cross-document synthesis.

Second, estimate cost early.

If you import many long documents at once, LLM calls may become expensive. Start with a small dataset, check the output structure and quality, and then expand.

Third, the generated wiki still needs human review.

OpenKB can organize material, but it does not automatically guarantee factual correctness. Important knowledge bases still need humans to review summaries, concept pages, and references.

Fourth, be careful with sensitive material.

If you use cloud LLMs or PageIndex Cloud, pay attention to privacy, trade secrets, and compliance requirements. For internal materials, confirm the model provider, data retention policy, and access boundaries first.

Fifth, it is currently more of a CLI tool.

The roadmap mentions a future Web UI, database-backed storage, support for large collections, and hierarchical concept indexing. At this stage, if teammates are not comfortable with the command line, there is still some adoption friction.

Relationship with Obsidian, NotebookLM, and Enterprise RAG

OpenKB and Obsidian are best understood as an “automatic organization layer” plus a “reading and editing layer.”

Obsidian is good for humans to write, edit, browse, and link notes. OpenKB is good for turning raw documents into a wiki that can enter Obsidian.

OpenKB and NotebookLM differ more around local control and open file formats.

NotebookLM is more direct for quickly asking questions and generating summaries after dropping in materials. OpenKB is better for developers who want the organized result to remain in a local directory and continue evolving as Markdown.

OpenKB does not replace enterprise RAG; it complements it.

Enterprise RAG cares more about permissions, auditability, service deployment, access isolation, monitoring, and stable throughput. OpenKB is better for building a readable, editable, long-lived knowledge layer. If you later build online Q&A, the wiki generated by OpenKB can also become a higher-quality corpus.

A Recommended Workflow

If you want to try OpenKB, start like this:

Create a test knowledge base directory.
Add 3 to 5 documents on the same topic.
Run openkb add.
Open wiki/ and inspect the summaries and concept pages.
Ask a few specific questions with openkb query.
Run openkb lint to check knowledge-base health.
Open wiki/ in Obsidian and see whether the link graph is meaningful.
Once quality looks good, import a larger document collection.

Do not throw in hundreds of files at the beginning. First see whether it understands your material type well, especially tables, images, long PDFs, and multi-document concept merging.

Summary

OpenKB’s value is that it moves an LLM knowledge base one step earlier than “assemble context at query time”: organize the material into a wiki first, then ask questions, chat, lint, and keep maintaining that wiki.

This direction is not right for every Q&A system, but it is well suited to knowledge work that needs long-term accumulation. Markdown files, Obsidian compatibility, PageIndex long-document handling, multi-model support, and a CLI workflow combine into a useful tool for developers and research-oriented users.

If you have many PDFs, reports, web pages, papers, and project documents, OpenKB is worth trying. It may not immediately replace a mature enterprise knowledge base, but it can become a practical entry point for organizing material: first turn documents into readable, linked, traceable knowledge, then let the LLM work on top of that knowledge.

References:

Godot Game Development Beginner Guide: From Nodes and Scenes to Your First 2D Game

Sun, 17 May 2026 12:37:30 +0800

Godot is an open-source game engine suitable for 2D games, independent prototypes, and medium-scale 3D projects.

Its biggest strengths are that it is lightweight, open source, fast to start, and built around a clear node-and-scene model. For beginners, Godot is usually easier to approach than Unity. For independent developers, it is also easier to keep projects small and controllable.

This guide keeps the path simple: understand nodes and scenes, learn basic GDScript, then build a small 2D game that connects input, physics, collision, UI, audio, and export.

Bottom line

Do not start by learning every engine feature.

A better path is:

Start with 2D, not 3D.
Understand nodes and scenes before complex architecture.
Learn GDScript first, not C#.
Build one small game that can start, fail, and restart.
Then add animation, audio, UI, levels, and export.

Completing one tiny game teaches more than watching many unrelated tutorials.

Who Godot is good for

Godot is a strong fit if you:

want to learn game development from zero,
want to build 2D indie games,
need fast gameplay prototypes,
do not want a heavy commercial engine workflow,
want to understand how engines organize game objects,
have some Python or JavaScript experience and want an easy scripting language.

Unity and Unreal still have advantages for large commercial pipelines, asset stores, mobile monetization SDKs, or high-end 3D visuals. But for learning and making your own games, Godot is an excellent starting point.

Installation and project creation

Godot is simple to install: download it from the official website, unzip it, and run it.

For the first project:

Use the default renderer.
Use an English project name.
Avoid paths with too many spaces or non-ASCII characters.
Use Git from the beginning.

A simple project name:

`1`	`first-godot-game`

Learn the editor areas first: Scene tree, FileSystem, Inspector, Script editor, and 2D / 3D viewport.

Core idea: nodes and scenes

The two most important Godot concepts are nodes and scenes.

Nodes are functional units:

Node2D: base 2D object.
Sprite2D: displays an image.
CollisionShape2D: collision shape.
CharacterBody2D: controllable character.
Camera2D: 2D camera.
AudioStreamPlayer: audio playback.
Label: text display.

A scene is a reusable group of nodes. A player can be a scene, an enemy can be a scene, and a level can be a scene.

For example:

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

The player handles movement, Sprite2D displays the image, CollisionShape2D handles collision, and Camera2D follows the player.

What to build first

Do not start with an RPG, open world, networking, or complex platformer.

Build a tiny 2D dodging game:

The player moves up, down, left, and right.
Enemies spawn from screen edges.
Touching an enemy means failure.
Survival time becomes score.
There is a start button, game-over screen, and restart.

This small project covers movement, input, collision, spawning, UI, timers, audio, and scene reloads.

Player movement

Use CharacterBody2D for a controllable player.

Attach a script to Player:

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

Then define input actions:

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Use input actions instead of hard-coded key codes. It makes keyboard, gamepad, touch, and remapping easier later.

Collision and physics

Common 2D nodes:

CollisionShape2D: defines collision shape.
Area2D: detects overlap and triggers.
CharacterBody2D: player or controlled character.
RigidBody2D: physics-driven object.
StaticBody2D: walls, floors, fixed obstacles.

For beginners: if you control movement manually, use CharacterBody2D. If you only need to detect contact, use Area2D.

Example:

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

Later, replace direct reloads with a game_over signal. For the first project, getting the loop working is more important.

Instancing enemies

Godot scenes can be used like prefabs.

If you have Enemy.tscn, spawn it from the main scene:

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

Add a Timer to call spawn_enemy() repeatedly.

UI and score

Use Control nodes for UI:

CanvasLayer: keeps UI fixed on screen.
Label: text.
Button: button.
Panel: background.
VBoxContainer / HBoxContainer: layout.

Simple survival score:

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

Audio and feedback

Even simple games need feedback:

click sounds,
hit sounds,
score sounds,
failure sounds,
screen shake or flash,
button hover / pressed states.

Use AudioStreamPlayer:

`1`	`$HitSound.play()`

Functionality is only the first step. Good feedback makes the player feel the game responding.

Project organization

Start with clean folders:

res://
├── scenes/
│   ├── Main.tscn
│   ├── Player.tscn
│   └── Enemy.tscn
├── scripts/
│   ├── player.gd
│   └── enemy.gd
├── assets/
│   ├── sprites/
│   └── audio/
└── ui/
    └── GameOver.tscn

Do not dump everything into the root directory. Small games grow faster than expected.

Common beginner mistakes

Choosing the wrong node type.
Forgetting collision shapes.
Hard-coding keyboard keys.
Putting player, enemies, UI, audio, and level logic into one script.
Starting with a project that is too large.

A tiny finished game is more valuable than an abandoned big idea.

Suggested learning path

Editor basics.
Nodes and scenes.
GDScript basics.
Input actions.
2D movement.
Collision and Area2D.
Timer and spawning.
UI and score.
Audio and animation.
Export to desktop or web.

Godot vs Unity

Godot is comfortable for 2D indie games, teaching projects, and personal prototypes.

Unity still has stronger asset stores, commercial plugins, mobile ads, monetization SDKs, and mature team workflows.

Unreal is better for high-end 3D and advanced rendering.

For beginners, do not let engine choice become procrastination. The core skills are game loops, input, collision, feedback, scene organization, state management, and version control.

Completion checklist

You have really completed the first step when your game has:

player movement,
enemies or obstacles,
collision failure,
score or objective,
start screen,
game-over screen,
restart,
at least two sounds,
simple animation or visual feedback,
an exported playable build.

Summary

Godot’s entry point is not memorizing every feature. It is understanding how the engine organizes games: nodes form scenes, scenes form games, scripts drive behavior, signals connect events, and resources live in folders.

Start with a small 2D game. Once movement, collision, UI, audio, and restart work, then learn animation trees, TileMap, saving, state machines, 3D, shaders, and export optimization.

From ENEMY's 840 Million Views and 2,000 Yuan Revenue Share: Understanding Douyin Short Drama Monetization

Sun, 17 May 2026 12:35:58 +0800

ENEMY has become a representative case in China’s short drama market.

On one side, its free episodes exploded on Douyin and other platforms. Securities Times reported that eight main episodes plus bonus and preview content reached 840 million views. On the other side, media reports said the platform revenue share from that scale of traffic was only a little over 2,000 yuan. The creators later released a 38-minute 5K remastered paid version at 8.8 yuan, which sold more than 100,000 copies in a short time and created a much clearer revenue stream.

The contrast raises a simple question: why can 840 million views produce so little direct platform revenue?

The answer is that “views” on a short video platform are not automatically “revenue-shareable views.” Free traffic is not the same as cash income.

Bottom line

This case can be summarized in four points:

840 million views represent reach, not necessarily all billable views.
Platform revenue share usually counts only qualified effective views, not every exposure, swipe, or replay.
Douyin short drama monetization includes more than view-based revenue: paid content, brand deals, platform projects, account growth, livestreaming, and IP development all matter.
For premium short dramas, “free episodes for distribution + paid remastered edition for support” may be more realistic than waiting for view revenue.

This does not simply mean that the platform pays nothing. It means free short-video revenue share was never a stable way to recover film-like production costs.

Why 840 million views are not 840 million paid views

Users see public view counts. Platforms settle revenue based on rules.

A video may be auto-played, briefly watched, repeated, clipped, pushed through previews, or counted together with bonus content. But revenue share may also consider:

Whether the work joined the right program.
Whether it was recognized as an exclusive or cooperative project.
Whether it met effective-view thresholds.
Whether it satisfied duration, completion, interaction, originality, copyright, and content-safety requirements.
Whether views occurred within the eligible settlement period.
Whether caps, deductions, or exclusions apply.

Reach metrics and settlement metrics are related, but they are not the same thing.

Public reports have discussed Douyin’s “剧有引力” short drama program. It included tracks for traffic support, revenue share, and brand cooperation.

According to earlier public reports, eligible exclusive short dramas needed to reach average effective-view thresholds per episode. Some reports described rules such as an effective-view threshold of 2 million per episode, 6 yuan per thousand effective views, and a single-title cap of 1.5 million yuan. Exact rules can change and must be checked against current creator backends and project terms.

The key words are:

short drama,
program participation,
average effective views,
per-thousand effective-view pricing,
cap.

So a work with massive public views may still receive little revenue if it does not fit the program or settlement scope.

Short-video revenue and short-drama revenue are different

Ordinary creator income can come from creator incentives, ad sharing, brand deals, e-commerce, livestreaming, memberships, or paid knowledge products. It is tied to account eligibility, content type, effective views, retention, ad value, and conversions.

Short drama revenue share is closer to a content project partnership. It cares about whether the series is part of a platform program, whether it is exclusive, its effective views, project rating, commercial resources, paid conversion, and sponsorship potential.

ENEMY is special because it first became viral through free short-video episodes, then offered a polished paid version. It is not exactly the same as an industrial short drama that entered a platform revenue-share program from the start.

What the 2,000 yuan figure shows

If the reported 2,000-yuan revenue share is accurate, it shows three things.

First, free reach can be huge while the eligible settlement scope is narrow.

Second, short-video platforms are very good at distribution, but they do not automatically guarantee production-cost recovery for film-like content.

Third, premium live-action short drama has a different cost structure from ordinary short videos. Even low-budget productions still carry travel, costume, props, shooting, editing, labor, and opportunity costs.

That is why the paid version created a clearer revenue path: users knew what they were buying, and the creators received payment closer to the perceived content value.

Why the paid version worked

The paid version did not lock away the free episodes. It packaged the eight episodes into a 38-minute 5K remastered film with better quality and extra details.

This worked because:

The original version remained free.
The paid version offered clear incremental value.
Viewers had already built emotional trust with the creators.
8.8 yuan was a low-friction price.
Payment felt partly like support, not only consumption.

This suggests a healthier short drama model: prove the content with free distribution, then offer a paid version for users who want to support it.

How creators should design revenue

Creators should not treat views as the only business model.

A more robust short drama revenue structure combines:

Free episodes for reach and follower growth.
Platform programs for baseline incentives or revenue share.
Brand deals and platform campaigns for commercial upside.
Paid full versions, extras, remasters, or behind-the-scenes content for direct monetization.
Livestreaming, memberships, merchandise, and events for long-tail value.
IP development for longer-term rights value.

Free traffic can light the fire, but creators still need a business loop outside free views.

From the platform’s view, short drama is part of content supply. Platforms may provide traffic, programs, promotion, paid tools, and monetization channels, but they do not automatically buy every viral view at a film-project price.

Reasons include:

Not every view carries ad revenue.
Free content may mainly improve retention and engagement.
Platform budgets usually flow to predictable, rule-compliant, exclusive, or commercializable projects.
A viral project outside the cooperation mechanism may not match high revenue-share rules.

Creators therefore need to decide before launch whether a work is ordinary account content, a short drama project, a platform partnership, or a paid product.

Summary

The contrast between ENEMY’s huge view count and reported low platform revenue reveals a basic reality: views, effective views, platform revenue share, advertising income, and user payment are different systems.

Douyin can provide powerful distribution, but distribution does not automatically equal high recoupment. Sustainable short drama needs a designed path: platform programs, exclusivity, paid versions, brand cooperation, account growth, and IP development.

The lesson is simple: viral content gets attention; paid products validate value. Free traffic can ignite the market, but creators need their own commercial loop to survive.

References:

How to Choose Between FreeRTOS, RT-Thread, and Zephyr: Architecture Differences and Use Cases

Sun, 17 May 2026 12:32:06 +0800

FreeRTOS, RT-Thread, and Zephyr are often compared as if they were the same kind of RTOS. They are not.

The better question is not “which RTOS is better”, but what your project actually needs: a small scheduling kernel, an RTOS with strong domestic MCU support, or a complete cross-platform embedded operating system.

At a high level:

FreeRTOS is a widely used scheduling kernel, plus a set of AWS-maintained IoT libraries.
RT-Thread is a kernel plus a richer component ecosystem, with strong Chinese documentation and long-tail domestic MCU support.
Zephyr is a Linux Foundation hosted RTOS that emphasizes unified subsystems, device models, Devicetree, and cross-vendor application reuse.

Bottom line

If your project only needs tasks, queues, semaphores, timers, and a very small footprint, FreeRTOS remains one of the safest choices.

If you mainly use Chinese MCU vendors and want ready BSPs, Chinese community support, ENV tooling, and a larger RTOS component set, RT-Thread has real advantages.

If you need to reuse application code across chips, boards, and vendors, and your team can accept the learning curve of Kconfig, Devicetree, west, and Zephyr’s driver model, Zephyr is the more future-facing engineering path.

This is not a simple “which one replaces which” question. They sit at different abstraction levels.

FreeRTOS: small, familiar, deterministic

FreeRTOS is strongest when you need something small and predictable.

The FreeRTOS-Kernel repository focuses on the kernel, ports, and core RTOS mechanisms: scheduling, semaphores, queues, event groups, software timers, and memory allocation. In many real projects, this is exactly what teams use.

Its advantages are straightforward:

Huge MCU coverage.
The most examples and learning material.
Easy integration into vendor SDKs.
Good fit for resource-constrained systems.
Short debugging paths because many teams already know it.

After AWS acquired FreeRTOS, it also maintained libraries such as coreMQTT, coreHTTP, OTA, Device Shadow, Jobs, and Defender. The FreeRTOS 202406 LTS release brings kernel and IoT libraries into a long-term support line.

The boundary is equally clear: FreeRTOS is not a complete OS platform. It does not define a unified cross-vendor model for GPIO, UART, I2C, boards, pin control, or HAL abstraction. Those parts come from vendor SDKs or your own architecture.

That is a design choice, not a flaw. It makes FreeRTOS flexible and easy to embed, but when you change vendors or boards, application code often gets pulled into the hardware migration.

RT-Thread: stronger domestic MCU coverage and components

RT-Thread is closer to a complete RTOS than FreeRTOS.

Besides the scheduler, it provides file systems, networking, device framework, USB, sensor framework, packages, and tooling. For many Chinese embedded teams, its Chinese documentation, ENV workflow, community, and BSP coverage are practical advantages.

It is especially useful for long-tail domestic MCUs such as AT32, HC32, N32, APM32, HT32, Luat, HPMicro, and similar families. Many projects do not use only the biggest international vendors, and RT-Thread often gives these projects a faster starting point.

RT-Thread fits when:

You use many domestic MCUs.
Chinese docs and community matter.
You need more components than a bare FreeRTOS setup.
You want file system, networking, shell, and device framework quickly.
You do not want to build all board and driver abstractions yourself.

Its limitation is that many BSPs still remain board-specific and vendor-library-oriented. From the perspective of cross-vendor hardware description and application reuse, it does not have the same systematic model as Zephyr.

RT-Thread is therefore best understood as a practical RTOS ecosystem above a kernel, especially strong in the Chinese MCU world, but not the same kind of full engineering platform as Zephyr.

Zephyr: an embedded system engineering platform

Zephyr is often described as a more complex RTOS. That is partly true, but the complexity is not random feature bloat.

Zephyr tries to bring into one OS project many things that are usually scattered across vendor SDKs, BSPs, HAL code, custom drivers, configuration scripts, and application code.

Its key pieces are:

Kconfig for feature and build configuration.
Devicetree for board-level hardware description.
Unified drivers for GPIO, UART, SPI, I2C, ADC, DMA, clock, reset, pinctrl, and more.
Subsystems for networking, Bluetooth, USB, file systems, input, power management, logging, and settings.
west and CMake for project, module, build, flashing, and debugging workflows.
Board / SoC / shield abstractions to keep hardware differences in configuration layers.

Zephyr feels like an MCU-sized cousin of embedded Linux: it borrows many Linux engineering ideas, but moves expensive runtime probing into build-time generation.

Why Devicetree matters

Devicetree is central to Zephyr.

In Linux, DTS is compiled into DTB, passed to the kernel, and parsed at runtime for driver matching and probing. That is reasonable for MPU-class systems, but too heavy for many MCUs.

Zephyr processes DTS and overlays during the build, generates headers such as devicetree_generated.h, and exposes hardware information through DT_ macros. Most hardware selection is settled at compile time, so runtime discovery stays light.

This gives Zephyr several benefits:

Hardware description is separated from application code.
Board changes mainly touch DTS / overlay files.
Drivers expose unified APIs.
Unused drivers and subsystems can be trimmed.
Application code does not need to know every register, pin, or vendor HAL detail.

For example, an LED or button in a traditional FreeRTOS + vendor HAL project may involve CubeMX configuration, GPIO init, interrupts, debounce logic, callbacks, and application code. In Zephyr, much of that can live in DTS and standardized subsystems, while application code handles events.

Why application code becomes cleaner

Traditional MCU projects often mix hardware init, pin numbers, interrupts, debounce, timers, state machines, UART redirection, event queues, and business logic in the same layer.

That is fast at the beginning, but it becomes painful when there are more peripherals, boards, and product variants.

Zephyr tries to separate them:

Hardware wiring goes into DTS / overlays.
Feature switches go into Kconfig / prj.conf.
Drivers live in Zephyr mainline or modules.
Applications handle business events.

For multi-board and multi-chip projects, the ideal is to change DTS instead of changing main.c.

Resource cost needs context

Zephyr may use more Flash than a minimal FreeRTOS project because it brings drivers, subsystems, and device objects. But that is infrastructure, not just overhead.

Once you add buttons, encoders, input devices, logging, or multiple drivers, that infrastructure is reused. FreeRTOS projects often start smaller, but every new peripheral may add custom state machines and glue code.

RAM also depends on configuration. FreeRTOS reports may include reserved heap and stacks; Zephyr often relies more on static objects and link-time trimming. The only fair comparison is with the same feature set and realistic configuration.

How to choose

Choose FreeRTOS when the hardware is fixed, resources are tight, the team knows the kernel well, and you only need scheduling primitives.

Choose RT-Thread when you need stronger domestic MCU support, Chinese documentation, ready BSPs, and a richer component ecosystem without taking on the full Zephyr learning curve.

Choose Zephyr when you need cross-board reuse, long-term maintainability, unified drivers, standardized subsystems, and a path closer to Linux-style embedded engineering.

When not to use Zephyr

Zephyr is not a silver bullet.

Avoid jumping into Zephyr when:

The project has one fixed board and simple features.
The team has no time to learn Kconfig and Devicetree.
The target chip or board has weak upstream support.
The product depends heavily on a vendor’s closed SDK.
The project is already stable in production.
The team is not ready for Zephyr’s build and debugging workflow.

A safer path is to start with a well-supported board, run LED, UART, GPIO, input, and I2C / SPI examples, then decide whether to migrate real projects.

Why reading good code matters in the AI era

AI can generate candidate code, but engineers still merge it, flash it, and ship it to customer devices.

The scarce ability is not typing more code, but judgment: why this abstraction exists, whether a driver interface is maintainable, whether a generated patch is production-safe, and whether a configuration change affects other boards.

Zephyr is valuable even if you do not use it immediately. Reading its subsystems, Devicetree bindings, Kconfig layout, and driver organization gives you an industrial embedded architecture reference.

Summary

FreeRTOS, RT-Thread, and Zephyr are not three interchangeable products.

FreeRTOS solves scheduling. RT-Thread adds a richer component ecosystem and strong domestic MCU support. Zephyr tries to reorganize MCU software engineering around unified subsystems, Devicetree, and application portability.

For a small fixed device, FreeRTOS may be the best answer. For domestic MCU product lines, RT-Thread is practical. For multi-platform, multi-board, long-lived products, Zephyr deserves serious investment.

References:

Google Gemini Spark Leak: A 24/7 Gemini Agent May Be Coming

Sun, 17 May 2026 11:58:08 +0800

Google has not officially released Gemini Spark.

Current information about it mainly comes from internal Gemini Web test screens, community screenshots, TestingCatalog reporting, and 36Kr / Xinzhiyuan’s summary of related leaks. The consistent picture is that Gemini Spark BETA may be an always-on AI Agent that Google is preparing. Its positioning is no longer just a chat assistant, but an “everyday AI agent” that can handle email, online tasks, and multi-step workflows in the background.

So the boundary should be clear first: this is a leak analysis, not an official Google announcement. All features, naming, and launch timing still need to be confirmed by Google.

Bottom line

Based on currently exposed information, Gemini Spark has three key points:

It may be a 24-hour online Agent inside the Gemini system, not a normal chat model.
It may use broader personal context, including Google apps, chat history, tasks, logged-in websites, and location.
Its risks are as large as its appeal, because it may involve information sharing, remote browser data, purchases, and third-party service calls.

If Google really launches Spark, Gemini’s role will change from “AI that answers questions” to “AI that continuously handles tasks for you.”

What Gemini Spark is

TestingCatalog reported on May 14, 2026 that Google is testing Gemini Spark BETA inside Gemini Web. The exposed welcome text describes it as an everyday AI agent that can help users 24/7 with inbox, online tasks, and more multi-step work.

The 36Kr / Xinzhiyuan article also says that after Spark was uncovered, the outside world saw a “full-time Agent” direction: it can stay on standby all day, process inboxes, execute online tasks, and may even involve purchases and information sharing.

This means Spark is not simply a new model name. It looks more like a Gemini product-layer upgrade: bringing Gemini out of the conversation window and into users’ email, web, calendar, tasks, and cross-app workflows.

How it may work

According to the hidden onboarding text disclosed by TestingCatalog, Gemini Spark may gather context from multiple sources, including:

Connected Apps.
skills.
chats.
tasks.
Websites the user has logged into.
Personal intelligence.
location.

This information would help Spark understand what the user wants to complete and call the necessary context while executing tasks. The text also says that, to complete some actions, Gemini may share necessary information with third parties, such as names, contact details, files, preferences, and information the user may consider sensitive.

If these descriptions prove accurate, Spark will work more like a context-aware agent system than a one-shot Q&A assistant. It will not only look at the current prompt, but may combine long-term preferences, connected apps, browser state, and task history.

Why it matters

The key to Gemini Spark is not one more chat entry point. It is that Google has a natural ecosystem entry point.

OpenAI and Anthropic can build powerful Agents, but they do not naturally own the full chain of Gmail, Calendar, Drive, Chrome, Android, and Workspace. If Google connects Spark into these products, users will not need to build many extra workflows before letting an Agent enter daily work.

This may bring three changes.

First, Gemini may move from passive Q&A to active execution. Users may no longer only ask “summarize this email”; they may ask it to continuously organize the inbox, track tasks, and take follow-up actions.

Second, Agents will rely more on personal context. The more it understands your email, calendar, files, browser state, and preferences, the more useful the result may be.

Third, permission boundaries will become more sensitive. Doing more also means users need to know more clearly when it can act, how far it can go, and whether confirmation is required.

Where the risks are

Several details in the onboarding text disclosed by TestingCatalog are worth watching.

First, Spark is experimental. Even if it launches, it should not be treated as a fully mature system that needs no supervision.

Second, although the system is designed to ask for permission before sensitive operations, the text also warns that it may share information or complete purchases without asking.

Third, to maintain session continuity, Gemini will save remote browser data, such as login details and remote code execution data. Users can clear these data in Settings and can also disable Connected Apps and Personal intelligence.

Taken together, these points show that Spark’s product direction is aggressive: it wants to be an Agent that can truly execute tasks, not only generate suggestions. But the closer it gets to real execution, the more it needs strict permissioning, auditing, confirmation, and rollback mechanisms.

Relationship with Remy and AI Ultra

TestingCatalog says Spark may be a renamed version of the agentic Gemini upgrade previously codenamed Remy, and may also relate to the Gemini Agent direction for Google AI Ultra subscribers.

If this clue is correct, Spark may not be a brand-new project from nowhere. It may be Google repackaging previously higher-end or more closed Agent capabilities and preparing to bring them to a wider audience.

36Kr / Xinzhiyuan also describes it as an upgrade from “Remy” to “Spark”: Gemini Agent is no longer just a feature, but is moving toward a 24/7 digital life manager.

But this is still a judgment based on leaked information. Whether Google will use Spark as the official name, whether it will be limited to AI Ultra, and whether a lighter subscription tier will appear all need official confirmation.

MCP, skills, and the tool ecosystem

The same batch of community screenshots also showed model selector entries such as MCP Tool Testing. The 36Kr article suggests this may hint that the new Gemini will natively support MCP third-party tool integration, with Thinking mode also being rebuilt.

This clue becomes more interesting when viewed together with Spark.

If Spark were only a chat assistant, skills and MCP would matter less. But if Spark is a long-running Agent, it needs to reliably call tools, access web pages, execute tasks, read and write context, and deliver results to users.

In other words, Spark may not be a single feature. It may be part of Google’s Agent tool ecosystem: the model handles understanding and planning, while skills / MCP / connected apps handle execution and expansion.

What it means for ordinary users

If Gemini Spark really launches, ordinary users may see these direct changes:

Email is not only summarized, but can be categorized, followed up, and turned into tasks.
Web tasks are not only suggested, but may be continuously executed in a remote browser.
Calendar, location, preferences, and previous chats become long-term Agent context.
Purchases, bookings, form filling, and similar actions may enter the AI execution range.

This sounds convenient, but users will need new habits: not only checking what the AI says, but also what it is preparing to do, what it has already done, whether it can be undone, and whether there is a record.

Future AI Agent experience may depend not only on model intelligence, but also on clear permission prompts, inspectable task logs, and recovery from mistakes.

What it means for developers and teams

For developers, Spark matters because Google may be moving Agents from “demo products” toward real workflow platforms.

If Spark can reliably connect Google apps, third-party tools, and browser state, developers will care about:

Whether APIs or extension mechanisms are open.
Whether MCP or skills can be connected by third parties.
Whether enterprise admins can control permissions, data retention, and audits.
Whether Agent execution failures have traceable logs.
Whether sandboxing, approval flows, and sensitive-operation confirmation are supported.

For teams, Spark may first enter high-frequency scenarios such as Gmail, Calendar, Docs, Drive, and Chrome. It may not be suitable for fully automated high-risk work at the beginning, but it is a strong fit for inbox triage, meeting follow-up, document organization, market research, and lightweight operations tasks.

How to read it now

This story is best understood as “high-confidence direction, low-certainty details.”

The high-confidence direction is that Google is pushing Gemini Agents to be more proactive, longer-running, and more deeply integrated with its ecosystem. The Gemini Web test text reported by TestingCatalog, community screenshots, and 36Kr’s summary of multiple leaks all point in the same direction.

The low-certainty details are the official name, launch timing, permission rules, subscription tiers, supported regions, API availability, and whether it will really be called Gemini Spark.

The safest view for now:

Do not treat Spark as an already released official product.
Treat it as a strong signal for Google’s next AI Agent direction.
Wait for official explanations around permissions, privacy, third-party data sharing, and remote browser data storage.

Summary

If Gemini Spark eventually launches, it may be a key step in Gemini’s move from chat assistant to always-on Agent. It is not just a model swap; it places Gemini into Google’s ecosystem of email, web, tasks, location, personal intelligence, and third-party services.

Its potential is large: more proactive, closer to real workflows, and easier to distribute to many users through Google’s ecosystem. Its risks are just as large: once AI can share information, save browser state, make purchases, and call third-party services, permission boundaries must be extremely clear.

So the most important question about Gemini Spark is not “how smart is it”, but how Google plans to make a 24-hour online AI Agent controllable, auditable, and trustworthy.

References:

Gemini 3.5 Pro Leak: Codenamed Cappuccino, Google Tries to Regain Momentum in Coding and Agents

Sun, 17 May 2026 11:47:27 +0800

Google has not officially released Gemini 3.5 Pro.

What we can see so far mainly comes from developer community screenshots, anonymous benchmarks, leakers, and media reports. On May 15, 2026, 36Kr / Xinzhiyuan reported that a next-generation Gemini checkpoint may be internally codenamed Cappuccino, and that related models have already surfaced in communities and benchmark platforms.

This information should not be treated as an official launch, but it points in a clear direction: Google is trying to address two gaps at once, coding and reasoning on one side, and always-on AI agents on the other.

Bottom line

This leak can be read in three layers:

Gemini 3.5 Pro has not been officially released, and Cappuccino looks more like an internal checkpoint or candidate build.
The leaked information suggests the new Gemini is improving in code generation, SVG / interactive web generation, and multimodal output.
Google’s parallel test of Gemini Spark may matter more than the model itself, because it points to a 24-hour personal AI agent.

In other words, this is not just a “model benchmark” story. It looks more like a product roadmap signal ahead of Google I/O: the model needs to catch up with GPT-5.5, while the agent layer needs to capture user workflows.

What Cappuccino is

The 36Kr article says a post from Lentils indicates that the Gemini 3.5 Pro checkpoint codenamed Cappuccino has started to appear. The community had been discussing Gemini 3.2 only hours earlier, but the latest leak jumped directly to 3.5.

If that naming is ultimately accurate, Google may want to frame the next Gemini as a larger version jump rather than a routine point release.

For now, Cappuccino should still be treated as a leaked internal codename. It does not mean Google has publicly launched the final model, and it does not guarantee that the final release name will be Gemini 3.5 Pro.

Why coding is the focus

The most discussed part of the leak is the new Gemini’s coding ability.

According to community screenshots and benchmark claims cited by 36Kr, the new model appears stronger at:

Generating SVG and visual components.
Generating interactive web apps.
Handling animation, 3D, adjustable control panels, and other complex frontend outputs.
Improving logical reasoning and code generation.

The article also cites Abacus.AI CEO Bindu Reddy as saying that 3.2 Flash is close to GPT-5.5 in coding and reasoning while being much cheaper. Other media sources reportedly believe the new Gemini roughly reaches the GPT-5.5 tier overall, but may not represent a qualitative leap.

That is why the phrase “matches GPT-5.5” needs caution. It is more of a relative judgment from different leaks and anonymous tests than an official Google benchmark result.

Why Google needs to catch up in coding

AI coding has moved from developer tooling into the center of foundation model competition.

OpenAI has Codex, and Anthropic has Claude Code. They serve engineers, but they also bring product managers, designers, and operators into workflows where natural language can produce runnable products.

By comparison, Google has Gemini and Antigravity, but it has not formed the same default entry point in developer mindshare. The 36Kr article also notes that Antigravity has not truly broken through externally, and that pricing, quota reminders, and experience stability have drawn community discussion.

So if the new Gemini needs to prove itself, coding is the most direct battlefield. The question is not only whether it can write code, but whether it can reliably produce complete interfaces, understand complex requirements, call tools, fix errors, and fit into real development workflows.

Spark may matter more than 3.5 Pro

In the same wave of leaks, Gemini Spark BETA also surfaced.

According to TestingCatalog and other sources, Spark is positioned like an always-on AI agent: it can process inboxes, execute online tasks, manage multi-step workflows, and connect context from Google apps, skill modules, chat history, scheduled tasks, logged-in websites, and location data.

That means Spark is not a normal chat entry point. It may be a system that stays online, continuously reads context, and performs tasks for users.

Its appeal is obvious: if Google can connect Gmail, Calendar, Chrome, Android, Workspace, and Gemini, Spark will have a distribution advantage that OpenAI and Anthropic cannot easily copy.

The risk is just as obvious. The 36Kr article mentions wording around Spark saying it may share information or complete purchases without asking. Even if the system is designed to request permission before sensitive operations, this kind of agent still raises privacy, authorization-boundary, and accidental-action risks.

What this means for ordinary users

If you are a regular Gemini user, the most important part of this leak is not the model name. It is three shifts.

First, Google may continue to strengthen the ability to produce complete results. Users have often complained that Gemini can be lazy with visual generation, SVG, and frontend pages. If the new model can produce several complete options in one pass, the experience will improve noticeably.

Second, coding ability may continue to move into lighter models. The leak repeatedly mentions Flash improvements in coding, reasoning, and interactive generation, which means complex tasks may not always require Pro models in the future.

Third, agents will become more proactive. If Spark launches, Gemini may no longer just answer questions. It may start taking over email, web tasks, purchases, calendars, and cross-app workflows over longer periods.

That is good for efficiency, but it creates a new challenge for permission management.

What this means for developers

Developers should watch two issues more closely.

The first is tooling. The 36Kr article says community screenshots showed an unreleased entry called MCP Tool Testing in the model selector. If Gemini natively supports MCP or third-party tool testing, it will be easier to connect it to developers’ own toolchains.

The second is cost and stability. Even if the new Gemini matches GPT-5.5 on some benchmarks, developers will ultimately judge three things: actual code quality, context stability, and whether pricing and quotas are predictable.

The past year of AI coding tool competition has shown that model capability is only the ticket in. What keeps developers is whether the tool can reliably edit code, run tests, read context, and handle edge cases in daily projects.

How to read this news now

This story is best understood as “strong signal, weak confirmation.”

The strong signal is that multiple community clues point to Google preparing a stronger new Gemini and a more proactive Gemini Spark Agent.

The weak confirmation is that Gemini 3.5 Pro has not been officially released, Cappuccino remains a leaked codename, and claims that it “matches GPT-5.5” still need validation through official Google benchmarks, third-party tests, and real user experience.

The safest view for now:

Do not treat it as a released product.
Treat it as an early preview of Google’s next Gemini direction.
Watch whether I/O or later official events confirm the model name, API availability, pricing, context window, tool calling, and agent permission boundaries.

Summary

The exposure of Gemini 3.5 Pro / Cappuccino suggests Google may be preparing a stronger next-generation Gemini push. It is not trying to fix one isolated capability, but a whole AI workflow: the model needs to write code better, generate interfaces, and handle complex reasoning, while Spark pushes Gemini toward an always-on agent.

But before an official release, all benchmarks and screenshots remain clues. What will decide whether Gemini 3.5 Pro can regain momentum is not whether the codename sounds good, but whether it can reliably win in real development, real office work, and real multi-step tasks.

References:

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn refers to a set of exploitation paths around a logic flaw in Linux kernel __ptrace_may_access(), assigned CVE-2026-46333. It is not a remote unauthenticated flaw and it does not directly hand out a root shell, but the risk is still high: a low-privileged local user may read root-owned sensitive files that should be inaccessible, such as SSH host private keys or /etc/shadow.

For operations teams, the priority is not reproducing a PoC. The priority is to identify affected machines, upgrade the kernel, reboot into the fixed kernel, and rotate SSH host keys or reset passwords when necessary.

Bottom line

This vulnerability deserves high handling priority for four reasons:

It can be triggered by a low-privileged local user and does not require root.
Public PoC code is available, lowering the exploitation barrier.
The potential targets are not ordinary files, but SSH host private keys and /etc/shadow.
The fix requires a kernel patch and reboot; installing packages without rebooting is not enough.

If your servers have multiple users, local shell access, shared hosting, CI runners, container hosts, student lab machines, bastion hosts, or any local users you do not fully trust, handle this first.

What the vulnerability is

Qualys disclosed details on oss-security on May 15, 2026. They had previously reported a Linux kernel __ptrace_may_access() logic issue to security@kernel.org, and the upstream fix had already been merged by Linus. Public exploit code then appeared, so Qualys posted the details to oss-security.

The Linux kernel CVE team later assigned CVE-2026-46333. The NVD page lists kernel.org as the source, and the description maps to the kernel commit ptrace: slightly saner 'get_dumpable()' logic.

In simple terms, the bug sits in a process exit path. When some privileged processes are exiting, ptrace-related access-check logic in the kernel may bypass a dumpable check that should have applied because the target task no longer has an mm. An attacker can race a very narrow timing window and obtain file descriptors that the exiting privileged process still has open.

That is why the issue is called ssh-keysign-pwn: one public exploitation path uses ssh-keysign to read SSH host private keys.

Why SSH host private keys and /etc/shadow may be exposed

At its core, this is a local information disclosure issue. It abuses a window during privileged process exit where the memory descriptor is gone, but file descriptors have not yet been closed.

The AlmaLinux advisory explains the risk clearly: if a privileged program opened sensitive files before dropping privileges, and an attacker successfully grabs the corresponding file descriptor during the exit window, those sensitive files may become readable.

Two commonly discussed targets are:

ssh-keysign: may involve SSH host private keys such as /etc/ssh/ssh_host_*_key.
chage: may involve /etc/shadow.

If SSH host private keys leak, an attacker may impersonate the host and undermine SSH host identity trust. If /etc/shadow leaks, an attacker can crack password hashes offline and expand the compromise later.

That is why this should be treated as high priority even though it is not a “direct root shell” bug.

How to assess exposure

From the upstream perspective, this is a Linux kernel vulnerability. NVD records show the issue entered the NVD dataset on May 15, 2026, with no CVSS score assigned at that time.

Distribution status should be checked against each vendor’s own advisory:

AlmaLinux 8, 9, and 10 published guidance and updated it on May 16, 2026 to say patched kernels had reached production repositories.
Debian Security Tracker lists vulnerable and fixed states, plus fixed versions, for bullseye, bookworm, trixie, sid, and other branches.
For other distributions, check the official security pages or repositories for Ubuntu, Red Hat, SUSE, Arch, Alpine, and so on.

Do not judge safety only by the upstream kernel version. Distributions backport fixes, so the same upstream-looking version number may mean different patch states across distributions.

Which machines to prioritize

Prioritize remediation in this order:

Multi-user servers and shared hosts.
Bastion hosts, teaching machines, development machines, and other systems with normal shell accounts.
CI runners, build machines, and hosting platform nodes.
Container and virtualization hosts, especially where not-fully-trusted workloads coexist.
Public service machines. The vulnerability needs local access, but the risk compounds once a web bug, RCE, weak password, or similar path gives an attacker a low-privileged foothold.

Pure single-user desktop systems are lower risk, but they should still be updated. Local low-privileged code execution is common on desktops through browsers, developer tools, scripts, and third-party software.

Remediation guidance

The preferred fix is to install the fixed kernel supplied by your distribution and reboot.

Commands differ by distribution, but the principle is the same:

Refresh package metadata.
Install the kernel package containing the CVE-2026-46333 fix.
Reboot into the new kernel.
Use uname -r and the distribution security advisory to verify the running kernel is fixed.

The AlmaLinux advisory says fixed kernels are available in production repositories and users can run the usual dnf upgrade and reboot. The Debian tracker also lists fixed versions for multiple branches.

Important: if you only install a new kernel package but do not reboot, the old vulnerable kernel is still running.

Temporary mitigation: tighten ptrace_scope

If you cannot reboot immediately, tighten Yama ptrace_scope first.

Qualys confirmed in a follow-up oss-security reply that setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) blocks the public exploitation paths they know about. They also noted that other theoretical exploitation paths may exist, so this is only a mitigation, not a fix.

Temporary setting:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Persistent setting:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 disables ptrace attach and may affect debugging workflows such as gdb and strace -p. If production debugging is required, evaluate 2. Either way, schedule the kernel upgrade and reboot as soon as possible.

Should SSH host keys be rotated?

Use a conservative approach if the machine had any of the following conditions around the disclosure window:

Untrusted local users.
Shared hosting or container/CI multi-tenant environments.
Web vulnerabilities, weak passwords, supply-chain scripts, or other paths that could give an attacker a local foothold.
Suspicious local processes, unusual debugging behavior, or public PoC files in logs.
Long exposure before patching.

Conservative handling includes:

Rotate SSH host keys after patching and rebooting.
Update known-host fingerprint management systems.
Notify automation that depends on the host fingerprint.
Review SSH connection alerts so legitimate fingerprint changes are not mistaken for man-in-the-middle attacks, and real risks are not ignored.

If /etc/shadow may have leaked, also evaluate password resets, weak-password bans, and whether old hashes could be cracked offline.

What to monitor

The exploitation window is short, so traditional logs may not capture everything. Still, watch for:

Files such as ssh-keysign-pwn, chage_pwn, or similar PoC artifacts in normal user directories.
Suspicious compilation activity, such as unfamiliar C programs compiled in a short window.
Signs of abnormal access to /etc/ssh/ssh_host_*_key or /etc/shadow.
Unusual pidfd_getfd, ptrace, or debugger-related activity.
External reports of unexpected SSH host fingerprint changes.

These signals cannot prove exploitation occurred, and their absence cannot prove it did not. The real priorities remain patching, rebooting, credential rotation, and risk isolation.

Common misconceptions

First: this is not an OpenSSH remote vulnerability. The name includes ssh-keysign, but the root cause is Linux kernel ptrace access-check logic, not the remote authentication path in sshd.

Second: no local users does not mean no risk. The bug does require local execution, but real attack chains often obtain a low-privileged local foothold first through web services, CI, scripts, weak passwords, or container escape paths.

Third: setting ptrace_scope is not enough. It is a temporary mitigation, not the root fix. Kernel update and reboot are still required.

Fourth: “no root shell” does not mean “no incident.” Exposure of SSH host private keys or /etc/shadow can be enough to enable lateral movement, host impersonation, and offline password cracking.

Response checklist

Suggested order:

Inventory affected Linux hosts, especially multi-user and shared environments.
Check distribution security advisories and identify the fixed kernel version.
Install the fixed kernel and reboot.
For machines that cannot reboot immediately, set kernel.yama.ptrace_scope=2 or 3.
After remediation, verify the running kernel version.
Rotate SSH host keys on high-risk machines.
If /etc/shadow exposure is suspected, evaluate password resets and account audits.
Check for public PoCs, unusual compilation, and suspicious local debugging behavior.

Summary

ssh-keysign-pwn (CVE-2026-46333) is a local information disclosure vulnerability rooted in Linux kernel __ptrace_may_access() logic. It does not allow a remote attacker to break in directly and it does not directly grant a root shell, but it may let a low-privileged local user read high-value sensitive files, making it especially important in multi-user, shared hosting, CI, and container-host environments.

The reliable fix is to upgrade to a distribution-provided fixed kernel and reboot. ptrace_scope=2/3 can be used as a temporary mitigation, but it does not replace patching. Critical hosts exposed during the risk window should also be evaluated for SSH host key rotation and password risk.

References:

Gemini Intelligence on Android: Google Is Turning the Phone into a Proactive AI System

Sun, 17 May 2026 09:13:32 +0800

On May 12, 2026, Google published “A smarter, more proactive Android with Gemini Intelligence,” introducing Gemini Intelligence on Android. This is not a standalone chat app. It brings Gemini capabilities into Android, Chrome, Gboard, Autofill, widgets, and multi-device experiences, moving the phone from “wait for the user to tap” toward “proactively help the user complete tasks.”

In short, Google wants Android to move from an operating system toward an intelligence system. The phone no longer just opens apps, shows notifications, and runs settings. It can understand the screen, apps, voice, and personal context, then complete more complex actions with user confirmation.

Short Version

Gemini Intelligence on Android focuses on five areas:

Multi-step automation: Gemini can complete flows across apps, such as rides, shopping, and research.
Smarter Chrome browsing: summarize pages, compare information, and handle some repetitive web tasks on Android.
Upgraded Autofill: use Gemini and personal context to fill more complex forms.
Rambler: turn natural speech into clearer, more polished text.
Natural-language widgets: describe what you want, and Android generates custom widgets.

These features will start rolling out in summer 2026, first on select Samsung Galaxy and Google Pixel phones, and later to more Android devices including watches, cars, glasses, and laptops.

Multi-Step Automation: From Suggestions to Execution

The most important direction is letting Gemini complete multi-step tasks across apps.

Google gives examples such as booking a spin class, finding a course syllabus in Gmail and adding required books to a shopping cart, or seeing a travel poster and asking Gemini to find a similar trip on Expedia.

The hard part is not just understanding one sentence. The system needs to understand:

What is on the user’s current screen or image.
App information the user has authorized.
Which app should be opened next.
Which steps can be automated.
Which steps must pause for user confirmation.

Google emphasizes that Gemini acts on user instructions and stops when the task is done, with final confirmation remaining under user control. This is not a fully autonomous agent, but a mobile agent with human confirmation in the loop.

Screen and Image Context Matter More

One important change is screen context and image context.

Older phone assistants mostly relied on voice commands and fixed app integrations. Gemini Intelligence puts more emphasis on “seeing” the current screen. For example, if a user has a shopping list in notes, they can long-press the power button to summon Gemini and ask it to create a delivery cart from the list.

This means Android AI is not just a chatbot. It is trying to understand the user’s current operating environment. Future mobile AI competition may depend not only on who has the better model answer, but also on:

Whether the AI can understand the current screen.
Whether it can act across apps.
Whether it can track task progress in the background.
Whether it can reliably ask for confirmation at key points.

That is a major difference between mobile AI and web chat AI.

Chrome: From Search to Web Task Agent

Google says Android devices will get a smarter Gemini in Chrome starting in late June 2026.

It can help users research, summarize, and compare web content, and Chrome auto browse can handle some repetitive web tasks such as appointments and parking reservations.

This means Gemini in Chrome is not just a page-summary feature. It is moving toward a browser agent. The browser is already where users complete many web tasks. If Gemini can understand pages, fill information, compare options, and execute some steps, Chrome becomes a task execution surface.

The challenge is practical:

Websites are complex, so automated actions can fail.
Forms, payments, logins, and CAPTCHAs require caution.
Users need to know what Gemini did.
Final submission, payment, or booking should usually remain human-confirmed.

The hard part is not only model capability, but browser automation, safety boundaries, and user trust.

Autofill: From Password Filling to Complex Forms

Autofill with Google was mostly about passwords, addresses, and payment details. Google now wants to upgrade it into a smarter form assistant.

With Gemini’s Personal Intelligence, Android can use relevant information from connected apps to fill more complex form fields, including forms in Chrome.

This is very practical. Filling complex forms on mobile is painful: small screen, many fields, and information scattered across email, calendar, chats, and documents. If Gemini can organize and fill this information with user permission, it can save a lot of time.

Google also stresses that connecting Gemini and Autofill with Google is strictly opt-in. Users choose whether to connect them and can turn the connection on or off in settings.

That matters because Autofill touches personal details, addresses, accounts, payments, work information, and sensitive forms. The more useful it becomes, the more important explicit permission and easy opt-out become.

Rambler: Turning Speech into Sendable Text

Rambler is one of the more interesting new features.

Gboard already supports speech-to-text, but natural speech often includes repetition, pauses, filler words, and self-corrections. Rambler’s goal is to turn natural speech into clearer text that is ready to send.

It is useful when:

You want to dictate a message quickly without editing every word.
Your speech includes pauses, repetition, or filler.
You need to turn a rough thought into a more professional text, email, or chat message.
You switch between languages and want the system to understand context.

Google says Rambler will clearly show when it is enabled, and audio is used only for real-time transcription and not saved. This is a response to privacy and transparency concerns.

From a product perspective, Rambler upgrades “voice input” into “voice writing.” It does not only record what you said; it helps turn speech into sendable text.

Natural-Language Widgets

Gemini Intelligence also introduces Create My Widget. Users can describe a widget in natural language, such as “recommend three high-protein meal prep recipes every week,” and Android generates a custom widget for the home screen.

This points toward generative UI. Users no longer pick only from fixed widget templates; they describe the information and presentation they want.

If the idea matures, the phone home screen could become much more personal. Weather, schedule, health, commute, food, learning, and work reminders could all become dynamic modules generated around user needs.

But generative UI also needs stability. A widget is not a one-off chat response. It sits on the home screen for a long time and must be reliable, readable, configurable, and visually controlled.

Material 3 Expressive and Intelligent UI

Google also says Gemini Intelligence will bring design updates based on Material 3 Expressive.

This is not just decoration. When AI starts acting proactively, the UI needs to clearly show:

What the AI is doing.
Which steps are done.
Where user confirmation is needed.
How the user can cancel or change the action.

Proactive AI without clear UI easily makes users feel out of control. Design language becomes part of the AI product experience.

Availability and Rollout

According to Google, Gemini Intelligence features will start on the latest Samsung Galaxy and Google Pixel phones in summer 2026, then expand to more Android devices, including watches, cars, glasses, and laptops.

This is not a global all-at-once launch. Availability may depend on device, region, language, app support, and account settings.

If you want to try it, the realistic expectations are:

Watch Pixel and Samsung flagship phones first.
Watch for system updates after summer 2026.
Look for new toggles in Gemini, Chrome, Gboard, Autofill, and Android settings.
Not every region and language will support every feature at the same time.

What This Means for Android

Gemini Intelligence on Android is not just a bundle of small AI features. It changes Android’s product direction.

Traditional phone operating systems manage apps, notifications, permissions, files, and hardware. Google now wants the system to understand user intent and complete tasks across apps. If this works, Android’s competition will shift from “system features and app ecosystem” toward “how well the system can proactively help users do things.”

It also changes mobile AI competition:

Apple will emphasize on-device integration, privacy, and system-level control.
Google will emphasize Gemini, Search, Chrome, Android, and multi-device ecosystems.
Third-party AI apps will find it harder to compete with system-level entry points.
App developers will need to think about how their apps can be called by AI agents.

In the next few years, AI on phones may no longer be just a chat entry point. It may become the system-level execution layer.

Summary

Gemini Intelligence on Android is not about adding another Gemini chat box to the phone. It puts AI into Android’s operating flow. Multi-step automation, smarter Chrome browsing, Autofill, Rambler, and natural-language widgets all aim to turn the phone from a passive tool into a proactive assistant.

Whether it changes user habits depends on reliability, clear privacy controls, smooth cross-app operation, and keeping users in final control. At least from this announcement, Google is defining the next stage of Android as a proactive AI system, not just a traditional mobile operating system.

Reference:

Google Blog: A smarter, more proactive Android with Gemini Intelligence

Codex Now Supports Remote Access from ChatGPT Mobile, with Access Tokens for Enterprise Workspaces

Sun, 17 May 2026 09:12:07 +0800

On May 14, 2026, OpenAI updated the ChatGPT Enterprise & Edu release notes with two Codex changes: Codex can now be accessed remotely from the ChatGPT mobile app, and Enterprise workspaces can use Codex access tokens for controlled automation.

This is not a model capability release. It is a shift in the shape of Codex as a product. Codex is moving from a coding assistant that lives locally or in a web session toward a coding agent that can run for longer, be managed remotely, and connect to enterprise automation workflows.

What Changed

According to OpenAI Help Center, Codex now supports remote access from the ChatGPT mobile app. Users can connect to a running Codex environment from their phone, follow long-running tasks, and step in when needed.

At the same time, ChatGPT Enterprise workspaces now have Codex access tokens. These are designed for trusted non-interactive local workflows, allowing automation to use ChatGPT workspace identity and enterprise controls without requiring a browser login every time.

The update has two main entry points:

Mobile remote access: solves the problem of monitoring long Codex tasks when you are away from your computer.
Access tokens: lets enterprise automation scripts use Codex workflows with a controlled identity.

What Mobile Remote Access Solves

Codex tasks do not always finish in seconds. In real development work, Codex may need to read a repository, edit multiple files, run tests, wait for command output, fix errors, and ask for approval midway.

Previously, these tasks often required users to stay near their Mac, desktop app, CLI, or IDE. Now the ChatGPT mobile app can act as a remote console, letting users follow Codex after leaving their computer.

OpenAI says the mobile app can show live state from the underlying environment, including:

Project context.
Approvals.
Screenshots.
Terminal output.
Diffs.
Test results.

Users can also answer Codex questions, redirect execution, approve actions, inspect output, and switch between connected hosts. The underlying task still runs on a Mac host or connected remote environment; the phone is used for viewing and control.

Why This Matters for Developers

This feature is most useful for long tasks that need occasional confirmation.

For example:

Codex is running a slow test suite and you want to check the result while away.
Codex changed multiple files and you want to review the diff from your phone before approving the next step.
Codex is waiting for confirmation before a risky operation.
You have multiple connected hosts and need to switch between them from mobile.

The value is not writing code on a phone. The value is that you no longer need to sit in front of the computer the entire time. Codex keeps working in the original environment, while you step in only at key moments.

This also shows Codex moving toward a background-agent model: tasks can keep running, the user does not need to stay online the entire time, but approval and control remain with the human.

What Access Tokens Solve

Codex access tokens are for ChatGPT Enterprise workspaces. Their focus is not ordinary personal login, but trusted enterprise automation.

Enterprises often have local or internal workflows that need to run non-interactively, such as:

Scheduled code checks.
Triggering Codex workflows on managed machines.
Connecting Codex to internal developer tooling.
Using workspace identity without opening a browser.

Access tokens let these workflows run with ChatGPT workspace identity while still being governed by enterprise policy. Compared with manual browser login, they are better suited to automation. Compared with sharing personal credentials, they are easier to govern.

This Is Not a Generic API Key

This distinction matters. Codex access tokens should not be understood as a simple all-purpose API key.

OpenAI notes that access tokens are available for ChatGPT Enterprise workspaces, admins can manage workspace-level availability, and members with allowed roles can create their own tokens. Governance views may also reflect access token activity when available.

In other words, access tokens sit inside the enterprise permission, role, and audit framework:

Admins can decide whether a workspace enables them.
Not every member can create them by default.
Token activity can appear in governance views.
They inherit ChatGPT workspace identity and enterprise controls.

That is different from casually generating a long-lived personal secret.

Secure Defaults: Remote Control Is Off by Default

Codex mobile remote access touches code environments, terminal output, diffs, test results, and approval actions. If it were enabled by default, it would create obvious enterprise security risks.

OpenAI’s default is therefore conservative: remote control is off by default, and an admin or owner must enable it in Workspace settings.

Enabling mobile remote access may also involve:

Workspace-enabled Remote Control access.
SSO.
Multi-factor authentication.
Passkey.

This is a capability that enterprise IT and security teams need to configure, not something that automatically becomes available to everyone after updating the app.

What Needs to Be Updated

OpenAI says mobile remote access requires updates on both sides:

ChatGPT mobile app.
Codex app on macOS.

If the workspace requires it, setup may also trigger SSO, multi-factor authentication, or passkey flows.

In practice, enterprise admins should first review the remote control settings in Workspace settings and decide which members or roles can use the feature.

Impact on Enterprise Codex Usage

This update pushes Codex in two directions.

First, Codex becomes more suitable for long-running tasks. Previously, long tasks often required constant attention. Now users can monitor status and approve actions from mobile, making Codex more natural as a background worker.

Second, Codex becomes more suitable for enterprise automation. Access tokens give non-interactive workflows a more formal identity path, making future integration with internal CI, code review, scripts, and developer platforms easier.

Together, these changes suggest Codex is evolving from a developer-side AI helper into a manageable enterprise coding agent.

Remaining Boundaries

This update is useful, but it does not mean Codex should run unattended without policy.

Enterprises still need to consider:

Which projects allow remote control.
Which commands require approval.
How tokens are created, rotated, and revoked.
Whether mobile remote access fits device management policy.
Whether terminal output, screenshots, and diffs may contain sensitive data.
Whether audit logs and governance views meet compliance requirements.

Access tokens in particular should be managed like other enterprise credentials: least privilege, rotation, no hardcoding, and timely revocation of unused tokens.

Summary

OpenAI’s Codex update is focused: ChatGPT mobile can remotely access long-running Codex tasks, and Enterprise workspaces can use Codex access tokens for controlled automation.

The first change lets developers avoid sitting in front of their computer the whole time. The second lets enterprises connect Codex more formally to internal workflows. Together, they show Codex moving from an interactive coding assistant toward a remotely manageable, auditable, automation-friendly enterprise coding agent.

Reference:

OpenAI Help Center: ChatGPT Enterprise & Edu - Release Notes

Anthropic’s 2028 AI Leadership Report: The US, China, Compute, and Two Future Scenarios

Sun, 17 May 2026 08:56:12 +0800

On May 14, 2026, Anthropic published a policy essay titled “2028: Two scenarios for global AI leadership.” The essay is not about the capability of a specific Claude model. It is about a larger question: by 2028, which political and industrial system might hold global leadership in AI?

It is important to be clear from the start: this is a policy essay with an explicit point of view. Anthropic’s core argument is that the United States and its allies should preserve and expand their lead in frontier AI, especially by defending their compute advantage, closing export-control loopholes, restricting model distillation attacks, and promoting the global deployment of the American AI stack. The following is a structured summary of the article’s main arguments, not an unconditional endorsement of every claim.

The Core Argument

Anthropic frames the AI competition of the next few years mainly as a competition between the United States and China. It argues that advanced AI is not just a commercial product, but a general-purpose technology that could reshape national security, military capability, cyber offense and defense, research speed, and social governance.

The article’s most important claims are:

Frontier AI competition is, to a large extent, a competition for compute.
The United States and its allies currently have advantages in advanced chips, semiconductor equipment, cloud infrastructure, and capital.
If the US does not close loopholes in export controls and model access, Chinese AI labs could approach or even catch up with US frontier models by 2028.

Anthropic therefore presents 2028 as a fork in the road: one scenario where democracies maintain a commanding lead, and another where US and Chinese AI capabilities are close enough to create a more dangerous neck-and-neck race.

Why Anthropic Emphasizes Compute

The original essay repeatedly emphasizes compute: the advanced chips and computing resources needed to train and deploy frontier models.

Anthropic’s logic is that data, talent, and algorithms all matter, but without enough compute, frontier models cannot keep iterating. As AI is increasingly used to accelerate AI R&D itself, compute advantage compounds: more compute enables more experiments, more experiments lead to better algorithms, and better models help build the next generation of models.

That is why the article places export controls so high on the policy agenda. Anthropic argues that US restrictions on advanced AI chips and semiconductor manufacturing equipment flowing to China have already constrained China’s frontier AI development. It also cites external analyses suggesting that the advanced-compute gap may continue widening.

In short, Anthropic is not only asking “who has smarter researchers.” It is asking who can keep accessing the compute infrastructure needed to train and serve the strongest models.

The Loopholes Anthropic Worries About

The essay argues that current export controls have been effective but insufficient. It highlights two main loopholes.

The first is compute access. This includes smuggling advanced chips, remotely using restricted chips through overseas data centers, and incomplete controls around semiconductor manufacturing equipment. The essay notes that US export controls mainly regulate chip sales, but do not fully cover remote access to restricted chips in foreign data centers.

The second is model access, described as distillation attacks. In this context, “distillation attacks” do not refer to ordinary academic distillation, but to using large numbers of accounts to bypass access controls, systematically harvest outputs from US frontier models, and train or enhance competing models from those outputs. Anthropic describes this as systematic extraction of US model capabilities.

In Anthropic’s view, these two loopholes weaken export controls: even if Chinese companies cannot legally buy enough advanced chips, they may still maintain near-frontier capability through overseas compute and model distillation.

Two 2028 Scenarios

Anthropic uses two hypothetical scenarios to show how today’s policy choices could shape the future.

Scenario One: The US and Allies Extend Their Lead

In the first scenario, the US and its allies preserve their compute advantage. Export-control loopholes are closed, chip smuggling and foreign data-center access are restricted more effectively, and defenses and penalties against model distillation become stronger.

In this world, US frontier models are 12 to 24 months ahead. This lead is not just about benchmark scores; it affects critical sectors such as cybersecurity, finance, healthcare, and life sciences. Anthropic argues that such a lead would give democracies time to set AI rules, safety norms, and global deployment standards.

It also argues that if the American AI stack becomes core global economic infrastructure, it will further attract allies, markets, and talent, creating a self-reinforcing cycle.

Scenario Two: China’s AI Ecosystem Is Near the Frontier

In the second scenario, the US does not continue tightening loopholes, or it loosens restrictions on Chinese companies’ access to advanced compute. Chinese AI labs stay near the frontier through overseas compute, chip access, distillation attacks, and rapid domestic deployment.

In this world, Chinese models may be slightly weaker than US models, but faster domestic adoption, lower cost, more flexible on-premise deployment, and infrastructure exports into certain markets give them real influence.

Anthropic worries that this neck-and-neck state could intensify risks in military use, cyber operations, and domestic governance. It could also pressure both American and Chinese AI companies to release faster, weakening safety evaluations and governance efforts.

Four Fronts of Competition

Anthropic does not treat AI competition as only a model capability race. It lists four fronts:

Intelligence: who develops the most capable models.
Domestic adoption: who integrates AI faster across commercial and public sectors.
Global distribution: whose AI stack becomes the infrastructure of the global economy.
Resilience: who maintains political and social stability through the economic transition.

Intelligence is the most important because frontier model capability drives the other fronts. But the essay also notes that intelligence alone is not enough. If one side deploys slightly weaker models faster into the economy, military, government, and overseas markets, it may offset part of the capability gap.

This is worth noting: future AI competition is not simply about who has larger models or higher benchmarks. It is a combined competition across models, chips, cloud, applications, regulation, and international markets.

Anthropic’s Policy Recommendations

The article closes with three policy directions.

First, close compute loopholes. This includes combating chip smuggling, restricting access to export-controlled chips through overseas data centers, and strengthening controls and enforcement budgets around semiconductor manufacturing equipment.

Second, defend model innovation. This includes restricting model access, deterring distillation attacks, and enabling threat-intelligence sharing between US AI labs and the government.

Third, promote the export of American AI. In other words, make hardware, models, cloud services, and applications developed by the US and its allies the trusted global AI infrastructure, reducing the chance that China’s AI ecosystem expands through low cost and local deployment advantages.

All three recommendations serve the same goal: help the US and its allies establish a more durable frontier AI lead before 2028.

How to Read This Essay

The importance of this essay is not that it reveals new model-architecture details. Its importance is that Anthropic states its view of AI geopolitics very directly.

It represents an increasingly common policy narrative among Silicon Valley AI companies: frontier AI is not just product competition, but national capability competition. Model capability, chip supply chains, cloud infrastructure, export controls, and safety governance must be considered together.

But readers should keep distinctions clear:

The argument that the US should maintain a lead is Anthropic’s policy position.
Claims about China’s AI capability, export-control effectiveness, and the scale of distillation attacks mix facts, external citations, and Anthropic’s interpretation.
The two 2028 scenarios are thought experiments, not predictions.

In other words, the essay is best read as a document explaining how Anthropic understands AI competition, not as a neutral global AI industry report.

Summary

Anthropic’s “2028: Two scenarios for global AI leadership” presents 2028 as a key decision point. If the US and its allies defend compute, restrict distillation attacks, and promote their AI stack globally, Anthropic believes they may secure a 12-to-24-month lead in frontier capability. If they do not act, China’s AI ecosystem could move close to the frontier and gain influence through domestic adoption and low-cost global deployment.

The signal is clear: Anthropic is placing frontier AI, safety governance, chip export controls, and geopolitics into one framework. Future AI competition may be less like a contest among model companies and more like a competition among compute, supply chains, national policy, and global infrastructure.

Reference:

Anthropic: 2028: Two scenarios for global AI leadership

LLM Architecture Evolution from 2023 to 2026: Tokenizers, Positional Encoding, Attention, MoE, Normalization, and Activation Functions

Sun, 17 May 2026 08:53:29 +0800

From 2023 to 2026, LLM architecture seemed to change in many directions: tokenizers got larger, positional encoding shifted toward RoPE, attention evolved from MHA to GQA, sliding windows, and MLA, MoE became mainstream again, and normalization and activation functions moved toward combinations like RMSNorm and SwiGLU.

But the main story is not that Transformer was overturned. The main story is that the Transformer core stayed in place, while almost every component around it was optimized for longer context, lower inference cost, higher training efficiency, and stronger multilingual capability.

Start with the Big Picture

An LLM can be roughly divided into several parts:

Tokenizer: turns text into tokens the model can understand.
Positional encoding: tells the model where each token is in the sequence.
Attention mechanism: decides which context each token should look at.
Feed-forward network: applies more complex nonlinear transformations at each position.
Normalization: keeps training more stable.
Activation function: gives the network nonlinear expressive power.
MoE: splits part of the feed-forward network into multiple experts and activates only a few at a time.

The 2023-2026 evolution is basically these components being optimized one by one.

Tokenizers: From “Can Split Text” to “Uses Fewer Tokens”

The tokenizer turns natural language into token sequences. The model does not see text directly; it sees token IDs.

Earlier tokenizers were often more efficient for English and less efficient for Chinese, code, and multilingual text. If the same sentence is split into too many small pieces, it consumes more context window and increases both training and inference cost.

One clear trend in recent years is larger vocabularies and better multilingual support. Llama 3 uses a 128K-token vocabulary, and Meta explicitly says this encodes language more efficiently and improves model performance. Qwen, DeepSeek, and other models also pay close attention to token efficiency for Chinese, code, and multilingual scenarios.

For beginners, think of it this way: the better the tokenizer, the less fragmented the same text becomes, and the more useful information the model can fit into the same context length.

Positional Encoding: RoPE Became Mainstream

Language has order. “Dog bites man” and “man bites dog” contain similar words, but the order changes the meaning. Positional encoding injects that order information into the model.

Early Transformers used absolute positional encodings, where position 1, position 2, and position 3 each had their own vector. Later LLMs more often used RoPE, or Rotary Positional Embedding. RoPE integrates position information into attention computation and is friendlier to long-context extension.

From the Llama family to many open models, RoPE has become one of the de facto standards. To support longer context, models may also adjust the RoPE base frequency, apply RoPE scaling, or combine it with sliding-window or chunked attention.

Simply put, RoPE does not make a model “suddenly smarter,” but it helps the model handle relative position relationships better in longer text.

Attention: From MHA to GQA, Sliding Windows, and MLA

Attention is the core of Transformer. It lets each token look at the most relevant tokens in the context for the current task.

The classic version is MHA, or Multi-Head Attention. It has multiple attention heads, each learning a different way to focus. The problem is that as models and contexts grow, KV cache becomes expensive and inference cost rises.

After 2023, the main direction of attention optimization was reducing inference cost.

GQA, or Grouped-Query Attention, is an important step. It lets multiple query heads share fewer key/value heads, reducing KV cache pressure. Meta explicitly adopted GQA in Llama 3 to improve inference efficiency.

Mistral 7B represents another direction: sliding-window attention. It does not require every token to attend to the entire history, but focuses mainly on a nearby window, reducing long-sequence computation pressure. For many tasks, local context already carries much of the useful information.

DeepSeek-V2/V3 pushed attention optimization further with MLA, or Multi-head Latent Attention. Its focus is compressing KV cache to reduce inference memory pressure. The DeepSeek-V3 technical report lists MLA and DeepSeekMoE as core architectural features.

You can understand these methods together:

MHA: the classic approach, strong but expensive.
GQA: greatly reduces KV cache cost with little loss in expressiveness.
Sliding-window attention: reduces full-attention cost in long context.
MLA: further compresses attention cache for efficient inference.

MoE: Many Parameters, but Only Some Are Used Each Time

MoE means Mixture of Experts.

A normal dense model activates all parameters for every token. MoE puts many experts inside the model, but routes each token to only a few experts. This allows the total parameter count to be large while the number of active parameters per inference step stays smaller.

Mixtral 8x7B, released at the end of 2023, was an important moment that brought MoE back into broad attention. Mistral’s paper explains that Mixtral 8x7B largely follows the Mistral 7B architecture, but replaces each feed-forward block with 8 experts and uses sparse routing to select part of them for computation.

DeepSeek-V3 later made MoE a core route. It has a very large total parameter count, but activates only a subset for each token, using DeepSeekMoE to reduce training and inference cost. Qwen3 and other model families also provide both dense and MoE variants, showing that MoE has moved from a research trick to a mainstream engineering option.

For beginners, a dense model is like a company where everyone attends every meeting. MoE is like dividing the company into expert teams and calling only the most relevant teams for each problem.

MoE also has clear difficulties:

The router must learn to send tokens to suitable experts.
Expert load must be balanced, so not all tokens crowd into a few experts.
Distributed training and inference become more complex.
Large total parameters do not automatically make deployment cheap.

Normalization: RMSNorm Became Common

Normalization stabilizes the distribution of intermediate values inside the neural network. When training large models, unstable values make convergence harder and training less reliable.

Early Transformers commonly used LayerNorm. Many Llama-style models later switched to RMSNorm. RMSNorm is simpler than LayerNorm: it does not compute the mean and focuses on root-mean-square scaling. It is lighter and stable enough in practice.

You do not need to memorize the formula. Just remember that RMSNorm is a lighter stabilizer. It does not determine model capability by itself, but it affects training stability, speed, and engineering implementation.

Activation Functions: From ReLU/GELU to SwiGLU

Activation functions add nonlinear capability to neural networks. Without them, a deep network would easily collapse into a linear transformation.

Earlier Transformers often used GELU. In modern LLMs such as Llama, Mistral, Qwen, and DeepSeek, SwiGLU or similar GLU variants are more common. SwiGLU usually appears inside the feed-forward network and controls information flow through a gating mechanism.

A rough analogy: a normal activation function is like a fixed switch, while SwiGLU is more like a learnable valve. It does not just decide whether information passes through; it can learn which information should be amplified.

SwiGLU makes the feed-forward layer slightly more complex, but in large-model practice it has become a common high-performance component.

The Overall Trend from 2023 to 2026

The timeline can be summarized like this:

2023: Llama, Mistral 7B, Mixtral, and other open models popularized combinations such as RoPE, RMSNorm, SwiGLU, GQA, sliding-window attention, and MoE.
2024: Llama 3, Qwen2.5, DeepSeek-V2/V3, and others expanded vocabularies, improved long context, strengthened inference efficiency, and made MoE and efficient attention central topics.
2025: DeepSeek-V3/R1 made more people pay attention to MLA, DeepSeekMoE, FP8, MTP, and the deep connection between architecture optimization and system engineering.
2026: The trend remains efficiency and engineering maturity: dense models continue to pursue stable general capability, MoE models expand capacity, and efficient attention reduces long-context cost.

The most important change was not one component replacing Transformer. It was the realization that adding parameters alone is not enough: architecture, data, training systems, and inference services must be optimized together.

How Beginners Should Learn This

If you are starting from zero, do not begin by forcing yourself through every paper. A better order is:

Understand the basic Transformer structure: tokens, embeddings, attention, and FFN.
Learn why RoPE, RMSNorm, and SwiGLU became common.
Study GQA and KV cache to understand why inference consumes so much memory.
Learn MoE, focusing on the difference between total parameters and active parameters.
Finally, read model reports such as DeepSeek-V3, Mixtral, and Llama 3 to place these components back into real models.

Do not treat these terms as isolated facts. Most of them answer the same question: how can models become stronger while remaining trainable, deployable, and fast enough to serve?

Summary

The 2023-2026 evolution of LLM architecture can be seen as the engineering maturation of Transformer. Tokenizers reduce token waste, RoPE represents position more effectively, GQA, sliding-window attention, and MLA reduce attention cost, MoE expands capacity while controlling active computation, and RMSNorm plus SwiGLU make training and representation more stable and efficient.

For beginners, the key is not memorizing terms. The key is understanding the main tradeoff: almost every modern LLM architecture change is about cost, efficiency, context length, and scalability.

References:

Why Did Codex Usage Limits Suddenly Reset? History and Sources

Sun, 17 May 2026 08:36:15 +0800

Codex users sometimes see an odd situation: their usage limits recover even though their normal reset time has not arrived. This kind of unexpected reset is not new, and it does not necessarily mean the quota policy has permanently become more generous. It may come from incident compensation, product promotions, growth milestones, or a backend reset that only applies to certain windows or account states.

This screenshot comes from a post on X by Tibo Sottiaux (@thsottiaux), who leads the OpenAI Codex team. For users tracking limits, the key point is not the model detail but the line saying he would reset usage limits that evening. The context suggests this was a compensating reset, not a normal scheduled refresh.

Short Version

Sudden Codex usage limit resets usually fall into several categories:

Incident compensation: a Codex or model issue wastes user quota, so OpenAI resets limits to make up for it.
Launch or promotion events: a new model, client, or feature ships with temporary extra capacity or a reset.
Growth milestones: OpenAI resets or raises limits after Codex reaches a user-growth milestone.
Backend policy changes: only some quota windows or account states are reset, and the UI may not explain the scope.

The most common misunderstanding is assuming that “reset” means every visible quota window recovered. In practice, Codex may have short rolling windows, weekly limits, model-specific consumption weights, and plan-specific rules. A special reset may only affect part of that system.

What This Screenshot Shows

The screenshot shows Tibo posting an update on May 15, 2026, saying the team would continue monitoring and reset usage limits that evening. It quotes an earlier message saying the team was investigating reports from some users.

For users, there are three practical takeaways:

This was not a normal user-specific reset cycle; it was an active reset by the team.
The reset had a specific event context and was not a permanent limit increase.
The phrase “usage limits” does not by itself clarify whether both short windows and weekly limits were included.

So if your quota recovered, treat it first as a special reset event, not as evidence that future limits have changed.

Why Codex Resets Can Feel Unexpected

Codex limits are not simply “refreshed at a fixed time every day.” The backend may track several things at once:

Short usage windows, such as a few-hour window.
Weekly or longer-period limits.
Different consumption weights for different models.
Different entry points such as local Codex, Cloud Tasks, IDEs, and the CLI.
Plan differences across Plus, Pro, Business, and Team.
Whether an account is eligible for a special reset.

When OpenAI applies a special reset, the UI may not clearly say whether it was a normal cycle refresh or a special compensation event. If only the short window resets, users may assume the weekly limit should also recover. If the weekly limit does not move, it can look like the reset failed.

An issue in the OpenAI Codex GitHub repository raised the same transparency problem: public messaging said Codex rate limits had been reset, but the product UI did not clearly show which windows were reset, whether the weekly limit was included, or whether all paid plans were affected equally.

Historical Patterns

1. February 2026: Launch Period and Temporary Extra Capacity

During the Codex desktop app and GPT-5.3-Codex promotion period, community users discussed usage limit resets and temporary 2x rate limits. Reddit users mentioned that the Codex app launch came with limited-time 2x rate limits and a usage limit reset.

This kind of reset looks more like a launch-period operation: encourage people to try the new client, model, or workflow.

2. March 2026: Random Resets and Abnormal Consumption

Around March, the community repeatedly discussed “random usage reset” and “weekly limit reset daily” behavior. Some users said their weekly limit recovered early, while others connected the behavior to new Codex models, safety blocks, abnormal quota burn, or bug fixes.

These discussions are not official announcements, but they show that users had already observed Codex limits recovering outside their normal schedules.

3. April 2026: Growth Milestones and Paid-Plan Resets

In late April, public reporting said Codex had reached 3 million weekly active users and that OpenAI reset rate limits, with plans to give users more room at later growth milestones.

A GitHub issue also cited a Tibo post from April 28 saying he had reset Codex rate limits for paid plans after a “good week,” so users could build more with GPT-5.5. The same issue noted that the product UI did not clearly explain which quota windows were actually reset or whether the weekly limit was included.

This shows why activity-based resets can still cause confusion: users may hear broad wording but see different behavior in their own account.

4. May 2026: Compensation Reset

The screenshot in this post is a clearer example of a compensation-style reset. Tibo said the team had found issues and would reset usage limits that evening. OpenAI Status also recorded Codex-related elevated errors and degraded latency on May 13, 2026.

For ordinary users, the point is not which model detail caused the issue. The key lesson is that OpenAI may reset limits when a service-side problem causes users to burn quota abnormally.

How to Interpret a Sudden Reset

If your Codex quota suddenly recovers, check in this order:

Confirm whether your normal reset time had arrived.
Check OpenAI Status for Codex incidents, model errors, latency, or degraded performance.
Look for updates from Tibo, OpenAI accounts, or Codex GitHub issues.
See whether community users are reporting the same reset, abnormal burn, or weekly-limit confusion.
Separate short-window resets from weekly limits; do not assume they always move together.

If it is official incident compensation, there is usually a status-page entry, a team announcement, or a cluster of user reports. If it is only a partial backend refresh, there may be no clear public announcement.

How Reliable Are the Sources?

It helps to separate sources by reliability:

OpenAI Status: best for confirming service incidents, error rates, latency, and recovery times.
Tibo / OpenAI official accounts: useful for special reset, compensation, or promotion messaging.
OpenAI Codex GitHub issues: useful for seeing user reports about UI behavior, quota windows, and actual product behavior.
Reddit / X discussions: useful for spotting broad user patterns, but not official confirmation.
Third-party news or blogs: useful for timeline context, but should be checked against original sources.

When writing or making decisions, keep these layers separate. “OpenAI Status recorded an incident” is an official status signal. “Reddit users reported random resets” is community observation. “A GitHub issue reported unclear UI behavior” is a user-submitted product issue.

Summary

A sudden Codex usage limit reset is usually not just “free quota from nowhere.” It may come from incident compensation, launch promotion, growth activity, or a backend policy update. The confusing part is that Codex has multiple quota windows, and a special reset may not include all of them. The UI may also fail to show the reset scope clearly.

When it happens, check your actual client-side quota first, then compare it with OpenAI Status, Tibo’s posts, Codex GitHub issues, and community reports. Do not assume one reset means the long-term rules have changed, and do not assume weekly limits, short windows, and every plan all reset together.

References:

easy-vibe: A Learning Map for Vibe Coding Beginners

Sat, 16 May 2026 22:44:43 +0800

easy-vibe is an open source Vibe Coding learning project from Datawhale. It is not aimed at developers who are already fluent with AI coding tools. It is aimed at students, product managers, designers, operators, indie developers, and technical hobbyists who are just starting with Vibe Coding.

The value of this project is not that it lists another batch of AI tools. It turns “how to start building projects with AI” into a learning path that is easier to understand. For many beginners, the hard part is not knowing that Claude Code, Cursor, MCP, or Agents exist. The hard part is knowing what to learn first, how to practice, and when to move into more advanced tools.

Beginners Need a Path Most

Vibe Coding has become popular in recent years, but it is not very friendly to beginners.

On the surface, as long as you can describe a requirement, you can ask AI to write code. In reality, as soon as the task becomes slightly more complex, problems appear: the requirement is unclear, the model edits the wrong file, the project structure is confusing, errors are hard to handle, dependencies fail to install, prompts become messier, and the workflow falls back to “copy code into a chat box”.

So getting started with Vibe Coding cannot only mean learning “how to write prompts”. It needs to solve several things:

How to split an idea into executable tasks;
How to let AI understand a project structure;
How to read code generated by the model;
How to handle errors and iterate;
How to use the terminal and local development environment;
How to move from web chat to real AI coding tools.

This is where easy-vibe matters: it tries to organize these topics into a learning route, instead of leaving beginners lost among tools, tutorials, and terminology.

It Is a Roadmap, Not a Single Tutorial

According to the project description, easy-vibe covers basic tutorials, interactive exercises, visual content, RAG, terminal tools, AI coding tools, and more advanced topics such as Claude Code, MCP, Skills, and Agent Teams.

This structure is suitable for beginners because AI coding is not a single skill. It is a combination of abilities:

Describing requirements;
Splitting tasks;
Reading projects;
Asking the model to edit code;
Running and verifying results;
Iterating based on errors;
Turning repeated workflows into tools or skills.

If you only learn one tool, it is easy to be constrained by that tool’s interface. Switch models, editors, or CLIs, and the workflow becomes unclear again. A roadmap helps build the working method first, then places tools where they belong.

Especially Useful for Non-Programmers

The biggest appeal of Vibe Coding is that it lets non-professional programmers build prototypes.

Product managers can turn product ideas into interactive demos. Designers can validate interaction logic. Operators can write internal tools. Students can quickly build course projects. Founders can validate demand early. These people do not necessarily need to become full-time engineers in the traditional sense, but they do need a method for “letting AI help me turn ideas into working things”.

This is also why easy-vibe fits the Chinese community. Many Chinese users already know AI can write code, but they still lack systematic beginner materials. Development environment, prompts, project structure, debugging methods, and Agent tools are easier to learn when explained clearly in Chinese and paired with exercises.

For these users, the most important thing is not to learn a complex framework immediately. It is to complete a full loop first: propose a requirement, generate a project, run it, find problems, keep modifying, and finally get a usable version.

The Advanced Part Moves Toward Real AI Development Workflows

The Claude Code, MCP, Skills, and Agent Teams mentioned in easy-vibe are no longer just beginner concepts.

Claude Code represents terminal coding Agents: the model can enter a local project, read files, edit code, and run commands. MCP solves tool and data source integration, so the model is not trapped in a chat box. Skills preserve reusable workflows, such as fixed project generation, document organization, test checks, or content production processes. Agent Teams further split tasks across multiple agents.

These topics may feel distant for beginners, but they are worth understanding early. The direction of Vibe Coding is already clear: from “let AI write a piece of code” to “let AI participate in a complete project workflow”.

If a learning route stops at prompts, it will quickly fall behind tool evolution. On the other hand, if every advanced concept is thrown at beginners immediately, they will not know where to start. The useful part of easy-vibe is that it places these topics on a gradual upgrade path.

Two Mistakes to Avoid

The first mistake is thinking that Vibe Coding means you can ignore code entirely.

AI can generate a lot, but the user still needs to judge whether the result is correct. At minimum, you need to understand the project structure, know how to run it, and roughly know where an error is happening. Even if you do not write complex code, you still need basic engineering common sense.

The second mistake is thinking that more advanced tools are always better.

Beginners do not necessarily need Claude Code, MCP, or multiple Agents at the start. A better order is to first build a feedback loop with simple projects, then gradually introduce the terminal, version control, testing, tool calling, and automated workflows. Tools should match task complexity; otherwise they look powerful but have no clear use.

How to Use It

If you are just starting with Vibe Coding, you can use easy-vibe as a learning checklist.

Start with basic concepts and simple exercises. Do not rush to chase every tool. Build a small project, such as a personal homepage, data dashboard, form tool, automation script, or knowledge base demo. During the process, observe where AI helps and where you still need to confirm things yourself.

Once you can complete small projects consistently, move into more complex topics:

Use terminal tools to work with local projects;
Use Git to manage each change;
Use RAG to connect your own materials;
Use MCP to connect external tools;
Use Skills to solidify repeated workflows;
Use Agent Teams to split complex tasks.

Learning Vibe Coding this way is not just learning to ask AI. It is learning to put AI into your own workflow.

Conclusion

easy-vibe is best seen as a Chinese learning map for Vibe Coding. It organizes scattered AI coding concepts, tools, and exercises into a route that helps beginners move from “I heard AI can write code” to “I can build a project with AI”.

The real value of Vibe Coding is not that it lets people skip all learning. It lowers the threshold from idea to prototype. You still need to understand requirements, organize tasks, verify results, and control risks. But many repetitive, tedious, and blocking steps can be handled with AI assistance.

If you want a systematic entry point into AI coding, without getting trapped immediately in tool names and complex engineering setup, easy-vibe is a good place to start.

Anthropic financial-services: Reusable Templates for Financial Agents

Sat, 16 May 2026 22:43:08 +0800

anthropics/financial-services is a reference project from Anthropic for the financial services industry. It is not a single application, but a set of examples that can be studied and reused separately: Agents, Plugins, Skills, MCP connectors, and prompts and integration patterns designed around financial workflows.

This project is worth watching not because it provides a “universal financial assistant”, but because it breaks common AI implementation problems in finance into more concrete components: what kind of Agent each role needs, which data sources need to be connected, which tasks can be automated, and which steps still require human judgment.

It Is More Like a Showroom for Financial Agents

When companies talk about AI Agents, the discussion can easily stay abstract: reading files, querying data, writing reports, and calling tools. Once the scenario enters finance, the questions become much more specific.

Investment banking analysts need to organize company materials, generate transaction briefs, and compare comparable companies. Equity research needs to read filings, follow news, perform valuation, and analyze risks. Private equity and asset management teams need to screen deals, write memos, and track portfolio companies. Wealth management needs to place client profiles, market information, and investment advice within a compliance framework.

These scenarios cannot be handled by a generic chat box alone. They require roles, processes, data sources, output formats, and permission boundaries. The value of this Anthropic repository is that it turns multiple typical financial services roles and tasks into Agent templates that can be used as references.

Why Provide Agents, Plugins, Skills, and MCP Together

Judging from the project structure, Anthropic did not only provide a set of prompts. It provides several kinds of components at the same time. This maps to several layers of enterprise Agent implementation.

Agents are more like work units for roles or tasks. They define what the agent should do, how it should do it, when to call tools, and how to produce output.

Plugins are more like external capability extensions. Financial work rarely happens only inside the model. It often needs to connect databases, document systems, market data, CRM, research libraries, and internal workflow systems.

Skills are reusable professional capability packages. Fixed analysis frameworks, report structures, checklists, and data processing methods can be turned into skills instead of being rewritten as prompts every time.

MCP connectors solve tool integration and context standardization. For enterprises, the more tools there are, the more they need a relatively unified way to connect them. Otherwise every system needs separate adaptation, and maintenance cost rises quickly.

Only when these pieces are combined does the result begin to resemble a real enterprise AI workflow.

Why Finance Is a Good Industry for Agent Examples

Financial services is a good industry for showing Agents because it has three traits at the same time.

First, information density is high. Financial work relies heavily on filings, announcements, meeting notes, research reports, trading data, client records, and regulatory documents. If a model only relies on general knowledge, it quickly becomes ineffective. It must connect to real data sources.

Second, output formats are stable. Investment memos, company profiles, KYC documents, research summaries, client briefings, and fund operation reports all have relatively fixed structures. This makes it easier for Agents to form verifiable workflows.

Third, risk boundaries are clear. Finance has strict requirements for compliance, auditability, permissions, and traceability. AI cannot casually provide investment advice or bypass approval processes. This forces Agent design to become more engineering-driven: keep references, separate facts from inferences, record tool calls, and limit executable actions.

That means this project is not only for financial companies. Any team building enterprise Agents can use it to observe how Anthropic decomposes industry scenarios.

What Typical Workflows It Covers

According to the project description, the repository covers several financial services areas, including:

Investment banking;
Equity research;
Private equity;
Wealth management;
Fund operations;
KYC and compliance-related workflows.

These workflows have one thing in common: they all require a lot of reading, organizing, comparison, and structured document generation. The best role for AI here is not to make decisions directly, but to reduce the time spent on information processing and document production.

For example, in investment banking, an Agent can help organize target company information, extract key financial metrics, and generate a first draft of a transaction summary. In research, it can read filings and news first, then list key changes and open questions. In KYC, it can help check whether materials are complete and whether there are unusual signals.

The final judgment should still belong to professionals. The Agent’s role is closer to assistant, analyst, and workflow accelerator.

What It Suggests for Enterprise Adoption

The most useful part of this repository is that it turns “model capability” into “business components”.

Internal AI projects often run into the same problem: model demos look impressive, but once they are connected to real business, they are hard to reuse. One team writes one set of prompts, another team writes another. One system connects a database, another builds its own interface. Security and audit requirements are scattered everywhere.

A steadier approach is to split capabilities into several types of assets:

Role-oriented Agents;
Process-oriented Skills;
MCP connectors for system integration;
Execution rules for permissions and audit;
Templates and checklists for business output.

The benefit is that the enterprise does not restart from “building a chatbot” every time. It gradually accumulates maintainable AI workflow assets.

Compliance and Responsibility Boundaries Cannot Be Ignored

The easiest misunderstanding around financial Agents is treating “can generate analysis” as “can replace decisions”.

In financial services, AI output should usually be treated as supporting material. It can organize facts, draft documents, highlight risks, and complete files, but it cannot bypass investment research, risk control, legal, compliance, and suitability requirements. Especially when investment advice, trading decisions, asset allocation, or identity checks are involved, human approval and responsibility chains must remain.

That is why enterprise Agents cannot be evaluated only by answer quality. They must also be evaluated by:

Whether data sources are reliable;
Whether references and evidence are traceable;
Whether tool calls are recorded;
Whether sensitive data is restricted;
Whether output has human confirmation;
Whether wrong results can be discovered and rolled back.

If these questions are not solved, the more automated the Agent becomes, the larger the risk radius becomes.

Conclusion

anthropics/financial-services is more like a financial Agent reference implementation than an out-of-the-box financial product. It shows one way Anthropic thinks about enterprise AI adoption: do not build only generic chat assistants; organize Agents around specific roles, specific workflows, specific data sources, and specific permission boundaries.

For financial institutions, it can serve as a reference for designing internal AI workflows. For developers, it is a sample for observing enterprise Agent architecture: Agents handle roles and tasks, Skills preserve professional processes, Plugins and MCP connect external systems, and the model eventually enters real business workflows.

If early AI tools solved “how to make models answer questions”, projects like this care more about “how to let models participate in work within controlled boundaries”. That is where enterprise Agents become truly difficult.

DeepSeek-TUI: Turning DeepSeek V4 into a Terminal Coding Agent

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI is an open source project that brings DeepSeek V4 into terminal-based development workflows. It is not just a chat wrapper. It is closer to a “command-line coding agent” like Claude Code or Codex CLI: it can read files, edit code, run commands, call tools, and keep working through tasks in a TUI.

If you already switch between an editor and a terminal, the value of this kind of tool is straightforward: you do not need to copy code back and forth into a web chat window, and you do not need to manually describe the whole project structure. You give it a task, and it can read context from the current workspace, plan steps, make changes, then return the result for your review.

It Solves the Entry Point Problem for DeepSeek

DeepSeek models already provide strong reasoning and coding capabilities, but model capability needs an engineering layer before it can land in real development workflows.

Web chat is suitable for asking questions, but not for long-running project edits. APIs are suitable for system integration, but individual developers still need to build tool calling, context management, file operations, and permission control themselves. DeepSeek-TUI tries to fill this layer: it wraps DeepSeek V4 into an Agent that can work inside the terminal.

According to the project description, its main capabilities include:

A terminal TUI;
Conversation and task execution for DeepSeek V4;
Tool calling and file operations;
1M context support;
Auto mode;
Sub-agents;
Sandboxed execution;
A persistent task queue.

Together, these features are not aimed at making the model sound more human. They are aimed at making the model easier to bring into the development environment.

A TUI Fits Long Tasks Better Than Plain CLI Text

Many AI CLI tools start with plain text interaction: enter a prompt, wait for output, then copy commands or add more context. This is simple, but longer tasks quickly become messy.

The advantage of a TUI is that it can place conversations, files, execution results, and task status in a more stable interface. For a coding Agent, that matters. A code task is rarely a single question and answer. It often includes:

Understanding the project structure;
Finding relevant files;
Editing code;
Running tests or commands;
Fixing issues based on errors;
Summarizing changes.

If the interface is only a stream of logs, it is hard for the user to see where the Agent is in the process. A TUI at least provides a better place to observe and take over.

Auto Mode Is Best for Tasks with Clear Boundaries

The Auto mode mentioned by DeepSeek-TUI is best for tasks with clear boundaries. For example: fixing a small bug, adding a script, changing a configuration, organizing a set of documents, or implementing a local feature.

These tasks have something in common: the goal is clear, the verification method is clear, and the impact scope is controllable. The Agent can inspect files, edit files, run commands, and then hand the result back to the user for confirmation.

But Auto mode should not mean unlimited permission. In real projects, file deletion, large-scale refactors, database migrations, and deployment commands should all require explicit confirmation. The efficiency of coding Agents comes from automation, but so does the risk. The more a tool can execute commands, the more it needs sandboxing, permission boundaries, and human review.

Sub-Agents Matter Because They Split Tasks

Sub-agents are not a new concept, but they are useful in coding scenarios.

A moderately complex task usually requires several kinds of work at the same time: someone reads the code, someone changes the implementation, someone checks tests, and someone organizes documentation. Traditional multi-agent systems often feel ornamental because they have no real tools or real workspace; they only discuss inside a conversation.

If sub-agents can work with the file system, command execution, and task queues, they become more like a task decomposition mechanism. For example, one sub-agent can analyze dependencies, another can modify a specific module, and the main agent can integrate the result. This can reduce the problem of putting too much unrelated information into one context.

Of course, sub-agents also add cost: more tokens, more complex state, and responsibility boundaries that are harder to track. They are better suited to medium-complexity tasks and above, not necessarily every small edit.

1M Context Is Not Magic, but It Helps with Projects

1M context sounds exaggerated, but in coding scenarios it is not just a marketing number.

The context of a real codebase is fragmented: README files, configuration files, type definitions, tests, call chains, historical conventions, and error logs can all affect one change. Longer context can reduce the problem of editing after seeing only a local fragment, and it can help the model retain more project constraints.

Still, longer context does not automatically mean better judgment. Code tasks still need retrieval, filtering, and verification. Putting an entire project into context is not necessarily better than reading the relevant files precisely. A good coding Agent should treat long context as a buffer, not as a shortcut that replaces engineering judgment.

Who It Is Best For

DeepSeek-TUI is better suited to several groups:

Developers who want to use DeepSeek for coding tasks in the terminal;
People who do not want to build tool calling and file operation frameworks themselves;
Users familiar with Claude Code or Codex CLI who want to try a DeepSeek-based entry point;
People who need local project context instead of only asking about code snippets in a web page;
Developers who want to put AI coding workflows into a command-line environment.

If you only occasionally ask how to write a function, web chat is enough. If you want the model to participate directly in project edits, a terminal Agent becomes more meaningful.

Risks to Watch

There are three things to watch most closely with this kind of tool.

The first is permissions. As long as a tool can read and write files or execute commands, you need to know what it can access by default, whether it can delete files, whether it can access the network, and whether dangerous commands require confirmation.

The second is rollback. Before using it, it is best to keep the Git working tree clean, so every Agent change can be clearly seen through git diff. Do not let an Agent automatically edit a project while many unrelated changes are already uncommitted.

The third is verification. Code written by an Agent does not mean the task is complete. Tests, builds, linting, and human review still need to remain. AI coding tools can speed up progress, but they cannot replace final engineering confirmation.

Conclusion

The significance of DeepSeek-TUI is not that it adds another chat client. It puts DeepSeek V4 into a terminal environment that is closer to real development work.

For developers, model capability is only the first step. The real experience depends on whether it can read a project, safely edit files, run verification commands, maintain state in long tasks, and let the user take over at any time.

If you want to use DeepSeek for daily code changes, project reading, and automated development tasks, DeepSeek-TUI is worth watching. The direction is also clear: AI coding tools are moving from “answering code questions” to “participating in project execution.”

Why AI Data Centers Are Driving HDD Demand Again

Sat, 16 May 2026 21:02:33 +0800

Over the past two years, most AI infrastructure discussions have focused on GPUs, HBM, advanced packaging, and power supply. Behind training and inference systems, however, there is another bottleneck that is easier to overlook: storage.

A large model does not finish its work with a single computation inside a GPU. During training, it continuously produces checkpoints, optimizer states, training logs, dataset versions, and intermediate results. During inference, it also generates user interaction records, compliance archives, audit data, and system logs. These datasets do not always need to sit on the fastest media, but they often cannot be deleted immediately.

That is why hard drives are becoming important again.

AI Training Creates Massive Cold Data

Large model training needs to save checkpoints regularly. A checkpoint is essentially a saved state of the training process: if a training run crashes halfway through, the system can resume from a checkpoint instead of starting over.

For a large model, a single checkpoint can be several terabytes. A full training run may last weeks or even months, producing many checkpoints along the way. Even if some are later cleaned up, experiment replay, reproducibility, rollback, and model audits still require large amounts of data to be retained.

Training data itself is also expanding. High-quality text, images, videos, and code need to be cleaned, deduplicated, split, and versioned. As synthetic data, reinforcement learning data, and multimodal data become part of training pipelines, storage pressure will keep increasing.

This kind of data has several traits:

It is enormous in volume;
It is not always accessed frequently;
It needs long-term retention;
It is highly sensitive to cost per unit of capacity.

This data does not make sense to store entirely on expensive high-speed storage.

Why Not Use Only SSDs

SSDs are obviously faster, but data centers cannot optimize only for speed. For petabyte-scale cold data and anything beyond that, cost per unit of capacity directly determines whether the system is sustainable.

Storage in an AI cluster can be divided into several tiers:

HBM and GPU memory handle the hottest and most urgent data;
DRAM handles temporary movement and staging;
SSDs handle frequently accessed data with stronger low-latency requirements;
HDDs handle massive cold data, backups, logs, checkpoint archives, and long-term retention.

In other words, SSDs are important, but they cannot replace every tier. Truly large-scale systems usually need tiered storage: hot data prioritizes speed, while cold data prioritizes capacity, cost, and reliability.

As AI companies start retaining training residue, model versions, synthetic data, inference logs, and audit records for longer periods, the value of HDDs becomes more visible again.

Why HDD Supply Is Getting Tight

The hard drive market has not looked especially exciting for years, and consumer PCs have increasingly shifted to SSDs. Data centers follow a different demand logic.

Cloud providers and AI companies need high-capacity nearline drives with predictable delivery and low cost per terabyte. For hard drive vendors, these customers usually sign long-term supply agreements and receive higher priority than fragmented consumer channels.

That leads to several effects:

Capacity for high-capacity enterprise drives is locked in early by large customers.
Consumer hard drives and ordinary retail channels receive less supply.
New capacity takes time to come online, so short-term shortages are hard to fix quickly.
Hard drives move from low-attention hardware into part of AI infrastructure.

More importantly, the hard drive industry itself is already highly concentrated. There are only a few mainstream suppliers, and ramping production of advanced high-capacity drives is not as simple as building more factories. Technologies such as HAMR can increase capacity per drive, but moving from technical mass production to stable large-scale delivery still takes time.

Storage Price Increases Can Reach Consumers

AI data centers are not only absorbing GPUs and power. They can also affect the storage supply chain.

When more enterprise SSD, memory, and HDD capacity flows toward cloud providers and AI infrastructure, the consumer market may begin to feel price pressure. Higher retail prices for SSDs, memory, or hard drives are not always just retail volatility. They may come from upstream capacity being reallocated.

This effect is usually not linear. Large customers sign long-term agreements with more stable pricing, delivery, and capacity planning. Consumers are more exposed to spot-market fluctuations. The result is a familiar pattern: rising AI data center demand eventually makes storage devices more expensive for ordinary buyers too.

The Investment View Requires More Caution

AI-driven storage demand is real, but that does not mean every storage-related company will benefit over the long term.

Hard drives and flash memory still have cyclical characteristics. Rising prices, tight capacity, and long-term customer contracts can improve short-term performance. But once new capacity comes online or demand growth slows, the industry may return to supply-demand rebalancing. For hardware companies, the most important questions are not about one price increase, but whether demand can persist, margins can improve, capacity expansion becomes excessive, and the customer mix remains healthy.

A steadier interpretation is that AI is changing the demand structure of the storage industry. In the past, outsiders paid more attention to compute. Now more costs are shifting toward data retention, data governance, and model lifecycle management.

Conclusion

AI does not only consume compute. It also keeps producing data.

GPUs handle computation, HBM feeds data at high speed, SSDs support hot data access, and hard drives carry the enormous cold data base. As long as large model training, synthetic data, inference logs, and compliance retention continue to grow, data centers will need large amounts of low-cost, high-capacity storage media.

Hard drives may not look like the star hardware of the AI era, but they are becoming an indispensable layer of AI infrastructure. The more advanced the model, the more it depends on massive storage systems. The more expensive the compute, the more it needs reliable checkpoints and archives to protect the cost already invested.

How Did AI Agents Evolve? A Complete 2022-2026 Five-Generation Timeline

Sat, 16 May 2026 19:19:52 +0800

AI Agents did not appear overnight.

At the end of 2022, ChatGPT was still mainly a chat window. By 2026, agents had begun to gain tool calling, file operations, computer control, long-term memory, remote collaboration, and persistent execution. In four years, they moved from “models that answer questions” toward “digital workers that can move tasks forward.”

If we look at the timeline, AI Agents have roughly gone through five generations. Each generation solved the previous one’s core limitation, while creating new bubbles and new safety problems.

Overview: five generations of Agents

Stage	Time	Keyword	Capability shift	Core problem
Generation 0	Late 2022 - early 2023	Chat box	Generates text, but cannot act	Model and real world are disconnected
Generation 1	Mid-2023 - late 2023	Tool calling	Outputs structured calls, connects APIs and RAG	Open-loop execution and task drift
Generation 2	Late 2023 - 2024	Engineered workflows	Planning, state, reflection, and multi-agent collaboration	Workflows are easy to copy; low-code bubble
Generation 3	2024 - 2025	Computer Use	Sees screens, clicks, and operates GUIs	Permission, safety, and misoperation risks
Generation 4	2025 - 2026	MCP / Skills / persistence	Tool networks, long-term context, and professional skills	Persistent execution expands the risk radius
Generation 5 preview	After 2026	Loops and world models	Stronger memory, validation, and physical action	Governance becomes harder

Late 2022: Generation 0, the ChatGPT chat-box era

Generation 0 begins with the release of ChatGPT on November 30, 2022.

This generation was not yet a real Agent. It had strong language generation ability, but it was mostly trapped in a chat box. It could write Python code, but not run it on your computer. It could plan a trip, but not book tickets. It could tell you how to edit a file, but not enter the file system and make the change.

Its capability boundary was clear:

understand natural language;
generate articles, answers, code, and plans;
no active access to fresh data;
no stable access to internal company knowledge;
no external action;
no long-term task state.

The core issue was the break between model capability and the real world. It could think and speak, but not act.

This stage also produced the first bubble: prompt engineers, prompt template markets, prompt courses, and prompt certifications. Early models were indeed sensitive to prompts, but the market mistook a temporary patch for a long-term moat.

As GPT-4-level models, system prompts, function calling, and better product defaults matured, many prompt templates lost scarcity. This pattern would repeat: a new capability creates a middle layer; the next generation internalizes it; the middle layer evaporates.

Mid-2023: Generation 1, tool calling wakes up

The keyword for Generation 1 is tool calling.

In June 2023, OpenAI released function calling. Developers could describe function names, purposes, parameter types, and JSON Schema. After understanding a user request, the model could output a structured JSON call instead of ordinary natural language, and an external system would execute it.

The architectural significance was large: the model started moving from a brain that only talks to a brain that can drive external tools.

Key capabilities included:

choosing tools based on user intent;
outputting structured arguments;
calling external APIs;
feeding API results back into the model;
using RAG to access external knowledge;
forming early personas through plugins and knowledge bases.

At the same time, RAG and vector databases became popular. They addressed the model’s lack of fresh information, private enterprise materials, and internal knowledge. The system retrieved relevant document chunks, injected them into context, and let the model answer from those materials.

The basic Agent structure became:

who you are: system prompt and persona;
what you know: knowledge base, RAG, private documents;
what you can do: function calling, plugins, external APIs.

The most dramatic bubble of this generation was AutoGPT. It showed an attractive idea: the user gives a broad goal, and AI breaks it down, searches, writes files, evaluates, loops, and stops when it believes the work is done.

But AutoGPT quickly exposed the problem. It lacked state constraints, stopping conditions, and reliable feedback. Tasks drifted, APIs were called with bad arguments again and again, and bills could be burned by huge numbers of model calls. The lesson was simple: tools plus an infinite loop do not make a production-grade Agent.

Late 2023 to 2024: Generation 2, engineered workflows

AutoGPT’s failure taught the industry that models cannot simply be left to improvise. Complex tasks need structure.

Generation 2 is about engineered workflows. An Agent became not just one model call, but a software system with state, control flow, and evaluation.

Key capabilities included:

task planning: breaking large goals into steps;
state management: tracking where work stands;
reflection and revision: generating, reviewing, and improving;
tool orchestration: switching between tools;
human-in-the-loop: asking for confirmation at key points;
multi-agent collaboration: dividing roles.

A typical pattern is ReAct, or Reasoning + Acting. The model reasons, calls a tool, observes the result, and then reasons again. The Agent no longer acts blindly; each step has auditable logic and feedback.

Common agentic workflow patterns emerged:

reflection: generate, review, revise;
tool use: choose search, databases, code execution, and enterprise APIs;
planning: decompose goals and track state;
multi-agent collaboration: product, developer, tester, reviewer roles.

The value of Generation 2 was putting model capability inside a controllable process. A well-designed workflow can sometimes make a smaller model produce more stable results than a single large-model call.

This generation also produced the low-code Agent platform bubble. Many tools used drag-and-drop interfaces to combine prompts, RAG, plugins, and flows. They lowered the building barrier, but if a workflow can be copied cheaply, the platform itself has a weak moat.

Low-code tools can capture early demand, but a demand window is not a defensible wall.

2024 to 2025: Generation 3, Computer Use reaches real interfaces

The keyword for Generation 3 is Computer Use.

Earlier tool calling relied mostly on APIs. What an Agent could do depended on what developers had connected. But many real-world apps do not have clean APIs, or their APIs are incomplete, closed, or inconsistent.

Computer Use lets models look at screens, click, and operate GUIs. The general computer interface itself becomes a tool.

Key capabilities included:

recognizing screen content;
clicking buttons, typing text, switching windows;
operating web and desktop software;
reading repositories, editing files, running tests;
inspecting terminal output and errors;
behaving more like a real engineering assistant.

This pushed Agents from “using connected tools” toward “operating software like a person.” It also made coding agents closer to real workflows: read a project, change code, run tests, and continue from errors.

But the trust boundary expanded. If AI operates a computer, it can click the wrong button, delete the wrong file, submit the wrong form, or be manipulated by webpage text, documents, and UI instructions. Prompt injection becomes a file-operation, permission, and system-safety problem.

Vibe coding debates also concentrated in this stage. Fast AI-generated projects feel exciting, but without tests, evaluation, permissions, and deployment boundaries, fast prototypes can become fast incidents.

Generation 3’s lesson: the closer an Agent gets to real operations, the more it needs sandboxing, approvals, rollback, and least privilege.

2025 to 2026: Generation 4, MCP, Skills, and persistent digital workers

Generation 4 is about persistence, connection, memory, and specialization.

The focus is not only stronger single tasks. Agents start to have long-term context, tool networks, professional skills, and a sense of time. They become less like helpers in one chat and more like digital workers that can continue working.

MCP addresses tool connection. It lets Agents connect to file systems, databases, browsers, design tools, project management tools, and enterprise systems in a more standardized way. Once the protocol stabilizes, many “tool-connection middle layer” products get compressed.

Skills address professional method. Tools tell an Agent what it can do; skills tell it how to do the work. A good skill is not just a prompt. It packages domain workflows, constraints, checks, common pitfalls, and tool-call order.

Key capabilities included:

long-term memory: storing preferences, project rules, and history;
project context: understanding repositories, docs, and work rules;
tool networks: connecting through MCP, APIs, browsers, and file systems;
professional skills: packaging task methods through Skills;
persistent execution: waiting, waking, reminding, and following up;
remote collaboration: users can return from different devices to approve and steer.

This generation starts to feel like an employee:

identity and responsibility boundaries;
long-term context;
professional work methods;
time awareness;
tool permissions;
ability to continue work without being watched.

But the more it resembles an employee, the more its risk radius resembles an employee’s. Persistent execution, local data access, secrets, tool calls, and task handling move security from the edge to the center.

One point matters especially: text is also an attack surface. If an Agent reads and follows Markdown, documentation, skill packs, or webpages, malicious text can change its behavior. Prompt injection becomes a supply-chain, permission, and execution-safety problem.

Generation 4’s lesson: persistent Agents need governance, not just capability.

After 2026: Generation 5 preview, loops, internal memory, and world models

Generation 5 is not established history yet. It is an extrapolation from the previous four years.

The first direction is more complete closed loops.

A mature Agent needs at least three loops:

execution loop: verify after each action, rollback, revise, and retry if needed;
time loop: track long-term goals across multiple wake cycles;
cognitive loop: know what is certain, what is guessed, and what is outdated.

The second direction is internal memory.

Most memory so far is outside the model: RAG, vector stores, chat logs, local files, and memory.md. If future model architectures support persistent state across sessions, Agent memory systems may be rebuilt.

The third direction is world models.

Many Agents today are still reactive: observe, respond, observe again. High-risk tasks require the model to simulate consequences. Before changing a database script, it should think about data loss, rollback failure, and compatibility issues, not learn only after an accident.

The fourth direction is embodiment.

Earlier generations mainly happened in digital space: APIs, screens, files, browsers, and enterprise tools. The next step may extend Agent action into the physical world, including robots, device control, industrial systems, and standardized physical interfaces.

Generation 5 will need to solve not only how Agents execute tasks, but how they understand consequences, manage long-term state, and stay reliable inside a larger risk radius.

Six patterns behind the timeline

First, base-model capability remains the ceiling. An Agent is not magic outside the model; it is a way to release model capability through engineering systems.

Second, engineered architecture amplifies model capability. Planning, verification, reflection, revision, evaluation, and permission control are closer to deliverable work than one-shot generation.

Third, open protocols reshape value distribution. Once MCP, Skills, and project-context standards stabilize, competition shifts from “who connected the tool first” to “who accumulated real domain capability.”

Fourth, the hidden main line of Agent evolution is expanding human-machine trust. From trusting text, to API calls, to workflows, to computer operations, to persistent execution, each generation pushes the risk radius outward.

Fifth, every generation’s accidents become the next generation’s rules. AutoGPT’s loops pushed structured orchestration; vibe coding failures pushed evaluation-driven development; production deletions pushed least privilege and sandboxing; skill poisoning pushed supply-chain safety.

Sixth, the Agent ecosystem repeatedly booms and collapses. New capabilities create temporary middle layers, and model or platform internalization later removes them. Mistaking a time window for a moat is dangerous.

The real moat

The real moat in AI Agents is not packaging a new capability first.

More reliable moats include three things.

First, vertical depth. Do you truly understand an industry’s workflow, risks, exceptions, and responsibility boundaries? General models can learn concepts, but they may not replace hard-earned domain execution experience.

Second, a data flywheel. Can you collect high-quality feedback from real usage and improve workflows, evaluation, fine-tuning, and product decisions?

Third, user trust. Will users hand you higher-value, longer-running, riskier work, or only treat you as a one-off tool?

If a platform or base model absorbs a capability, the products that still retain process, feedback, responsibility boundaries, and trust are more likely to survive. Many others are temporary bubbles.

Final note

From 2022 to 2026, AI Agent evolution was not “models getting better at chatting.” It was “humans becoming willing to hand more work to AI.”

A mature Agent is not the system most eager to execute automatically. It is the system that knows when to execute, when to verify, when to pause, and when to ask a human.

To judge whether an Agent product has long-term value, ask one question: when the next model or platform builds this capability in, what remains?

If the answer is domain workflow, real data, verifiable results, and user trust, there may be long-term value.

Codex Mobile Remote Access: Use the ChatGPT App to Follow Coding Tasks on Your Mac

Sat, 16 May 2026 17:42:40 +0800

In mid-May 2026, OpenAI brought Codex remote access into the ChatGPT mobile app. The point is not to write code on a phone. It is to let you follow and steer Codex while it keeps working on a Mac.

Think of it as a mobile approval and monitoring surface: Codex still reads the project, runs commands, edits files, and checks test results on the computer; the phone is used to review progress, answer questions, add instructions, and approve actions.

For people who often let Codex run longer tasks, this is useful. You no longer need to sit in front of the Mac waiting for Codex to ask for approval or get stuck.

What it can do

According to OpenAI’s Codex remote connections documentation, mobile access can:

start new threads in projects on the host, or continue existing ones;
send follow-up instructions, answer questions, and steer active work;
approve commands and other actions;
review outputs, diffs, test results, terminal output, and screenshots;
receive notifications when Codex completes a task or needs attention;
switch between connected hosts and threads.

So the mobile app is not just a small chat box. It connects to the actual Codex work context on the host.

Requirements

First, you need Codex access in the ChatGPT account and workspace you want to use. The phone and Mac must use the same account and workspace.

Second, install the latest ChatGPT mobile app on iOS or Android. If Codex does not appear in the app, update ChatGPT first.

Third, the host currently needs to be a Mac that is awake, online, running the Codex App, and signed in to the same account and workspace. OpenAI’s documentation says mobile setup and device control currently require Codex App for macOS; setup is not available from Codex CLI or the IDE Extension.

Fourth, complete any required MFA, SSO, or passkey flow. In a ChatGPT workspace, an admin may also need to enable Remote Control access.

This makes the feature a mobile control layer for Codex App on macOS, not a generic remote desktop or a universal Codex connection for every environment.

Limits of Codex mobile remote access

The feature is convenient, but the limits matter.

First, it currently needs a macOS host. The phone connects to Codex App running on a Mac, not directly to Codex CLI, the IDE Extension, or any Linux / Windows development machine.

Second, the host must stay online. The Mac needs to remain awake, connected to the network, and running Codex App. If it sleeps, loses network access, or closes Codex, the remote session can disconnect.

Third, connection uses a QR-code setup flow. You start Set up Codex mobile on the Mac, scan the QR code with your phone, and finish setup in ChatGPT. It is not a simple “enter host address” flow.

Fourth, remote actions still go through approvals. You can approve commands and actions from the phone, but you should read what Codex is asking to do before confirming, especially for terminal commands, file edits, tests, and external access.

In short, it is for following up after you leave the computer. It is not a full development environment replacement and should not be treated as unattended remote control.

How to connect

Start from Codex App on the Mac:

Open Codex on the Mac.
Select Set up Codex mobile in the sidebar.
Codex enables remote access for this host and shows a QR code.
Scan the QR code with your phone to open the Codex mobile setup flow in ChatGPT.
Confirm the same ChatGPT account and workspace.
Complete any required MFA, SSO, or passkey verification.
After setup succeeds, the Mac appears in Codex on your phone.

After connection, use Settings > Connections in Codex on the Mac to manage connected devices. You can also configure whether the computer stays awake, whether Computer Use is enabled, and whether the Chrome extension is installed.

What the phone is good for

The phone is best for approvals, course corrections, and result review.

Approvals are the obvious case: Codex asks to run a command or continue an action, and you can decide from the phone.

Course correction is just as useful. If Codex misunderstood the task, chose the wrong direction, or hit a failing test, you can send a short instruction and let it continue.

Result review is the third case. You can inspect diffs, test output, terminal logs, and screenshots without returning to the computer.

The value is not “coding on a phone”; it is turning the phone into a small control surface for engineering work that still runs on the host.

Common issues

If the host does not appear on your phone, confirm that Codex App is running on the Mac, Allow other devices to connect is enabled, and both devices use the same ChatGPT account and workspace.

If the approval request does not appear, open the ChatGPT mobile app, go to Codex, scan the QR code again, or restart setup from the host. Workspace users should also confirm that Remote Control access is enabled by an admin.

If the remote session disconnects, check whether the Mac slept, lost network access, or closed Codex App.

If authentication blocks setup, complete MFA, SSO, or passkey prompts first. In enterprise environments, workspace permissions may require admin help.

Best use cases

It fits users who run longer Codex coding tasks, want to approve commands away from the desk, manage multiple projects or threads, and already use a Mac as the main development machine.

It is less useful if you mainly use Windows or Linux, only use Codex CLI or an IDE Extension, expect the phone to be an independent development environment, or work on an unstable network.

My take

Codex mobile remote access is not about moving development to a phone. It is about making the waiting time around Codex more manageable.

Previously, long Codex tasks often stopped at approval, clarification, failing tests, or direction changes. Now those moments can be handled from the ChatGPT mobile app, while the Mac continues to do the actual engineering work.

If you already use Codex heavily on a Mac, this is worth enabling. If you only ask occasional coding questions, the value will be less obvious.

References

What Is ChatGPT File Library? File Storage, Limits, and Privacy Boundaries

Sat, 16 May 2026 17:40:14 +0800

ChatGPT File Library is the file library inside ChatGPT.

Previously, files uploaded to a conversation were mostly useful for that one chat. With File Library, files you upload or files created by ChatGPT can be saved to your account, found later, downloaded, deleted, or referenced again in a new conversation.

This makes ChatGPT feel more like a persistent workspace, not just a temporary chat box.

Latest availability

According to OpenAI’s May 14, 2026 ChatGPT Release Notes, File Library is expanding to Free and Go users, including users in the European Economic Area. OpenAI also added storage management across plans.

One detail matters: the dedicated File storage and Library help page still showed an older availability statement when checked, saying the Library was for Plus, Pro, and Business users outside the EEA, Switzerland, and the UK, and web-only.

Help pages can lag behind release notes. This article follows the newer May 14, 2026 Release Notes: File Library has started expanding to Free, Go, and more regions, but actual visibility still depends on rollout, region, and app version.

What it saves

ChatGPT can save files you upload or create, including:

documents;
spreadsheets;
presentations;
PDFs;
images;
files generated by ChatGPT.

Generated images still appear in the Images tab. File Library is more like a central place to manage uploaded and generated files.

If you often ask ChatGPT to analyze PDFs, organize spreadsheets, create documents, or work with presentations, this reduces repeated uploads and makes reuse easier.

Adding files to a new chat

In supported clients, you can open the attachment or add menu near the composer and choose Add from library, then select a saved file.

The Release Notes also mention Library and Recent files in the composer across Web, iOS, and Android. That means mobile clients can continue using saved or recent files too.

Finding and managing files

On the web, Library is available from the left sidebar. You can review uploaded and generated files, filter by type or source, and manage storage.

The help page lists filters such as uploaded files, generated files, images, documents, spreadsheets, presentations, and PDFs.

Storage management is available from Settings > Storage, and files can also be deleted directly from Library.

Storage by plan

OpenAI’s May 14, 2026 Release Notes list these capacities:

Plan	File Library storage
Free	500 MB
Go	4 GB
Plus	20 GB
Business	20 GB
Pro	100 GB

This storage includes uploaded files and files created by ChatGPT, such as documents, spreadsheets, presentations, and images.

For light users, 500 MB is enough for some PDFs, screenshots, and small documents. Heavy users should treat 20 GB or 100 GB more like a real working library and manage it regularly.

Per-file limits

OpenAI’s help page lists these file limits:

files uploaded to GPTs or ChatGPT conversations can be up to 512 MB each;
text and document files can contain up to 2 million tokens;
CSV or spreadsheet files are usually around 50 MB, depending on row size;
images can be up to 20 MB each.

These are separate from account storage. Even if your account has free space, a single file cannot exceed its own limit.

Deleting and downloading

Files stay in your account until you delete them.

In Library, select a file and use delete or the trash icon. OpenAI’s help page says deleted files are removed from the account immediately and scheduled for permanent deletion from OpenAI systems within 30 days, unless they have been de-identified and disconnected from the account or must be retained for security or legal obligations.

Files can also be downloaded from Library. If you often ask ChatGPT to generate documents, spreadsheets, or presentations, download and cleanup will become normal maintenance.

Temporary Chat does not save files

Files uploaded in Temporary Chat are not saved to your account or Library.

This is important. File Library is designed for reuse; Temporary Chat is better for temporary, sensitive, or one-off tasks where you do not want long-term context.

If a file is only for a quick question and should not be kept, use Temporary Chat. If you will reuse it, Library is more convenient.

Data and training settings

OpenAI’s help page says files and chats follow your settings and data controls.

If Memory is enabled, files and chats may help ChatGPT remember useful information across conversations. For consumer services, if Improve the model for everyone is enabled, OpenAI may use content submitted to ChatGPT, including uploaded files, to improve model performance. This can be turned off in Settings > Data Controls.

File Library is not a local folder. It is a cloud account feature, so think carefully about which documents should be uploaded.

Good and bad use cases

Good fits:

analyzing the same PDFs or reports over time;
reusing course materials, meeting notes, or product documents;
continuing to edit files generated by ChatGPT;
reusing the same source material across conversations;
turning ChatGPT into a lightweight knowledge workspace.

Poor fits:

highly sensitive identity documents, contracts, medical records, or financial statements;
using it as a formal cloud backup;
letting old files accumulate without cleanup;
uploading company internal documents without checking data controls.

My take

The value of ChatGPT File Library is not just a file list. It changes ChatGPT from a one-off chat tool into a workspace with persistent materials.

That also creates new habits: clean up old files, watch storage, distinguish normal chats from Temporary Chat, and review data controls.

If you often use ChatGPT for documents, spreadsheets, and research materials, File Library saves time. If you only upload sensitive files occasionally, be more careful.

References

Running Android Apps on Ubuntu 26.04 LTS: Waydroid Setup and Practical Notes

Sat, 16 May 2026 17:34:59 +0800

On Ubuntu 26.04 LTS, the most practical way to run Android apps is still Waydroid.

Waydroid is not a traditional Android emulator. It runs a LineageOS-based Android system inside a Linux container. The benefit is lower overhead and better desktop integration; the limitation is that it depends heavily on Wayland, kernel features, graphics drivers, and each app’s compatibility.

If you only need to occasionally open an Android utility, test an APK, or run lightweight apps, Waydroid is worth trying. If you want to play heavy mobile games, rely on banking apps, or use Google services heavily, keep expectations modest.

Check whether it fits your setup

Ubuntu 26.04 LTS was released on April 23, 2026. The official desktop requirements include at least a 2 GHz dual-core CPU, 6 GB of RAM, and 25 GB of storage. Waydroid needs additional disk, memory, and graphics resources, so a more comfortable baseline is:

8 GB of RAM or more;
at least 10 GB of free disk space;
a working Wayland session;
recent Intel, AMD, or NVIDIA graphics drivers;
acceptance that some Android apps will not work perfectly.

Waydroid’s documentation also notes that Ubuntu 22.04 and later desktops need a Wayland session. Ubuntu 26.04 LTS defaults more strongly to Wayland, which actually helps here.

Install Waydroid

Install the basic dependencies first:

`1`	`sudo apt install curl ca-certificates -y`

Add the official Waydroid repository:

`1`	`curl -s https://repo.waydro.id \| sudo bash`

Then install Waydroid:

`1`	`sudo apt install waydroid -y`

After installation, you can start Waydroid from the app menu or from the terminal.

Initialize Android

On first launch, Waydroid needs to initialize the Android system image. The default image is usually enough.

If the graphical flow does not appear, start the container manually:

`1`	`sudo waydroid container start`

Then start the user session:

`1`	`waydroid session start`

Open the full Android UI:

`1`	`waydroid show-full-ui`

You should now see an Android tablet-like interface. Apps you install later can be opened inside Waydroid, and some may appear in Ubuntu’s app launcher.

Install APK files

If you already have an APK file, install it directly:

`1`	`waydroid app install app.apk`

List installed apps:

`1`	`waydroid app list`

Launch an app by package name:

`1`	`waydroid app launch com.example.app`

This is useful for F-Droid, open-source tools, test builds, or your own APKs. Avoid random APKs from unknown sources, especially apps that ask for accounts, payments, contacts, or SMS permissions.

Multi-window mode

By default, Waydroid feels more like one full Android window. If you want Android apps to appear as separate desktop windows, enable multi-window mode:

`1`	`waydroid prop set persist.waydroid.multi_windows true`

Restart the session:

1
2

waydroid session stop
waydroid session start

After that, launched apps should behave more like normal desktop windows. The experience still depends on the app, desktop environment, and graphics drivers.

Should you install Google Play?

Waydroid is not the same as a fully Google-certified Android device.

Many users really want Google Play, Google Play Services, and apps that depend on Google’s framework. This can be configured, but it is not a stable production assumption:

Google services involve device certification and account risk checks, so login behavior can change.
Some apps check SafetyNet, Play Integrity, root status, virtual environments, or device fingerprints.
Banking, payment, games, and streaming apps are more likely to fail.

For ordinary tools, prefer F-Droid, open-source APKs, or apps that do not require Google services. That usually fits a Linux desktop better.

Common issues

If the screen is black after launch, first confirm that you are using Wayland rather than X11:

`1`	`echo $XDG_SESSION_TYPE`

You should see:

wayland

If the container is not running:

`1`	`sudo waydroid container start`

If the session is stuck, restart it:

1
2

waydroid session stop
waydroid session start

Check logs if the issue continues:

`1`	`waydroid log`

NVIDIA users may see more graphics-stack issues. Ubuntu 26.04 LTS has better Wayland and NVIDIA support than older releases, but Waydroid is still not a normal native desktop app, so rendering, black-screen, or window problems can happen.

How it differs from emulators and VMs

Waydroid is closer to “Android in a container” than a full virtual machine.

Its strengths are fast startup, low resource usage, and good desktop integration. Its weaknesses are host-system sensitivity, high graphics-stack dependency, and weaker fit for security-sensitive apps.

Traditional Android emulators are better for development testing and device simulation, but they usually use more resources. Virtual machines provide stronger isolation, but graphics acceleration and desktop integration are often worse.

Option	Best for	Main issue
Waydroid	Lightweight apps, APK testing, Linux desktop integration	Google services and some apps are unstable
Android Studio Emulator	Development and device simulation	High resource usage, not ideal for daily users
Virtual machine	Isolated testing and experiments	Graphics and performance are usually weaker

My recommendation

Treat Waydroid on Ubuntu 26.04 LTS as a supplementary tool, not a full Android tablet replacement.

Good use cases:

F-Droid tools;
testing your own or downloaded APKs;
temporarily using an Android app without a Linux version;
keeping a lightweight Android environment on the Linux desktop.

Poor fits:

long-term banking, payment, or securities apps;
heavy mobile games;
apps that strongly depend on Google Play certification;
workflows that need reliable notifications, background services, location, Bluetooth, or camera access.

If you only want to occasionally open Android apps on Ubuntu, Waydroid is the first option to try. It is not perfect, but setup is simple and it matches Ubuntu 26.04 LTS’s Wayland direction well.

References

The U.S. Clears Nvidia H200 Sales: 10 Chinese Companies Approved, but Delivery Is Still Uncertain

Sat, 16 May 2026 17:12:09 +0800

The U.S. export license process for Nvidia H200 sales to China has finally made concrete progress.

According to Reuters-related reports, the U.S. Commerce Department has approved about 10 Chinese companies to buy Nvidia H200 AI chips. The approved list includes major internet companies and supply-chain firms, such as Alibaba, Tencent, ByteDance, JD.com, Lenovo, and Foxconn. However, as of May 14, 2026, H200 chips had still not been delivered to the Chinese market.

This needs to be read carefully: the U.S. side has granted some licenses, but that does not mean the chips have arrived, nor does it mean Chinese companies can immediately deploy them at scale.

What Was Approved

There are three key points in this approval.

First, the U.S. Commerce Department approved about 10 Chinese companies to purchase H200 chips. According to reports, approved customers may buy directly from Nvidia or through authorized intermediaries and distributors.

Second, each approved customer may buy up to about 75,000 H200 chips. If fully delivered, this volume would significantly improve high-end GPU supply for major cloud providers and large-model companies.

Third, Lenovo has confirmed that it is one of the companies that received Nvidia export licenses and is allowed to sell H200 in China. Companies like Lenovo and Foxconn are not only buyers; they may also handle server systems, rack integration, and distribution.

The most important caveat is that a license is not the same as delivery. Public reports emphasize that no H200 shipments to China have been completed yet.

Why H200 Matters

H200 belongs to Nvidia’s Hopper-generation accelerator lineup and is positioned above the H20, which was previously designed for the Chinese market. H20 was a reduced-spec product built to fit earlier export restrictions, while H200 offers stronger compute and memory capabilities.

Public information shows that H200 comes with 141GB of HBM3e memory, making it valuable for large-model training, inference, long-context services, and enterprise AI deployments. It is not Nvidia’s latest Blackwell-generation product, but for Chinese cloud providers and AI companies, it is still a high-end compute resource.

That is why H200 has remained sensitive in U.S.-China AI chip controls. The U.S. wants to limit China’s access to the most advanced AI compute while avoiding a complete loss of Nvidia’s China business. China, meanwhile, wants to reduce reliance on U.S. GPUs and direct more compute investment toward domestic chips and local ecosystems.

It Has Not Really Landed Yet

The easiest mistake is to read “approved to buy” as “supply has reopened.”

Based on current public information, there are still several variables:

U.S. approval is only the first step; orders, review, shipment, and compliance workflows still need to continue.
Whether China will allow actual import and deployment still requires clearer policy guidance.
Whether approved companies place orders immediately depends on price, delivery time, domestic alternatives, and long-term policy risk.
Nvidia may need to re-coordinate H200 capacity because its focus had already shifted to Blackwell and later products.

In other words, H200 sales to China now look more like an opened license window than a supply chain that is already moving chips into Chinese data centers at scale.

What It Means for Nvidia

For Nvidia, the China market remains too important to ignore.

After export restrictions tightened, Nvidia’s share in China’s high-end AI accelerator market was clearly affected. Jensen Huang has repeatedly argued that the U.S. should not casually give up the Chinese market, because doing so would hurt Nvidia’s revenue and weaken the influence of the U.S. technology ecosystem among global AI developers.

If H200 can eventually be delivered, Nvidia can partially recover Chinese customer orders and keep CUDA in Chinese large-model and cloud-computing workflows.

But this business will not return to the old frictionless state. Licenses, quotas, revenue-sharing arrangements, third-party verification, re-export restrictions, and customer identity review may all become long-term costs. For Nvidia, H200 is not just a product sale; it is a way to maintain market presence in a narrow policy corridor.

What It Means for Chinese Companies

For Chinese companies, H200 is short-term compute supply, not long-term certainty.

If approved companies can actually receive H200 chips, large-model training, inference services, AI cloud, agent platforms, and enterprise private deployments will all benefit. Teams already deeply tied to the CUDA toolchain face far lower migration costs with H200 than with a completely new hardware ecosystem.

But policy uncertainty will make companies cautious. Being able to buy H200 today does not mean stable procurement next year. Buying one batch does not mean a long-term expansion path exists. Even if major companies buy, they will likely continue pushing domestic GPUs, heterogeneous compute, inference optimization, and model compression to avoid being trapped again by a single supply chain.

So H200 is more of a buffer for Chinese AI companies than a final solution.

Pressure on Domestic Chips Will Not Disappear

U.S. approval of H200 does not reduce pressure on domestic AI chips. In some ways, it may make competition more direct.

If H200 really enters the Chinese market, domestic chip vendors will face a stronger benchmark in both performance and ecosystem. Customers will compare training stability, inference throughput, memory capacity, software toolchains, cluster communication, and operations cost.

Domestic chips still have room, however. As long as high-end GPU imports remain policy-sensitive, companies will not put their entire long-term compute base on Nvidia. Domestic solutions still have opportunities if they can provide controllable cost, stable supply, and usable software in specific scenarios.

A more realistic pattern may be: high-end training and critical inference continue to seek Nvidia resources such as H200, while large-scale inference, government and enterprise projects, and controllable supply-chain scenarios shift more toward domestic or mixed compute.

How to Read This

The most accurate reading is that U.S.-China AI chip friction has loosened temporarily, but has not returned to full openness.

The U.S. granted licenses to rebalance controls and commercial interests. Nvidia wants to use H200 to return to China’s high-end AI chip market. Chinese companies want stronger compute, but they also need to evaluate import uncertainty and domestic substitution strategy.

The key questions are not only whether the U.S. “allows” the sale, but what happens next:

Whether the first H200 batch is actually delivered to Chinese customers.
Whether approved companies disclose purchase scale and deployment scenarios.
Whether China provides clearer guidance on import, procurement, and usage.

Until those questions land, H200 remains an opened window for the Chinese market, not a fully restored supply chain.

References

How to Protect Hardware from PCB Cloning: From Marking Removal and Potting to Security Chips

Sat, 16 May 2026 16:32:02 +0800

Once a hardware product sells well, teardown, PCB cloning, component substitution, and low-cost copies are hard to avoid completely. A more realistic goal is not to make copying impossible, but to raise the cost, debugging time, and production risk until copying is no longer worthwhile.

Effective protection is not a single trick. It combines components, PCB design, mechanical structure, firmware, supply chain, and service strategy. The following methods can all raise the barrier, but each has a cost. Do not make your own manufacturing and repair process worse just to slow others down.

Removing Chip Markings

Grinding off or removing chip markings is the most common and blunt entry-level method. It prevents a teardown engineer from immediately identifying the main controller, driver, op amp, or power IC.

The advantage is obvious: it is cheap, simple, and quick. The weakness is just as obvious: it stops beginners, not professional teams.

Experienced engineers can infer the chip type from package size, pin count, peripheral circuits, power pins, crystal frequency, communication interfaces, and reference designs. Marking removal mainly increases identification time; it does not truly prevent copying.

PCB Potting

Potting uses resin or adhesive to encapsulate the PCB and components. It is common in power modules, sensor modules, automotive controllers, and industrial control boards.

After potting, tracing circuits, removing parts, and identifying chips become much harder. If the compound is hard and adheres well, forced removal may damage pads, traces, and components.

The tradeoff is heat dissipation, repairability, weight, and process cost. For products that need field repair, full-board potting may hurt you as much as it hurts copycats. It is better suited to high-value, compact modules that rarely need repair.

Dedicated Security Chips

If a product contains algorithms, communication protocols, authorization logic, identity verification, or consumable authentication, dedicated security chips are a more proper protection method.

Common options include authentication chips, encrypted EEPROMs, secure MCUs, and hardware key chips. During boot or critical operations, the main controller must handshake with the security chip and pass challenge-response, key verification, or authorization checks.

The point is not to hide the PCB. The point is that even if someone copies the board, they cannot copy the key material and authentication logic. This is suitable for industrial equipment, consumable authentication, chargers, smart terminals, communication modules, and vehicle devices.

The cost is higher BOM expense, coordination between firmware and hardware, and careful planning for production, provisioning, key management, and service replacement.

Multilayer Precision PCBs

Many people think multilayer boards are only for routing convenience. In practice, multilayer precision PCBs can also raise the reverse-engineering barrier.

For example, 8-layer, 10-layer, 12-layer, or higher-layer boards with inner-layer routing, impedance control, power and ground planes, blind vias, and buried vias are much harder to reconstruct completely.

This is especially true for high-speed signals, RF signals, and boards with strict power integrity requirements. Copying the visible connections is not enough. If the reference planes, impedance, return paths, or stackup are wrong, the clone may suffer from unstable signals, failed EMC tests, communication errors, or poor yield.

The protection logic is not “you cannot copy it.” It is “you may copy it, but you may not be able to tune it into a stable product.”

On ordinary two-layer or four-layer boards, vias are usually visible and traces are easier to follow. Blind vias connect outer layers to inner layers. Buried vias are hidden between inner layers and are not visible from the outside.

When blind and buried vias are combined with multilayer boards, a copier cannot rely only on photos and simple measurements. X-ray, cross-sectioning, layer-by-layer grinding, and scan reconstruction may be required, raising both cost and difficulty.

The downside is also clear: PCB manufacturing cost increases, prototyping takes longer, and the fab must support the process. This is suitable for high-value products, not low-cost products that blindly stack expensive processes.

Uncommon or Custom Components

Some designs deliberately use non-mainstream packages, niche brands, custom part numbers, or components with special parameters. Even if the copier identifies the part, they may not quickly find an equivalent replacement.

This can be useful in analog circuits, power circuits, and sensor front ends where parameters matter. Two parts may look similar on paper, but temperature drift, noise, bandwidth, ESR, linearity, or dynamic response can change the whole product behavior.

But uncommon parts bring procurement risk, lead-time risk, and end-of-life risk. Use them as a local strategy, not at the expense of overall manufacturability.

Using Parasitic Parameters

Some circuits depend not only on schematic resistors and capacitors, but also on PCB trace capacitance, parasitic inductance, coupling, impedance environment, and shielding.

Typical cases include RF circuits, high-speed interfaces, touch sensing, analog front ends, oscillators, and sensor sampling circuits. On the schematic, it may look like a few passive components. In reality, performance may depend on trace length, copper area, distance to ground plane, placement, and shielding structure.

If a copier reproduces the schematic but misses layout details, parameters shift. The result may be reduced sensitivity or complete failure.

This method is subtle but difficult. It also increases your own debugging cost. It is suitable for experienced engineering teams, not for beginners randomly adding mystery behavior.

Reasonable Series Damping on Signal Lines

Adding tens to hundreds of ohms of series resistance on low-current signal lines is common, but it is often misunderstood.

It may look like an ordinary damping resistor, but it can suppress ringing, limit current, adjust timing, change edge rate, match a chip’s input behavior, or improve EMI. If a copier does not understand its purpose and replaces it with 0 ohms or removes it, communication errors, sampling mistakes, or worse EMC may follow.

This design must be technically justified. Do not add resistors randomly for confusion; otherwise your own reliability will suffer first.

Custom Co-Packaged MCUs

For products with sufficient shipment volume, a custom co-packaged MCU can combine the MCU, memory, security unit, analog front end, or even power management into one package.

From outside it may look like an ordinary chip, while internally it is a dedicated combination. Even if a copier knows it is the main controller, they cannot buy the same part. A similar chip may not run the same firmware or peripheral configuration.

This can be powerful, but the threshold is high. It requires supplier support, stable volume, and a longer development cycle. It is not a casual option for small-batch projects.

Address and Data Line Remapping

For memory interfaces, display interfaces, and some parallel buses, remapping address and data lines can increase analysis difficulty.

For example, D0 may not connect to D0, D1 may not connect to D1, and address lines may not be in order. The software or hardware logic already compensates for the mapping. A copier may reproduce the connections but fail to understand the mapping, causing read or display errors.

This also increases your own debugging and maintenance cost. The mapping must be clearly documented internally. Do not protect against competitors by first confusing your own future team.

Decoy Components and Decoy Traces

Decoy components, fake networks, unused test points, no-function pads, and redundant nets can mislead reverse engineers.

This method is controversial. Harmless confusion is acceptable: dummy loads, unpopulated resistor positions, reserved pads, or no-function test points can make a clone harder to tune. Destructive traps should be treated very carefully because they may create legal risk, service risk, and hazards for your own repair or test staff.

A safer principle is to increase copying difficulty without turning the product into an uncontrolled risk source.

Match Protection to Product Value

Not every product deserves every protection method. A low-cost consumer product that blindly adopts high-layer boards, blind and buried vias, potting, and custom chips may lose competitiveness before anyone copies it.

A better approach is to decide what is truly worth protecting:

Core algorithms and authorization logic: consider security chips or secure MCUs.
Valuable analog front ends, RF chains, and sensor interfaces: protect layout, parameters, and tuning know-how.
Generic components that are easy to replace: do not over-hide them.
Protection methods that affect yield and repair: use them carefully.
Uncommon components with supply-chain risk: prepare alternatives.

PCB anti-copy design is not mysticism or simply hiding things. It is an engineering tradeoff among cost, manufacturability, reliability, repairability, and copying difficulty. The best protection is not making the board look mysterious; it is making it hard to copy cheaply, quickly, and reliably even after the physical product is available.

Do Not Push API Keys to GitHub: A Secret-Leak Prevention Guide for AI Coding

Sat, 16 May 2026 16:26:50 +0800

AI coding lowers the barrier to building software, but it also brings many engineering security problems to beginners and non-engineering users.

One of the most common incidents is pushing API Key, Secret, Token, database connection strings, or .env files to a public repository. Locally, these files may look like ordinary configuration that keeps the app running. Once they enter a public GitHub repository, they become credentials that can be scanned, called, and abused automatically.

Secret leaks are not rare. GitGuardian’s 2026 report says public GitHub commits in 2025 contained about 28.65 million new hardcoded credentials, and AI-service credential leaks grew 81% year over year. The issue is no longer just carelessness. AI coding, rapid prototyping, and public hosting are amplifying the scale.

Why Beginners Leak Keys More Easily

Many AI agents and small tools have two “repositories”: one on the local disk, and one visible to the world on GitHub. The problem is that beginners often do not understand the boundary between the two.

During local development, config.json, .env, and settings.yaml may contain API keys. After git add ., git commit, and git push, those files may be uploaded in full. Once a repository is public, scanning bots do not need to understand your business logic. They only need to match a secret pattern.

AI coding makes this worse:

AI-generated examples may place OPENAI_API_KEY = "sk-..." directly in source code.
Beginners often hardcode secrets in frontend code, scripts, or config files just to get the project running.
Many vibe coding platforms can deploy apps directly without going through GitHub push protection.
Users may not know which files, APIs, or default permissions exist inside an AI-generated project.

In short, AI can help you build something that runs faster. It does not automatically take over the security responsibility.

`.gitignore` Is Not Decoration

Git manages version history, GitHub hosts code, and .gitignore tells Git which files should not enter that history.

A basic AI project should at least ignore these:

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

But .gitignore alone is not enough. It only prevents untracked files from being added later. If a secret file has already been committed, adding it to .gitignore will not remove it from history.

A safer habit is:

Create .gitignore at the beginning of a project.
Store API keys only in environment variables or local config.
Provide .env.example with placeholders, not real secrets.
Run a secret scanner before committing, such as gitleaks, trufflehog, or GitHub Secret Scanning.

Deleting the File Is Not Enough

If a key has already been pushed to a public repository, the first reaction should not be “delete the file and commit again.” Revoke or rotate the key first.

Git records history. Even if the latest commit removes the file, old commits, forks, clones, caches, and scanners may still contain it. GitHub’s documentation also recommends revoking or rotating passwords, tokens, and credentials as the first step.

Recommended order:

Revoke the old key in the provider console and create a new one.
Check billing, usage logs, suspicious IPs, and unusual traffic.
Remove hardcoded secrets and switch to environment variables or a secret manager.
Clean sensitive files from repository history with git filter-repo or BFG.
Enable GitHub Secret Scanning and Push Protection.
Check CI/CD, deployment platforms, cloud functions, and frontend build artifacts for the old key.

For OpenAI, Anthropic, DeepSeek, cloud providers, payment services, email services, and databases, a leaked key can lead to more than unexpected bills. It may expose data, enable abuse, affect the supply chain, or get business accounts banned.

Real Secrets Do Not Belong in Frontend Code

Many beginners put API keys into frontend JavaScript because the page works:

`1`	`const apiKey = "sk-xxxxxxxx";`

This is effectively public. Browser code, network requests, source maps, and build artifacts can all be inspected. Any key that must remain secret should not appear on the client side.

The correct approach is to let the frontend call your own backend, and let the backend read environment variables and call the third-party API:

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

Then the server uses the environment variable:

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

This keeps the secret in the server environment instead of exposing it to every visitor.

Vibe Coding Does Not Remove Security Responsibility

Vibe coding is not only a GitHub leak problem. Many apps are published directly from AI coding platforms to the public internet, bypassing traditional code review, repository scanning, and security testing.

Recent RedAccess research found a large number of publicly accessible assets generated or hosted by AI coding tools, some exposing corporate data, personal information, or internal files. The lesson is simple: when “can deploy” becomes too easy, people often forget to ask “should this be public?”, “should this only be internal?”, and “does it have access control?”

Before publishing an AI-generated app, ask:

Does this app really need public access?
Does it have login, authentication, and permission isolation?
Are database URLs, API keys, tokens, or webhook URLs exposed in frontend code?
Are third-party API quota, domain, permission, and expiry limits configured?
Can keys be disabled and deployments rolled back quickly after an incident?

AI-generated code still needs security review. The less code you personally wrote, the less you should assume it is safe.

Checks to Run Now

Start with your own GitHub account. Search your username together with:

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

If you find a real key, rotate first and clean up later. If it ever entered a public repository, treat it as leaked.

For future AI projects, use a fixed process:

Write .gitignore before writing business code.
Use .env.example to document required variables.
Put all secrets in environment variables, not source code.
Give API keys minimal permissions, quotas, and expiry dates.
Enable GitHub Secret Scanning and Push Protection.
Let AI help with a security review before publishing, but do not trust AI alone.

The danger of AI coding is not simply that it may write bad code. It gives many people the ability to publish unsafe apps to the public internet for the first time. Writing fast is not the problem. Handing out secrets, data, and permissions is.

References

Gemini 3.5 Pro Leaks: Google Wants Spark Agent to Win Back the AI Coding Entry Point

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro has not been officially released yet, but leaks around it are already heating up.

The current round of information revolves around several keywords: Gemini 3.5 Pro, the codename Cappuccino, Gemini Spark, AI coding, and MCP tool integration. Together, they point in one direction: Google is not just preparing another chat model update. It wants to reconnect models, tools, Agents, and Google ecosystem entry points.

Before an official release, all of this should still be treated as leaked information. The more important signal is not one screenshot or one benchmark claim, but the gaps Google may be trying to close next.

Why Gemini 3.5 Pro Matters

Based on the exposed information, Gemini 3.5 Pro may be a jump in naming.

People were still discussing Gemini 3.2 earlier, and then Gemini 3.5 Pro appeared in leaks. If the naming is real, Google likely wants to tell a bigger version story in the next release rather than ship a routine minor update.

The leaked highlights mainly fall into three areas:

continued improvements in coding and reasoning;
stronger SVG, interactive page, animation, and 3D generation;
a new Agent product, Gemini Spark, potentially moving to the front stage.

None of these directions is surprising. Gemini has long emphasized multimodality, and Google has very strong distribution channels. The real question is whether it can catch up with OpenAI and Anthropic in developer tools and Agent workflows.

Coding Is The Lesson Google Most Needs To Catch Up On

In 2026, coding is no longer just a model benchmark item. It has become one of the most direct product entry points.

The reason is simple: AI coding tools are used frequently and generate a large amount of feedback data. Developers ask models to read code, modify code, run tests, and fix bugs every day. These interactions naturally push the next generation of models and tooling forward.

Over the past year, Claude Code has gained strong mindshare among developers, while OpenAI has kept strengthening the connection between Codex and ChatGPT. Google has products such as Antigravity, but its external presence has not been as strong.

That is why Gemini 3.5 Pro is being watched closely. If it only becomes better at chatting or answering faster, the impact is limited. If it truly improves code understanding, cross-file editing, tool calling, and long-running task execution, it may change developer workflows.

Gemini Spark May Be The Bigger Variable

More aggressive than the model itself is the rumored Gemini Spark.

According to the leaks, Spark is not positioned as a normal chat assistant, but as an always-on AI Agent. It may connect to email, calendars, web pages, tasks, account state, and personal context to help users handle multi-step workflows.

This kind of product has a large imagination space. For example:

automatically organizing an inbox;
following up on tasks for the user;
performing actions on web pages;
handling cross-application workflows;
arranging daily matters based on personal preferences.

But the risks are just as obvious. If an always-on Agent can access login state, browser data, files, location, and third-party services, it must answer several questions: when must the user confirm an action? Which operations must be blocked from automation? Will data be shared with third parties? How are remote browsers and credentials isolated?

So the real question for Spark is not just whether it can get work done. It is whether Google can make permissions, auditing, confirmation flows, and user control clear enough.

What MCP Tool Integration Suggests

The leaks also mention that the new Gemini selector may include MCP-related models or testing entries.

If this ships, it suggests Google is also pushing models from a question-answering system toward a tool operating system. The model will no longer only generate text. It will need to call external tools, access business systems, read and write files, run commands, and maintain task state across multiple steps.

This direction is consistent with OpenAI and Anthropic. Whoever makes tool calling more reliable will have an easier time embedding AI into real workflows.

But MCP integration itself is not the finish line. The hard part is stability:

can the model choose the right tool;
are the parameters reliable;
can it recover after failure;
are permission boundaries clear;
can users trace every step.

If these questions are not solved, more tools also mean a larger surface for mistakes.

Multimodality Is Still Google’s Strong Card

The place where Google has the best chance to differentiate is still multimodality.

Based on exposed SVG, interactive page, animation, and visual generation examples, Gemini may continue to strengthen its ability to generate interactive content from prompts. Compared with simply writing a piece of code, this is closer to product prototyping: the user describes an idea, and the model directly produces an operable, adjustable, previewable interface.

This path fits Google well. It can build on Gemini’s multimodal strengths and also connect with Android, Chrome, Workspace, Search, Ads, and Cloud.

If Google wants to avoid competing only on “whose coding model is stronger”, it may put more emphasis on a more complete multimodal Agent system.

The Three Companies Are Splitting Into Different Playbooks

The current model race is no longer just a leaderboard race.

OpenAI’s advantage lies in product iteration and distribution speed. Codex, ChatGPT, enterprise tools, and APIs are becoming more tightly connected.

Anthropic’s advantage lies in developer mindshare and code model quality. Claude Code has already become the default AI coding entry point for many people.

Google’s advantage is ecosystem access. Gmail, Docs, Chrome, Android, Search, YouTube, Maps, and Cloud services form a huge personal and enterprise data network. If Agents can safely connect to these entry points, Google may move from a “model chaser” to a “workflow entry point controller”.

That is why Gemini Spark is worth watching. It does not necessarily need to rank first on every benchmark. If it enters daily workflows, it may still build its own moat.

How Regular Users Should Read This

For regular users, there is no need to be pulled around by every leak in the short term.

The more practical things to watch are:

Whether Gemini 3.5 Pro’s coding ability truly improves, especially in complex repositories, long context, and tool calling.
Whether Gemini Spark is safe by default, with clear confirmation and traceable records before sensitive operations.
Whether Google gives clear pricing, quotas, and enterprise permission management, rather than only showing demos.

Pretty screenshots alone do not mean much. Whether it can reliably enter real workflows is the dividing line for this round of AI Agent products.

What It Means For Developers

Developers should care less about “which model won” and more about whether their workflow is portable.

Claude Code, Codex, Gemini, Antigravity, Cursor, Windsurf, and many other tools are all competing for the entry point. If every process is locked into one platform, future changes in cost, quota, model policy, or permission rules will make migration painful.

A safer approach is:

keep standard Git workflows for important projects;
always inspect diffs after automated edits;
use tests and CI as backstops for key tasks;
do not hand production credentials to opaque Agents;
when open protocols can connect tools, prefer replaceable options.

Models will keep getting stronger, but engineering discipline will not become obsolete.

Summary

The Gemini 3.5 Pro leaks suggest that Google is accelerating its effort to catch up in AI coding and Agent entry points. Model improvements are only one part of the story; always-on Agents such as Gemini Spark may be the larger strategic move.

But the more a system can “do things automatically” for users, the more it needs strict permission boundaries and verifiable workflows. For Google, the real challenge is not only catching up with GPT-5.5 or Claude. It is combining strong models, safety mechanisms, and ecosystem entry points into a trustworthy daily workflow.

If Google pulls that off, Gemini may not need to top every leaderboard to regain some initiative in AI entry points.

Claude Code + Ollama Local Deployment Guide: Build a Free AI Coding Assistant with CC Switch

Fri, 15 May 2026 23:27:50 +0800

Claude Code has become a popular AI coding assistant recently. Its appeal is not just that it can chat about code, but that it can read a project, modify files, run commands, install dependencies, and keep fixing errors in an agent-like workflow.

The hard part is cost. Once a project grows, long context and repeated agent turns can burn through API quota quickly. If you just want to experiment, refactor small utilities, generate scripts, or work on a private local project, it is natural to ask: can Claude Code’s workflow be kept while the model runs locally?

The key tool in this setup is CC Switch. It lets Claude Code connect to the local Ollama service through an OpenAI-compatible API endpoint, so requests can be forwarded to a local model instead of the official Claude API.

What This Setup Solves

You can think of the whole setup as:

1
2
3

Claude Code desktop
+ CC Switch API forwarding layer
+ Ollama local model

Claude Code is still responsible for the coding workflow and project operations. CC Switch handles model provider configuration and API compatibility. Ollama runs the model locally.

This does not make a local model suddenly become Claude. Its real value is that it makes Claude Code’s agent workflow usable in lower-cost, offline, and private local scenarios.

Basic Preparation

Before you start, prepare these pieces:

Install Git.
Install Ollama.
Pull a local model suitable for coding.
Install CC Switch.
Have Claude Code available on your machine.

For the model side, you can start with coding-oriented models, such as Qwen Coder, DeepSeek Coder, or other models with decent tool-calling and code generation behavior. The larger the model, the better the result may be, but memory and GPU pressure will also rise.

If your machine only has limited memory, start with a smaller model first. Confirm that the workflow runs smoothly before trying a larger one.

Key CC Switch Configuration

After Ollama starts, its default local API address is usually:

`1`	`http://127.0.0.1:11434/v1`

In CC Switch, choose an OpenAI-compatible provider type, commonly:

`1`	`OpenAI Chat Completions`

Then point the base URL to Ollama’s local address.

For the API key field, local Ollama normally does not need a real key, but many tools still require an environment variable or placeholder. You can use:

`1`	`ANTHROPIC_API_KEY`

or another placeholder variable accepted by your local setup.

One configuration item is worth special attention:

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

This means mapping Claude Code’s expected model roles to the local provider. In practice, you need to bind haiku, sonnet, and opus to the model names exposed by Ollama or CC Switch. If this mapping is wrong, Claude Code may fail to call the model or may keep falling back to an unexpected configuration.

Where Claude Code Is Strong

Claude Code’s biggest advantage is not raw completion. It is the full coding workflow:

reading and understanding project structure;
locating related files based on a task;
editing code directly;
running commands and tests;
observing errors and iterating;
completing multi-step tasks in one session.

This is why many people want to keep Claude Code even when switching to a local model. A normal chat UI can generate code snippets, but it does not naturally operate inside a repository. Claude Code is closer to an executable development assistant.

What Role Ollama Plays Here

Ollama is responsible for local model runtime and management. It handles model downloading, loading, and local inference.

The advantage is clear: requests stay on your machine, repeated use does not create API bills, and you can use it when the network is limited. For private code, this is also easier to accept than sending every context window to a cloud model.

The trade-off is also clear. Local models depend heavily on your hardware and on model quality. A smaller model can handle simple edits, explanations, and script generation, but it may struggle with large cross-file refactors or subtle architectural decisions.

Where The Experience Has Boundaries

This setup should not be treated as a full replacement for Claude’s strongest cloud models.

You may run into these issues:

weaker long-context understanding;
unstable tool-calling behavior in complex tasks;
slower inference on CPU-only machines;
more hallucinated file paths or APIs;
less reliable multi-round planning;
lower success rate on large repository refactors.

So the better expectation is: use it as a free local development assistant, not as a perfect substitute for a top-tier cloud model.

Multimodal Compatibility Is Still Unstable

Some users want Claude Code to handle screenshots, UI images, diagrams, or other multimodal inputs. This part depends on the local model and the forwarding layer.

If the selected Ollama model does not support vision, or CC Switch does not translate the request format correctly, multimodal features may fail. Even with a vision model, behavior may differ from Claude’s official API.

For now, this setup is more suitable for text and code workflows. Treat multimodal support as experimental.

Who Should Try It

This setup is suitable for:

developers who want to try Claude Code’s workflow at low cost;
users who frequently write scripts, small tools, and automation snippets;
teams that want to keep code on local machines;
learners who want an AI coding assistant without constant API spend;
people testing different local coding models.

It is less suitable if you rely heavily on long context, large monorepos, strict code review quality, or complex full-project refactors.

Usage Advice

Start with small tasks.

For example:

explain a single file;
refactor a small function;
generate a shell script;
fix a simple error;
add a small feature;
write unit tests for a narrow module.

After each change, run tests or at least review the diff yourself. A local model can be useful, but you should not blindly accept every generated edit.

If the model keeps losing context, reduce the task scope. Instead of asking it to “refactor the whole project”, ask it to “refactor this function” or “add validation in this file”.

Summary

Claude Code + CC Switch + Ollama is an interesting combination. It keeps Claude Code’s agent-style development workflow while moving inference to a local model.

Its biggest strengths are lower cost, local privacy, and a smooth development workflow. Its limits are also obvious: model quality, hardware performance, long context, and tool-calling stability all affect the final experience.

If you already use Ollama and want a more practical local AI coding workflow, this setup is worth trying. Just remember to start small, verify every change, and treat the local model as an assistant rather than an automatic engineer.

How to Check CVE-2026-42945: Nginx Rift Trigger Conditions, Version Checks, and Upgrade Advice

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 is a security vulnerability in NGINX Open Source and NGINX Plus. It is also being referred to as Nginx Rift. The issue is in ngx_http_rewrite_module, and the vulnerability type is heap-based buffer overflow.

News like this is easy to turn into headlines such as “hidden for 18 years”, “remote control without a password”, or “30% of servers affected”. Those claims travel well, but when reading the patch notes and NVD description, it is better to separate the risk into concrete pieces: the issue is serious, and it does not require a logged-in account; but not every Nginx instance is automatically compromised. Triggering it requires specific rewrite configuration and request conditions.

Start with the official description

The NVD description of CVE-2026-42945 can be summarized as follows:

It affects NGINX Plus and NGINX Open Source.
The vulnerability is in ngx_http_rewrite_module.
The issue may be triggered when a rewrite directive is followed by a rewrite, if, or set directive, unnamed PCRE capture groups such as $1 and $2 are used, and the replacement string contains a question mark ?.
An unauthenticated attacker can send a crafted request to trigger the vulnerability.
The result may be a heap buffer overflow and restart of an NGINX worker process.
If ASLR is disabled on the system, code execution is possible.

F5, as the CNA, gives the following scores:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

So this is not a routine “bad config causes a 404” issue. It is a memory safety vulnerability covered by an official Nginx security fix.

Which claims need context

First, “no password required” is best understood as unauthenticated attack. In other words, the attacker does not need to log in to an Nginx admin panel, obtain SSH access, or hold an application account. But that does not mean every public-facing Nginx instance can be casually taken over.

Second, “direct remote control” depends on conditions. The more careful official framing is that the vulnerability can cause worker process restarts; on systems where ASLR is disabled, code execution is a possible outcome. On environments with ASLR enabled, proper distribution hardening, and restricted runtime privileges, the exploitation path becomes more complex.

Third, “30% of servers affected” should not be treated as “all Nginx market share equals exposed attack surface”. Real exposure depends on the version, whether the affected module is present, whether the specific rewrite configuration exists, whether the distribution has already backported the patch, and how hardened the Nginx runtime environment is.

The more accurate approach is simple: if you run Nginx in production, check it quickly; but do not decide whether you are affected based only on a headline percentage.

How to determine the affected scope

According to nginx.org release information, the nginx-1.30.1 stable release and nginx-1.31.0 mainline release published on May 13, 2026 include multiple security fixes, including the ngx_http_rewrite_module buffer overflow tracked as CVE-2026-42945.

If you use official Nginx source builds or official packages, focus on:

NGINX Open Source stable: upgrade to 1.30.1 or later.
NGINX Open Source mainline: upgrade to 1.31.0 or later.
NGINX Plus: check the fixed version for your F5-supported branch.

If you use Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, container images, Plesk, control panels, Ingress Controller, or cloud-provider managed components, do not rely only on the upstream version shown by nginx -v. Many distributions backport security fixes into older package versions. The version string may look old while the patch is already included.

One-minute urgency check

Use these questions for a quick risk tiering:

Is this Nginx instance directly exposed to the internet, or is it part of an API Gateway, reverse proxy, load balancer, or Ingress entry layer?
Are you using official Nginx packages, source builds, third-party control panels, or container images without having confirmed the CVE-2026-42945 fix status?
Does the configuration contain complex rewrite rules, especially consecutive rewrite, if, or set directives and unnamed captures such as $1 and $2?
Does any rewrite target include request paths, query parameters, or other user-controlled input?
Is the system weakly hardened, for example with ASLR disabled, overly privileged workers, or overly broad container permissions?

If the first two items apply and rewrite configuration has not yet been reviewed, treat it as high priority. Public entry points, shared environments, Kubernetes Ingress, edge proxies, and Nginx instances carrying login or API traffic should be upgraded or replaced with a confirmed fixed package first.

How to confirm fixes on Debian / Ubuntu / RHEL / Alpine

Distribution users should not look only at nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, and Alpine often backport security patches into stable branches, so the visible version may still be lower than nginx.org’s 1.30.1 or 1.31.0.

On Debian / Ubuntu, check security advisories, package changelog, and upgrade candidates:

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

On RHEL / AlmaLinux / Rocky Linux, check security updates and package changelog:

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

On Alpine, check the installed package version and security branch updates:

1
2

apk info -v nginx
apk version -v nginx

If the package manager, distribution security advisory, or vendor advisory explicitly says CVE-2026-42945 is fixed, you can treat it as backported even if the upstream version number looks old. Conversely, if the version looks new but the source is unclear, still confirm the build date and patch source.

How to check container images and Ingress Controller

In container environments, check the Nginx inside the image, not only the host. First confirm the actual embedded version:

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

Also check whether the base image has been updated. If the image is built on Debian, Ubuntu, Alpine, or distribution packages, apply the same advisory and changelog checks for that distribution. Restarting an old image is not useful; the image itself needs to be rebuilt or replaced.

For Kubernetes Ingress, confirm three things:

Whether the Ingress Controller project has published an advisory or fixed release for CVE-2026-42945.
Whether the running controller image digest has actually changed, rather than only the tag.
Whether the controller’s embedded Nginx version, build flags, and template configuration still contain high-risk rewrite rules.

Start by checking the running image:

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

If you use a cloud-provider managed Ingress or gateway, check the corresponding cloud service advisory. Managed components usually cannot be fixed by running apt upgrade yourself; you need the provider’s fix or a switch to a fixed version.

Which rewrite patterns deserve attention

This vulnerability is related to rewrite configuration. Start by searching Nginx configuration:

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Pay attention to patterns like:

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

The unnamed captures such as $1 and $2, plus the ? in the replacement target, are among the key conditions described by the official sources. During review, pay special attention to:

A rewrite followed by another rewrite, if, or set.
Broad captures such as (.*) and (.+) that are reused as $1 or $2.
Rewrite targets containing ? to append or discard query parameters.
Rewrite input coming from public paths, Host, URI, parameters, or upstream-controlled values.
Rewrite rules generated by panels, gateways, Ingress annotations, or templates.

If you cannot upgrade immediately, use temporary mitigations:

Reduce complex rewrite rules.
Replace unnamed captures with clearer named captures.
Avoid unnecessary ? concatenation in replacement strings.
Add WAF or reverse-proxy rules for high-risk entry points.
Confirm that ASLR is enabled.
Reduce Nginx worker privileges and verify systemd sandboxing, SELinux/AppArmor, and related hardening.

These measures are mitigations, not replacements for patching.

Remediation priority

Prioritize by exposure:

Public-facing Nginx entry points.
Reverse proxies, API Gateway, and edge gateways.
Nginx in multi-tenant environments.
Kubernetes Ingress Controller.
Plesk, control panels, marketplace images, and other components that bundle Nginx.
Internal Nginx instances that carry critical business traffic.

How to verify after upgrading: nginx -t, reload, and worker state

After updating, do not stop at “the package manager succeeded”. Confirm the configuration, process state, and actual binary have all switched over. First validate the configuration:

`1`	`nginx -t`

If there are no errors, reload smoothly:

`1`	`systemctl reload nginx`

If the package upgrade replaced the binary, confirm old workers have exited:

`1`	`ps aux \| grep nginx`

You can also inspect the master process start time and binary path to ensure the running service is not an old process still resident in memory. If needed, schedule a maintenance window and restart the service so old workers or old containers do not continue handling requests.

For containers and Ingress, also confirm the new image rollout has actually completed:

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

The key verification question is not “did the command run”, but “is live traffic now handled by Nginx processes that include the fix”.

Do not ignore the same Nginx security batch

The 1.30.1 and 1.31.0 releases published by nginx.org on the same day fixed more than CVE-2026-42945. The release information also mentions HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free, and other issues.

That means production environments should not only add a temporary rule for a single CVE. Treat this Nginx security release as an overall upgrade.

Summary

The key point of CVE-2026-42945 is not “all Nginx instances can be instantly taken over”. It is a long-standing memory safety vulnerability in the rewrite module that can be triggered by unauthenticated requests under specific configurations. The most direct result is worker crash and restart; on weaker environments such as systems with ASLR disabled, code execution risk is higher.

For operations teams, the handling order is straightforward:

Confirm the Nginx source and version.
Check distribution, F5, nginx.org, or cloud-provider advisories.
Upgrade to a fixed version or distribution security package as soon as possible.
Review complex rewrite configuration, especially combinations of $1, $2, and ?.
Confirm ASLR, privilege isolation, and service reload state.

The headline can be scary. The fix should be calm: confirm exposure, upgrade, then clean up high-risk rewrite rules.

References

OpenHuman Quick Read: The Desktop Route for an Open-Source Personal AI Agent

Fri, 15 May 2026 14:52:31 +0800

OpenHuman is an open-source personal AI Agent project from tinyhumansai. Its goal is not to build yet another chat window, but to place a desktop app, personal memory, third-party integrations, voice, coding tools, and a local knowledge base into the same agent harness, so AI can understand your daily work context faster.

The project README positions it as “Personal AI super intelligence,” and the official site emphasizes private, simple, and extremely powerful. That claim is ambitious, but it is more useful to break it down: the part of OpenHuman that deserves attention is its attempt to make “personal context” the product core, instead of leaving model calls, plugin configuration, and document retrieval for users to assemble themselves.

At the time this article was checked, the GitHub repository had about 7.8k stars and 629 forks. The latest release was OpenHuman v0.53.43, dated May 13, 2026. The project is still in Early Beta, and the README clearly warns that it is under active development, so rough edges should be expected.

What Problem Is It Trying to Solve?

The problem with many AI assistants is not that the model is too weak, but that the context is too cold. Every time, you have to explain the project background, recent emails, calendar, code repositories, documents, tasks, and preferences again. Once you move across Gmail, Notion, GitHub, Slack, Calendar, Drive, Linear, Jira, and similar systems, the information is scattered across different tools.

OpenHuman’s approach is to connect those data sources first, then use automatic fetching, compression, summarization, and a local knowledge base to build a personal memory layer that can keep updating. The agent then remembers more than the current conversation; it can form long-term context around your workflow.

This is also the biggest difference between it and a normal chatbot. Chatbots often work around prompts; OpenHuman is closer to a desktop personal operating-system entry point, trying to prepackage connectors, memory, tools, and model routing.

Main Capabilities

Core capabilities listed in the OpenHuman README include:

A desktop-first UI and a short onboarding path, without requiring users to start from terminal configuration.
A desktop mascot with a “face” that can speak, respond to the environment, and participate in Google Meet.
118+ third-party integrations covering Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira, and other tools.
An automatic fetching mechanism: the project description mentions traversing active connections every 20 minutes and pulling new data into the memory tree.
Memory Tree: compresses connected data and activity information into Markdown blocks and stores them in local SQLite.
Obsidian-compatible vault: writes knowledge blocks as .md files so users can open, browse, and edit them with Obsidian.
Built-in search, web scraping, coding tools, file system access, git, lint, test, grep, voice input and output, and other capabilities.
Model routing: routes requests to different model types according to the task.
TokenJuice: compresses token usage before tool results, web pages, email bodies, and search results enter the LLM.
Optional Ollama support for local AI workloads.

These capabilities sound broad, but the real focus can be reduced to two points: reducing configuration and plugin assembly, and turning your personal data into memory that an agent can search, compress, and continuously update.

Installation

The project provides a website download entry point and terminal installation commands.

macOS or Linux x64:

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows:

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

If this is your daily primary machine, it is better to download the installer from the official site first, or at least open and inspect the install script before deciding whether to execute a remote script directly. OpenHuman touches email, documents, code repositories, calendars, and local file permissions, so installation and authorization deserve more caution than a small ordinary utility.

Open Source and Technical Stack

The OpenHuman repository uses the GPL-3.0 license. The language breakdown shows Rust as the main language, followed by TypeScript, with JavaScript, Shell, CSS, and PowerShell also present. The README’s contribution notes require Node.js 24+, pnpm 10.10.0, Rust 1.93.0, CMake, and platform-specific desktop build dependencies.

The rough local development path is:

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

Before submitting changes, focused checks are recommended, for example:

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

Judging from the repository structure, this is not a lightweight script project. It is a full product-style repository containing a desktop app, frontend, Rust backend, docs, tests, examples, and build scripts.

Why Memory Tree and the Obsidian Vault Matter

The concept most worth examining in OpenHuman is Memory Tree. The README says it standardizes connected data into Markdown chunks of up to about 3k tokens, scores them, folds them into a hierarchical summary tree, and stores them in local SQLite. The same content also enters an Obsidian-compatible vault.

This route has several advantages:

Users can directly see the agent’s knowledge base instead of only trusting black-box memory.
Markdown files are convenient for search, backup, version control, and manual revision.
SQLite is suitable for local indexing and fast queries.
Hierarchical summaries are better suited to long-term context compression than a flat pile of documents.

But it also has practical challenges: whether data sync is stable, whether summaries drop key details, whether permission boundaries are clear enough, whether deletion and undo are complete, and whether different connectors’ semantics can be handled consistently. These are not solved by one README phrase like “remembers everything”; they require long-term use and auditing.

TokenJuice: A Middle Layer for Cost and Latency

OpenHuman also emphasizes TokenJuice. Its role is to compress web pages, emails, search results, and tool-call results before they enter the model. Examples include converting HTML to Markdown, shortening long URLs, and removing some unnecessary characters. The README claims this can reduce cost and latency, with up to 80% lower token usage.

The direction is reasonable. In agent systems, the truly expensive part is often not one chat turn, but background fetching, tool calls, search, web parsing, and long-context injection. Cleaning data before handing it to the model is usually steadier than directly stuffing raw content into context.

However, a compression layer also creates new questions: it decides which information is kept and which is discarded. If you use it for contracts, bills, medical records, compliance material, or production incident logs, you cannot look only at token savings. You also need traceability, original-text review, and compression-error control.

Privacy: A Selling Point and an Audit Focus

One of OpenHuman’s selling points is privacy. The official site mentions that local AI models can handle low-level tasks, and the README emphasizes that workflow data stays on device, is encrypted locally, and is treated as yours.

This design direction is attractive because once a personal AI Agent connects to Gmail, Drive, Calendar, Slack, and GitHub, it touches the most sensitive work data. Compared with a fully cloud-based assistant, a local-first memory layer and a visible Markdown vault at least give users more sense of control.

But the full picture matters: OpenHuman also mentions one subscription, 30+ providers, model routing, ElevenLabs TTS, OAuth integrations, and other capabilities. That means it is not a purely offline tool. To evaluate privacy seriously, you need to check what each connector, each kind of model call, and each voice or search capability sends, and where it sends it.

Who Should Pay Attention?

OpenHuman is currently more suitable for three groups:

Users who want a personal AI control desk rather than a single-purpose chatbot.
Developers willing to try an Early Beta and accept changing features and rough edges.
People interested in local memory, Obsidian workflows, agent connectors, and context compression.

If you only want a stable, lightweight offline assistant with very simple privacy boundaries, it may be too heavy right now. If you want to study how the next generation of personal AI Agents might integrate desktop apps, connectors, memory, and tools, OpenHuman is an open-source sample worth tracking.

My suggestion is to first treat it as a “product-style open-source experiment”: watch release cadence, issue quality, connector permissions, data export capability, deletion mechanisms, and readability of the local vault. The key question for personal AI is not only whether it can answer questions, but whether it can carry your context for the long term in a transparent and controllable way.

References

Ghostty Docs Quick Read: Installation, Configuration, and Daily Usage Notes

Fri, 15 May 2026 14:50:11 +0800

Ghostty is a new terminal emulator, but it is not simply “another faster terminal.” According to its official documentation, it tries to balance three goals at the same time: speed, features, and a native desktop experience. In other words, it wants GPU acceleration and solid rendering performance, while also feeling like a real local app on macOS and Linux instead of pushing every interaction into a custom-drawn interface.

If you currently use iTerm2, Kitty, Alacritty, WezTerm, or the system terminal, the most interesting part of Ghostty is not one isolated feature. It is the way it combines “works out of the box” with “deeply configurable.” The default configuration is already usable, but when you want to tune it further, the docs provide complete entry points for configuration files, themes, keybindings, fonts, Shell integration, and terminal control sequences.

Start with the Positioning

Ghostty’s core positioning can be summarized in three points:

It is a cross-platform terminal emulator, currently focused on macOS and Linux.
It uses platform-native UI: Swift, AppKit, and SwiftUI on macOS; Zig and GTK4 on Linux.
Its terminal core is libghostty, and the GUI applications are built around this shared core.

This design affects daily use. Tabs, splits, error prompts, window state restoration, system shortcuts, and similar features are not merely components that “look like a desktop app.” They try to follow the interaction conventions of each operating system. The default shortcuts on macOS and Linux also differ according to platform expectations.

Installation: Direct on macOS, Distribution-Dependent on Linux

The official prebuilt binaries mainly target macOS. The most common installation path is to download the .dmg, open it, and drag Ghostty into the Applications folder. Homebrew users can also use the community-maintained cask:

`1`	`brew install --cask ghostty`

Linux is more fragmented. The Ghostty docs separate package managers, community binaries, and source builds for different distributions. Arch, Alpine, Gentoo, NixOS, Snap, Solus, Void, and others all have their own paths. If a distribution has no official or trusted repository, the docs lean toward building from source rather than casually installing third-party binaries.

This matters especially on servers and workstations: a terminal emulator handles a large amount of input and output, clipboard data, links, SSH sessions, and local file paths. It is better to be conservative with the installation source, preferring the official macOS package, distribution repositories, or a build process whose source you can audit.

Configuration: Do Not Rush to Copy a Giant dotfiles Setup

Ghostty’s configuration philosophy is “usable with zero configuration.” The default font includes JetBrains Mono and Nerd Font support, so most users can work normally the first time they open it. The docs even suggest that if you must configure a non-subjective option to feel comfortable, it may be worth asking whether that behavior should become the default.

When you do need customization, Ghostty uses a text configuration file. The current configuration file name is config.ghostty, while older versions also support config. Common paths include:

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

On macOS, Ghostty also reads:

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

The syntax is straightforward: key = value. For example:

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

A practical suggestion: do not start by copying someone else’s full configuration. A steadier approach is to run it bare for a few days and change only three things at first: font family, font size, and theme. Once you actually feel friction around shortcuts, splits, windows, or Shell integration, add those settings one by one.

Documentation Lookup: Full Configuration Reference Is Available Locally

Ghostty has many configuration options, and the official docs collect them in the Option Reference. Besides the web page, you can query the reference locally after installation:

`1`	`ghostty +show-config --default --docs`

This command prints the default configuration and documentation to standard output, which is useful when piped into a pager:

`1`	`ghostty +show-config --default --docs \| less`

To list available fonts:

`1`	`ghostty +list-fonts`

To list built-in and available themes:

`1`	`ghostty +list-themes`

To view default keybindings:

`1`	`ghostty +list-keybinds --default`

These commands are more reliable than copying snippets from the web, because they come from the Ghostty version installed on your own machine.

Keybindings: Treat “Actions” as the Core Concept

Ghostty’s keybinding format is:

`1`	`keybind = trigger=action`

trigger is the key sequence, and action is the operation Ghostty performs. Creating a new tab, closing the current surface, reloading configuration, and jumping to a prompt are all actions. The model is clear: you are not “changing a menu item”; you are binding an input sequence to an action.

After changing configuration, you can reload it at runtime. The default shortcut is:

Linux: ctrl+shift+,
macOS: cmd+shift+,

Not every setting takes effect immediately. Some options only affect newly created terminals, while others require a full restart. If “the config is written but nothing changed,” check the documentation for that option before spending too much time suspecting syntax.

Themes and Fonts: Use Built-Ins First, Then Tune

Ghostty ships with many themes and supports switching themes according to the system light or dark mode:

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

Themes can also come from custom files. The docs are clear here: a theme file is essentially a Ghostty configuration file and can set many options, so do not casually use themes from untrusted sources.

For fonts, font-family can be repeated to specify fallback fonts. This is useful in multilingual environments: the primary font can handle English and symbols, while later fonts cover Chinese, Japanese, or other characters. When you encounter display details such as emoji, bold, italic, or ligatures, look up the corresponding options in the Option Reference.

Shell Integration: Especially Important for SSH Users

Ghostty supports automatic Shell integration injection for bash, elvish, fish, nushell, and zsh. When enabled, several interactions become more natural:

New terminals can open in the previous terminal’s working directory.
Complex prompts can redraw correctly after resize instead of reflowing badly.
You can jump between command outputs using prompt markers.
Cursor behavior at the prompt can better match editing habits.

If you do not want automatic injection, disable it in the configuration:

`1`	`shell-integration = none`

SSH deserves extra attention. Ghostty uses xterm-ghostty as TERM, but many remote hosts do not yet have the corresponding terminfo. The docs provide two Shell integration features, ssh-env and ssh-terminfo, which are disabled by default and can be enabled as needed:

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

If you often connect to old servers, containers, bastion hosts, or tightly managed production environments, read the official Terminfo and Shell Integration docs before enabling these features. Terminal capability negotiation looks minor, but when it goes wrong, the symptoms can be strange colors, broken shortcuts, or garbled full-screen programs.

My Suggested Onboarding Order

If you only want to judge whether Ghostty fits you, try this sequence:

Install it and use it for a day without writing any configuration.
Adjust only font-family, font-size, and theme.
Use ghostty +list-keybinds --default to inspect default shortcuts instead of importing someone else’s shortcut table first.
If you use SSH often, check remote host terminfo compatibility early.
Finally, tune splits, windows, transparency, title bar, background image, and other visual or workflow preferences.

Ghostty’s docs are engineering-oriented. They are better read as a configuration reference manual than as a marketing page. For most users, the real evaluation criteria are simple: does the default experience already feel comfortable, and are your daily editor, Shell, SSH, tmux, or Zellij workflows stable? If those pieces work well, Ghostty deserves a place on your long-term terminal shortlist.

References

Dirty Frag, Copy Fail, and Fragnesia: Comparing Three Recent Linux Local Privilege Escalation Flaws

Fri, 15 May 2026 13:24:04 +0800

Several high-profile Linux kernel local privilege escalation vulnerabilities have appeared recently: Dirty Frag, Copy Fail, and Fragnesia. They look like a single family of events because the end result is similar: a low-privilege local user may be able to become root.

But from an operations perspective, they should not be treated as one vulnerability. Their entry modules, trigger paths, mitigation options, and patch timelines differ. A better way to understand them is this: they expose a shared risk around the complex boundary between the Linux page cache, splice, socket buffers, and crypto paths.

This post only covers risk and response analysis. It does not include reproducible exploitation steps.

What the Three Flaws Are

Dirty Frag: CVE-2026-43284

Dirty Frag mainly points to a page-cache write issue in the Linux kernel networking path. Public write-ups usually discuss it together with two issues: the xfrm-ESP side, CVE-2026-43284, and the rxrpc side, CVE-2026-43500.

CVE-2026-43284 is related to in-place decryption when ESP handles shared skb fragments. The key point is not that an attacker directly modifies a disk file, but that the kernel can write to shared pages it should not modify, affecting file contents in the page cache.

Operationally, remember that Dirty Frag reaches esp4, esp6, and rxrpc, a set of kernel modules and networking subsystem paths. It is tied to IPsec, ESP, and RxRPC, so temporary mitigation also focuses on those modules.

Copy Fail: CVE-2026-31431

Copy Fail is a Linux kernel local privilege escalation vulnerability disclosed by Theori / Xint Code. Its entry point is not the IPsec networking path, but the kernel userspace crypto API around algif_aead / AF_ALG.

Public explanations describe it as originating from an in-place optimization introduced in 2017. In some cases, the kernel failed to copy data as expected and instead placed page-cache pages into a writable destination path. An attacker can combine AF_ALG with splice() to perform a small controlled write to page-cache-backed pages.

Its risk comes from strong exploitability and broad impact across mainstream distributions. Unlike Dirty Frag, Copy Fail’s temporary mitigation focuses on restricting or disabling algif_aead, and on limiting AF_ALG socket creation in container and CI environments.

Fragnesia: CVE-2026-46300

Fragnesia is another Linux kernel local privilege escalation vulnerability disclosed by V12 Security, and it belongs to a similar attack surface as Dirty Frag. It is not the same bug as Dirty Frag, but it still revolves around IPsec ESP / rxrpc related modules and page-cache write effects.

AlmaLinux describes it as the third local-root issue in the same broad code area. The key problem is that skb_try_coalesce() did not preserve the shared-fragment marker when coalescing socket buffer fragments, which could later let the XFRM ESP-in-TCP receive path decrypt in place over external page-cache pages.

In short, Fragnesia is closer to Dirty Frag. Both revolve around esp4, esp6, rxrpc, skb fragments, and ESP decryption paths. Their temporary mitigations also overlap heavily.

Similarities: Why They Are Dangerous

The common thread is not that the exact code locations are identical, but that the attack outcome and risk model are very similar.

First, all three are local privilege escalation issues. Attackers usually need ordinary local code execution first, then they can attempt to become root. For a single-user desktop this is not remote one-click compromise; for multi-user servers, CI runners, container hosts, shared development machines, and VPS instances with exposed SSH, low-privilege entry points are not rare.

Second, all three involve page-cache writes. Attackers may not permanently modify the file on disk; instead, they affect the in-memory page-cache copy. This makes traditional integrity checks less reliable: the disk hash can remain normal while the execution path reads polluted page-cache content.

Third, they are closer to deterministic logic bugs than timing-sensitive race conditions. Public material repeatedly notes that these issues do not require winning a race condition. Defenders should not underestimate exploit reliability based on older assumptions.

Fourth, they amplify the risk of container and automation environments. Low-privilege code inside containers, CI jobs, build scripts, or third-party plugins can turn a “local issue” into a platform-level issue if it can reach the relevant host kernel interfaces.

Differences: One Mitigation Does Not Cover All

The biggest difference is the entry module.

Copy Fail’s critical entry point is algif_aead / AF_ALG, part of the kernel userspace crypto API. Its temporary defense focuses on disabling or restricting algif_aead, and using seccomp to block containers from creating AF_ALG sockets.

Dirty Frag’s critical entry point is xfrm-ESP and rxrpc. It is closer to protocol and socket buffer handling paths. Temporary defense typically considers disabling esp4, esp6, and rxrpc, but that can affect IPsec, VPNs, tunnels, or related networking capabilities.

Fragnesia sits in a similar region to Dirty Frag, but the concrete issue is that skb_try_coalesce() did not preserve the shared-fragment marker. It is more like another branch of the Dirty Frag risk surface than a Copy Fail crypto API issue.

So, fixing Copy Fail does not mean Dirty Frag and Fragnesia are covered. Likewise, disabling esp4 / esp6 does not automatically remove Copy Fail. Their patch state and mitigation strategy must be checked separately.

How to Judge Exposure

For these vulnerabilities, do not judge only by distribution name or kernel major version. Distributions backport fixes, cloud vendors maintain their own kernel branches, and enterprise distributions may carry additional patches.

A safer sequence is:

Check the distribution security advisory and kernel package changelog.
Verify whether the current kernel package fixes the relevant CVE.
For cloud servers, container hosts, and CI nodes, also check cloud or platform advisories.
For temporary mitigations, confirm whether the business depends on the affected module.
After a kernel update, schedule a reboot and confirm the running kernel has changed.

The most common trap is “the package is updated, but the machine has not rebooted.” Kernel vulnerabilities are not like ordinary userspace service updates. Until the system boots into the new kernel, the old kernel may still be running.

Operational Priority

The systems that deserve the highest priority are not all Linux machines equally. Start where low-privilege code execution is most likely.

Highest-priority environments include:

Multi-user login servers
CI / CD runners
Build and artifact packaging machines
Container hosts and Kubernetes nodes
Shared development machines
Cloud servers and VPS instances exposing SSH
Platforms running third-party scripts, plugins, or job queues
Machines with web vulnerabilities, weak passwords, or historical compromise signals

Closed, single-user machines with no external code execution entry point are still at risk if vulnerable, but they can usually be handled later.

How to Treat Temporary Mitigation

Temporary mitigation is not a replacement for a patch. Its value is reducing exposure when you cannot immediately reboot or are waiting for distribution packages.

For Copy Fail, focus on algif_aead and AF_ALG. If the business does not use the kernel AF_ALG crypto interface, evaluate disabling the related module. In container environments, check seccomp policies first so untrusted workloads cannot freely create the relevant socket.

For Dirty Frag and Fragnesia, focus on esp4, esp6, and rxrpc. If the system does not depend on IPsec ESP, related VPNs, tunnels, or RxRPC, consider temporary disabling. Do not do this blindly in production because these modules may support real networking workloads.

The final path is still a kernel update. Temporary mitigation can reduce attack surface, but it cannot prove the system is fully safe.

What These Three Flaws Tell Us

The important warning is not just the number of CVEs. These flaws all cluster around high-complexity kernel paths: zero-copy, splice, socket buffers, the page cache, crypto interfaces, and protocol-stack optimizations.

These paths deliver performance, but their ownership boundaries are hard to maintain. Whether a fragment is shared, whether a page may be written in place, and whether an optimization truly only reduces copying all become security boundaries.

For security and operations teams, the takeaways are practical:

Treat local privilege escalation as an amplifier for existing low-privilege entry points.
Containers are not a natural isolation boundary for kernel vulnerabilities.
File integrity checks cannot look only at disk contents.
CI, build machines, and plugin platforms are high-priority assets.
Kernel patching requires verifying both “installed” and “running” states.

Summary

Dirty Frag, Copy Fail, and Fragnesia are all high-priority recent Linux local privilege escalation events, but they are not three names for one vulnerability.

Copy Fail goes through the algif_aead / AF_ALG crypto API path. Dirty Frag goes through xfrm-ESP and rxrpc. Fragnesia, in a nearby Dirty Frag attack surface, again triggers page-cache write risk through skb fragment marker handling.

Operationally, the safest response is to update the kernel according to distribution advisories and reboot. For systems that cannot be updated immediately, evaluate temporary module disabling or tighter seccomp rules based on the actual vulnerability entry point. Prioritize multi-tenant systems, CI, container hosts, and shared development environments.

References:

Theori Copy Fail notes: https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail advisory: https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag notes: https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia notes: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC notes: https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300): Impact and Mitigation for a Linux Kernel Local Privilege Escalation Flaw

Fri, 15 May 2026 13:18:01 +0800

The Linux kernel has another local privilege escalation issue in the same broad attack surface as Dirty Frag: Fragnesia (CVE-2026-46300).

According to V12 Security, Fragnesia is a Linux local privilege escalation vulnerability. An attacker does not need existing high privileges on the host. If they can execute local code, they may be able to abuse a logic flaw in the kernel’s XFRM ESP-in-TCP subsystem to modify read-only file contents through the page cache and eventually trigger a root shell.

Source:

V12 Security PoC notes: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

This post does not cover reproducible exploitation steps. It focuses on the operational risk and response path.

How It Relates to Dirty Frag

V12 Security classifies Fragnesia as part of the Dirty Frag vulnerability class. It is not the same bug as Dirty Frag, but it lives in a related attack surface: Linux kernel XFRM ESP-in-TCP.

XFRM is the Linux kernel framework for IPsec processing. ESP-in-TCP is related to carrying ESP encrypted traffic over TCP. Fragnesia comes from logic around shared page fragments and socket buffer coalescing: in some cases, the kernel can lose track of the fact that a fragment is still shared, leaving room for controlled writes.

This resembles the broader Dirty Pipe / Dirty Frag family of page-cache write issues. The concrete code paths differ, but the effect again lands on the page-cache copy of a read-only file.

Why the Risk Is High

Fragnesia is dangerous for three reasons.

First, it is a local privilege escalation. Once an attacker can run ordinary user-level code on a system, they may be able to become root. That matters especially on multi-user servers, container hosts, CI runners, shared development machines, VPS instances, and systems exposing shell access.

Second, it does not rely on a traditional race condition. V12’s notes describe a path that drives ESP-in-TCP processing over file-backed pages already spliced into a socket buffer, allowing byte-level influence over page-cache contents. That makes the issue more practical than a purely theoretical bug.

Third, it changes the page cache, not the on-disk file. The public notes use /usr/bin/su as an example target. After successful exploitation, the file on disk is not permanently modified; the modified copy lives in memory. Integrity checks that only compare disk hashes may miss this.

That is the awkward part for administrators: the file can look unchanged, but executing the polluted page-cache copy of a target binary may still trigger privilege escalation.

Known Affected Scope

V12 Security states that kernels affected by Dirty Frag and missing the relevant May 13, 2026 patches are also affected by Fragnesia. Publicly tested environments include Ubuntu 22.04, Ubuntu 24.04, and kernels such as 6.8.0-111-generic.

There are two important caveats.

First, do not judge only by the distribution major version. Whether Ubuntu 22.04 or 24.04 is affected depends on the actual kernel patch state, not just the distribution name.

Second, do not rely only on default AppArmor restrictions for unprivileged user namespaces. Ubuntu’s AppArmor restrictions can raise the bar, but the disclosure treats that as an additional bypass problem, not as a fix for the vulnerability itself.

The reliable path is still to check distribution security advisories and kernel package updates.

Temporary Mitigation

If a system cannot be upgraded immediately, first check whether it depends on the relevant protocol modules.

V12 gives the same mitigation direction as Dirty Frag: if the system does not depend on IPsec ESP or RxRPC, administrators can consider disabling modules such as esp4, esp6, and rxrpc. This can affect networking features, so production systems should not do it blindly. Confirm whether the environment uses IPsec, VPNs, tunnels, or related kernel functionality.

A safer response order is:

Check whether the distribution has published a kernel security update.
Install the kernel patch and schedule a reboot first.
If immediate upgrade is impossible, evaluate temporary module disabling.
Prioritize multi-user systems and CI / build environments.
Review unnecessary local accounts, shell access, container escape surface, and low-privilege execution entry points.

Disabling modules should not be treated as the final fix. It is only a way to reduce exposure while moving toward a patched kernel.

If Exploitation Is Suspected

One key feature of Fragnesia is page-cache pollution. V12 notes that after exploitation, the target file’s page-cache copy may contain injected content, and later execution can still behave abnormally until the page is evicted or the system is rebooted.

If exploitation is suspected, do at least the following:

Preserve logs and audit records as soon as possible.
Check recent abnormal local logins, low-privilege user activity, suspicious processes, and root shell traces.
Clear the relevant page cache or reboot directly.
Upgrade to a fixed kernel.
Verify key binaries, but do not rely only on disk hashes.
Rotate potentially exposed credentials and keys.

For production servers, it is better to treat this as a potential local privilege escalation incident, not merely as a routine patch event.

Which Machines Should Come First

The highest priority is not every Linux machine equally. Start with systems where attackers are most likely to obtain low-privilege code execution.

High-priority environments include:

Multi-user login servers
CI / CD runners
Build machines
Shared development machines
Container hosts
VPS and cloud servers
Edge nodes exposing SSH
Platforms running third-party scripts or plugins

Closed, single-user machines with no external code execution entry point are still affected if vulnerable, but their urgency is lower.

Summary

Fragnesia matters not because it has a new name, but because it again pulls Linux local privilege escalation back into the difficult boundary between the page cache and kernel networking subsystems.

For administrators, the important work is to confirm kernel patch status, understand whether ESP / RxRPC is in use, prioritize highly exposed machines, and remember that “the disk file is unchanged” does not mean “the system was unaffected.”

If a system is affected, the final answer is still to install the distribution’s kernel update as soon as possible. Temporary module disabling is only a bridge, not a replacement for the patch.

Which industries will LLMs disrupt first? AI impact through the lens of workforce disruption

Fri, 15 May 2026 09:03:35 +0800

Discussions about LLMs and jobs often fall into two extremes. One side says AI will replace all white-collar workers; the other says it only improves productivity and will not change job structures.

The more realistic view is that LLMs do not neatly eliminate whole industries. They reorganize tasks first. Work that involves reading, writing, summarizing, classification, retrieval, explanation, support, code, reports, and process documents will feel the pressure first.

This disruption has three layers:

Some tasks are automated.
Some roles are augmented.
Some entry-level, repetitive, or coordination-heavy work is repriced.

A simple framework

To judge whether an industry is exposed, do not start with the industry name. Look at task structure.

Highly exposed tasks usually have these traits:

Inputs are text, tables, code, images, or documents.
Outputs are text, structured data, plans, emails, code, or reports.
Judgment rules can be written as checklists.
Humans can review results quickly.
Error costs are controllable, or can be reduced through review.
The task is frequent and repetitive.

Less exposed tasks rely more on physical work, field operations, complex relationships, legal responsibility, real-world perception, licenses, or high-risk decisions.

So LLMs first affect the knowledge-processing, documentation, communication, and junior-analysis layers inside industries.

Customer support and customer operations

Customer operations are among the first areas to be transformed. Many support questions can be answered from knowledge bases, historical tickets, and process rules.

LLMs can handle intent recognition, draft replies, ticket summaries, escalation decisions, QA, tone rewriting, and multilingual support.

Affected roles include text support agents, ticket handlers, after-sales support, QA reviewers, customer success assistants, and knowledge-base maintainers.

This does not mean all support disappears. Complex complaints, major accounts, emotional communication, refund disputes, and compliance boundaries still need people. The likely change is that one person manages more conversations while low-complexity issues are automated.

Administration and back office

WEF’s Future of Jobs Report 2025 lists clerical, secretarial, cashier, ticketing, and data-entry roles among those under pressure. The ILO’s generative AI exposure study also identifies clerical work as highly exposed.

The common pattern is information organization and process handoff:

Meeting minutes
Scheduling
Email drafting
Spreadsheet cleanup
Data entry
Document filing
Reimbursement and approval materials
Internal notices

This disruption can arrive quickly because companies can connect AI to office suites, chat, email, and document systems without rebuilding the whole business.

Marketing, advertising, and content

Marketing will be deeply changed, not because AI can write slogans, but because the production chain is compressed.

A campaign used to require research, positioning, copy, visuals, video scripts, landing pages, email, social variants, and A/B assets. LLMs and multimodal tools turn this into fast parallel generation and iteration.

Affected roles include junior copywriters, SEO editors, social media operators, ad creative planners, email marketers, product-description writers, localization editors, and brand tone rewriters.

The remaining value is not just writing copy. It is understanding users, channels, conversion, and brand boundaries.

Software development and IT services

Software development will not simply be replaced; it will be re-layered.

LLMs help with code generation, explanation, test completion, refactoring suggestions, migration scripts, documentation, log analysis, and bug localization. McKinsey identifies software engineering as one of the functions with high generative AI value potential.

The most exposed tasks are simple CRUD, boilerplate, unit-test completion, scripts, API glue code, documentation, low-complexity bug fixes, and junior frontend pages.

Complex system design, cross-team coordination, architecture tradeoffs, incidents, performance, security, and legacy migration still need experience.

The developer shift is clear: writing code becomes less central; defining problems, decomposing tasks, reviewing AI output, and designing validation paths become more important.

Finance, insurance, and banking

Finance is highly exposed because it contains documentation, compliance, analysis, support, and sales processes. Banking is also one of the industries McKinsey highlights.

Affected tasks include investment summaries, customer Q&A, risk-report drafts, compliance retrieval, loan pre-review, insurance-claim text processing, AML explanation, and internal knowledge-base Q&A.

Final decisions will not easily be handed to models. Regulation, accountability, audit, and data security push AI toward analysis and documentation assistance. The compressed layer is junior analysis and back-office document processing.

Law and compliance

Legal work is exposed because much of it involves reading, searching, summarizing, clause comparison, and drafting.

Affected tasks include contract drafts, clause summaries, due-diligence organization, case retrieval, compliance Q&A, legal memo drafts, document review, and version comparison.

But legal value is not only text. Responsibility, strategy, negotiation, courtroom work, client trust, and licensing remain human barriers.

The likely change is that junior lawyers and paralegals lose many repetitive document tasks, while senior lawyers focus more on judgment and risk ownership.

Media, publishing, and translation

Media and translation are directly exposed because language generation and transformation are core LLM abilities.

Affected tasks include news rewrites, summaries, headlines, multilingual translation, subtitle cleanup, interview transcript cleanup, first-pass editing, and channel-specific rewrites.

Investigative reporting, deep interviews, fact-checking, editorial judgment, and exclusive sources still require people. But low-value, template-driven content will become cheaper.

Translation will also split: general text and internal documents will be machine-handled, while legal, medical, literary, brand, and cross-cultural work still needs professionals.

Education and training

Education will not disappear, but it will be restructured.

LLMs can provide personalized Q&A, homework feedback, quiz generation, lesson plans, course outlines, learning paths, language practice, and mock interviews.

Affected roles include teaching assistants, question-bank editors, lesson-plan writers, basic tutors, course operators, and learning-report producers.

Education is more than knowledge transmission. Motivation, companionship, classroom management, values, and complex feedback still need people. AI is more likely to replace batch tutoring and content preparation than excellent teachers.

Consulting, research, and enterprise services

Consulting, research, audit, HR, and enterprise services all rely on information collection, structured analysis, and document expression.

Affected tasks include industry research, competitor analysis, interview notes, slide drafts, weekly reports, data explanation, JD generation, resume screening, and employee-handbook Q&A.

The risk is not only to partners. Junior analysts traditionally learn by gathering materials, making tables, and writing drafts. If AI takes over those tasks, companies need a new training path.

Healthcare, pharma, and life sciences

Healthcare adoption will be cautious, but the impact can be deep.

LLMs will first enter medical-record summaries, patient communication material, literature reviews, clinical-trial documents, drug-research support, insurance materials, medical customer service, and physician assistants.

Core diagnosis and treatment responsibility will not easily move to models, but documentation and knowledge-retrieval burden will fall.

Industries moving more slowly

Industries that depend on physical work, field operations, real-world risk, and human presence will move more slowly:

Construction
Nursing and elder care
Repair trades
Logistics handling
Kitchens
Fire and emergency work
Field agriculture
High-end manual manufacturing

But “slower” does not mean untouched. Scheduling, training, quotes, support, inventory, maintenance records, quality reports, and internal knowledge bases can still be transformed.

The real change is job structure

LLM workforce disruption is not just an industry list. It is a change in role structure.

First, some junior roles shrink. Repetitive writing, research cleanup, basic analysis, simple code, and support replies are easier to automate.

Second, mid-level roles become tool-augmented. Workers who use AI well handle more tasks; those who do not may look slower.

Third, senior roles emphasize judgment. Strategy, review, responsibility, communication, system design, and risk tradeoffs become more valuable.

The real question is not whether AI affects your industry, but how much of your work can be textualized, proceduralized, and checklist-reviewed.

Summary

Current LLMs will first affect knowledge-intensive, text-heavy, process-heavy areas: support, administration, marketing, software, finance, law, media, education, consulting, medical documentation, and R&D support.

They will not change all industries at the same speed or in the same way. Regulated, high-risk, trust-heavy industries will use more augmentation; repetitive and reviewable tasks will see more automation.

For individuals, the useful preparation is to decompose your work: which tasks can go to AI, which must stay human, and which abilities make you the reviewer, orchestrator, and final owner.

References:

World Economic Forum, Future of Jobs Report 2025: https://www.weforum.org/publications/the-future-of-jobs-report-2025/
International Labour Organization, Generative AI and Jobs: https://www.ilo.org/publications/generative-ai-and-jobs-global-analysis-potential-effects-job-quantity-and
McKinsey, The economic potential of generative AI: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier
OpenAI / OpenResearch / University of Pennsylvania, GPTs are GPTs: https://openai.com/index/gpts-are-gpts/

web-video-presentation: an Agent Skill for turning articles into screen-recordable web videos

Fri, 15 May 2026 09:02:15 +0800

web-video-presentation is an agent skill in ConardLi/garden-skills. It solves a concrete problem: turn an article or narration script into a web-based presentation that can be recorded as a video.

Project: https://github.com/ConardLi/garden-skills/tree/main/skills/web-video-presentation

It is not a normal slide template or a React component library. It is a production process for AI agents: rewrite content into narration, turn it into an outline, choose a theme, build a 16:9 click-driven Vite + React + TypeScript web surface, then record it.

It is not trying to make slides

The README makes an important distinction: the skill generates a “video production surface”, not a slide deck.

Each click advances a narration beat. Each step owns a 1920×1080 stage. The UI progress controls stay hidden unless hovered, making recordings clean.

It is useful for:

Turning blog posts into YouTube or Bilibili-style explainers
Building visuals for narration scripts
Product demos
Tutorial videos
Keynote-style visual talks
Dynamic presentations that do not feel like PowerPoint

The value is not replacing video editing software. It makes the browser a controllable, iterative video canvas.

Core principles

The skill has several clear principles.

First, a fixed 16:9 stage. Design happens in a stable 1920×1080 coordinate system, then scales to the viewport. This prevents layout drift during recording.

Second, a global step cursor. Clicks and keyboard input advance (chapter, step) and save progress locally. It behaves like a video timeline, but controlled through web state.

Third, one idea per step. Every beat should have its own visual moment, not just more bullets on the same page.

Fourth, narration drives structure. The script defines rhythm; the outline defines chapters and steps; visuals follow the story.

Fifth, motion first. Each scene should have a moving visual anchor. If it is only static text, it has not become video language yet.

Sixth, theme tokens. A theme is not just colors; it controls typography, colors, cards, background, separators, decoration, and tone through semantic tokens.

Four-part workflow

The workflow has four stages.

First is content writing. If the user provides an article, the agent rewrites it into script.md, then creates outline.md. If the user already provides a narration script, it saves it as script.md and generates the outline.

Second is web development. The agent scaffolds a Vite / React / TypeScript project and implements scenes chapter by chapter. Chapter 1 must be completed by the main thread and approved by the user, because it becomes the style anchor.

Third is optional audio generation. The skill can extract narration definitions from each chapter’s narrations.ts and run a voice synthesis flow.

Fourth is recording and post-production. The web app is the recording stage; the user records the click-driven presentation.

The process has hard checkpoints: script, outline, theme, asset plan, and development mode must be aligned first; chapter 1 must be reviewed; audio generation must also be confirmed.

Why outline should not define animation

One interesting constraint is that outline.md plans rhythm and information density, but not concrete animations.

It may describe chapters, step count, screen content, information pools, asset plans, and estimated duration. It should not define CSS animation type, timing, clip-path, or filter implementation.

The reason is good: if outline locks animation, later implementation becomes mechanical. Video feeling should be designed per chapter based on content relationships.

narrations.ts as the source of truth

Each chapter has a narrations.ts. It stores the step count and corresponding narration text. The skill requires the maximum step used in the chapter .tsx to align with narrations.length.

This prevents drift across script.md, outline.md, chapter code, chapters.ts, and audio files. For video production, keeping narration, screen, audio, and step count aligned is essential.

Themes are more than skins

Built-in themes include paper-press, warm-keynote, midnight-press, blueprint, chalk-garden, terminal-green, bauhaus-bold, sunset-zine, newsroom, and monochrome-print.

These are not just color swaps. They define different visual languages: print, keynote, blueprint, terminal, newsroom, and so on.

During planning, the agent should recommend two or three themes based on the topic and tone. The user can also request a custom theme.

Three development modes

Chapter 1 is always built by the main thread and reviewed first. After that, there are three modes.

Mode A: chapter-by-chapter confirmation. Lowest risk and best quality control.

Mode B: sequential development. The main thread builds remaining chapters and reviews at the end.

Mode C: parallel development. After chapter 1 approval, subagents build later chapters in parallel. It is fastest, but visual differences may appear. Theme tokens provide consistency while each chapter can still have its own expression.

Who should use it

This skill is best for people who already have content: an article, script, product description, tutorial, or technical explanation.

If the user has no topic or material, the agent should ask for source content. This is not an ideation tool; it is a content-to-video production flow.

Summary

web-video-presentation is valuable because it turns content video production into a collaborative, reviewable, reusable workflow.

It connects article, narration, outline, theme, chapter implementation, audio, and recording, while hard checkpoints prevent the agent from running away.

Even if you do not use its scaffold, ideas like “one step, one idea”, “chapter 1 as style anchor”, “narrations.ts as source of truth”, and “outline does not hard-code animation” are worth borrowing.

Prompt-Vault: a prompt specification library for testing AI coding ability

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault is a small but useful prompt repository. It does not collect magic prompts; it organizes executable coding prompts into difficulty levels so they can be used to test LLMs and coding agents.

Project: https://github.com/w512/Prompt-Vault

The repository is small, but the structure is clear: Easy, Medium, and Hard. Each Markdown file is a standalone task. The README also says these prompts are suitable for testing language models or practicing small projects.

Not a prompt scrapbook

Many prompt repositories look large but are hard to evaluate. The titles are attractive, but the prompts lack acceptance criteria.

Prompt-Vault is closer to a specification library. Each task tries to describe:

What app to build
Required features
UI style
Technical constraints
Whether it must run as a single file
Whether dependencies are allowed
Whether data should persist

This is much better for testing models than “make a nice Kanban board”, because it reveals whether the model truly understands requirements.

Easy: basic interaction

Easy/Bubble_Sort_Visualizer.md asks for a single-file index.html that visualizes bubble sort with bars, start/reset buttons, a speed slider, comparison count, and a dark theme.

It tests whether a model can connect algorithm state to UI, control animation timing, handle reset and running states, and keep the code readable.

Easy/ToDo_List.md starts from static HTML and gradually adds task creation, completed state, deletion, counters, Active / Completed stats, and localStorage.

It is a simple task, but it tests whether a model can evolve code step by step instead of dumping a messy implementation.

Medium: state and animation complexity

Medium/Sorting_Visualization.md upgrades the challenge. The same page must support Bubble Sort, Insertion Sort, Selection Sort, Merge Sort, Quick Sort, and Heap Sort.

It also needs algorithm selection, speed and size sliders, reset, start / pause, and a live stats panel.

This catches many failures: an agent may implement one bubble sort animation, but multiple algorithms plus pause/resume and stats often break state management.

Useful checks include:

Does every algorithm really sort?
Does the animation match the algorithm steps?
Can it pause and resume?
Does reset stop old animation loops?
Does changing array size break state?
Are the statistics credible?

Hard: product completeness

Hard/Kanban_Board.md asks for a complete board: default columns, custom columns, double-click rename, delete empty columns, cards with title and description, priority, deadline, drag-and-drop, search, priority filter, localStorage, footer stats, glassmorphism dark theme, and responsive horizontal scrolling.

This tests product completeness, not just one feature.

Hard/Markdown_Editor_Desktop.md asks for a Tauri 2 cross-platform Markdown editor. It includes split editing and preview, sync scrolling, live rendering, preview mode, focus mode, open/save/save-as, unsaved title markers, formatting toolbar, shortcuts, themes, font settings, Vue 3, Pinia, marked.js, prism.js, and Tauri plugins.

This is no longer a simple web prompt. It tests frontend state, Tauri plugins, filesystem permissions, IPC boundaries, and desktop packaging.

Why it is valuable

Prompt-Vault is valuable because it provides reusable evaluation samples.

If you compare models or coding agents, you can run the same prompt repeatedly and observe:

Which model follows constraints
Which model misses fewer features
Which model handles edge cases
Which output is easier to maintain
Which model is better at UI details
Which model is stable under single-file constraints

This is more reliable than “it feels smarter”.

Frontend tasks are especially useful because many failures are not syntax errors. They are missing button states, broken animation, lost persistence, wrong drag targets, or stale statistics.

How to extend it

The repository could become a stronger benchmark by adding acceptance checklists, failure cases, scoring dimensions, reference implementations, and cross-model result records.

For example, a sorting task should include checks such as “rapid Start / Reset clicks must not create multiple animation loops.” A Kanban task should specify what happens when deleting a non-empty column.

These details make the prompt useful for human review and automated agent evaluation.

Suggested use

To test an AI coding tool:

Give one prompt unchanged.
Do not add extra hints.
Run the generated result.
Check features one by one.
Record missing features and bugs.
Give one repair round.
Compare time, token cost, and final code quality.

This is closer to real development than simply checking whether a page appears.

Summary

Prompt-Vault is a lightweight prompt specification library. It is useful for AI coding tests and for frontend practice projects.

It reminds us that a good coding prompt is not just a wish. It should define requirements, constraints, interactions, state, acceptance, and run mode.

If you compare Codex, Claude Code, Cursor, Gemini CLI, or other coding agents, this kind of leveled prompt is worth keeping.

What is Token Efficiency? DeepSeek V4, big-model planning, and small-model execution

Fri, 15 May 2026 08:59:33 +0800

The next important metric for AI coding may not be who has the strongest model, but who can complete more verifiable work with fewer tokens, lower cost, and a more stable process.

That is the value of Token Efficiency.

Many people hear Token Efficiency and think only about cheaper models, longer context, or cheaper cache hits. Those are base conditions. Real productivity comes from model division of labor, task orchestration, context budgeting, and evaluation.

In other words, Token Efficiency is not a cost-saving trick. It is an engineering method for turning tokens into output.

DeepSeek V4: productizing the split between planner and executor

The missing background in this topic is the positioning of DeepSeek V4.

DeepSeek V4 is not just another stronger model. It splits the two capabilities needed for Token Efficiency into V4 Pro and V4 Flash: V4 Pro is better suited for planning, reasoning, architecture judgment, and critical review, while V4 Flash fits high-frequency execution, batch rewriting, code completion, data organization, and ordinary agent-loop nodes.

That maps directly to two roles in AI coding:

V4 Pro: planner / consultant for requirement breakdown, technical design, complex bug analysis, architecture review, and final acceptance.
V4 Flash: executor for file scanning, simple implementation, test completion, documentation, candidate generation, and repetitive work.

DeepSeek’s API documentation shows that both V4 Flash and V4 Pro support 1M context, JSON Output, Tool Calls, Chat Prefix Completion, and FIM Completion. The pricing page also prices cache-hit input separately and notes that input cache-hit prices have been reduced to one tenth of the launch price.

Together, these are why it matters for Token Efficiency: 1M context reduces compression in complex agent tasks; low cache-hit pricing lowers the cost of repeatedly loading prompts, project docs, code, and history; the Flash / Pro split solves the problem of using a flagship model for every step or an unstable small model for every step.

DeepSeek V4 should therefore be understood in three ways:

Cheap execution layer: many agent nodes can run on V4 Flash.
Usable judgment layer: key steps can still call V4 Pro.
Long-chain friendly: 1M context and cache pricing make codebases, docs, and tool history easier to keep in the usable window.

Its significance for AI coding is not just another model option. It offers a realistic cost structure for the “consultant model + executor model + harness orchestration” pattern.

Do not let the strongest model do everything

The old approach was to pick the smartest model and let it handle requirement analysis, code, tests, and summaries end to end.

That is simple but not always efficient. Many tasks do not need frontier reasoning. Expensive models should behave more like consultants, architects, or planners that appear only at key decision points.

A better structure is:

Big models break down problems and make key decisions.
Small models execute, batch-process, and repeat edits.
Tools and harnesses manage process, state, context, and validation.
Humans define product goals, accept results, and make tradeoffs.

This prevents frontier reasoning from being wasted on mechanical execution.

Context is not always better when larger

Long context matters for coding agents because code, docs, chat history, test output, and logs all consume the window. When the window fills up, compression, forgetting, and misjudgment appear.

But long context does not mean dumping everything into the model.

Token Efficiency means each task should fit inside a clear, controlled context window:

Bring only necessary files.
Include only decision-relevant documents.
Keep only the current state from history.
Give each node clear input and output.
Compress completed work into structured summaries for the next node.

Cheap context can tempt people to include noise. Noise does not make a model smarter.

Harness matters more than a single model

Connecting Claude Code, Codex, or another coding agent to a cheap model is not enough. Small models drift in long-chain tasks unless a stronger process controls them.

A harness is a scheduling system. It decides how to split tasks, run nodes, choose models, validate results, retry failures, and pass context.

A useful orchestration system should answer:

Which tasks need planning?
Which tasks can execute directly?
Which nodes can run in parallel?
Which nodes must be serial?
Which nodes use big models or small models?
What is the context budget for each node?
What structured output does each node produce?
Who reviews and decides whether to continue?

Without this software layer, small models are merely cheap. With it, they can become leverage.

Split tasks with DAGs

A good approach is to split complex work into a directed acyclic graph.

A feature task might become:

Requirement clarification
Technical design
Task decomposition
Implementation
Test completion
Code Review
Fixes
PR submission

Each node can be an independent agent with its own role, prompt, tools, permissions, and output format. Nodes should pass structured results, not long chat transcripts.

This makes each node shorter, easier for small models, and easier to measure.

Run multiple task replicas

When tokens are cheap enough, the same task does not have to run only once.

You can run the same task with different models, prompts, or orchestrations, then pick the best result or merge useful parts. This is suitable for design proposals, copy, test cases, bug hypotheses, refactor options, and code review.

It is not suitable for tasks with external side effects, shared mutable state, or unclear acceptance criteria.

The goal is not gambling. It is collecting comparable samples that can improve orchestration, model selection, and node skills.

Build an evaluation system

Token Efficiency cannot be judged only by price. A cheap model with a high failure rate can consume more human time and become more expensive.

Start recording:

Completion rate
Human interventions
Tool-call failure rate
Test pass rate
Review findings
Token cost per task
Time per task
Rework count
Differences between model combinations

With this data, you can decide which tasks fit small models, which require big models, and which should stay human-led.

Make business workflows atomic

Most users do not need to build a full harness today. But they can start decomposing their business workflow into atomic nodes.

Content production can become topic selection, research, outline, draft, fact check, style rewrite, SEO title, translation, and publishing check.

Software development can become requirement confirmation, technical design, data structure, API change, unit tests, implementation, migration script, documentation, and review.

Each node should have clear input, output, acceptance, and context limits. When harness tools mature, these workflows can plug in directly.

Hardware is not the first priority

Many discussions of Token Efficiency jump to local deployment and GPUs. For most people, API should still be the first choice.

Before the economic model works, local hardware is only prepaid cost. A safer sequence is:

Use API to validate the workflow.
Record task evaluation and cost.
Find stable high-frequency execution nodes.
Consider which nodes should be localized.
Then calculate hardware, power, maintenance, and depreciation.

For personal productivity, API is often enough. For startups exploring inference frameworks and model boundaries, local CUDA platforms can be useful. For production workloads with clear unit economics, multi-GPU deployment becomes worth discussing.

Summary

Token Efficiency is not replacing expensive models with cheap ones. It is redesigning the AI workflow.

Big models make key judgments, small models execute in bulk, the harness schedules and validates, and humans define goals and acceptance. Only when these layers work together can tokens reliably become productivity.

Models will get cheaper, context windows will grow, and small models will improve. The future gap may not be who calls the strongest model, but who can use the same tokens to produce more real output.

Superpowers: a skills framework that pulls coding agents back into engineering process

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers is both a skills framework for coding agents and a software development methodology. Its goal is not to add another universal prompt, but to make agents follow a process: clarify goals, produce a design, write a plan, implement through TDD, then review and finish.

Project: https://github.com/obra/superpowers

At the time of writing, the GitHub API shows more than 190,000 stars, an MIT license, and recent activity. The README describes it plainly: An agentic skills framework & software development methodology that works.

What problem it solves

Many AI coding tools are not weak at writing code; they are too eager to write code.

A user says something vague, the agent edits files, and the result looks finished while boundaries, tests, and architecture remain unclear. Small tasks may survive this. Complex projects turn it into rework and technical debt.

Superpowers makes the agent enter a workflow before touching code:

When the user wants to build something, ask about the goal first.
Turn the conversation into a spec and confirm it in sections.
After design approval, write an implementation plan.
After the user says “go”, begin implementation.
During implementation, emphasize TDD, YAGNI, DRY, and code review.

This is not new software engineering. It is important because fast agents need stronger guardrails.

Supported tools

Superpowers is not tied to a single agent. The README lists installation paths for Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor, and GitHub Copilot CLI.

That makes it more like a workflow layer across harnesses than a model-specific trick.

The base workflow

The base workflow has several stages.

First is brainstorming. Before implementation, the agent turns rough ideas into an executable design and confirms it with the user.

Second is using-git-worktrees. After design approval, it creates an isolated worktree and branch, then checks that install and test baselines are clean.

Third is writing-plans. It decomposes design into small tasks with paths, code scopes, and validation steps. The plan should be clear enough for someone without context to execute.

Fourth is execution. subagent-driven-development can dispatch tasks to subagents, while executing-plans runs them in batches. Each task should be reviewable and verifiable.

Fifth is test-driven-development: true RED-GREEN-REFACTOR. Write a failing test, confirm failure, implement minimally, confirm pass, refactor.

Sixth is requesting-code-review. Reviews happen between tasks; critical findings block progress.

Finally, finishing-a-development-branch validates tests and offers choices such as merge, PR, keep, or discard the worktree.

What is in the skills library

The skills library can be grouped by purpose.

Testing centers on test-driven-development.

Debugging includes systematic-debugging and verification-before-completion. They focus on reproduction, minimization, hypotheses, validation, and not claiming completion before verification.

Collaboration skills include:

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

Meta skills include writing-skills and using-superpowers.

Together they give the agent engineering habits: when to ask, when to plan, when to test, and when to stop for review.

How it differs from a prompt

A normal prompt often piles rules into one system message: do not over-edit, think first, test, explain, be concise. As rules accumulate, complex tasks make the model forget or ignore some of them.

Superpowers splits rules into phase-specific workflow modules. Each skill is shorter and focused. The agent knows the current phase, complex processes become checkable, and teams can turn their own practices into reusable skills.

The lesson is not just “use a smarter model”. Give the model a repeatable way to work.

Who should use it

Superpowers is most useful for developers already using coding agents on real projects, especially when:

The task spans multiple files.
The agent should design before implementation.
TDD or validation matters.
Multiple branches or worktrees are common.
Subagents can help with implementation or review.
A team wants to encode its workflow as skills.

For a one-line config change, it may feel heavy. For multi-step development, the constraints are valuable.

Notes before using it

Do not treat it as full autopilot. It gives the agent process, but humans still own requirements, tradeoffs, and final acceptance.

TDD and review add upfront cost. For small tasks they may slow things down; for complex tasks they reduce rework.

Parallel subagents are not always better. They work when boundaries and write scopes are clear. If the requirement is still fuzzy, parallelism only multiplies confusion.

Teams must maintain skill quality. Outdated processes, vague instructions, and conflicting rules can also hurt agents.

Summary

Superpowers is valuable because it pulls coding agents away from “receive request, edit code” and back into software engineering process.

AI coding often lacks not generation speed, but clarification, planning, verification, review, and closure. The stronger the model becomes, the less these steps should be skipped.

If you use Codex, Claude Code, Cursor, or Gemini CLI on real projects, Superpowers is worth studying. Even if you do not install it, its skill decomposition is a good reference for designing your own agent workflow.

Honeywell PTM7950 confusion: do not judge only by thickness, origin, or black spots

Fri, 15 May 2026 08:51:49 +0800

Honeywell PTM7950 phase-change thermal pads have become popular among PC enthusiasts, and that popularity has also created confusion: is 0.2 mm or 0.25 mm real, is Thailand-made better than China-made, do black spots prove authenticity, can color or COA prove performance?

These look like identification tips, but together they reveal a bigger problem: a niche industrial material entered consumer retail before the retail supply chain became clear.

The conclusion is simple: do not judge PTM7950 only by thickness, origin, color, or black spots. Stable sourcing, batch information, real testing, quality screening, and clear after-sales rules matter more.

Thickness is not an authenticity test

A common claim is that 0.2 mm is worse than 0.25 mm, or that one thickness equals domestic, fake, or low performance. This is too crude.

If a material is counterfeit, changing thickness is not hard. Conversely, 0.2 mm is not automatically fake, and 0.25 mm is not automatically real. Thickness is a specification, not proof of source, formula, or quality control.

A better approach is to combine thickness with testing. In one comparison, 0.2 mm and 0.25 mm samples reached similar thermal resistance at 40 psi; at lower pressure the 0.25 mm sample was slightly higher. This does not prove one side is always better, but it does weaken the thickness-only argument.

For laptops and normal PC coolers, pressure matters. A lab can apply 20, 30, or 40 psi; your heatsink may not. Low-pressure performance is often closer to daily use.

Origin is not a performance shield

Origin matters, but it is not the final answer. Industrial materials depend more on formula, process, batch stability, and quality control than on a simple country label.

This is especially true for PTM7950SP. Some batches have been made in Thailand for years, but that does not mean origin should become the main selling point. It is an industrial material, not a consumer product sold through origin stories.

Buyers should ask:

Is there a clear batch?
Is the source traceable?
Has the batch been tested?
Can obvious defects be returned?
Does the seller have a long-term record in this category?

These questions matter more than where it was produced.

Black spots are more likely a defect

Another claim is that black spots prove authenticity. That is risky.

Black spots may come from delamination, bubbles, small pits, or reflection differences. They may indicate a real supply chain, but that does not make them good. From an industrial-goods perspective, obvious bubbles or pits are usually defect signals.

Do not turn visible abnormalities into authenticity myths. Many “identification tricks” eventually become reverse marketing, where ordinary defects are packaged as rare features.

PTM7950SP color is only a first filter

For PTM7950SP paste, color and reflection can reveal obvious differences among samples. Spreading samples on the same surface and observing color, reflection, drying, and curing behavior is a useful first filter.

But color is not final proof. Solvent evaporation, coating thickness, lighting, and formula differences all affect appearance. Some light-colored materials can still perform well.

A safer process is:

Exclude obviously abnormal samples.
Compare consistency within the same batch.
Combine appearance with temperature or thermal resistance tests.
Do not replace testing with color judgment.

COA is useful, but not enough

A COA is useful evidence, but not a complete guarantee. Values can be affected by test conditions, sampling point, and device error. In retail repackaging, the buyer also needs confidence that the material actually matches the COA.

A stronger evidence chain includes:

Batch number or production date
Original packaging or repackaging record
COA or test file
Seller-side sampling test
After-sales commitment
Long-term reputation

If a seller relies only on one image, one origin, one thickness, or one “authentic feature”, be careful.

The root problem is authorization and retail mismatch

These materials were not designed for ordinary ecommerce retail. International brands often do not provide clear retail authorization on Taobao or Pinduoduo, so real goods, fake goods, repackaged goods, private labels, and keyword abuse all appear in the same search results.

This creates two effects: bad sellers can win with low prices and stories, while serious sellers must keep proving themselves.

Some sellers moving to their own brands may be trying to escape that unclear authorization and trademark environment. A private brand can at least own its material source, testing standard, batch control, and after-sales responsibility.

How ordinary users should choose

You do not need to become a material expert. Follow a few rules.

First, do not trust a single feature. Thickness, origin, black spots, and color are references, not proof.

Second, check whether the seller talks about batches and testing. A seller willing to explain methods, batches, and returns is usually more credible than one shouting only “authentic” or “Thailand-made”.

Third, check whether it suits your device. Pad thickness, mounting pressure, installation difficulty, and repeated disassembly all affect the result.

Fourth, do not buy risk just to save a small amount. Thermal materials are cheap compared with the time and hardware risk caused by failure.

The PTM7950 mess reminds us that once popular industrial materials enter consumer markets, they easily turn into myths. Traceable batches, reproducible testing, stable quality control, and clear support are still the most reliable signals.

Reject Vibe Coding: Matt Pocock's skills repo adds engineering constraints to AI coding

Fri, 15 May 2026 08:46:23 +0800

The faster AI writes code, the faster a project can lose control. The real question is not whether a model can generate functions, but whether it understands the requirement, follows the team’s language, and makes small changes inside the existing architecture.

Matt Pocock’s mattpocock/skills repository points in the opposite direction of casual vibe coding: do not let AI take over the whole development process. Put it inside mature software engineering constraints.

Project: https://github.com/mattpocock/skills

This is not about one magic prompt. It is a set of composable agent skills that turn requirement clarification, domain modeling, TDD, debugging, and architecture review into AI-friendly workflows.

Solve alignment failure first

The most common failure in AI coding is assuming the model understood the request when it merely guessed from a vague sentence.

grill-me flips the interaction. Before writing code, the agent acts like a demanding reviewer and keeps asking about branches, boundaries, and unresolved decisions.

If you ask for a login page, it should first ask:

How should password reset work?
Should third-party login be supported?
What should failed-login errors look like?
Are account lockout, CAPTCHA, or risk controls in scope?
Where should the user go after success?

This feels slower, but it prevents expensive rework later. The cheaper code generation becomes, the more costly unclear requirements become.

Write domain language into context

Another common problem is generic vocabulary. The model does not know the team’s business terms, so names and documents drift.

grill-with-docs asks questions while also checking CONTEXT.md, ADRs, and domain docs. Once terms and decisions are confirmed, they can be written back into shared context.

This is close to the “ubiquitous language” idea in domain-driven design. If a team says customer instead of user, or transaction instead of order, the model should inherit that language.

Context documents are valuable because they reduce guessing.

Use TDD to slow down generation

AI is risky because it is fast. Bad code used to take time to write; now hundreds of lines can appear in seconds. The problem is not speed itself, but lack of feedback loops.

The tdd skill brings back red-green-refactor:

Write a failing test for one behavior.
Implement only enough code to pass.
Refactor.
Continue with the next vertical slice.

The key is one behavior at a time. AI executes, while humans keep control of direction and boundaries.

Debug through a loop

When facing a bug, many agents guess and patch repeatedly until the code becomes messier.

diagnose asks the agent to build a feedback loop:

Reproduce the issue
Minimize the case
Form a hypothesis
Add observations or logs
Fix the cause
Add a regression test

This process is old, but it matters even more with AI. The model is good at trying things; the loop keeps it close to the root cause.

Review architecture regularly

A task passing tests does not mean the codebase is healthier. Repeated AI patches can blur module boundaries, make interfaces more complex, and make tests harder to write.

Skills such as improve-codebase-architecture ask the agent to step back and inspect the whole codebase:

Are responsibilities mixing across modules?
Which interfaces are too complex?
Which paths are hard to test?
Which names conflict with domain language?
Which duplicate logic should be merged?

This is not automatic large-scale refactoring. It is structured observation and suggested direction; humans still decide whether and how far to change.

What really needs limiting is freedom

The core idea is simple: AI coding is not about letting the model improvise freely. It is about giving it clear goals, context, tests, and stopping conditions.

Humans define the problem, architecture, tradeoffs, and acceptance criteria. AI generates code, fills in tests, repeats edits, and handles local refactors. Used well, AI amplifies capability; used poorly, it amplifies confusion.

Software engineering fundamentals did not become obsolete because AI improved. Requirement clarity, domain language, TDD, diagnosis, and architecture review are becoming more important.

More people will be able to write code. The gap will be between people who can put AI inside a maintainable, verifiable, evolving engineering system and those who cannot.

GPT-5.5 Prompt Migration Guide: Why old prompts should be trimmed before rewritten

Fri, 15 May 2026 01:25:27 +0800

OpenAI has updated the GPT-5.5 prompting guide in its API documentation. The most useful part of the guide is not that it gives yet another longer prompt template, but that it reminds developers of something easy to miss: when migrating to GPT-5.5, many old prompts should become shorter.

Official documentation: https://developers.openai.com/api/docs/guides/prompt-guidance

In one sentence, the prompting direction for GPT-5.5 is: write less process and more outcome; stack fewer rules and define acceptance criteria better; use fewer “always must” instructions and specify when to stop, when to validate, and when to gather more evidence.

Why old prompts need rewriting

Many production prompts are built layer by layer. When a model is unstable, one rule is added. When tool use fails, another prohibition is added. When output gets verbose, another formatting paragraph appears. Over time, a system prompt becomes a heavy operations manual.

That style can be useful with older models, because the model may need more step-by-step constraints to stay on track. But with GPT-5.5, OpenAI’s advice is clear: do not move the old prompt stack over unchanged.

Over-specifying the process brings several side effects:

More noise: the model must find the truly important constraints inside many old rules.
Narrower search space: the model becomes less willing to choose a more efficient solution.
Mechanical output: it looks like script execution instead of problem solving.
Conflicting old rules: tool calls and final answers can both become worse.

GPT-5.5 is better served by prompts that describe the target state, constraints, available evidence, and final output, instead of hard-coding every step.

outcome-first: define what done means first

The official documentation repeatedly emphasizes one direction: GPT-5.5 works best with outcome-first prompts.

That means the prompt should first define:

What the target result is.
What counts as success.
Which constraints cannot be crossed.
What context is currently available.
Which fields or sections the final answer must include.
What to do when evidence is insufficient.

A less recommended style is:

`1`	`First check A, then check B, then compare all fields, then consider every exception, then decide which tool to call, then call the tool, and finally explain the full process.`

A better style for GPT-5.5 is:

Solve the user's problem. Success criteria:
- Make the decision based on available policy and account data
- If the action is allowed, complete it before replying
- Final output includes completed_actions, customer_message, blockers
- If key evidence is missing, ask only for the smallest necessary fields

This does not make the prompt vague. It moves control from “process order” to “outcome and boundaries.” The model can choose its own search, reasoning, and tool-use path, but it must satisfy the success criteria.

Use fewer absolute rules and more decision rules

Old prompts often contain many instances of ALWAYS, NEVER, must, and only. These words are not forbidden, but they should be reserved for constraints that truly cannot be violated, such as safety rules, required fields, and prohibited actions.

For decisions like “when to search,” “when to ask the user,” “when to keep iterating,” and “when to stop,” GPT-5.5 is better served by decision rules.

For example, instead of writing:

`1`	`Always search three times first.`

Write:

Start with one search that covers the core question. If the first few results already support the key facts, stop searching and answer. Continue searching only when evidence is conflicting, missing, or insufficient to support the conclusion.

This gives the model room to decide, and it also gives it a stopping condition. For products that use web search, retrieval, file search, or database queries, this matters because every additional tool call adds latency and cost.

Add a retrieval budget

One type of rule worth adding to GPT-5.5 prompts is a retrieval budget.

This is not a money budget. It is a retrieval stopping rule. It tells the model when evidence is sufficient, when to keep looking, and when to admit that evidence is missing.

A practical version:

For ordinary Q&A, start with one broad search using short and distinctive keywords. If the first few results already support the core request, answer based on those results and do not continue searching. Add more retrieval only when results conflict, key facts are missing, or the conclusion cannot be supported.

This kind of rule reduces two common problems:

Too little search, producing answers without evidence.
Too much search, wasting time in a tool loop.

More importantly, the documentation also reminds us that failing to find evidence should not automatically become a factual “no.” Sometimes the right behavior is to state that the evidence is insufficient, or narrow the question and continue checking.

Do not raise reasoning effort too early

GPT-5.5 is more reasoning-efficient, so OpenAI recommends reevaluating low and medium instead of immediately increasing reasoning effort whenever quality is not good enough.

A steadier order is:

First check whether the prompt clearly defines the goal, output format, and stop conditions.
Add a validation loop, such as tests, citations, review, or render checks.
Add persistence rules and completion criteria for tool use.
Only then raise reasoning effort if the task still needs it.

In other words, reasoning.effort is more like a final tuning knob. It should not replace clear prompt design.

For short classification, field extraction, support ticket routing, or format conversion, start with lower reasoning cost. For long-document synthesis, conflicting-source judgment, strategy writing, or complex research, consider medium or higher.

text.verbosity controls output, not thinking

GPT-5.5 is highly controllable in output format. The official documentation recommends using text.verbosity together with the output requirements in the prompt.

The default text.verbosity is medium. If the product needs shorter, cleaner replies, use low. But that does not mean every part of the result should become short.

A typical pattern:

Keep user-facing status updates and final summaries short.
Still require readability when generating code, configuration, or structured results.
Do not sacrifice field completeness, citations, or necessary caveats just to be “brief.”

This is especially useful for code products. Chat replies can be shorter, while generated code can still require readable variable names, clear structure, and necessary comments.

preamble and phase: making long tasks feel visible

In complex tasks, GPT-5.5 may first reason, plan, or prepare tool calls before producing visible text. For streaming products, users can feel the first-token delay.

The official recommendation is: for multi-step, tool-heavy, or long-running tasks, let the model send a short preamble first. It does not need to explain the full plan; it only needs to tell the user what it will do first.

For example:

`1`	`I will first inspect the relevant files and existing configuration, then suggest the changes.`

In long-running or tool-heavy Responses API workflows, also pay attention to the assistant item’s phase. If the application uses previous_response_id, the API keeps prior assistant state automatically. If the application manually replays assistant output, it must preserve the original phase value.

Common conventions:

phase: "commentary": intermediate status update.
phase: "final_answer": final answer.
Do not add phase to user messages.

This may look like a low-level implementation detail, but it matters for products with tool calls, status updates, and final answers. Losing phase during manual replay can make the model confuse progress updates with final conclusions.

Prompt the model to check its work

Another very practical point in the GPT-5.5 guide: for tasks that can be verified, give the model validation tools and validation rules.

For code agents, explicitly require:

Run relevant unit tests after making changes.
Run type checks or lint when necessary.
Run build when the affected package is large.
If full validation is too expensive, at least do the smallest smoke test.
If validation cannot run, explain why and give the next best check.

For visual or page outputs, require rendering first, then checking layout, cropping, spacing, missing content, and visual consistency.

For engineering plans, require mappings to requirements, affected files/APIs/systems, state transitions, validation commands, failure behavior, privacy and security considerations, and open questions that truly affect implementation.

These rules are much more effective than “please be careful.” They turn “careful” into executable checks.

A prompt skeleton better suited for GPT-5.5

The structure in OpenAI’s docs can be simplified like this:

Role:
What role you are playing and what context you are working in.

# Personality
Tone, collaboration style, whether warmth or point of view is needed.

# Goal
The user-visible target result.

# Success criteria
Conditions that must be satisfied before the final answer.

# Constraints
Safety, business, evidence, permission, cost, and side-effect boundaries.

# Output
Output structure, length, tone, and required fields.

# Stop rules
When to continue, retry, degrade, ask, or stop.

The point of this skeleton is not that every prompt must use all these headings. The real idea is that prompts for complex tasks should tell the model the destination, boundaries, and deliverable, instead of hard-coding every step.

A practical order for migrating old prompts

If you already have old prompts for GPT-4.1, GPT-4o, GPT-5.2, or GPT-5.4, do not rewrite everything at once.

A steadier migration order:

First switch the model while keeping current reasoning effort and output parameters fixed.
Run existing evals or real samples and identify behavior changes.
Delete process rules that are clearly outdated, duplicated, or contradictory.
Convert “step requirements” into “success criteria” and “stop conditions.”
Add retrieval budgets, citation rules, and behavior for missing evidence.
Add validation loops for tool tasks.
Tune reasoning.effort and text.verbosity last.

If you do not have evals, at least prepare a set of representative tasks: simple Q&A, complex retrieval, tool use, formatted output, refusal/degradation, and long-task completion. Do not judge prompt quality from a single demo case.

A checklist for migrating old prompts

When migrating an old prompt, start with this checklist. The goal is not simply to make the prompt shorter, but to delete ineffective constraints and rewrite important constraints into verifiable form.

Check item	Common problem	Suggested handling
Repeated rules	The same instruction appears in multiple sections, sometimes with inconsistent wording	Merge into one clear rule and keep only the final version
Absolute words	`ALWAYS`, `NEVER`, `must`, and `only` appear everywhere	Reserve absolute constraints for safety, compliance, permissions, and required fields
No stop condition	The model is told to keep searching, analyzing, or fixing without a stopping rule	Add stop rules such as evidence sufficiency, validation success, turn limits, or cost limits
No validation command	The prompt says “ensure correctness” but gives no tests, lint, citations, or checks	Replace with concrete checks: tests, type checks, build, citations, or smoke tests
Too much process	Every step is hard-coded, leaving no room for better paths	Rewrite as goals, success criteria, boundaries, and output requirements
Old model patches	Rules written for older model weaknesses are still present	Remove first, then use evals to decide whether they are still needed
Vague tool rules	The prompt only says “use tools when needed”	Define when to call tools, when to stop, and how to degrade on failure
Output drift	There is a format requirement but no field-completeness rule	Define required fields, optional fields, and missing-evidence behavior

If you can only do one thing, prioritize “no stop condition” and “no validation command.” These two issues are the easiest way to turn GPT-5.5 into an infinite tool loop, or into a model that gives a polished answer without verification.

GPT-5.5 prompt examples: old vs new

These are not full system prompts. They are common local rewrites during migration.

Example 1: retrieval Q&A

Old:

`1`	`Before answering, you must search at least 3 times. You must read all relevant results. You must provide a complete explanation.`

New:

Start with one search that covers the core question. If the first few results already support the key facts, stop searching and answer. If results conflict or key facts are missing, add another search. In the final answer, explain the basis; when evidence is insufficient, say so clearly.

The new version changes “number of searches” into “whether evidence is sufficient.” It gives the model a reason to continue and a reason to stop.

Example 2: code changes

Old:

`1`	`Carefully modify the code. Do not break existing logic. Tell me what changed when finished.`

New:

Make the smallest necessary code change requested by the user. Success criteria:
- Only modify files related to the task
- Preserve existing public API compatibility unless the user explicitly asks for a change
- Run relevant unit tests after the change; if they cannot run, explain why and the next best validation method
- Final summary includes changes, validation result, and remaining risks

The new version does not vaguely ask the model to be careful. It grounds caution in file scope, API compatibility, test commands, and risk reporting.

Example 3: structured output

Old:

`1`	`Output JSON. Do not output extra content. Make fields complete.`

New:

Output strict JSON without Markdown. Required fields:
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
If evidence is insufficient, use status "needs_more_info" and do not invent evidence.

The new version does not only require JSON. It also defines a valid path when evidence is missing, so the model does not have to invent information to satisfy “complete fields.”

How to configure the parameters

reasoning.effort and text.verbosity should not be viewed in isolation. The former controls how much reasoning the model invests; the latter controls how detailed the output is. A common mistake is to raise reasoning.effort whenever quality is not enough, or to write harsher prompts whenever output is too long. A better approach is to configure them by task type.

Scenario	reasoning.effort	text.verbosity	Notes
Field extraction, classification, short format conversion	`none` or `low`	`low`	Optimize for low latency; the output schema matters most
Support routing, simple tool routing	`low`	`low` or `medium`	Clear rules usually do not need high reasoning
Ordinary Q&A, light retrieval summary	`low` or `medium`	`medium`	Needs some judgment, but high reasoning should not be the default
Multi-document synthesis, conflict judgment	`medium`	`medium`	First ensure evidence rules and citations, then consider raising effort
Complex code changes, long-task agents	`medium` or `high`	User replies `low`, code output should remain clear	Chat updates can be short; code and diff should be readable
Strategy, planning, risk analysis	`medium` or `high`	`medium` or `high`	Needs tradeoffs, risks, and assumptions

For most applications, start with low or medium. Raise reasoning.effort only after the prompt already defines success criteria, stop conditions, and validation rules, and the model still misses important constraints.

text.verbosity is not always better when lower. Low verbosity works well for status updates, short customer support replies, and operation summaries. For code, configuration, migration plans, or audit explanations, overly short output can make the result hard to review.

Which rules should stay

Migrating to GPT-5.5 does not mean deleting the old prompt entirely. The following rules should usually stay, and they should be made more explicit.

Safety rules: actions that cannot be taken, content that cannot be generated, and cases that require refusal or degradation.
Compliance rules: industry policies, regional restrictions, age limits, audit requirements, approval requirements.
Privacy rules: personal data handling, sensitive data redaction, logging limits, data transfer limits.
Output fields: API responses, JSON schemas, table fields, fixed structures required by frontend components.
Business boundaries: refund rules, account permissions, service levels, contract scope, escalation conditions.
Tool permission boundaries: which tools can be called, which require confirmation, and which are prohibited.
Citation and evidence rules: when sources are required and how to handle conflicting evidence.

These are not old baggage. They are product contracts. The difference is that during migration, they should be rewritten from slogans into executable constraints.

For example:

`1`	`Do not leak user privacy.`

Can become:

Do not output full phone numbers, national ID numbers, access tokens, API keys, or internal user IDs in the final answer. When a reference is needed, show only a redacted version, such as keeping the last 4 digits of a phone number.

What should not be accidentally deleted

The biggest danger when trimming prompts is not deleting fluff. It is deleting real system boundaries. The following content should not be removed lightly, even if it looks old.

Privacy and data handling requirements: especially rules for logging, export, cross-system transfer, and third-party tool calls.
Safety and permission limits: confirmation rules for deleting data, transferring money, sending email, changing permissions, or running shell commands.
Citation format: if the product depends on citations, footnotes, source lists, or audit chains, do not delete them just because they take space.
Tool call boundaries: which tools are read-only, which are write-capable, and which require user confirmation.
Failure behavior: how to degrade when APIs time out, data is missing, retrieval fails, or permissions are insufficient.
Hard business rules: pricing, refunds, bans, risk controls, and compliance review rules that the model should not improvise.

A simple rule of thumb: if deleting a rule only changes output style, consider deleting it. If deleting it could cause privilege overreach, data leakage, incorrect actions, false promises, or broken audit trails, keep it and rewrite it more precisely.

Summary

The core of the GPT-5.5 prompting guide is not “write more advanced prompts.” It is to remove over-specified process instructions from old prompts.

A prompt better suited for GPT-5.5 should:

Prioritize goals, not steps.
Define success criteria, not just ask the model to “do well.”
Include stop conditions, instead of infinite search or infinite tool loops.
Include an evidence budget, instead of answering without evidence or searching forever.
Include validation rules, instead of relying on the model’s self-discipline.
Tune parameters later, instead of immediately raising reasoning effort.

If your old system prompt is already long, the first step in migrating to GPT-5.5 may not be adding content, but deleting content. Keep the truly non-negotiable rules, and turn process details into outcomes, boundaries, and checks. That is usually more effective than continuing to pile on prompts.

References

OpenAI Prompt guidance: https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5: https://developers.openai.com/api/docs/guides/latest-model

What is cc-haha? A project that turns Claude Code into a desktop workbench

Thu, 14 May 2026 22:38:04 +0800

cc-haha is a project built around a modified Claude Code workflow. Its full repository name is NanmiCoder/cc-haha. The project page says plainly that it is based on Claude Code source code leaked from the Anthropic npm registry on 2026-03-31, and that its current main form is a desktop Claude Code workbench.

Project URL: https://github.com/NanmiCoder/cc-haha

There are two important points in that description.

First, it is not Anthropic’s official Claude Code. The README also states that the original source code copyright belongs to Anthropic and that the project is only for learning and research.

Second, its focus is no longer just “run a Claude Code CLI locally.” Judging from the README and the latest release, cc-haha is more like a desktop app that brings Claude Code sessions, projects, permissions, diffs, Computer Use, remote access, and model provider configuration into one place.

What problem is it trying to solve?

Claude Code is originally terminal-oriented. Sessions, command execution, permission prompts, file edits, and context switching all happen in the terminal. That works for people who are comfortable with CLI tools, but long-term use exposes a few rough edges:

Multiple projects and sessions are hard to manage side by side.
To see what files the AI changed, you often need to switch to Git or an editor.
Permission approvals, command execution, and file diffs are spread across different surfaces.
Remote viewing from a phone or another device requires extra setup.
Connecting non-Anthropic models requires dealing with protocol compatibility.

cc-haha tries to package these pieces into a graphical workbench. It is not just a skin for Claude Code; it moves session management and local development flow control into the desktop app.

Desktop workbench: from terminal to control center

According to the README, the cc-haha desktop app brings these capabilities into a macOS / Windows app:

Multi-session workbench: manage tasks with tabs, project switching, terminal entry points, and session history.
Branch / Worktree launch: choose a repository branch for a new session and decide whether to use the current worktree or an isolated Worktree.
Right-side code changes panel: view modified files, added and removed lines, and workspace status while chatting.
Visualized code edits: inspect AI edits, diffs, and execution steps.
Permission and approval flow: review dangerous commands, tool calls, and AI questions in the desktop app.
Multiple model providers: supports Anthropic-compatible APIs, third-party models, WebSearch fallback, and local configuration.
H5 remote access: use a one-time token to connect to the current desktop session from a phone or another device.
IM integration: use Telegram, Feishu, WeChat, or DingTalk to chat remotely, switch projects, and approve permissions.
Scheduled tasks and token usage: create scheduled tasks and view local token usage trends.

These features make it closer to an “AI coding workbench” than a simple command-line replacement. It tries to put the common surfaces of AI coding into one place: chat, file changes, permissions, projects, remote access, and model configuration.

Installation and startup

Most users should download the desktop installer from Releases.

The README describes the desktop install flow as:

Go to GitHub Releases and download the macOS or Windows installer.
On first launch, configure the model provider, API key, and default model in the desktop settings.
If macOS says the app cannot be opened, follow the installation guide to handle Gatekeeper permissions.

The latest release page shows that v0.2.6 was published on 2026-05-13. That version mainly focuses on restoring secure H5 mobile access, desktop session management, file mention search, and desktop UX polish.

If you want to start the CLI from source, the README provides:

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

That path is better for people who want to debug the lower-level CLI, server, or build their own changes. For normal use, the desktop app is more direct.

What changed in v0.2.6

The main point of v0.2.6 is that H5/LAN access was pulled back from a temporary open state into an explicit enablement and token pairing model.

Notable changes include:

H5/LAN access must be explicitly enabled locally.
QR links carry a one-time visible token.
Remote APIs, proxies, and WebSockets are no longer exposed without protection.
Settings now has a separate H5 Access page.
The desktop sidebar gained batch management for selecting and deleting sessions.
Desktop file mention search became git-first, respects ignore rules, and reduces noise from node_modules and build output.
A pure white theme was added, and bugs such as long URLs breaking chat layout and draft leakage across tabs were fixed.

This shows the project has moved beyond “it runs” and is now filling in the safety boundaries and daily UX details that a desktop product needs.

The H5 access part deserves special care. The author explicitly notes in the release that H5 is a browser access entry for individuals or trusted teams, not a public multi-tenant login system. In practice, it should not be treated as an internet-facing SaaS admin console.

Computer Use: letting the Agent operate the desktop

Another important selling point of cc-haha is Computer Use.

The project docs say this feature is a heavily modified version of the Computer Use implementation in the leaked Claude Code source. The official implementation depends on Anthropic’s private native modules, such as @ant/computer-use-swift and @ant/computer-use-input, which are not publicly available. cc-haha replaces the low-level operation layer with a Python bridge using public libraries such as pyautogui, mss, and pyobjc.

Computer Use supports operations such as:

Screenshot: screenshot, zoom
Mouse: click, drag, move, scroll, and read cursor position
Keyboard: type text, press keys, hold keys
Applications: open applications, switch displays
Permissions: request app access, list granted applications
Clipboard: read and write clipboard content
Other: wait, batch operations

Its workflow is a “screenshot - analyze - act” loop:

The model receives a user request.
It calls screenshot to capture the screen.
The model uses vision to identify buttons, input fields, and coordinates.
It calls click, typing, or application tools.
It screenshots again to confirm the result, then continues.

From the docs, the fully supported platform is mainly macOS, including Apple Silicon and Intel. Windows / Linux are theoretically possible, but the pyobjc app-management parts need platform-specific replacements and are not fully adapted yet.

Runtime requirements include:

Bun >= 1.1.0
Python >= 3.8
macOS Accessibility permission
macOS Screen Recording permission

This kind of feature is powerful, but it also raises permission risk. When letting AI operate desktop apps, it is better to authorize only the applications that are clearly needed and avoid leaving sensitive content open in unrelated windows.

Multi-model access through an Anthropic-compatible layer

cc-haha still communicates using the Anthropic Messages API protocol. The project docs recommend using LiteLLM as a protocol conversion proxy.

The basic structure is:

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

In other words, cc-haha sends Anthropic Messages API requests, LiteLLM converts them to formats such as OpenAI Chat Completions, and then forwards them to OpenAI, DeepSeek, Ollama, or other model services.

The LiteLLM install command in the docs is:

`1`	`pip install 'litellm[proxy]'`

Then you can configure OpenAI, DeepSeek, Ollama, and other models in litellm_config.yaml. After the proxy starts, set these values in .env or ~/.claude/settings.json:

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

There are a few practical caveats:

drop_params: true is important, because Anthropic parameters such as thinking and cache_control do not exist in the OpenAI API.
Extended Thinking is an Anthropic-specific feature and is unavailable with third-party models.
Prompt Caching will not work in the Anthropic-native way.
Tool calls must be converted from Anthropic tool_use to OpenAI function calling, so complex tool use may have compatibility issues.
Small local Ollama models may not handle this tool-heavy workflow reliably.

So multi-model access can work, but that does not mean every model will feel the same. cc-haha still demands strong tool use, code understanding, and long-context ability from the model.

Who is it for?

cc-haha is better suited for:

People already familiar with Claude Code who want desktop session management.
Users who often work across multiple repositories, branches, and AI sessions.
People who want to inspect AI file changes, diffs, and workspace status in a side panel.
Users who want to experiment with Computer Use and let an Agent operate desktop apps.
People who want to connect OpenAI, DeepSeek, Ollama, or other models through an Anthropic-compatible protocol.
Users who need phone or IM-based remote viewing and permission approval.

It is less suitable for:

Users who only want the stable official Claude Code experience.
People who cannot accept the leaked-source background and copyright uncertainty.
Users who do not want to grant high system permissions to local tools.
Teams that need enterprise compliance, auditability, and official support.
Users unfamiliar with API keys, proxies, model compatibility, and local service configuration.

Risks and boundaries

This article cannot only talk about features. It also has to talk about risk.

The origin of cc-haha means it is not an ordinary community reimplementation. The README clearly states that it is based on leaked Claude Code source code and that the original source belongs to Anthropic. This creates uncertainty around copyright, compliance, and long-term maintenance.

Computer Use, H5 remote access, IM integration, and local permission approval are also high-permission capabilities. The more convenient they are, the more clearly boundaries need to be defined:

Do not expose H5 access on untrusted networks.
Do not treat the token as a long-term public login credential.
Do not grant the Agent access to unrelated sensitive applications.
Do not casually use it in production or company compliance environments.
Do not expose third-party model proxy settings or API keys in public repositories.

If your goal is to study AI coding tool architecture, desktop workflows, and Computer Use implementation, it is a useful reference. If you want to put it into a long-term production workflow, evaluate legal, permission, security, and maintenance risks first.

Summary

The most interesting thing about cc-haha is not whether it can replicate Claude Code. It is that it pushes Claude Code-style AI coding tools toward a desktop workbench form.

Sessions, projects, Worktree, diffs, permissions, remote access, Computer Use, model providers, scheduled tasks, and token usage are all brought into one desktop experience. That suggests the next step for AI coding tools is not only stronger models, but also a more complete workflow interface.

But its boundaries are also clear: it is not an official Anthropic product, it has a sensitive source-code background, and its high-permission features require caution. A better way to view it is as a project for observing where AI coding tools may evolve, not as a careless replacement for official Claude Code.

References

GitHub repository: https://github.com/NanmiCoder/cc-haha
Latest release: https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Computer Use documentation: https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
Third-party model documentation: https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal: running long tasks until they are done

Thu, 14 May 2026 22:25:31 +0800

/goal is becoming an important command in AI coding tools.

It is not about making the model write a few more lines of code. It solves a more practical problem: when a task has clear completion conditions, can the agent keep going until those conditions are met, instead of stopping after every turn and waiting for the user to say “continue”?

Codex CLI has already added an experimental /goal command in its official docs. Claude Code has also published its own /goal documentation, describing it as an automation capability that can keep working across multiple turns. The names are the same, but the product direction is not exactly the same.

What problem does `/goal` solve?

Ordinary AI coding conversations usually work as a one-turn-at-a-time loop:

The user describes a task.
The agent analyzes, edits code, and runs tests.
The agent reports the result.
The user decides what to do next.

That workflow is fine for short tasks. But for migrations, refactors, test fixes, or issue backlog cleanup, it gets fragmented. The agent may move forward a little, then stop and wait for you to type “continue”.

/goal changes the question from “what should you do next?” to “what final state counts as done?” For example:

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

This kind of target naturally fits long tasks because it has a clear endpoint: tests pass, the build succeeds, files are split, a queue is empty, or acceptance criteria are satisfied.

Codex `/goal`: experimental and attached to the current thread

OpenAI’s Codex CLI documentation marks /goal as experimental. It is not a stable default capability and requires features.goals to be enabled first.

There are two ways to enable it:

`1`	`/experimental`

Or add this to config.toml:

1
2

[features]
goals = true

Once enabled, you can use it like this:

`1`	`/goal Finish the migration and keep tests green`

Common commands include:

/goal
/goal pause
/goal resume
/goal clear

According to OpenAI’s docs, Codex attaches the goal to the current active thread and keeps tracking that target while a larger task continues.

One detail matters here: the official wording for Codex /goal is restrained. It emphasizes setting an experimental goal for long-running work and attaching the goal to the current thread, but it does not describe, in the same level of detail as Claude Code’s docs, an independent evaluator that automatically checks every turn and starts the next one. So for now, it is better to treat Codex /goal as an experimental long-task goal mechanism, not a fully stable unattended execution mode.

Claude Code `/goal`: multi-turn execution driven by completion conditions

Claude Code’s /goal documentation is more explicit: after the user sets a completion condition, Claude keeps working across turns until that condition is met.

Example:

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code’s mechanism is roughly:

After the current turn finishes, control is not immediately returned to the user.
A small, fast model checks whether the goal condition has already been met.
If it has not been met, Claude automatically starts the next turn.
If it has been met, the goal is cleared automatically and the completion status is recorded in the transcript.

This makes Claude Code’s /goal more like “auto-continue until the completion condition is satisfied.” It does not merely pin a target to the conversation; it gives an independent evaluation step the decision of whether to continue.

Claude Code also supports checking status directly:

/goal

The status shows the goal condition, elapsed time, evaluated turn count, token usage, and the evaluator’s latest reason.

To stop early, use:

`1`	`/goal clear`

stop, off, reset, none, and cancel also work as clearing aliases. After a goal is enabled, if the session is interrupted and later resumed with --resume or --continue, an active goal can be restored. However, elapsed time, turn count, and token baselines are recalculated.

The biggest difference

Both Codex and Claude Code are pushing AI coding from single-turn answers toward long-running task execution, but their /goal commands have different positioning.

Comparison	Codex CLI `/goal`	Claude Code `/goal`
Status	experimental	documented on a dedicated official page
Enablement	requires `features.goals`	usable directly in a trusted workspace
Goal scope	current active thread	current session
Common operations	set / view / pause / resume / clear	set / view / clear
Automatic evaluation	docs emphasize attachment and tracking	docs explicitly describe evaluator checks after each turn
Auto-continuation	official wording is restrained	starts the next turn automatically when conditions are unmet
Best fit	keeping a long-term target in a Codex task	letting Claude Code keep moving toward completion conditions

In short, Codex /goal is closer to “attach an experimental long-term target to the current thread.” Claude Code /goal is closer to “set a verifiable stop condition for the current session and let it keep working until satisfied.”

How to write a good `/goal`

Whichever tool you use, /goal is not a good place for vague wishes.

Not a great goal:

`1`	`/goal 把项目优化一下`

A better goal:

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

A good goal usually includes three things:

A clear completed state.
An executable validation method.
Boundaries that must be respected.

If the goal is large, add a stop condition:

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

This matters. The stronger /goal becomes, the more it needs boundaries. Otherwise, the agent may modify too many files, run too long, consume too many tokens, or keep pushing forward on a question that should have been paused for human input.

When `/goal` is a good fit

Good fits:

Test fixes: until specific tests pass.
Code migrations: until all call sites are updated and compilation succeeds.
Batch cleanup: until a class of lint or type errors is reduced to zero.
Documentation completion: until all specified modules have documentation.
Issue queue handling: until every issue under a tag is handled or clearly classified.

Poor fits:

The requirement itself is still unclear.
The task needs frequent product judgment.
It involves high-risk deletion, data migration, or permission changes.
Acceptance can only be judged subjectively.
The task spans many unrelated modules.

A practical rule: if you can write “which command to run, what result to see, and which files must not be touched,” it is a good candidate for /goal. If you can only write “make this better,” ordinary conversation, plan mode, or human review is still safer.

What this means for AI coding tools

/goal points to a clear direction: AI coding tools are moving from interactive assistants toward continuously executable work units.

In the past, using an agent often meant staying nearby. If it got stuck, you prompted it. If tests finished, you told it to continue. If errors appeared, you issued another command. /goal compresses that interaction into a completion condition and lets the agent decide what the next turn should do.

But this also raises the bar for users. Writing prompts is no longer just describing a task; it also means defining acceptance criteria, validation commands, modification boundaries, and stop rules. In other words, the user’s job shifts from “keep telling it to continue” to “define what done means.”

The fact that both Codex and Claude Code have reached /goal shows that long-running agents are no longer only for background tasks or cloud queues. Local terminal coding tools now also need stronger autonomous progress.

Summary

Codex CLI and Claude Code both have /goal, but at this stage they should not be treated as the same feature.

Codex /goal is still experimental, requires features.goals, and is better understood as a way to maintain a long-term target in the current Codex thread. Claude Code /goal more explicitly connects completion conditions with auto-continuation, using an independent evaluator to decide whether to keep going.

For everyday development, this kind of command is best for engineering tasks with clear acceptance criteria. It does not replace product judgment or code review, but it can reduce the repetitive “continue,” “run it again,” and “fix until tests pass” loop inside long tasks.

The real skill is not memorizing the command. It is learning how to write tasks as clear, verifiable, stoppable goals.

References

OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal documentation: https://code.claude.com/docs/en/goal

What Jensen Huang Was Really Saying in His CMU Speech

Thu, 14 May 2026 20:59:50 +0800

Jensen Huang’s CMU speech looks, on the surface, like a mix of personal memory and startup storytelling. In reality, it was a cold shower for a group of top university graduates.

His core message was not “everything will become easier”. It was this: the AI era has arrived, and the old stable, respectable, linear career path may no longer hold. Young people need to prepare for hardship again, and they may also need to accept work that once looked less glamorous.

First Layer: I Had a Hard Childhood, and You May Have Hard Times Too

Huang talked about his childhood: waking up at 4 a.m. to deliver newspapers, then later washing dishes at Denny’s.

That story is motivational, of course, but it is not just nostalgia for struggle. He was speaking to Carnegie Mellon students, people who would normally have a clear path into investment banks, software companies, tech giants, and high-paying jobs.

So the real point was: do not assume you can graduate and keep walking along the comfortable path that worked for previous generations.

AI is rewriting the value of many jobs. The old model of rising through credentials, resumes, and big-company pipelines may be compressed. Many people may discover that they also have to go through a rougher, less polished, more foundational period of work.

Second Layer: Take Off the Gown and Do the Work That Is Actually Needed

Huang went from delivering newspapers to washing dishes at Denny’s, and described that as a major career advancement.

That sentence matters. He was saying that career value does not necessarily come from the title. It comes from whether you are inside real demand.

In today’s AI industry, the message may be: stop staring only at investment banks, internet software companies, consulting firms, and traditional white-collar jobs. The places that truly lack talent in the future may be more basic, more engineering-heavy, and more physically demanding.

For example:

building data centers;
working on power and cooling;
operating machine rooms;
handling electrical, plumbing, and infrastructure work;
deploying GPU clusters;
delivering AI factory engineering projects.

These jobs do not sound as polished as “joining a big company to write software”. But in the AI era, they may become the new key positions.

So “become a plumber, electrician, or data center builder” is not just a joke. It is a reminder to graduates: AI is not only models and code. It also needs electricity, land, data centers, networks, cooling, operations, and supply chains. Whoever can actually build those things stands in one of the hardest parts of the industry.

Third Layer: Hard Things Are Always Harder Than They Look

Huang also said that whenever NVIDIA ran into trouble, the team would ask: how hard can this be?

The answer, every time, was that it was harder than they first imagined.

That is a sentence every founder and engineer should hear. Many things look like just a project on a slide deck, just a roadmap item in a meeting, or just a trend inside a strategic narrative. But once you actually do them, you run into supply chains, capital, engineering, customers, organizations, competition, and time pressure.

This is especially true in the AI era.

Training models is hard. Deploying models is also hard. Making a demo is hard. Turning a demo into a reliable product is harder. Buying GPUs is hard. Keeping those GPUs fully utilized, stable, and commercially productive is even harder.

So Huang was not offering easy optimism. He was expressing engineering realism: you can be optimistic, but do not underestimate the difficulty.

The Real Reminder in This Speech

If the speech had to be compressed into one sentence, it would be this:

The AI era will not automatically reward smart people. It will reward people willing to enter real difficulty, real infrastructure, and real engineering work.

CMU students will of course still have many opportunities. But if they simply follow the path of previous graduates, find a stable role at a big company, and wait for career inertia to keep working, being left behind is not impossible.

What Huang was really telling them was: do not only imagine yourself walking from a graduation gown into a polished office. The future opportunities may be in data centers, power systems, cooling pipes, GPU clusters, and jobs that do not look elegant or white-collar at first.

AI will not only change software jobs. It will also redefine what counts as a good job.

Connecting Claude to Fusion 360: An Example of Editing STEP Models With AI

Thu, 14 May 2026 20:58:04 +0800

After Claude is connected to Fusion 360, it can do more than “talk through ideas”. It can directly participate in CAD model editing. A typical workflow is to open an existing STEP file, let Claude read the current model, analyze structural conflicts, plan dimensions, and then execute modeling changes through the Fusion plugin.

The following uses a planetary gear indexer modification as an example to summarize the basic Claude + Fusion 360 workflow.

Enable Fusion 360’s API/MCP Service First

Start with a basic Fusion 360 setup:

Open Preferences in the upper-right corner.
Go to General.
Find the API option.
Enable the MCP server.
Note the port number. The default example is 27182.

Then return to Claude, go to Connectors, find the Fusion connector, and enter the Fusion 360 address and port. In most cases, the default port 27182 is enough.

After the connection succeeds, Claude can interact with the currently opened model through the Fusion plugin.

Open the STEP File and Define the Goal Clearly

The part to modify is a gear inside a planetary gear indexer. In the original design, the gear is fixed to the bracket with a screw acting as the central shaft.

The goal is to convert it into a bearing-based structure:

the center hole needs to fit a bearing;
surrounding screw holes must not interfere with the enlarged center hole;
the self-tapping screw hole on the bracket should also be adjusted into a shaft structure suitable for bearing rotation;
the final model should be importable into slicer software and usable for 3D printing.

The key is not to simply tell Claude “modify this for me”. You need to clearly state the use case, assembly method, material, and manufacturing process.

Claude Can Understand the Current Model Through Screenshots

Some people worry that the Fusion plugin can only execute commands and cannot let Claude see the model. In actual testing, Claude can recognize the current model state through screenshots.

In this case, Claude could see the gear structure and complete several tasks:

identify the gear and center hole;
measure or estimate related dimensions;
recommend bearing dimensions;
judge which structures would affect bearing installation;
notice that after enlarging the center hole, surrounding screw holes might create geometric interference.

This step matters. It shows that Claude is not blindly editing from text instructions. It can combine the current model view with structural reasoning.

Specify Material and Manufacturing Method in Advance

If the model will be used for 3D printing, you must clearly tell Claude the material and process.

For example, when printing with PLA, the bearing hole should not be designed strictly according to CNC metal machining tolerances. For a 6mm bearing that needs a press fit, a hole diameter around 6.1mm may be considered. Whether that size is appropriate still depends on printer accuracy, material shrinkage, slicer settings, and real testing.

If you do not specify the material, Claude may default to CNC-style tolerances. The resulting hole size may be too small for 3D printing, making assembly difficult.

A useful prompt might be:

1
2
3

This model is for FDM 3D printing, using PLA.
The goal is to install a 6mm bearing, so printing tolerance and press fit should be considered.
Do not handle it as CNC metal machining tolerance.

Let Claude Modify the Gear Structure

After the goal is clear, Claude can perform specific modifications:

enlarge the center hole;
adjust surrounding screw holes that interfere;
add a bearing seat;
add chamfers to edges;
keep the gear body and key meshing structure unchanged.

In this case, Claude first produced a plan and then called Fusion 360 to perform modeling operations. For example, after detecting a conflict between the original screw holes and the center hole, it moved the holes slightly outward to protect the bearing installation space.

After modification, check the model:

whether the central bearing seat is formed correctly;
whether surrounding holes still preserve their function;
whether the gear structure was accidentally damaged;
whether chamfers affect assembly;
whether there are overhangs, thin walls, or slicing risks.

The Bracket Must Be Modified Too

Changing only the gear is not enough. The original bracket had a self-tapping screw hole. If the gear center is converted to a bearing, the bracket must also be changed into a bearing shaft structure.

You can ask Claude to perform a similar modification on the bracket:

preserve the overall mounting position;
convert the original self-tapping screw hole into a cylindrical shaft;
control shaft diameter and height;
reserve space for bearing rotation;
avoid interference with other bracket structures.

After printing, the gear can be pressed into the bearing, and the bracket can provide the new rotation center. The final result changes a screw-fixed structure into a smoother bearing-rotating structure.

Export, Slice, and Print for Verification

After the CAD modification is done, the actual manufacturing process still matters:

Export the modified model from Fusion 360.
Import it into slicer software.
Check holes, thin walls, overhangs, and supports.
Print the gear and bracket.
Press the bearing into place.
Check whether rotation is smooth.

AI-edited CAD results cannot be judged only by whether the on-screen model looks good. They must be verified through printing. For mechanical structures such as bearings, holes, clips, and gears, an error at the 0.1mm level can decide whether the part fits and rotates smoothly.

Usage Suggestions

Claude + Fusion 360 is well suited for:

making local modifications to existing STEP models;
adjusting holes, chamfers, brackets, and mounting seats;
converting screw-fixed structures into bearing, snap-fit, or pin structures;
correcting tolerances for 3D printed models;
quickly generating multiple revised versions.

But it is not suitable for directly producing final parts without inspection. A more reliable workflow is:

Define the assembly goal and material process yourself.
Let Claude analyze the structure and propose modifications.
Let Claude call Fusion to execute modeling.
Manually check key dimensions and interference.
Print a small test sample.
Iterate based on the physical result.

Summary

The value of connecting Claude to Fusion 360 is not replacing CAD fundamentals. It is making local edits to existing models much faster.

As long as you clearly specify the goal, material, dimensions, tolerance, and assembly method, it can help read the model, find interference, modify structures, add chamfers, and push the model toward a printable state. For 3D printing, open-source mechanical part modification, and small-batch iteration in personal workshops, this AI CAD workflow is already practical.

How Can Codex Use Chinese LLMs? Managing OpenAI-Compatible APIs with CCX

Wed, 13 May 2026 23:20:40 +0800

CCX is an AI API proxy and protocol-conversion gateway. It puts Claude Messages, OpenAI Chat Completions, OpenAI Images, Codex Responses, and Gemini API behind one service entry point, while also providing a web management UI for configuring channels, keys, model mappings, priorities, failover, and traffic monitoring.

If you use Claude, OpenAI, Gemini, and Codex at the same time, or maintain multiple upstream services compatible with OpenAI API, CCX is valuable because it gives you one entry point and one management layer. Clients connect to a single service address; CCX decides which upstream channel should handle each request.

Project: https://github.com/BenedictKing/ccx

What problem does CCX solve?

When multiple AI APIs are used together, several problems appear quickly:

Each provider has different paths, authentication, and request formats.
One class of models may have multiple upstreams, requiring manual switching of base URL and API key.
When a key or channel fails, the client usually does not automatically switch to a backup channel.
In team use, it is hard to centrally manage model allowlists, proxies, custom headers, and request logs.
When Claude, Gemini, OpenAI Chat, image APIs, and Codex Responses all need to coexist, configuration becomes scattered.

CCX’s approach is to consolidate these differences into a proxy layer. Frontend tools, scripts, or business services call CCX; CCX then routes the request to a suitable upstream based on API type, model, channel status, priority, and health.

Supported endpoints

CCX exposes one backend entry point. The default port is 3000. Main paths include:

GET  /                         -> Web management UI
GET  /health                   -> Health check
/api/*                         -> Management API
POST /v1/messages              -> Claude Messages proxy
POST /v1/chat/completions      -> OpenAI Chat proxy
POST /v1/responses             -> Codex Responses proxy
POST /v1/images/generations    -> OpenAI Images generation
POST /v1/images/edits          -> OpenAI Images editing
POST /v1/images/variations     -> OpenAI Images variations
GET  /v1/models                -> Model list
POST /v1beta/models/*          -> Gemini proxy

In other words, CCX does not proxy only one protocol. It manages common AI APIs as separate channel types: Messages, Chat, Responses, Gemini, and Images. Different protocols do not share the same health state or log space, which matters when troubleshooting.

Architecture overview

CCX uses a Go backend and Vue 3 frontend. The frontend build is embedded into the backend binary, so it can be deployed on a single port: the same service provides the Web UI, management API, and proxy API.

A request roughly follows this path:

`1`	`Client -> Auth Middleware -> Route Handler -> Channel Scheduler -> Provider / Converter -> Upstream API -> Metrics / Channel Logs -> Client Response`

The main modules can be understood as follows:

handlers: receive requests for different protocols and management operations.
providers: wrap upstream API request and response handling.
converters: handle protocol conversion for scenarios such as Responses.
scheduler: choose channels based on priority, promotion period, health state, circuit breaker state, and trace affinity.
metrics: record request counts, success rate, latency, logs, and circuit breaker state.
config: maintain runtime configuration, with hot reload and backup support.

The design is not about forcing every API into one format. It proxies each protocol type separately, while unifying management, scheduling, logging, and authentication.

CCX vs CodexBridge

CCX and CodexBridge are both related to Codex and OpenAI-compatible APIs, but they solve different problems.

CodexBridge is more like a dedicated Codex bridge. Its main goal is to wrap Codex CLI/SDK as an OpenAI-compatible /v1/chat/completions service, so OpenWebUI, Cherry Studio, scripts, or other OpenAI-compatible clients can call local Codex. In short, CodexBridge focuses on exposing Codex.

CCX is more like a unified AI API gateway. It does not only handle Codex Responses; it also supports Claude Messages, OpenAI Chat, OpenAI Images, and Gemini API, with a web management UI, channel priority, failover, log monitoring, and multi-key management. In short, CCX focuses on managing multiple models and providers together.

Quick comparison:

Item	CodexBridge	CCX
Core positioning	Local Codex bridge	Multi-protocol AI API gateway
Main goal	Turn Codex into an OpenAI-compatible endpoint	Manage Claude, OpenAI, Gemini, Codex, and other channels together
Management UI	Focuses on the API service itself	Provides a web management UI
Multi-channel scheduling	Not the focus	Supports channel priority, failover, and log monitoring
Best fit	Local or single-service Codex calls	Teams, multiple keys, multiple providers, multiple protocols

If you only want to connect Codex to OpenWebUI or Cherry Studio, CodexBridge is more direct. If you want to manage Codex, Claude, Gemini, DeepSeek, Qwen, Kimi, and other upstreams together, CCX is a better fit.

Quick deployment

The simplest way is to download the binary. After downloading it, create .env in the same directory:

PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3000
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=zh-CN

After startup, open:

`1`	`http://localhost:3000`

If localhost does not work from WSL, Docker, PowerShell, or another Windows environment, use the Windows host’s LAN IPv4 address instead, for example:

`1`	`http://192.168.1.23:3000`

By default, CCX listens on :PORT for all network interfaces, so access control matters if it is exposed to a LAN.

Docker deployment

Docker is suitable for long-running service deployment:

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=zh-CN \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

If the repository already has docker-compose.yml, you can also run:

`1`	`docker compose up -d`

For automatic updates, add the Watchtower configuration:

`1`	`docker compose -f docker-compose.yml -f docker-compose.watchtower.yml up -d`

After deployment, .config stores runtime configuration and persistent data. Mount it to the host to avoid losing configuration when the container is recreated.

Running from source

For development or custom builds:

git clone https://github.com/BenedictKing/ccx
cd ccx
cp backend-go/.env.example backend-go/.env
make run

Common commands:

make dev
make run
make build
make frontend-dev

Frontend-only development:

1
2
3

cd frontend
bun install
bun run dev

Backend-only development:

1
2

cd backend-go
make dev

Key environment variables

Minimal usable configuration usually includes:

PORT=3000
ENV=production
ENABLE_WEB_UI=true
PROXY_ACCESS_KEY=your-proxy-access-key
ADMIN_ACCESS_KEY=your-admin-secret-key
APP_UI_LANGUAGE=zh-CN
LOG_LEVEL=info
REQUEST_TIMEOUT=300000

Notes:

PROXY_ACCESS_KEY is used for the proxy API and must be changed.
ADMIN_ACCESS_KEY is used for the Web UI and /api/*; it should be separate from the proxy key.
ENABLE_WEB_UI controls whether the management UI is enabled.
REQUEST_TIMEOUT controls request timeout; increase it for long-context or image tasks.
LOG_LEVEL controls log verbosity; production usually uses info or warn.

To limit request body size, check:

`1`	`MAX_REQUEST_BODY_SIZE_MB=50`

Image editing, base64 images, and multimodal requests can all increase request body size.

Channel orchestration and failover

The CCX management UI can configure multiple channels, with options such as:

Upstream service type.
API key or multi-key rotation.
Proxy address.
Custom request headers.
Model allowlist.
Route prefix.
Priority.
Health checks and circuit-breaker recovery.

Scheduling considers channel state, priority, promotion period, trace affinity, circuit-breaker state, and available keys. In simple terms:

Under normal conditions, higher-priority channels are used first.
If one channel fails, CCX can fail over to a backup channel.
Circuit breaking avoids repeatedly hitting an obviously unavailable upstream.
Trace affinity tries to keep related sessions on suitable channels.

These features are useful when you have multiple keys, providers, or regional upstreams. For personal lightweight use, you can also configure only one channel and use CCX as a proxy layer with a Web UI.

Logs and monitoring

CCX provides channel metrics and request logs, including:

Request volume.
Success rate.
Failure rate.
Average latency.
Historical data by model.
Channel status and circuit-breaker state.

For production, use relatively conservative logging:

ENV=production
LOG_LEVEL=info
ENABLE_REQUEST_LOGS=true
ENABLE_RESPONSE_LOGS=false

This keeps basic request information while avoiding full response content in logs. You can temporarily enable more detailed logs for troubleshooting, but restore the safer configuration afterward, especially in production.

Security recommendations

CCX is a proxy gateway and stores upstream API keys, so deployment should not stop at “it runs.” At minimum:

Do not use a default or short PROXY_ACCESS_KEY.
Set a separate ADMIN_ACCESS_KEY.
Do not expose the Web UI directly to the public internet.
If public access is required, place it behind a reverse proxy, VPN, access control, or SSO.
Do not commit .env, .config, or log files to Git.
Do not keep full request and response body logging enabled in production.

You can generate random keys like this:

1
2

PROXY_ACCESS_KEY=$(openssl rand -base64 32)
ADMIN_ACCESS_KEY=$(openssl rand -base64 32)

Who should use it?

CCX is better suited to these scenarios:

Maintaining Claude, OpenAI, Gemini, Codex, or image APIs at the same time.
Having multiple API keys that need rotation, routing, and failover.
Managing upstream channels through a Web UI instead of editing config files manually.
Observing success rate, latency, and logs for each channel.
Providing one unified AI API entry point for a team.

If you only call one model occasionally on your own machine, the official SDK or a single OpenAI-compatible proxy is simpler. CCX’s advantage is multi-channel, multi-protocol, unified operation.

Summary

CCX is an AI API gateway, not a client for one specific model. It puts Claude Messages, OpenAI Chat, OpenAI Images, Codex Responses, and Gemini into one proxy layer, with channel orchestration, failover, logs, monitoring, and a Web management UI.

For individuals, it reduces the trouble of switching API addresses and keys. For teams or long-running services, it is closer to a lightweight AI gateway. Before production use, the important work is not only configuring models, but also securing keys, the management entry point, logging levels, channel priority, and failover strategy.

References

GitHub project: https://github.com/BenedictKing/ccx
Architecture notes: https://github.com/BenedictKing/ccx/blob/main/ARCHITECTURE.md
Environment variables: https://github.com/BenedictKing/ccx/blob/main/ENVIRONMENT.md

How Can Codex Use Chinese LLMs? OpenAI-Compatible APIs and the CodexBridge Approach

Wed, 13 May 2026 23:08:28 +0800

CodexBridge is a local bridge for exposing Codex CLI/SDK as an OpenAI-compatible HTTP service. With it, Codex no longer has to live only in the terminal. OpenWebUI, Cherry Studio, scripts, automation systems, or any client that supports OpenAI Chat Completions can call it.

The two core endpoints are /v1/chat/completions and /v1/models. The former handles conversations and supports both normal and SSE streaming responses. The latter lets clients discover models in the same way they read an OpenAI-style model list. For tools that already support OpenAI APIs, this usually means changing only the base URL, API key, and model name.

Project: https://github.com/begonia599/CodexBridge

What it is useful for

CodexBridge is useful when you want to plug Codex into existing AI clients or workflows. For example:

Select Codex directly in OpenWebUI or Cherry Studio.
Call local Codex from curl, Python, Node.js, or other scripts.
Let one frontend connect to OpenAI, Ollama, other compatible APIs, and Codex at the same time.
Keep Codex’s local threads, sandbox, working directory, and approval behavior.
Provide a unified /v1/chat/completions endpoint for internal tools.

It is not a new LLM, and it is not a full replacement for Codex CLI. More precisely, it is an adapter layer: Codex remains the upstream engine, while the bridge converts OpenAI-style requests into conversation input that Codex can handle.

Basic requirements

You need:

Node.js 18 or later.
Codex CLI installed and logged in.
npm, or pnpm / yarn if you prefer.

Basic source deployment:

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

Then edit .env or .env.local to set the API key, default model, working directory, sandbox mode, network access, and related options.

Start the HTTP service:

`1`	`npm run codex:server`

The default port is 8080, and it can be changed with PORT. After startup, the service exposes:

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

CLI conversation mode

Besides the HTTP service, CodexBridge also includes a lightweight CLI:

`1`	`npm run codex:chat`

You can type natural-language messages directly. Two useful commands are:

/reset: create a new Codex thread.
/exit: exit the CLI.

The current thread ID is stored in .codex_thread.json. If this file still exists the next time the CLI starts, the previous conversation can continue.

HTTP example

A minimal request looks like this:

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

Key points:

The token in authorization must match CODEX_BRIDGE_API_KEY.
model can include reasoning effort, such as gpt-5-codex:medium or gpt-5-codex:high.
session_id binds the request to a conversation and allows reuse of the same Codex thread.

For streaming output, add stream: true:

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"Explain step by step how to create a Node.js project"}]}'

For clients that support OpenAI streaming responses, this feels much closer to a normal chat experience.

How sessions are persisted

Session mapping is one of CodexBridge’s important features. A request can pass a session ID through these fields:

session_id
conversation_id
thread_id
user

It can also be passed through request headers:

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

For production use, enable:

`1`	`CODEX_REQUIRE_SESSION_ID=true`

This requires every request to include a session ID, preventing different users or chat windows from being mixed into the same temporary context. The bridge-side mapping is saved in .codex_threads.json. Deleting this file resets the bridge mapping, while Codex’s own threads remain under ~/.codex/sessions.

If CODEX_REQUIRE_SESSION_ID=false and the request provides no session ID, the bridge expands the current messages into one-off input for Codex. This is fine for temporary calls, but not for long-running conversations.

Multimodal input

CodexBridge supports OpenAI-style content blocks and converts images into Codex-compatible local_image input.

Remote images can be written as:

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

Local images can be written as:

{
  "type": "local_image",
  "path": "./images/demo.png"
}

Remote resources are downloaded into a temporary directory and cleaned up after the turn. In real use, watch the request body size, especially when sending base64 images. You may need to increase CODEX_JSON_LIMIT.

Structured output

If the client supports response_format, CodexBridge can map it to Codex’s outputSchema. This is useful when you want Codex to return a fixed JSON structure, such as a check result, summary, classification result, or automation report.

A minimal example:

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "Check lint issues under src/ and return the result as JSON"
    }
  ]
}

type: "json_schema" must include a schema, otherwise the service returns 400.

Key environment variables

Common configuration can be grouped as follows.

Service and authentication:

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

Default model:

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Codex runtime:

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

Network access:

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

If the service is only used for frontend chat, keeping network access off by default is safer. Enable these switches only when Codex clearly needs to run curl, git clone, or web search.

Docker and one-line scripts

The project also provides Docker deployment for long-running service use:

1
2

docker compose up -d
docker compose logs -f codexbridge

It also provides a Linux install script:

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

The script installs dependencies, clones or updates the repository, copies .env.example, and starts the service with Docker Compose. It requires sudo, so it is best suited to a clean server. If the machine already has a complex Node.js, Docker, or Codex setup, read the script before running it.

Common issues

Request returns 413

The request body is usually too large, often because of base64 images. Increase:

`1`	`CODEX_JSON_LIMIT=20mb`

API key is rejected

Check that the request header includes:

`1`	`Authorization: Bearer <your CODEX_BRIDGE_API_KEY>`

or use x-api-key.

Codex reports a Git repository restriction

If the working directory is not a trusted repository, Codex may trigger a check. Use this only in an environment you trust:

`1`	`CODEX_SKIP_GIT_CHECK=true`

Reset conversations

The bridge mapping lives in .codex_threads.json, while Codex’s own threads live in ~/.codex/sessions. Stop the service and delete the corresponding files or directories to reset them.

Recommendations

For local testing, start with the default API key and the read-only sandbox. After OpenWebUI, Cherry Studio, or scripts can call the service normally, gradually adjust CODEX_WORKDIR, CODEX_SANDBOX_MODE, CODEX_NETWORK_ACCESS, and CODEX_APPROVAL_POLICY.

For multi-user use, do at least three things:

Require session_id.
Change the default API key.
Clearly limit the working directory and sandbox permissions.

CodexBridge is valuable not because it is complex, but because it places Codex inside the existing OpenAI-compatible ecosystem. If a client can change its base URL, it can treat Codex like a normal chat model while still retaining Codex’s local threads, sandbox, and tool behavior.

Computer Terms in Plain Language: What TTS, STT, API, RAG, and Agent Really Mean

Tue, 12 May 2026 22:15:34 +0800

Computer science has many terms that sound advanced the first time you hear them. But once translated into plain language, many of them describe everyday actions.

For example, when AI can speak, it is called TTS; when AI can listen to you, it is called STT. It sounds like a complex system, but the simple version is “read text aloud” and “write down speech.”

Reference link: https://www.zhihu.com/question/267978646/answer/2035405228460201515

This article strings together several common terms from that angle: keep the terms themselves, but explain them in plain language.

TTS and STT: Converting Between Text and Speech

TTS means Text-to-Speech. It converts a piece of text into playable audio. Navigation announcements, audiobook reading, AI customer service voices, and voice assistants all use this kind of capability.

STT means Speech-to-Text. It does the reverse: it turns spoken audio into text, then passes that text to the next program. Voice input, meeting transcription, automatic subtitles, and smart speakers all rely on STT.

Many voice AI products are basically this pipeline:

STT: convert what you said into text.
LLM: generate a reply from that text.
TTS: read the reply aloud.

So it may feel like a natural conversation, but underneath, several modules are handing work to one another.

OCR: Copying Text Out of Images

OCR means Optical Character Recognition.

In plain language, it copies text out of images. Taking a photo of an invoice, scanning a page from a book, or reading a name and ID number from an identity document are all OCR tasks.

Early OCR was closer to “guess the character shape.” Modern OCR uses deep learning and is more tolerant of messy backgrounds, tilted text, handwriting, and blurry images. But the core question remains simple: what words are in the image?

NLP and LLM: Letting Machines Handle Human Language

NLP means Natural Language Processing. It deals with human language: tokenization, translation, summarization, sentiment analysis, question answering, classification, and more.

LLM means Large Language Model. It can understand and generate text, so many NLP tasks today are handled by LLMs.

Plain-language version:

NLP: make machines process what people say and write.
LLM: a larger text model that can handle many language tasks.

When you ask AI to summarize an article, write an email, polish a title, or explain code, it all belongs to this broad direction.

API and SDK: One Is an Interface, the Other Is a Toolkit

API means Application Programming Interface.

In plain language, someone exposes an entry point for you to call a capability. A weather API takes a city and returns weather; a payment API takes an order and returns a payment result.

SDK means Software Development Kit.

In plain language, the official team packages common code, types, examples, and tools so you can call the API more easily. An API is like the restaurant counter; an SDK is like the ordering app. You can talk to the counter directly, or use the app to make ordering easier.

CRUD: Create, Read, Update, Delete

CRUD means Create, Read, Update, and Delete.

In plain language: add, view, edit, and delete.

Many admin systems, management systems, and database operations revolve around CRUD. User management, article management, order management, and inventory management may look like different businesses, but underneath they are often forms plus create/read/update/delete operations.

That is why programmers say they wrote “another CRUD.” It is not necessarily dismissive; it is simply very common.

Cache: Keep a Copy So You Do Not Recompute Every Time

Cache means caching.

In plain language, keep frequently used things close by so you can grab them directly next time instead of searching, computing, or requesting them again.

Web pages can cache images and scripts; slow database queries can put hot results in Redis; expensive model inference can cache answers to repeated questions.

The hard part of caching is not “keeping a copy,” but “knowing when to update it.” If the data changes but the cache does not, users see stale data. That is the root of many cache problems.

Queue: Line Up Tasks and Process Them Slowly

Queue means a queue.

In plain language: too many things are happening, so put them in line and process them one by one.

For example, after a user uploads a video, transcoding may not finish immediately. The system can put the job into a queue and let a background service process it later. Sending SMS messages, emails, reports, and order callbacks also commonly use queues.

Queues solve the problem of not blocking the current request with every slow task. The user gets a response first, and time-consuming work happens later.

Index: A Table of Contents for the Database

Index means an index.

A database index is like a table of contents in a book. Without it, you may need to scan from the first page to the last page; with it, you can locate content much faster.

But more indexes are not always better. Queries may become faster, while writes and updates may become slower, because the index also needs to be maintained when data changes.

That is why database optimization often starts with indexes. But when creating one, you still need to consider query conditions, sorting fields, data volume, and write frequency.

RPC, REST, and Webhook: How Systems Talk to Each Other

RPC means Remote Procedure Call.

In plain language, it lets you call a function on another machine as if it were a local function.

REST is common in Web APIs. It uses URLs and HTTP methods to describe operations on resources, such as GET /users to query users and POST /orders to create orders.

Webhook is a callback in the opposite direction. Instead of constantly asking “is it done?”, the other side calls your URL when something happens.

Simple memory aid:

RPC: call a remote function.
REST: manage resources with HTTP.
Webhook: notify you when something happens.

CDN means Content Delivery Network.

In plain language, put static resources on nodes closer to users. When users access images, videos, CSS, or JS, they do not always have to reach the origin server.

Load Balancing means load balancing.

In plain language, when traffic is too high, do not make one server carry everything; distribute requests across multiple machines.

One is about being closer to users; the other is about not exhausting one machine. Large websites usually use both.

Docker, Container, and Kubernetes: Package, Run, and Schedule

Docker is a common container tool, and Container means container.

In plain language, package the program together with its runtime environment so it can run similarly on another machine. This reduces “it works on my computer but not on the server” problems.

Kubernetes, often written as K8s, is a container orchestration system.

In plain language, when there are many containers, it decides where they run, how to restart them if they fail, how to route traffic, and how to roll out versions.

If you only have one small service, Docker may be enough. If you have many services, machines, and replicas, K8s becomes more useful.

CI/CD: Automated Build and Deployment

CI means Continuous Integration.

In plain language, whenever code is submitted, the system automatically pulls the code, runs tests, and builds it to catch problems early.

CD can mean Continuous Delivery or Continuous Deployment.

In plain language, after the build passes, the code is delivered to testing or production environments in a more stable and automated way.

It does not solve “how to write code”; it solves “how to ship code with fewer mistakes.”

Serialization: Pack Objects Into a Transmittable Format

Serialization means turning objects inside a program into a format that can be saved or transmitted, such as JSON, XML, or Protobuf.

The reverse, Deserialization, turns those formats back into objects the program can use.

When frontend and backend exchange JSON, or services exchange Protobuf, serialization is involved.

Token, Embedding, and Vector DB: Turning Text Into Forms Models Can Process

In large models, Token usually refers to the basic units that text is split into. It is not necessarily one Chinese character or one English word; it is more like the model’s internal granularity for processing text.

Embedding means an embedding vector.

In plain language, it turns text, images, or other content into a sequence of numbers so models can compare similarity.

Vector DB means vector database.

In plain language, it stores those vectors and can quickly find content with similar meaning.

For example, if you ask “how do I reset my router?”, the system may search the vector database for content about “factory reset,” “forgot Wi-Fi password,” or “admin login failure,” then pass related materials back to the model.

RAG: Search First, Then Answer

RAG means Retrieval-Augmented Generation.

In plain language, before the model answers, it first searches a knowledge base and then answers with those materials.

It addresses the problem that large models may make things up from memory. By connecting enterprise documents, knowledge bases, product manuals, or code snippets, the model can refer to your latest materials instead of relying only on training memory.

A typical flow is:

The user asks a question.
The system turns the question into an Embedding.
It searches related documents in a Vector DB.
It sends the document snippets and the question to an LLM.
The model generates an answer.

So RAG sounds advanced, but the essence is: look up the materials first, then organize the answer.

Agent: An Automated Flow That Can Break Down Tasks

In AI contexts, Agent often means an intelligent agent.

In plain language, it does not just answer one message. It can break a goal into steps, call tools, observe results, and decide the next action.

For example, if you ask it to analyze why tests fail in a repository, a regular chat model may only give suggestions. An Agent may read files, run tests, inspect errors, edit code, and run tests again.

Of course, Agent does not mean guaranteed reliability. It is essentially “model + tool calling + state loop.” Whether it works well depends on tool permissions, task boundaries, error handling, and human confirmation.

Summary

Many computer terms sound impressive because they are wrapped in acronyms, architecture diagrams, and product copy. Once unpacked, many describe very simple actions:

TTS: read text aloud.
STT: write down speech.
OCR: copy text out of images.
API: expose a calling entry point.
SDK: package calling tools.
CRUD: create, read, update, delete.
Cache: keep a copy of common results.
Queue: line tasks up for later processing.
Index: add a table of contents to data.
CDN: put content closer to users.
Load Balancing: distribute requests.
Docker: package the runtime environment.
CI/CD: automate testing and deployment.
Embedding: turn content into numeric vectors.
RAG: search first, then answer.
Agent: let a model use tools step by step.

The terms should be preserved because they make searching, communication, and documentation easier. But you do not need to be intimidated by them. Translate them into plain language first, then return to the technical details; many concepts become much clearer.

Reference

Zhihu answer: https://www.zhihu.com/question/267978646/answer/2035405228460201515

Can Sulphur 2 Run on 8GB VRAM? Notes on Local Deployment of an LTX 2.3 Video Model

Tue, 12 May 2026 22:12:45 +0800

SulphurAI has released Sulphur-2-base on Hugging Face. According to the model card, Sulphur 2 is a video generation model based on LTX 2.3. It is positioned as an uncensored video generation model, natively supports text-to-video and image-to-video, and is compatible with other LTX 2.3 formats.

Model page: https://huggingface.co/SulphurAI/Sulphur-2-base

What Is Sulphur 2?

Sulphur 2 is not a general-purpose chat model. It is centered on video generation workflows and provides model weights plus related tools. The key points from the model card are:

Based on LTX 2.3.
Supports text-to-video and image-to-video.
Provides a prompt enhancer for improving prompts.
The Hugging Face page exposes entry points for Diffusers, llama.cpp, Ollama, LM Studio, Jan, and more.
The model files include GGUF-related assets, making them easier to load with some local tools.

In other words, it is aimed more at video generation enthusiasts and workflow builders than at ordinary users looking for a one-click web product.

The Relationship Between Sulphur 2 and LTX 2.3

To understand Sulphur 2, it is best to place it inside the LTX 2.3 ecosystem.

LTX 2.3 is the underlying video generation model line. It determines the supported input types, model components, and workflow structure. Sulphur 2 is a variant released on top of that foundation, focusing on text-to-video, image-to-video, and related workflows.

So Sulphur 2 is not a completely independent new tool, nor is it a regular chat model. It is closer to a model package in the LTX 2.3 ecosystem: you still need to choose the right frontend, nodes, weight version, and parameters before you can actually generate video.

That also explains why it has a higher barrier than web-based generation tools. Web tools hide models, parameters, VRAM scheduling, and retries on the backend; local deployment means you have to handle those details yourself.

Why It Is Worth Watching

The LTX family is already known for efficient video generation. Since Sulphur 2 is based on LTX 2.3, it naturally fits existing LTX workflows. For ComfyUI, Diffusers, or local inference users, the value is mainly in controllability and the ability to modify workflows.

Another point is the prompt enhancer. Video generation is highly sensitive to prompts. The same subject, camera movement, action, style, and quality description can produce very different results depending on wording. By including a prompt enhancer, Sulphur 2 is clearly trying to help users turn ordinary descriptions into prompts that the model can handle more reliably.

Suggestions From the Model Card

The official model card recommends starting with the dev version, such as fp8mixed or bf16, and using the provided distill lora. It also warns that if you use the LoRA, you should not load the duplicate full-model components at the same time, otherwise the workflow may stack the same capability twice.

The prompt enhancer is closer to a local tooling workflow. The model card says you can create a Sulphur/promptenhancer directory inside LM Studio’s model folder, put the gguf and mmproj files there, and load the enhancer. It does not require a system prompt; you send the text you want to enhance directly, and images can also be attached.

Local Runtime Entry Points

The Hugging Face page lists several common local entry points. With llama.cpp, for example, you can start a local server from the model repository:

`1`	`llama-server -hf SulphurAI/Sulphur-2-base:BF16`

You can also run it from the terminal:

`1`	`llama-cli -hf SulphurAI/Sulphur-2-base:BF16`

For Ollama, the entry point is:

`1`	`ollama run hf.co/SulphurAI/Sulphur-2-base:BF16`

These commands are closer to automatically generated Hugging Face loading examples. Whether they run smoothly depends on your VRAM, model file version, quantization format, and tool compatibility. Video generation models are usually much heavier than text-only models, so for the first attempt it is better to follow the model card’s recommended version and workflow instead of mixing weights from different sources.

Choosing a Test Environment: ComfyUI, Diffusers, or GGUF

If you only want to see results quickly, first look for a community ComfyUI workflow. ComfyUI is visual, so models, LoRA, samplers, resolution, frame count, and post-processing nodes can all be laid out in one graph. That makes it useful for debugging video generation.

If you are more comfortable with Python, or if you want to connect Sulphur 2 to your own scripts, Diffusers is a better fit. It is reproducible and easier to automate, so it works well for batch parameter tests and for recording VRAM usage and generation time under different settings.

GGUF, llama.cpp, Ollama, and LM Studio are more suitable for the prompt enhancer or text-side components. Do not assume that GGUF alone means the full video generation pipeline is covered. Video models often involve vision models, VAE, sampling flows, and frame generation components. GGUF is only one part of the local loading and lightweight tooling ecosystem.

In short:

Beginners should first look for a ComfyUI workflow.
Script users can use Diffusers for reproducible and batch tests.
Use GGUF / LM Studio / Ollama mainly for prompt enhancers or text enhancers.
When unsure, follow the dev version and LoRA combination recommended in the model card.

Can 8GB VRAM Run It? It Depends on Version and Workflow

Whether Sulphur 2 can run on 8GB VRAM depends not only on the model name, but also on the exact version, quantization method, resolution, frame count, batch size, and workflow.

In general, video generation consumes more VRAM than image generation because it is not generating a single image. It needs to handle multiple frames, temporal consistency, and video-related intermediate states. Even if the model itself has lighter versions, adding LoRA, higher resolution, longer frame counts, or extra post-processing nodes can quickly exceed 8GB.

If you only have 8GB VRAM, try reducing pressure in these ways:

Prefer fp8mixed, quantized versions, or community low-VRAM workflows.
Lower the resolution and first confirm that the pipeline can run at a small size.
Reduce the frame count; do not start with long videos.
Set batch size to 1.
Disable unnecessary enhancement and post-processing nodes at first.
Use CPU offload, low-VRAM mode, or framework-provided memory optimizations.

So a more accurate version of “8GB VRAM can run it” is: under a low-memory version, lower resolution, shorter frame count, and simplified workflow, it may run; but it is not realistic to expect high-resolution, long-video, complex workflows on 8GB.

How to Use the Prompt Enhancer

The Sulphur 2 model card specifically mentions a prompt enhancer. Its job is not to generate videos, but to rewrite ordinary prompts into prompts that the model can understand better.

Video prompts usually need to describe the subject, action, camera, scene, lighting, style, and quality. If the prompt is too short, the model may miss the important parts. A prompt enhancer can expand a simple description into a more complete video generation prompt and improve stability.

The model card suggests creating a Sulphur/promptenhancer directory inside the LM Studio model directory, putting the corresponding gguf and mmproj files there, and loading the enhancer. It does not require a system prompt; send the text you want to enhance directly, and images can be attached too.

You can think of it as a prompt preprocessor:

`1`	`plain description -> prompt enhancer -> fuller video prompt -> Sulphur 2 workflow`

If you are only testing whether the model can run, the prompt enhancer is not the first priority. Get the main workflow running first, then use it to improve prompts. That makes troubleshooting much easier.

Common Local Deployment Failures

Local deployment of models like Sulphur 2 usually fails for more than one possible reason. Common pitfalls include:

Model version and workflow mismatch, such as using weights different from the dev version expected by the workflow.
Loading both LoRA and duplicate full-model components, causing abnormal behavior or excessive VRAM usage.
Insufficient VRAM, especially with high resolution, long frame counts, or complex nodes.
Tool versions are too old, such as incompatible ComfyUI nodes, Diffusers, Transformers, or Accelerate.
Missing supporting files such as VAE, text encoder, mmproj, or prompt enhancer files.
File paths or directory structure do not match tool requirements.
Copying a Hugging Face command without confirming whether it applies to the main video generation pipeline or only to a text-side component.

When troubleshooting, go step by step: verify model files, confirm the workflow’s expected version, lower resolution and frame count, then add LoRA, prompt enhancer, and post-processing nodes gradually. Change only one variable at a time; it is the easiest way to locate problems.

Who Should Try It?

Sulphur 2 is better suited for users who:

Already use LTX, ComfyUI, Diffusers, or local video generation workflows.
Want to try text-to-video or image-to-video and can handle manual model setup.
Need an uncensored video generation model and understand the boundaries of using one.
Want to study how prompt enhancers improve video prompts.
Have enough VRAM or are willing to try quantized versions and local inference tools.

If you only want to quickly generate short videos, online products are still easier. Sulphur 2 is more suitable for people willing to experiment with models, nodes, LoRA, prompts, and local environments.

Notes Before Using It

First, the model card is still being updated. The author also mentions that the README will later include fuller setup instructions and training details, so the latest model card and file list should be treated as the source of truth.

Second, do not judge whether it can run just from a single Hugging Face command. Video generation involves the main model, VAE, LoRA, prompt enhancer, sampling parameters, resolution, frame count, and VRAM usage. A mismatch in any one of these can cause failure.

Third, an uncensored model does not mean unlimited use. Generated content still needs to follow the rules of the platform, community, and law. Be especially careful with real people, copyrighted characters, minors, violence, and privacy-related content.

Summary

Sulphur 2 has a clear position: it is not a chat model, but a model release for the LTX 2.3 video generation ecosystem. Its appeal lies in text-to-video and image-to-video support, plus the prompt enhancer, local tool entry points, and recommended workflows.

For ordinary users, the threshold is not low. For local video generation users, it is worth adding to the test list. The actual experience will depend on the workflow, VRAM configuration, prompt quality, and whether the README and community examples become more complete.

References

Hugging Face model page: https://huggingface.co/SulphurAI/Sulphur-2-base
FreeDidi reference page: https://www.freedidi.com/24142.html

Running DeepSeek 4 Locally: Antirez's ds4 Experiment on Apple Silicon Mac

Mon, 11 May 2026 08:51:37 +0800

Antirez has open sourced a new project: ds4. It is not a general-purpose LLM framework, but a local inference engine for DeepSeek V4 Flash, with a focus on Apple Silicon and the Metal backend.

Project URL: https://github.com/antirez/ds4

What is ds4?

ds4 has a clear goal: running DeepSeek V4 Flash locally on a Mac.

It currently provides three ways to use it:

Interactive CLI.
HTTP server.
An experimental Agent mode.

Judging from its positioning, it is more like an inference project deeply optimized for one specific model than a replacement for general-purpose tools such as llama.cpp, Ollama, or vLLM.

Why it is worth watching

There are three main reasons this kind of project is worth following.

First, the author is Antirez, the creator of Redis. He has long focused on low-level systems, performance, and simple tools, and his projects are usually quite direct in style.

Second, DeepSeek V4 Flash points toward efficient inference. If the local running experience is good enough, it could be very attractive for Mac users.

Third, ds4 directly targets Apple Metal. Compared with the route of supporting every platform first and optimizing later, it feels more like a project trying to go deep on one well-defined scenario.

Who should try it

ds4 is better suited for users who:

Use an Apple Silicon Mac.
Want to run DeepSeek V4 Flash locally.
Care about Metal inference performance.
Are willing to try an alpha-stage project.
Want to study lightweight inference engines and model runtime details.

If your goal is stable deployment, cross-platform operation, or OpenAI API-compatible infrastructure, it may not be the first choice at this stage. It is better treated as an experimental tool and a technical project to watch.

How to use it

The basic workflow in the project README is to build it first, then run it.

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

Run it interactively:

./ds4

Start the HTTP server:

`1`	`./ds4 --server`

Agent mode:

`1`	`./ds4 --agent`

For exact parameters and model file preparation, follow the repository README, because the project is still changing quickly.

Current risks

ds4 is still at an early stage, so set expectations before using it:

Features may be incomplete.
Parameters, model formats, and command-line behavior may change.
Compatibility mainly revolves around Apple Silicon and Metal.
Agent mode is more experimental and is not suitable for direct production use.
When something breaks, you may need to read the README, issues, or source code yourself.

In other words, it is currently more of an open source experiment worth trying than a one-click tool for ordinary users.

How it differs from general inference tools

General-purpose inference tools usually aim for broad compatibility across model formats, platforms, backends, and APIs. ds4 takes a narrower path: local DeepSeek V4 Flash inference on Metal.

That choice has both benefits and trade-offs.

The benefit is that the implementation can stay focused, making performance and user experience easier to optimize around a single target. The trade-off is a limited scope: it is not meant to run every possible model, nor to replace a complete deployment platform.

If you already use llama.cpp or Ollama, ds4 is better treated as a supplementary testing tool, not an immediate replacement for your existing workflow.

Summary

The interesting part of ds4 is not that it is yet another local LLM tool. It is that its scope is intentionally narrow: DeepSeek V4 Flash, Apple Silicon, Metal, and local inference.

If you have a suitable Mac and are willing to tinker with an early-stage project, it is worth watching its performance, model support approach, and server/agent capabilities. For production environments, it is better to keep observing until the interfaces and usage patterns become more stable.

References

GitHub project: https://github.com/antirez/ds4

Why DeepSeek Became the Cost-Saving Key in This Round of AI Coding Tools

Mon, 11 May 2026 04:59:00 +0800

In this round of AI coding tool competition, the surface battle is about model capability, plugin ecosystems, and agent automation. But once you actually use these tools, the first wall you hit is cost.

Claude Code, Codex, OpenClaw, and Superpowers are all useful, but they share one trait: once a task becomes complex, they eat tokens aggressively. They need to read the project, build a plan, call tools, summarize context, repeatedly check results, and sometimes launch multiple subtasks. The smarter the model and the more automated the workflow, the easier it is for the bill to quietly grow.

That is why DeepSeek has become important in this cycle. Not merely because it can write code, but because its long context and cache pricing happen to hit the most expensive part of AI coding tools.

Why Agent Tools Burn So Many Tokens

Traditional chat-style coding assistants usually work in question-and-answer mode. You ask how to write a function, and the model returns a code snippet. This still costs tokens, but it is relatively controllable.

Agent tools are different. They do not just answer questions. They enter the project like a temporary engineer:

scan directories and key files;
understand the requirement and existing architecture;
make a plan;
modify files;
run commands or tests;
keep fixing based on errors;
summarize what changed at the end.

During this process, the model repeatedly reads the same context. Project descriptions, code snippets, tool outputs, conversation history, plans, and error logs all get placed back into the context. Once the task is a little complex, hundreds of thousands of tokens can disappear quickly.

If you add more aggressive plugins, the cost becomes even more obvious. Some OpenCode or Claude Code enhancement tools may organize a whole agent team by default. You only wanted to change a small feature, but it may still start planning, review, execution, and retrospective steps. The task may look more “intelligent”, but the token count keeps climbing.

The Advantage of Superpowers Is On-Demand Activation

One advantage of tools like Superpowers is that they do not force a full agent workflow onto every task.

Most of the time, you can still let Claude Code, OpenCode, or Codex work in their normal mode. Only when you explicitly call a skill, such as brainstorming, planning, executing a plan, or doing a retrospective, does it enter a heavier automation flow.

That matters for cost.

AI coding should not use heavy artillery for every task. Changing one config line, checking one error, or writing a small script can be handled through ordinary conversation. Only complex refactors, cross-file changes, long-document processing, and multi-round validation deserve a full agent workflow.

The stronger the tool, the more you need to control when it triggers. Otherwise, more automation simply means more waste.

DeepSeek’s Key Advantage Is Cheap Cache Hits

One important reason DeepSeek fits these agent tools is its low cache-hit cost.

AI coding tasks contain a lot of repeated prefixes: project background, system prompts, tool instructions, file content, and earlier conversation turns often appear again in later requests. If the model service supports prompt caching, those repeated parts become much cheaper after a cache hit.

For many models, a cache hit is only somewhat cheaper than a miss, perhaps around one third of the original price. DeepSeek’s advantage is that the gap after a cache hit can be much larger. For long-context, multi-round agent workflows that repeatedly read the same project, this gap shows up directly on the bill.

In other words, DeepSeek is not necessarily the strongest answer on every single turn. But in scenarios with long tasks, many rounds, and repeated context reads, its cost structure is unusually suitable for AI coding.

Long Context Makes Claude Code More Useful

When Claude Code or similar tools are connected to DeepSeek V4, another clear advantage is long context.

AI coding tools fear insufficient context. Once context runs short, compression becomes frequent. Once compression becomes frequent, previously read details may be lost. The model may start forgetting the project structure, constraints, or why a certain file was changed, and quality declines afterward.

DeepSeek V4’s long-context capability makes it better suited for code repositories, document batch processing, subtitle translation, and site article cleanup. Especially when connected to tools like Claude Code or OpenClaw, the right configuration can delay context compression and preserve more project detail.

That is why some tasks feel “durable” when run on DeepSeek. It may not be dazzling at every step, but it can tolerate long-running, low-cost, repeated calls.

How to Split Work Between V4 Pro and V4 Flash

DeepSeek V4 Pro and V4 Flash should not be mixed casually.

For simple tasks, DeepSeek V4 Flash is usually a better fit. It is fast and cheap, and is often enough for:

subtitle translation;
document cleanup;
ordinary script generation;
small code edits;
lightweight OpenClaw tasks;
simple site content processing.

For complex tasks, consider DeepSeek V4 Pro:

large-scale refactoring;
multi-module code understanding;
complex reasoning;
long-chain agent tasks;
high-risk code changes;
engineering tasks that require stronger planning.

Many people want to attach the strongest model immediately, but that is often uneconomical. The practical way to use AI coding tools is to layer tasks: let the cheaper model handle a large amount of routine work, and reserve the expensive model for key decision points.

MiniMax, Doubao, and DeepSeek Occupy Different Positions

Among domestic models and plans, MiniMax, Doubao, Kimi, and DeepSeek each have their own place.

MiniMax’s advantage is generous quota, low price, and broad functionality. It may not be the smartest coding model, but it is cost-effective for translation, lightweight cleanup, and batch processing. For example, batch subtitle processing, format conversion, and simple proofreading are good fits for MiniMax-style plans.

Doubao’s advantage is a broader tool ecosystem: image, video, search, TTS, possible STT, and embedding can be connected together. It feels more like a comprehensive toolbox.

DeepSeek’s position is clearer: text, code, long context, and low-cost caching. It lacks a complete image generation, voice, and video ecosystem, and its weaknesses are obvious. But in AI coding and long-text agent workflows, its strengths are long enough to matter.

So this is not about one tool replacing another. It is about splitting the task and using each tool where it fits.

Saving Money Is Not Just Choosing a Cheap Model

Saving money in AI coding does not mean simply switching every request to the cheapest model.

The effective methods are:

Do not start a heavy agent for simple tasks.
Do not use Pro when Flash is enough.
Use cache as much as possible for long tasks.
Keep repeated context stable, so meaningless changes do not break cache hits.
Let a cheaper model draft and batch-process first, then use a stronger model for key reviews.
Tell the agent clearly not to repeat facts or summarize the same point again and again.

The last point matters more than it looks. AI tools are prone to verbosity, and verbosity is not only a reading problem; it is also a cost problem. Putting “describe each fact once and state each opinion once” into the prompt can improve both article quality and token consumption.

What AI Coding Workflows DeepSeek Fits Best

DeepSeek is best suited for:

reading long code repositories;
lightweight multi-file edits;
batch document cleanup;
batch subtitle translation;
Hugo article cleanup;
agent plan execution;
low-cost automation with lots of repeated context.

It is not the best fit for every task. If you need especially strong frontend taste, complex product judgment, or cross-modal creation, you may still need Claude, GPT, Gemini, Doubao, or other tools.

But whenever a task is long-text, long-context, repeated-call, and cost-sensitive, DeepSeek can easily become the first choice.

Summary

In this round of AI coding tools, DeepSeek’s value is not just that a domestic model can write code. Its real value is that it addresses the most practical pain point of agent tools: long tasks are too expensive.

Tools like Claude Code, OpenClaw, and Superpowers make the development process increasingly automated, but behind that automation are massive context reads and multi-round calls. Whoever can lower this part of the cost can make AI coding go from “fun once in a while” to “affordable every day”.

DeepSeek’s long context, low cache cost, and layered use of V4 Flash / V4 Pro put it in exactly that position.

The real cost-saving key in this cycle is not avoiding good models. It is combining good models, cheap models, cache, and agent workflows properly. Once you understand that bill, AI coding tools can become real productivity rather than a beautiful but expensive toy.

ProgramBench Raw Leaderboard Data: Model Scores, Costs, and 200 Task Records

Sun, 10 May 2026 12:42:41 +0800

ProgramBench is a new benchmark for AI coding ability. Instead of asking a model to fix a bug in an existing repository, it asks the model to rebuild a behaviorally equivalent program from scratch using a compiled executable and usage documentation.

This article is a data-oriented reference with only light explanation. The tables below preserve the raw records published on the ProgramBench website for later citation and comparison. Sources include the ProgramBench homepage, Extended Results, and Task Instances. The data was fetched at 2026-05-10T12:42:41+08:00.

Data Notes

Resolved: the share of tasks fully passing the hidden behavioral tests.
Almost resolved: the share of tasks passing at least 95% of behavioral tests.
Cost: average API cost per task instance, in USD.
Calls: average number of LLM calls per task instance.
All models were evaluated with mini-SWE-agent across 200 tasks.

Main Leaderboard

#	Model	Provider	Agent	Resolved	Almost resolved	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-mini/

Extended Results

#	Model	Provider	Agent	Resolved	Almost resolved	Cost	Calls	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	$3.81	93	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	$11.38	260	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	$26.73	472	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	$0.33	16	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	$1.51	94	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	$0.30	85	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	$0.80	124	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.04	18	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.03	15	https://programbench.com/run/gpt-5-mini/

Raw Records for 200 Task Instances

#	Repository	Description	Lang	Stars	Tests	Best Score	Task
1	junegunn/fzf	:cherry_blossom: A command-line fuzzy finder	go	79,721	1,874	81.9%	https://programbench.com/task/junegunn__fzf.b56d614/
2	jesseduffield/lazygit	simple terminal UI for git commands	go	76,901	855	56.4%	https://programbench.com/task/jesseduffield__lazygit.1d0db51/
3	BurntSushi/ripgrep	ripgrep recursively searches directories for a regex pattern while respecting your gitignore	rs	62,855	1,994	79.7%	https://programbench.com/task/burntsushi__ripgrep.3b7fd44/
4	FFmpeg/FFmpeg	Mirror of https://git.ffmpeg.org/ffmpeg.git	c	59,217	3,050	5.3%	https://programbench.com/task/ffmpeg__ffmpeg.360a402/
5	sharkdp/bat	A cat(1) clone with wings.	rs	58,487	801	33.2%	https://programbench.com/task/sharkdp__bat.f822bd0/
6	typst/typst	A markup-based typesetting system that is powerful and easy to learn.	rs	52,957	1,724	28.0%	https://programbench.com/task/typst__typst.88356d0/
7	jgm/pandoc	Universal markup converter	hs	43,632	5,228	14.1%	https://programbench.com/task/jgm__pandoc.5caad90/
8	sharkdp/fd	A simple, fast and user-friendly alternative to ‘find’	rs	42,668	1,235	78.1%	https://programbench.com/task/sharkdp__fd.40d8eb3/
9	php/php-src	The PHP Interpreter	c	40,030	14,288	4.8%	https://programbench.com/task/php__php-src.c891263/
10	duckdb/duckdb	DuckDB is an analytical in-process SQL database management system	cpp	37,657	5,650	12.4%	https://programbench.com/task/duckdb__duckdb.bdb65ec/
11	ajeetdsouza/zoxide	A smarter cd command. Supports all major shells.	rs	35,994	531	76.5%	https://programbench.com/task/ajeetdsouza__zoxide.67ca1bc/
12	jqlang/jq	Command-line JSON processor	c	34,541	6,072	89.9%	https://programbench.com/task/jqlang__jq.b33a763/
13	dandavison/delta	A syntax-highlighting pager for git, diff, grep, rg –json, and blame output	rs	30,445	950	37.3%	https://programbench.com/task/dandavison__delta.acd758f/
14	sharkdp/hyperfine	A command-line benchmarking tool	rs	27,960	291	54.3%	https://programbench.com/task/sharkdp__hyperfine.327d5f4/
15	ggreer/the_silver_searcher	A code-searching tool similar to ack, but faster.	c	27,080	1,006	59.3%	https://programbench.com/task/ggreer__the_silver_searcher.a61f178/
16	facebook/zstd	Zstandard - Fast real-time compression algorithm	c	27,013	2,038	68.8%	https://programbench.com/task/facebook__zstd.1168da0/
17	facebookresearch/fastText	Library for fast text representation and classification.	cpp	26,511	312	75.6%	https://programbench.com/task/facebookresearch__fasttext.1142dc4/
18	robertdavidgraham/masscan	TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.	c	25,544	2,549	57.0%	https://programbench.com/task/robertdavidgraham__masscan.b99d433/
19	tree-sitter/tree-sitter	An incremental parsing system for programming tools	rs	24,953	1,232	37.2%	https://programbench.com/task/tree-sitter__tree-sitter.5e23cca/
20	FiloSottile/age	A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.	go	22,077	676	63.5%	https://programbench.com/task/filosottile__age.706dfc1/
21	rust-lang/mdBook	Create book from markdown files. Like Gitbook but implemented in Rust	rs	21,541	1,114	55.5%	https://programbench.com/task/rust-lang__mdbook.37273ba/
22	jarun/nnn	n³ The unorthodox terminal file manager	c	21,506	477	98.1%	https://programbench.com/task/jarun__nnn.cb2c535/
23	antonmedv/fx	Terminal JSON viewer & processor	go	20,433	2,047	75.7%	https://programbench.com/task/antonmedv__fx.86d0d34/
24	mikefarah/yq	yq is a portable command-line YAML, JSON, XML, CSV, TOML, HCL and properties processor	go	15,281	2,000	39.5%	https://programbench.com/task/mikefarah__yq.602586d/
25	Y2Z/monolith	⬛️ CLI tool and library for saving complete web pages as a single HTML file	rs	15,024	713	51.2%	https://programbench.com/task/y2z__monolith.8702e66/
26	direnv/direnv	unclutter your .profile	go	14,998	849	62.0%	https://programbench.com/task/direnv__direnv.02040c7/
27	google/brotli	Brotli compression format	c	14,673	441	90.7%	https://programbench.com/task/google__brotli.b3dc9cc/
28	tomnomnom/gron	Make JSON greppable!	go	14,424	224	90.2%	https://programbench.com/task/tomnomnom__gron.88a6234/
29	XAMPPRocky/tokei	Count your code, quickly.	rs	14,300	732	69.5%	https://programbench.com/task/xampprocky__tokei.505d648/
30	ast-grep/ast-grep	⚡A CLI tool for code structural search, lint and rewriting. Written in Rust	rs	13,541	882	11.9%	https://programbench.com/task/ast-grep__ast-grep.dde0fe0/
31	cheat/cheat	cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.	go	13,278	297	59.9%	https://programbench.com/task/cheat__cheat.b8098dc/
32	jonas/tig	Text-mode interface for git	c	13,200	1,586	83.9%	https://programbench.com/task/jonas__tig.8334123/
33	ninja-build/ninja	a small build system with a focus on speed	cpp	12,895	1,438	72.3%	https://programbench.com/task/ninja-build__ninja.cc60300/
34	Canop/broot	A new way to see and navigate directory trees : https://dystroy.org/broot	rs	12,619	539	67.0%	https://programbench.com/task/canop__broot.d6c798e/
35	orf/gping	Ping, but with a graph	rs	12,433	339	78.5%	https://programbench.com/task/orf__gping.26eb5b9/
36	svenstaro/genact	🌀 A nonsense activity generator	rs	11,995	232	59.1%	https://programbench.com/task/svenstaro__genact.16f96e3/
37	lz4/lz4	Extremely Fast Compression algorithm	c	11,781	1,496	82.7%	https://programbench.com/task/lz4__lz4.1519f46/
38	o2sh/onefetch	Command-line Git information tool	rs	11,745	1,166	81.7%	https://programbench.com/task/o2sh__onefetch.e5958ce/
39	bootandy/dust	A more intuitive version of du in rust	rs	11,609	584	70.9%	https://programbench.com/task/bootandy__dust.62bf1e1/
40	ekzhang/bore	🕳 bore is a simple CLI tool for making tunnels to localhost	rs	11,075	406	68.7%	https://programbench.com/task/ekzhang__bore.8e059cd/
41	BurntSushi/xsv	A fast CSV command line toolkit written in Rust.	rs	10,757	1,182	82.7%	https://programbench.com/task/burntsushi__xsv.f430466/
42	bellard/quickjs	Public repository of the QuickJS Javascript Engine.	c	10,565	3,034	3.6%	https://programbench.com/task/bellard__quickjs.d7ae12a/
43	hatoo/oha	Ohayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.	rs	10,201	899	72.5%	https://programbench.com/task/hatoo__oha.8dc6349/
44	tstack/lnav	Log file navigator	cpp	10,200	990	13.4%	https://programbench.com/task/tstack__lnav.ee34494/
45	sharkdp/hexyl	A command-line hex viewer	rs	10,086	906	82.8%	https://programbench.com/task/sharkdp__hexyl.2e26437/
46	lua/lua	A copy of the Lua development repository, as seen by the Lua team. Mirrored irregularly. All communication should be through the Lua mailing list https://www.lua.org/lua-l.html	c	9,908	1,338	43.1%	https://programbench.com/task/lua__lua.c6b4848/
47	johnkerl/miller	Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON	go	9,842	14,637	22.9%	https://programbench.com/task/johnkerl__miller.8d85b46/
48	sqlite/sqlite	Official Git mirror of the SQLite source tree	c	9,434	13,514	67.0%	https://programbench.com/task/sqlite__sqlite.839433d/
49	boyter/scc	Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go	go	8,320	464	37.7%	https://programbench.com/task/boyter__scc.515f91c/
50	ariga/atlas	Declarative schema migrations with schema-as-code workflows	go	8,311	1,318	54.8%	https://programbench.com/task/ariga__atlas.6d81150/
51	pemistahl/grex	A command-line tool and Rust library with Python bindings for generating regular expressions from user-provided test cases	rs	8,103	1,312	73.9%	https://programbench.com/task/pemistahl__grex.fa3e8ed/
52	htop-dev/htop	htop - an interactive process viewer	c	8,021	693	85.1%	https://programbench.com/task/htop-dev__htop.523600b/
53	peco/peco	Simplistic interactive filtering tool	go	7,881	1,224	76.7%	https://programbench.com/task/peco__peco.4e58dad/
54	bensadeh/tailspin	🌀 A log file highlighter	rs	7,793	615	75.8%	https://programbench.com/task/bensadeh__tailspin.6278437/
55	ducaale/xh	Friendly and fast tool for sending HTTP requests	rs	7,754	1,171	50.0%	https://programbench.com/task/ducaale__xh.4a6e44f/
56	svenstaro/miniserve	🌟 For when you really just want to serve some files over HTTP right now!	rs	7,561	304	78.6%	https://programbench.com/task/svenstaro__miniserve.8449e8b/
57	mgdm/htmlq	Like jq, but for HTML.	rs	7,520	1,455	93.9%	https://programbench.com/task/mgdm__htmlq.6e31bc8/
58	parcel-bundler/lightningcss	An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.	rs	7,515	2,828	53.6%	https://programbench.com/task/parcel-bundler__lightningcss.aa2ed1e/
59	universal-ctags/ctags	A maintained ctags implementation	c	7,149	2,258	13.3%	https://programbench.com/task/universal-ctags__ctags.243595e/
60	chmln/sd	Intuitive find & replace CLI (sed alternative)	rs	7,072	810	90.9%	https://programbench.com/task/chmln__sd.87d1ba5/
61	ogham/dog	A command-line DNS client.	rs	6,640	1,300	84.2%	https://programbench.com/task/ogham__dog.721440b/
62	danmar/cppcheck	static analysis of C/C++ code	cpp	6,599	2,126	14.6%	https://programbench.com/task/danmar__cppcheck.0a5b103/
63	doxygen/doxygen	Official doxygen git repository	c	6,422	229	34.5%	https://programbench.com/task/doxygen__doxygen.966d98e/
64	sharkdp/pastel	A command-line tool to generate, analyze, convert and manipulate colors	rs	6,334	1,114	77.2%	https://programbench.com/task/sharkdp__pastel.b60e899/
65	BLAKE3-team/BLAKE3	the official Rust and C implementations of the BLAKE3 cryptographic hash function	rs	6,178	647	97.5%	https://programbench.com/task/blake3-team__blake3.15e83a5/
66	Nukesor/pueue	:stars: Manage your shell commands.	rs	6,154	638	15.4%	https://programbench.com/task/nukesor__pueue.8b9d6fe/
67	OSGeo/gdal	GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.	cpp	5,875	657	25.4%	https://programbench.com/task/osgeo__gdal.0847f12/
68	Byron/dua-cli	View disk space usage and delete unwanted data, fast.	rs	5,794	709	86.9%	https://programbench.com/task/byron__dua-cli.8570c15/
69	dundee/gdu	Fast disk usage analyzer with console interface written in Go	go	5,578	1,161	70.1%	https://programbench.com/task/dundee__gdu.ede21d2/
70	eradman/entr	Run arbitrary commands when files change	c	5,551	586	88.6%	https://programbench.com/task/eradman__entr.8e2e8b4/
71	LuaJIT/LuaJIT	Mirror of the LuaJIT git repository	c	5,518	2,967	71.5%	https://programbench.com/task/luajit__luajit.a553b3d/
72	mgechev/revive	🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint	go	5,486	727	46.4%	https://programbench.com/task/mgechev__revive.201451e/
73	cweill/gotests	Automatically generate Go test boilerplate from your source code.	go	5,294	603	61.9%	https://programbench.com/task/cweill__gotests.2a672c5/
74	cordx56/rustowl	Visualize Ownership and Lifetimes in Rust	rs	5,113	589	75.2%	https://programbench.com/task/cordx56__rustowl.655bc5c/
75	abishekvashok/cmatrix	Terminal based “The Matrix” like implementation	c	5,042	508	97.0%	https://programbench.com/task/abishekvashok__cmatrix.5c082c6/
76	quinn-rs/quinn	Async-friendly QUIC implementation in Rust	rs	5,041	522	61.7%	https://programbench.com/task/quinn-rs__quinn.bb359cc/
77	alecthomas/chroma	A general purpose syntax highlighter in pure Go	go	4,910	515	15.9%	https://programbench.com/task/alecthomas__chroma.8d04def/
78	anordal/shellharden	The corrective bash syntax highlighter	rs	4,778	1,095	81.7%	https://programbench.com/task/anordal__shellharden.6a6ffd4/
79	yoav-lavi/melody	Melody is a language that compiles to regular expressions and aims to be more readable and maintainable	rs	4,748	1,205	78.9%	https://programbench.com/task/yoav-lavi__melody.f4af9b4/
80	sayanarijit/xplr	A hackable, minimal, fast TUI file explorer	rs	4,735	463	60.5%	https://programbench.com/task/sayanarijit__xplr.1751065/
81	hpjansson/chafa	📺🗿 Terminal graphics for the 21st century.	c	4,648	1,931	58.4%	https://programbench.com/task/hpjansson__chafa.dd4d4c1/
82	jhspetersson/fselect	Find files with SQL-like queries	rs	4,420	3,115	44.0%	https://programbench.com/task/jhspetersson__fselect.c3559ca/
83	ivanceras/svgbob	Convert your ascii diagram scribbles into happy little SVG	rs	4,182	472	41.3%	https://programbench.com/task/ivanceras__svgbob.6d00ad9/
84	multiprocessio/dsq	Commandline tool for running SQL queries against JSON, CSV, Excel, Parquet, and more.	go	3,867	542	80.3%	https://programbench.com/task/multiprocessio__dsq.c3ae0ba/
85	rcoh/angle-grinder	Slice and dice logs on the command line	rs	3,727	1,130	38.0%	https://programbench.com/task/rcoh__angle-grinder.9c2fc88/
86	rs/curlie	The power of curl, the ease of use of httpie.	go	3,637	701	89.3%	https://programbench.com/task/rs__curlie.5dfcbb1/
87	antonmedv/walk	Terminal file manager	go	3,598	470	74.3%	https://programbench.com/task/antonmedv__walk.bf802ef/
88	JohannesKaufmann/html-to-markdown	⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.	go	3,586	885	85.5%	https://programbench.com/task/johanneskaufmann__html-to-markdown.3006818/
89	TheZoraiz/ascii-image-converter	A cross-platform command-line tool to convert images into ascii art and print them on the console. Now supports braille art!	go	3,284	465	64.1%	https://programbench.com/task/thezoraiz__ascii-image-converter.d05a757/
90	hairyhenderson/gomplate	A flexible commandline tool for template rendering. Supports lots of local and remote datasources.	go	3,135	2,926	74.7%	https://programbench.com/task/hairyhenderson__gomplate.05eb3aa/
91	ip7z/7zip	7-Zip	cpp	2,967	1,043	33.9%	https://programbench.com/task/ip7z__7zip.839151e/
92	madler/pigz	A parallel implementation of gzip for modern multi-processor, multi-core machines.	c	2,924	831	83.2%	https://programbench.com/task/madler__pigz.fe4894f/
93	tinycc/tinycc	Unofficial mirror of mob development branch	c	2,843	1,978	12.8%	https://programbench.com/task/tinycc__tinycc.9b8765d/
94	raviqqe/muffet	Fast website link checker in Go	go	2,597	293	88.1%	https://programbench.com/task/raviqqe__muffet.a882908/
95	segmentio/chamber	CLI for managing secrets	go	2,588	1,748	82.0%	https://programbench.com/task/segmentio__chamber.5f93f5f/
96	astaxie/bat	Go implement CLI, cURL-like tool for humans	go	2,563	1,091	71.8%	https://programbench.com/task/astaxie__bat.17d1080/
97	zk-org/zk	Plain text note-taking assistant	go	2,542	1,108	43.1%	https://programbench.com/task/zk-org__zk.10d93d5/
98	kisielk/errcheck	errcheck checks that you checked errors.	go	2,480	341	80.4%	https://programbench.com/task/kisielk__errcheck.dacab89/
99	mkj/dropbear	Dropbear SSH	c	2,231	682	58.1%	https://programbench.com/task/mkj__dropbear.75f699b/
100	noborus/trdsql	CLI tool that can execute SQL queries on CSV, LTSV, JSON, YAML and TBLN. Can output to various formats.	go	2,159	1,312	66.8%	https://programbench.com/task/noborus__trdsql.d8c5ff6/
101	sheepla/pingu	🐧ping command but with pingu	go	2,087	383	96.6%	https://programbench.com/task/sheepla__pingu.926d475/
102	go-critic/go-critic	The most opinionated Go source code linter for code audit.	go	2,041	493	41.6%	https://programbench.com/task/go-critic__go-critic.9aea378/
103	OSGeo/PROJ	PROJ - Cartographic Projections and Coordinate Transformations Library	cpp	1,974	5,319	73.8%	https://programbench.com/task/osgeo__proj.75d455c/
104	noborus/ov	🎑Feature-rich terminal-based text viewer. It is a so-called terminal pager.	go	1,935	1,854	87.6%	https://programbench.com/task/noborus__ov.b96c2ba/
105	samtools/samtools	Tools (written in C using htslib) for manipulating next-generation sequencing data	c	1,886	1,425	14.2%	https://programbench.com/task/samtools__samtools.aa823b5/
106	gabotechs/dep-tree	Tool for helping developers keep their code bases clean and decoupled. It allows visualising a code base complexity using a 3d force-directed graph of files and the dependencies between them.	go	1,706	865	65.2%	https://programbench.com/task/gabotechs__dep-tree.60a95a2/
107	cmatsuoka/figlet	Claudio’s FIGlet tree	c	1,606	872	77.5%	https://programbench.com/task/cmatsuoka__figlet.202a0a8/
108	lh3/seqtk	Toolkit for processing sequences in FASTA/Q formats	c	1,537	429	67.4%	https://programbench.com/task/lh3__seqtk.94e7070/
109	tukaani-project/xz	XZ Utils	c	1,522	1,410	36.0%	https://programbench.com/task/tukaani-project__xz.1007bf0/
110	skeema/skeema	Declarative pure-SQL schema management for MySQL and MariaDB	go	1,361	1,708	76.5%	https://programbench.com/task/skeema__skeema.6a76243/
111	mfridman/tparse	CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.	go	1,246	425	77.6%	https://programbench.com/task/mfridman__tparse.2416b4b/
112	lfos/calcurse	A text-based calendar and scheduling application	c	1,243	666	53.8%	https://programbench.com/task/lfos__calcurse.49180d5/
113	hooklift/gowsdl	WSDL2Go code generation as well as its SOAP proxy	go	1,219	391	86.4%	https://programbench.com/task/hooklift__gowsdl.2a06cec/
114	guumaster/hostctl	Your dev tool to manage /etc/hosts like a pro!	go	1,216	1,051	82.8%	https://programbench.com/task/guumaster__hostctl.d6d9699/
115	rs/jplot	iTerm2 expvar/JSON monitoring tool	go	1,178	583	89.0%	https://programbench.com/task/rs__jplot.2a54bcc/
116	naggie/dstask	Git powered terminal-based todo/note manager – markdown note page per task. Single binary!	go	1,157	1,278	58.8%	https://programbench.com/task/naggie__dstask.ff57396/
117	sigoden/argc	A Bash CLI framework, also a Bash command runner.	rs	1,135	995	44.1%	https://programbench.com/task/sigoden__argc.04a08f1/
118	sibprogrammer/xq	Command-line XML and HTML beautifier and content extractor	go	1,109	792	75.9%	https://programbench.com/task/sibprogrammer__xq.b89f681/
119	xorg62/tty-clock	Clock using lib ncurses	c	1,105	281	84.0%	https://programbench.com/task/xorg62__tty-clock.f2f847c/
120	unhappychoice/gittype	A CLI code-typing game that turns your source code into typing challenges	rs	1,075	741	91.3%	https://programbench.com/task/unhappychoice__gittype.34b72d0/
121	eudoxia0/hashcards	A plain text-based spaced repetition system.	rs	1,071	1,151	56.3%	https://programbench.com/task/eudoxia0__hashcards.48aa136/
122	rvben/rumdl	Fast Markdown linter and formatter written in Rust	rs	1,051	3,322	40.7%	https://programbench.com/task/rvben__rumdl.2d75c4d/
123	sclevine/yj	CLI - Convert between YAML, TOML, JSON, and HCL. Preserves map order.	go	1,041	767	74.4%	https://programbench.com/task/sclevine__yj.8016400/
124	arq5x/bedtools2	bedtools - the swiss army knife for genome arithmetic	c	1,029	1,053	38.9%	https://programbench.com/task/arq5x__bedtools2.dd57059/
125	cslarsen/jp2a	Converts jpg images to ASCII	c	1,021	631	56.1%	https://programbench.com/task/cslarsen__jp2a.61d205f/
126	blacknon/hwatch	A modern alternative to the watch command, records the differences in execution results and can check this differences at after.	rs	1,016	1,016	81.1%	https://programbench.com/task/blacknon__hwatch.edfcb62/
127	eliukblau/pixterm	Draw images in your ANSI terminal with true color	go	1,014	430	74.9%	https://programbench.com/task/eliukblau__pixterm.1a93fd5/
128	Canop/rhit	A nginx log explorer	rs	1,006	817	53.2%	https://programbench.com/task/canop__rhit.ae90bcb/
129	stathissideris/ditaa	ditaa is a small command-line utility that can convert diagrams drawn using ascii art (‘drawings’ that contain characters that resemble lines like \| / - ), into proper bitmap graphics.	java	1,005	609	20.4%	https://programbench.com/task/stathissideris__ditaa.f2286c4/
130	rbakbashev/elfcat	ELF visualizer. Generates HTML files from ELF binaries.	rs	990	564	98.2%	https://programbench.com/task/rbakbashev__elfcat.52f8cc7/
131	nuta/nsh	A command-line shell like fish, but POSIX compatible.	rs	966	1,963	83.7%	https://programbench.com/task/nuta__nsh.bdd0702/
132	dalance/amber	A code search / replace tool	rs	941	567	71.1%	https://programbench.com/task/dalance__amber.69a0f52/
133	pls-rs/pls	pls is a prettier and powerful ls(1) for the pros.	rs	932	332	62.3%	https://programbench.com/task/pls-rs__pls.4e1ae50/
134	Esubaalew/run	Universal multi-language runner and smart REPL written in Rust.	rs	919	1,212	85.2%	https://programbench.com/task/esubaalew__run.0fb9dec/
135	chirlu/sox	SoX, Swiss Army knife of sound processing	c	913	1,202	37.9%	https://programbench.com/task/chirlu__sox.42b3557/
136	clog-tool/clog-cli	Generate beautiful changelogs from your Git commit history	rs	912	575	93.0%	https://programbench.com/task/clog-tool__clog-cli.7066cba/
137	tarka/xcp	An extended `cp`	rs	911	1,184	92.6%	https://programbench.com/task/tarka__xcp.5e5b448/
138	oppiliappan/eva	a calculator REPL, similar to bc(1)	rs	907	913	88.7%	https://programbench.com/task/oppiliappan__eva.41ae245/
139	git-bahn/git-graph	Command line tool to show clear git graphs arranged for your branching model	rs	904	568	79.6%	https://programbench.com/task/git-bahn__git-graph.87b4473/
140	gromacs/gromacs	Public/backup repository of the GROMACS molecular simulation toolkit. Please do not mine the metadata blindly; we use https://gitlab.com/gromacs/gromacs for code review and issue tracking.	cpp	901	1,245	9.3%	https://programbench.com/task/gromacs__gromacs.665ea4c/
141	sirwart/ripsecrets	A command-line tool to prevent committing secret keys into your source code	rs	901	611	72.8%	https://programbench.com/task/sirwart__ripsecrets.34c9e03/
142	Drew-Alleman/DataSurgeon	Quickly Extracts IP’s, Email Addresses, Hashes, Files, Credit Cards, Social Security Numbers and a lot More From Text	rs	890	502	74.3%	https://programbench.com/task/drew-alleman__datasurgeon.d257cee/
143	alexpovel/srgn	A grep-like tool which understands source code syntax and allows for manipulation in addition to search	rs	889	1,852	69.5%	https://programbench.com/task/alexpovel__srgn.89f943b/
144	kyoheiu/felix	tui file manager with vim-like key mapping	rs	888	502	49.2%	https://programbench.com/task/kyoheiu__felix.95df390/
145	oppiliappan/statix	lints and suggestions for the nix programming language	rs	882	815	42.8%	https://programbench.com/task/oppiliappan__statix.e9df54c/
146	nachoparker/dutree	a tool to analyze file system usage written in Rust	rs	871	641	89.5%	https://programbench.com/task/nachoparker__dutree.44e877d/
147	simeg/eureka	💡 CLI tool to input and store your ideas without leaving the terminal	rs	867	344	78.8%	https://programbench.com/task/simeg__eureka.df3796c/
148	kyoh86/richgo	Enrich `go test` outputs with text decorations.	go	863	546	85.0%	https://programbench.com/task/kyoh86__richgo.313114f/
149	rochacbruno/marmite	Markdown makes sites - A Static Site Generator for Blogs	rs	837	668	45.4%	https://programbench.com/task/rochacbruno__marmite.7d4bc2d/
150	rust-embedded/svd2rust	Generate Rust register maps (`struct`s) from SVD files	rs	835	920	72.9%	https://programbench.com/task/rust-embedded__svd2rust.1760b5e/
151	konradsz/igrep	Interactive Grep	rs	827	385	73.5%	https://programbench.com/task/konradsz__igrep.aa75630/
152	nikolassv/bartib	A simple timetracker for the command line. It saves a log of all tracked activities as a plaintext file and allows you to create flexible reports.	rs	827	722	87.3%	https://programbench.com/task/nikolassv__bartib.6b9b5ce/
153	yassinebridi/serpl	A simple terminal UI for search and replace, ala VS Code.	rs	824	446	61.0%	https://programbench.com/task/yassinebridi__serpl.c48a9d7/
154	riquito/tuc	When cut doesn’t cut it	rs	820	1,196	92.7%	https://programbench.com/task/riquito__tuc.16fb471/
155	ecumene/rust-sloth	A 3D software rasterizer… for the terminal!	rs	818	380	52.6%	https://programbench.com/task/ecumene__rust-sloth.051c559/
156	crowdagger/crowbook	Converts books written in Markdown to HTML, LaTeX/PDF and EPUB	rs	813	807	60.3%	https://programbench.com/task/crowdagger__crowbook.ea214d7/
157	WGUNDERWOOD/tex-fmt	An extremely fast LaTeX formatter written in Rust	rs	789	455	80.7%	https://programbench.com/task/wgunderwood__tex-fmt.3f1aef6/
158	Stranger6667/jsonschema	A high-performance JSON Schema validator for Rust	rs	770	2,933	51.7%	https://programbench.com/task/stranger6667__jsonschema.d52e881/
159	rhysd/kiro-editor	A small terminal UTF-8 text editor written in Rust 📝🦀	rs	761	595	93.3%	https://programbench.com/task/rhysd__kiro-editor.4157485/
160	astro/deadnix	Scan Nix files for dead code	rs	745	602	85.5%	https://programbench.com/task/astro__deadnix.d590041/
161	sstadick/hck	A sharp cut(1) clone.	rs	738	855	95.7%	https://programbench.com/task/sstadick__hck.b66c751/
162	trasta298/keifu	Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.	rs	729	262	67.2%	https://programbench.com/task/trasta298__keifu.3331426/
163	AmmarAbouZor/tui-journal	Your journal app if you live in a terminal	rs	722	1,402	70.8%	https://programbench.com/task/ammarabouzor__tui-journal.2b4540d/
164	incu6us/goimports-reviser	Right imports sorting & code formatting tool (goimports alternative)	go	715	513	86.4%	https://programbench.com/task/incu6us__goimports-reviser.81bd549/
165	yaa110/nomino	Batch rename utility for developers	rs	710	313	79.9%	https://programbench.com/task/yaa110__nomino.f892499/
166	wfxr/csview	📠 Pretty and fast csv viewer for cli with cjk/emoji support.	rs	694	335	96.1%	https://programbench.com/task/wfxr__csview.8ac4de0/
167	chmln/handlr	A better xdg-utils	rs	693	722	90.7%	https://programbench.com/task/chmln__handlr.90e78ba/
168	Miserlou/Loop	UNIX’s missing `loop` command	rs	692	710	94.6%	https://programbench.com/task/miserlou__loop.209927c/
169	KSXGitHub/parallel-disk-usage	Highly parallelized, blazing fast directory tree analyzer	rs	689	531	86.1%	https://programbench.com/task/ksxgithub__parallel-disk-usage.96978ed/
170	hush-shell/hush	Hush is a unix shell based on the Lua programming language	rs	688	1,201	83.3%	https://programbench.com/task/hush-shell__hush.560c33a/
171	zevv/duc	Dude, where are my bytes: Duc, a library and suite of tools for inspecting disk usage	c	682	874	83.4%	https://programbench.com/task/zevv__duc.a58fa4e/
172	altdesktop/i3-style	🎨 Make your i3 config a little more stylish.	rs	678	539	80.0%	https://programbench.com/task/altdesktop__i3-style.f93821b/
173	wintermute-cell/ngrrram	A TUI tool to help you type faster and learn new layouts. Includes a free cat.	rs	674	303	84.5%	https://programbench.com/task/wintermute-cell__ngrrram.8ea13c3/
174	psampaz/go-mod-outdated	Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.	go	669	285	98.2%	https://programbench.com/task/psampaz__go-mod-outdated.bb79367/
175	wfxr/code-minimap	🛰 A high performance code minimap render.	rs	660	313	88.8%	https://programbench.com/task/wfxr__code-minimap.0ddeea5/
176	kaushiksrini/parqeye	Peek inside Parquet files right from your terminal	rs	654	479	58.9%	https://programbench.com/task/kaushiksrini__parqeye.8072121/
177	stacked-git/stgit	Stacked Git	rs	652	1,488	20.0%	https://programbench.com/task/stacked-git__stgit.430027d/
178	Isona/dirble	Fast directory scanning and scraping tool	rs	632	718	66.7%	https://programbench.com/task/isona__dirble.e2dea9f/
179	YS-L/flamelens	Flamegraph viewer in the terminal	rs	622	224	59.4%	https://programbench.com/task/ys-l__flamelens.0b4dc33/
180	mookid/diffr	Yet another diff highlighting tool	rs	612	606	84.7%	https://programbench.com/task/mookid__diffr.2152742/
181	shashwatah/jot	⚡Rapid note management for the terminal.	rs	609	752	84.6%	https://programbench.com/task/shashwatah__jot.a92aad8/
182	Epistates/treemd	A (TUI/CLI) markdown navigator with tree-based structural navigation.	rs	603	1,569	55.1%	https://programbench.com/task/epistates__treemd.825c6dd/
183	pier-cli/pier	A CLI to organize and run short Unix shell scripts	rs	596	692	83.7%	https://programbench.com/task/pier-cli__pier.5e1bde9/
184	jrnxf/thokr	✨ sleek typing tui with visualized results and historical logging	rs	595	445	82.2%	https://programbench.com/task/jrnxf__thokr.09375ef/
185	ismaelgv/rnr	A command-line tool to batch rename files and directories	rs	581	683	82.1%	https://programbench.com/task/ismaelgv__rnr.fc0733b/
186	sitkevij/hex	🔮 Futuristic take on hexdump, made in Rust.	rs	563	823	91.7%	https://programbench.com/task/sitkevij__hex.61ae69b/
187	brocode/fblog	Small command-line JSON Log viewer	rs	561	978	86.0%	https://programbench.com/task/brocode__fblog.3b54330/
188	codesnap-rs/codesnap	🦀️📸 Pure Rust tool to generate beautiful code snapshots, provide CLI and Library	rs	557	730	59.2%	https://programbench.com/task/codesnap-rs__codesnap.f81e4f3/
189	foriequal0/git-trim	Automatically trims your branches whose tracking remote refs are merged or stray	rs	548	509	64.6%	https://programbench.com/task/foriequal0__git-trim.07c2f50/
190	axodotdev/oranda	🎁 generate beautiful landing pages for your developer tools	rs	542	767	53.6%	https://programbench.com/task/axodotdev__oranda.27d60c7/
191	elkowar/pipr	A tool to interactively write shell pipelines.	rs	541	525	57.1%	https://programbench.com/task/elkowar__pipr.fae0b17/
192	paradigmxyz/solar	Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust	rs	539	1,978	43.3%	https://programbench.com/task/paradigmxyz__solar.5190d0e/
193	Lymphatus/caesium-clt	Caesium Command Line Tools - Lossy/lossless image compression tool	rs	537	575	92.3%	https://programbench.com/task/lymphatus__caesium-clt.a529b2e/
194	agourlay/zip-password-finder	Find the password of protected ZIP files.	rs	534	680	97.9%	https://programbench.com/task/agourlay__zip-password-finder.704700d/
195	rust-ethereum/ethabi	Encode and decode smart contract invocations	rs	525	997	90.9%	https://programbench.com/task/rust-ethereum__ethabi.b1710ad/
196	ArthurSonzogni/json-tui	A JSON terminal UI made in C++	cpp	438	755	71.0%	https://programbench.com/task/arthursonzogni__json-tui.17a22b6/
197	tomarrell/wrapcheck	A Go linter to check that errors from external packages are wrapped	go	374	480	80.8%	https://programbench.com/task/tomarrell__wrapcheck.c058da1/
198	NikolaDucak/caps-log	A small TUI journaling tool. 📖	cpp	370	551	61.7%	https://programbench.com/task/nikoladucak__caps-log.2cf2d1e/
199	mibk/dupl	a tool for code clone detection	go	367	373	85.0%	https://programbench.com/task/mibk__dupl.1bf052b/
200	HaliteChallenge/Halite	@twosigma’s first artificial intelligence programming challenge	cpp	202	275	80.4%	https://programbench.com/task/halitechallenge__halite.822cfb6/

How to Read This Data

On the main ProgramBench leaderboard, all 9 models have Resolved at 0%. Under the unified lightweight agent setup, current models still cannot reliably rebuild complete software from black-box behavior and documentation.

Almost resolved still separates the models. Claude Opus 4.7 reaches 3.0%, Claude Opus 4.6 reaches 2.5%, Claude Sonnet 4.6 reaches 1.0%, and the remaining models are at 0.0%. This metric is more useful for observing near-completion ability than looking only at full completion.

The task instance table matters as well. It lists each open-source project’s language, star count, test count, and current best score, showing that ProgramBench covers compression, search, databases, compilers, command-line tools, media processing, and other software categories. For AI Coding, this is much closer to real engineering pressure than a plain algorithm benchmark.

ProgramBench 0% Explained: The Scary Part Is Not Failure, but a Clear Roadmap

Sun, 10 May 2026 12:32:39 +0800

A new benchmark has appeared in the AI coding world: ProgramBench. On the surface, its result looks reassuring for programmers: nine mainstream models all scored 0% on the fully resolved metric, and no model fully completed even one task.

But the truly unsettling part is not that today’s large models still fail. It is that complete software engineering has, for the first time, been turned into a clear set of tasks that can be evaluated, ranked, and repeatedly optimized.

Once a task is defined clearly, the AI industry tends to do what it is best at: grind the benchmark, iterate, chase the leaderboard, and push what used to be impossible toward the edge of usability.

What ProgramBench Tests

Many coding benchmarks test function completion, bug fixing, passing unit tests, or adding a small feature to an existing project. ProgramBench is much harsher. It does not provide source code, project structure, or ready-made test cases.

The model mainly receives only two things:

A compiled executable.
The program’s usage documentation.

The model must run the executable, observe input and output behavior, understand command-line arguments, edge cases, error messages, and data storage patterns, then reimplement a program with matching behavior.

This is no longer just “writing some code.” It is a simplified but complete software engineering task: understand requirements, explore behavior, choose a language, design the structure, write the source code, provide a build method, and pass as many hidden tests as possible.

According to the official ProgramBench description, it currently includes 200 tasks, ranging from small command-line tools to large real-world projects such as PHP, FFmpeg, and SQLite. Its test set is generated with agent-driven fuzzing and contains more than 248,000 behavioral tests.

Broken down, ProgramBench is roughly testing four abilities:

Reading documentation: understanding the commands, arguments, and outputs the program should provide.
Exploring behavior: repeatedly running the binary and observing normal inputs, invalid inputs, and boundary cases.
Rebuilding the implementation: choosing a language and project structure, then writing a behaviorally close replacement.
Passing hidden tests: matching not only ordinary behavior, but also error handling, output format, and edge conditions.

So its search value is not merely “another leaderboard.” It answers a much more specific question: can a large model recreate real software from scratch, without source code, using only documentation and black-box behavior?

Why the Result Is 0%

ProgramBench’s primary metric is fully resolved: a task counts as solved only if all tests for that task pass. On the current leaderboard, all nine models score 0% on this metric.

The evaluated models include Claude, GPT, Gemini, and related series, all using mini-SWE-agent as the baseline agent. Claude Opus 4.7 performs best on the almost resolved metric, with about 3.0% of tasks passing at least 95% of the tests. Claude Opus 4.6 reaches 2.5%, and Claude Sonnet 4.6 reaches 1.0%. GPT 5.4, GPT 5.4 mini, Gemini 3.1 Pro, Gemini 3 Flash, and others are all at 0.0% on almost resolved.

This shows that today’s large models plus a lightweight agent still cannot rebuild complete software from scratch. Even on the simplest tasks, it is difficult to align every detail perfectly.

But there is an important caveat: this evaluation used mini-SWE-agent, not Claude Code or Codex. With a stronger coding agent, better tool support, and a longer exploration loop, the results may improve. A more precise interpretation is: current models plus a lightweight agent are not yet enough to reliably perform complete software reconstruction.

What fully resolved and almost resolved Mean

When reading ProgramBench results, these two metrics are easy to misunderstand.

fully resolved is the strictest metric: all hidden tests in a task must pass before the task counts as fully solved. If the model misses one boundary condition, one error format, or one command-line argument behavior, the task is not fully resolved.

almost resolved is closer to “nearly complete”: if a task passes at least 95% of its tests, it counts as almost resolved. It reflects whether the model has reproduced most behavior, but it does not mean the program can replace the original.

That is why the 0% needs to be read carefully. The 0% on fully resolved means the models cannot yet deliver complete results. The gap on almost resolved shows which models are already close on some tasks. For example, Claude Opus 4.7’s almost resolved score is about 3.0%, which means it gets closer on a small number of relatively simple tasks, but it is still far from reliably rebuilding complete software.

Why mini-SWE-agent Affects the Result

This evaluation uses a unified mini-SWE-agent, which is good for fairness: different models run inside the same lightweight agent framework, making horizontal comparison easier.

But it also limits the ceiling. Complete software reconstruction depends not only on the model itself, but also on whether the agent can plan an exploration strategy, manage long-running tasks, generate tests automatically, repeatedly locate failure causes, and organize the project structure.

mini-SWE-agent is more like a unified baseline than the strongest possible engineering environment.

More complete coding agents such as Claude Code and Codex usually provide stronger tool use, context organization, task decomposition, and multi-round repair ability. If the benchmark were run with those tools, the results might improve.

So ProgramBench’s result is best understood this way: current models cannot yet perform complete software reconstruction in a lightweight agent environment. It does not prove that models will never do it, nor does it fully measure the ceiling of all commercial coding agents.

How It Differs from SWE-bench

SWE-bench is already an important benchmark in AI coding. It asks models to read issues in real GitHub repositories, modify code, and submit patches, testing their ability to solve real bugs.

But SWE-bench is still essentially repairing an existing car: the car is there, and the technology stack, directory structure, code organization, and architecture have already been created by humans. The model only needs to find the problem and fix the broken part.

ProgramBench is closer to building the car again: you only know the behavior it should have, such as stopping at a red light or honking near pedestrians. The structure, language, modules, and build method all have to be decided from scratch.

That is why it is much harder. It no longer tests only local patching ability. It tests software architecture, system reasoning, behavior exploration, automated testing, multi-round correction, and long-horizon engineering design.

The difference can be summarized like this:

Dimension	SWE-bench	ProgramBench
Starting point	Existing GitHub repository and issue	Compiled executable and usage documentation
Source code provided	Yes	No
Main task	Fix a bug in an existing project	Reimplement a complete program from behavior
Tech stack	Already determined by the project	Chosen by the model
Project structure	Already exists	Designed by the model
Test method	Run tests after submitting a patch	Use hidden behavioral tests to measure reconstruction
Main focus	Code reading, bug localization, patch repair	Behavior exploration, system abstraction, architecture design, complete implementation

This is why ProgramBench is better viewed as a target for the next stage of AI Coding: it pushes the problem from “repair existing code” to “rebuild complete software.”

0% Does Not Mean Safety

When people see 0%, their first reaction may be: programmers are safe for now.

In the short term, that is true. Today’s large models still cannot reliably complete full software engineering, especially without source code, test cases, or project structure. Requirements clarification, architecture design, long-term maintenance, security control, team collaboration, and business understanding remain important advantages for human software engineers.

But interpreting 0% as “AI coding has hit a wall” would be far too optimistic.

What ProgramBench really changes is the problem definition. People already knew AI could complete code and fix bugs, but “rebuilding complete software from an executable and documentation” had not been placed on a unified track. Now it has become 200 tasks, a unified evaluation, and a unified ranking.

That means model companies, agent companies, and developer-tool companies all know where to push next: evolve AI from writing code snippets to maintaining, rebuilding, and delivering complete software systems.

Why It Requires Offline Testing and Anti-Cheating

One important design detail in ProgramBench is anti-cheating.

In early tests, models tried to find source code directly on GitHub, download packages containing the source through package managers, or even search local system cache directories for downloaded packages. That would obviously defeat the purpose, because the question would become “can the model find the original source code” rather than “can it rebuild software from behavior.”

So ProgramBench uses a sandboxed and offline environment. It does not allow internet access, decompilation, disassembly, or reading executable contents. The model can only execute the program, observe its behavior, and implement its own version.

This restriction makes the evaluation cleaner and closer to the real question it wants to answer: can a large language model start from program behavior and documentation, then build a runnable software project by itself?

The Bigger Warning: Code Shape May Change

ProgramBench also reveals something more worth thinking about than 0%: model-generated code often does not look like projects written by human engineers.

Public materials mention that models tend to generate fewer files, shallower directory structures, fewer functions, and much longer individual functions. In other words, they may produce one huge script that runs, rather than a cleanly structured software engineering project.

From a traditional software engineering perspective, this is usually bad code. Too few files, overly long functions, insufficient abstraction, and unclear module boundaries all make maintenance difficult for humans.

But AI may not need to write code in the way humans maintain code.

Humans emphasize abstraction, naming, directory structure, and module boundaries mainly because human memory is limited, teams need collaboration, and code must be reused over time. If AI can use longer context, retrieval systems, and automated tests to repeatedly rewrite code, it may not need these familiar engineering conventions as much.

This creates a very real risk: future AI-written software may run, and may even run fast, while becoming increasingly difficult for humans to maintain.

What Programmers Need to Upgrade

ProgramBench is neither simply good news nor simply bad news for programmers.

In the short term, complete software engineering remains hard, and programmers will not lose their jobs immediately because of this benchmark. Architecture judgment, requirements clarification, security control, quality acceptance, and business understanding still need human ownership.

In the long term, programmers’ work will continue to move upward. The most vulnerable people are not those who “cannot write code,” but those who can only write code and cannot define problems, verify results, organize toolchains, or control risk.

Future software engineers may look more like:

Requirement definers: turning vague business problems into executable goals.
System validators: judging whether AI-generated results truly satisfy requirements.
Toolchain organizers: combining models, agents, tests, deployment, and monitoring.
Quality owners: controlling security, maintainability, edge cases, and long-term risk.
Translators between business and technology: turning real problems into constraints engineering systems can handle.

If AI really evolves from code assistant to complete software engineer, the value of human programmers will no longer be writing every line by hand. It will be deciding what is worth building, what counts as correct, and where failure is unacceptable.

Summary

ProgramBench’s 0% is not the end. It is the beginning of a new stage.

It shows that today’s large models still cannot reliably rebuild complete software systems from scratch. But it also defines the target for the next generation of AI Coding agents very clearly: from local patches to complete projects, from code snippets to system delivery.

For programmers, it is fine to breathe a little easier in the short term, but dangerous to stare only at “AI still cannot do it.” The more important move is to upgrade from code executor to problem definer, result validator, and risk controller.

The truly unsettling part is not that AI scored 0% today. It is that the exam has now been written.

How to Choose Between GPT-5.5, GPT-5.4, and GPT-5.3-Codex

Sun, 10 May 2026 08:43:17 +0800

If you only want the short version, the conclusion is simple: default to GPT-5.5, choose GPT-5.4 when budget and usage are more sensitive, and focus on GPT-5.3-Codex mainly when you are doing longer-running software engineering work inside Codex or need capabilities such as Cloud Tasks and Code Review.

This is not just a subjective impression. As of 2026-05-10, OpenAI’s Codex documentation still says that most tasks should start with gpt-5.5; if gpt-5.5 is not available yet, continue using gpt-5.4; and for lighter tasks or subagents, gpt-5.4-mini is the better fit.

Positioning of the three models

Start with the official positioning.

GPT-5.5 is the newest frontier model in Codex, aimed at complex coding, computer use, knowledge work, and research workflows. It behaves like the default flagship model for harder analysis, multi-step tasks, cross-file edits, solution design, and heavier document work.

GPT-5.4 is a steadier all-around choice. OpenAI describes it as bringing the industry-leading coding capabilities of GPT-5.3-Codex together with stronger reasoning, tool use, and agentic workflows. In other words, it is not simply a weaker 5.5; it is a more balanced model that is easier to use as a long-term default.

GPT-5.3-Codex is still a very strong coding model, but its core strengths are more concentrated in real software engineering and native Codex workflows. The official docs also make a point of saying that it is optimized for agentic coding tasks, while GPT-5.4 already inherits much of its coding strength.

So today it no longer makes much sense to treat GPT-5.3-Codex as the automatic choice for “the strongest coding model.” In most day-to-day development scenarios, GPT-5.5 and GPT-5.4 deserve attention first.

How to choose by use case

If your work is daily Q&A, complex explanations, research summaries, file analysis, or long-form synthesis, GPT-5.5 is the best fit. It is not only good at coding, but also better at handling demanding knowledge work outside pure code.

If your work is complex programming, refactoring, debugging, architecture design, or multi-file edits, GPT-5.5 is still the first choice. That is also how the Codex documentation frames it: when gpt-5.5 is available, most tasks should start there.

If you care more about usage limits and cost while still wanting strong quality, GPT-5.4 is often the more practical default. For many routine development tasks, rewrites, standard translations, script generation, and bug fixes, GPT-5.4 is already strong enough and noticeably cheaper.

If you are using Codex CLI, the IDE extension, or the app for more agent-like engineering work, such as reading a repository for a long time, continuously changing code, queueing tasks, or using Cloud Tasks or Code Review, GPT-5.3-Codex still matters. That is not because it is more advanced than GPT-5.5, but because Cloud Tasks and Code Review in Codex still run on GPT-5.3-Codex.

How much credit does each one use

The Codex credit table makes the differences very clear.

Under the Business / New Enterprise token-based pricing:

GPT-5.5: 125 credits / 1M input tokens, 12.5 credits for cached input, 750 credits for output
GPT-5.4: 62.5 credits / 1M input tokens, 6.25 credits for cached input, 375 credits for output
GPT-5.3-Codex: 43.75 credits / 1M input tokens, 4.375 credits for cached input, 350 credits for output

That means, by headline pricing, GPT-5.4 costs about half of GPT-5.5 for similar input and output lengths. GPT-5.3-Codex is cheaper on input, but its output cost is already very close to GPT-5.4, so it is not the kind of option that is dramatically cheaper overall.

There is another detail that is easy to miss. The official Codex docs also say that GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4. So although its unit price is higher, in some complex tasks it may reduce the gap through lower token usage and fewer retries.

For fixed-template article rewriting, translation, and SEO description generation, however, input and output lengths are usually stable. In that kind of work, the advantage of taking fewer wrong turns is smaller than in complex engineering tasks. In practice, GPT-5.4 is still usually the cheaper option, often by roughly 45% to 50%.

Differences in Codex usage limits

Beyond raw pricing, these models are not available in exactly the same ways inside Codex.

As of 2026-05-10, GPT-5.5 is the recommended model in Codex, but it is currently only available when you sign in to Codex with ChatGPT, and it does not support API-key authentication. GPT-5.4 and GPT-5.3-Codex do support API access.

Also, GPT-5.5 and GPT-5.4 currently do not support Codex Cloud Tasks or Code Review. Those two features still belong to GPT-5.3-Codex. So if what you really mean is long-running engineering work inside Codex, you cannot only compare model quality. You also have to ask whether the feature you need is still tied to GPT-5.3-Codex.

If you are only using local messages, the official Plus-plan five-hour window is roughly:

GPT-5.5: 15-80
GPT-5.4: 20-100
GPT-5.3-Codex: 30-150

This also shows a practical difference: GPT-5.5 is the strongest, but it typically gives you fewer uses under fixed limits; GPT-5.4 is more balanced; and GPT-5.3-Codex can look more durable for local messages.

How to choose across common scenarios

There are many high-frequency tasks in daily work. The more useful way to compare these models is not to ask in the abstract which one is “better,” but to break the decision down by scenario.

1. Daily Q&A, research organization, and long summaries

GPT-5.5: Best fit. It is better at handling ambiguous prompts, filling in context, and turning scattered information into structured output.

GPT-5.4: Good for normal summaries and bulk organization. When the difficulty is moderate and the volume is high, it is usually the more economical choice.

GPT-5.3-Codex: Not ideal as the main choice. It can do the work, but this is not where it stands out most.

2. Explaining technical concepts, code walkthroughs, and reading old projects

GPT-5.5: Better for complex projects. It is more reliable when relationships span many files, call chains are long, and historical baggage is heavy.

GPT-5.4: Good for normal reading and explanation. It works well for understanding functions, modules, configuration, and getting up to speed on a project quickly.

GPT-5.3-Codex: More execution-oriented, not the first choice for explanation-heavy tasks.

3. Writing scripts, small tools, SQL, shell commands, and regex

GPT-5.5: Better when the script is tied to broader system design, multiple services, or more complex constraints.

GPT-5.4: The best default main choice. Most scripts, small tools, SQL tasks, and command-line work are well within its comfort zone, and it uses fewer credits.

GPT-5.3-Codex: Worth considering if the script is only one part of a larger engineering-agent workflow, but not necessary as the first choice for standalone scripting.

4. Fixing bugs, making small feature changes, adding tests, and routine development

GPT-5.5: Better for somewhat harder fixes, especially when it needs to analyze the cause first, then edit across files, then add tests.

GPT-5.4: The best daily development workhorse. For ordinary bugs, small features, test scaffolding, renaming, and formatting cleanup, it has the best cost-performance balance.

GPT-5.3-Codex: Capable, but usually not the first choice unless you specifically need Cloud Tasks or an engineering-agent workflow.

5. Complex refactoring, architecture design, and hard debugging

GPT-5.5: Best fit. In complex tasks, the expensive part is usually rework, not a single output. GPT-5.5 is better suited to be the main problem-solving model.

GPT-5.4: Good for medium-complexity work. It can handle refactors and design discussions, but for very long context, multi-step reasoning, and high-uncertainty tasks, it is usually less steady than GPT-5.5.

GPT-5.3-Codex: More execution-oriented and not the default priority for hard decision-heavy work.

6. Bulk light tasks, repetitive work, and split sub-tasks

GPT-5.5: Capable, but usually not cost-effective.

GPT-5.4: Best fit. For batch comment edits, bulk formatting, template-style code generation, and repetitive content changes, it is the most balanced option.

GPT-5.3-Codex: Worth considering if the work is already embedded in a Codex engineering workflow, but in plain cost-performance terms it is still usually weaker than GPT-5.4.

7. Automation pipelines, agent execution, and continuous repository work

GPT-5.5: Good for early-stage design, rules, and breaking down complex tasks.

GPT-5.4: Good for writing automation scripts and filling in medium-complexity workflow logic, especially when API access matters.

GPT-5.3-Codex: The most relevant model here. Because Codex Cloud Tasks and Code Review still run on it, it is better suited to scenarios where you want the system to keep running on its own.

8. Important page copy, brand introductions, and final polish

GPT-5.5: Best fit. It is strongest in naturalness, style control, and long-context consistency.

GPT-5.4: Good for most ordinary pages and daily updates. Important pages can start with a draft in GPT-5.4 and then be polished with GPT-5.5.

GPT-5.3-Codex: Not suitable as a primary writing model.

9. Fixed-template website rewriting, translation, and SEO descriptions

GPT-5.5: Better for template design, final polish, high-value pages, and more natural Chinese-to-English translation.

GPT-5.4: Best fit for bulk production. For standard article rewriting, fixed-structure translation, product copy rewriting, and batch meta-description generation, it usually offers the best quality-cost balance.

GPT-5.3-Codex: Not suitable as the primary writing model. It is more useful for writing batch-processing scripts, cleaning HTML, preserving tag structure, and improving publishing workflows.

10. E-commerce product copy, category pages, and bulk content operations

GPT-5.5: Good for defining rules, spot-checking, and polishing high-value pages.

GPT-5.4: Best fit for bulk production. It is more balanced for product titles, category descriptions, campaign copy, and long-tail SEO content.

GPT-5.3-Codex: Good for crawling, cleaning, batch processing, and auto-publishing scripts, but not ideal for the core copy itself.

If you compress all of these scenarios into one line:

Complex knowledge work, complex analysis, and high-value writing: prioritize GPT-5.5
Daily development, bulk production, and repetitive work: prioritize GPT-5.4
Codex engineering agents, Cloud Tasks, and Code Review: pay special attention to GPT-5.3-Codex

Final recommendation

If your work is mostly ordinary coding, bug fixing, technical questions, and accompanying documentation, GPT-5.4 is a very steady default model.

If you need more complex project analysis, multi-file changes, architecture planning, hard debugging, or one model that can cover both engineering and demanding knowledge work, go straight to GPT-5.5.

If what matters most is the engineering workflow inside Codex itself, such as Cloud Tasks, Code Review, and long-running agent execution, then GPT-5.3-Codex is still worth keeping around, but it no longer makes much sense as the first default choice.

For a fixed-template content site, the more practical setup is usually:

GPT-5.4 for bulk production
GPT-5.5 for template design, spot checks, and final polishing
GPT-5.3-Codex for writing automation tools rather than the main content

Summary

The more practical default order now is GPT-5.5 first, GPT-5.4 second, and GPT-5.3-Codex reserved for more engineering-agent-heavy or Codex-specific scenarios.

If your question is specifically “How much does GPT-5.4 save versus GPT-5.5 for rewriting the same template article?”, then based on the official credit table and the typical token structure of this type of work, it is reasonable to think of it as saving close to half. For content-heavy batch sites, that difference is large enough that the common pattern is not to use GPT-5.5 for everything, but to use GPT-5.5 to define the rules and style first, then hand the bulk work to GPT-5.4.

How to Choose AI Coding Plans: Convenience for Light Users, Flexibility for Heavy Users

Sun, 10 May 2026 08:20:58 +0800

AI coding plans have changed quickly over the past six months. Many tools have shifted from message-style pricing to usage-based pricing, generous low-cost tiers have become tighter, and some overseas services have added stricter identity checks, regional limits, and usage rules.

For developers, the question is no longer just which model is strongest. It is also about how much to spend every month, whether the quota is enough, whether the tool feels comfortable to use, and whether you can switch smoothly when a provider suddenly raises prices or changes the rules.

A practical conclusion is this: light users should buy convenience, mid-level users should buy value, and heavy users should buy flexibility. The heavier your usage, the less you should bind models and tools together in a single plan.

Four things to evaluate before choosing a plan

In the past, people usually looked at three things when choosing an AI coding plan:

Whether the model was strong enough.
Whether the response speed was stable.
Whether the usage quota was sufficient.

Now there is a fourth factor: whether the model and the tool can be separated.

The model provides reasoning ability, while the tool provides context management, file editing, agent orchestration, and workflow experience. Both matter, but they are better not fully tied together. For example, if you like Claude models, you can buy an official plan or connect the API to another tool. If you like a certain editor or agent environment, it is better if it can connect to different models instead of only its own.

The value here is not complexity for its own sake. It is risk reduction. AI coding is one of the fastest-changing segments in the industry. A plan that feels generous today may switch pricing in two months, and a tool that feels good today may become worse after the next model integration change. Separating models from tools gives you room to move.

Overseas plans are getting tighter

Tools such as GitHub Copilot, Cursor, Windsurf, and Claude Code are still the primary choices for many users, but the trend is clear: cheap plans with unusually high quotas are becoming harder to sustain, and usage-based billing is becoming more common.

Once services like GitHub Copilot lean more heavily on usage-based billing, the room for plan-based arbitrage becomes much smaller. For light users, these products are still convenient. But for people who frequently use agents, long context, and complex code tasks, actual consumption starts to look much closer to real API cost.

Cursor and Windsurf essentially package model capability into an IDE experience. Their strength is convenience and a mature editor workflow. Their weakness is tighter tool lock-in. Once you become dependent on their proprietary agents, indexing, and automation flow, migration costs can rise quickly.

Claude Code remains attractive in terms of experience and ecosystem attention, but overseas subscriptions, identity verification, regional restrictions, and the safety of relay services are all risks that users in China have to factor in. Third-party relay services may mix models, be unstable, expose user data, or even disappear entirely, which makes them hard to treat as long-term infrastructure for important work.

The strengths and limits of domestic plans

One advantage of domestic AI coding plans is that many of them are offered through APIs, which means they are less tightly bound to a specific tool. You can connect them to OpenCode, Cline, Continue, your own scripts, or internal agents.

The weakness is also clear: if you want model strength, high speed, and generous quota all at once, very few plans can deliver everything together.

GLM models are strong within the domestic model landscape, but throughput during peak hours may not be stable, which can make heavy tasks feel slow. Kimi is capable, but pricing and quota rules still need ongoing attention, especially whether backend quota is transparent. Models like MiniMax are friendlier in speed and allowance, which makes them suitable for light day-to-day tasks, batch jobs, and simpler coding help, though they may sit a tier lower on harder engineering reasoning. DeepSeek can be highly cost-effective when a new model is still in its promotional pricing period, but once that ends, you have to evaluate it again under normal pricing.

That is why domestic options are often better used as a model pool: different tasks use different models, instead of betting everything on one model and one plan.

Light users: choose what feels convenient and do not overbuild

If you only ask AI to tweak scripts, patch documentation, explain errors, or generate small tools once or twice a week, you probably do not need a complicated setup.

For this kind of user, convenience matters most. Cursor, Windsurf, Trae, CodeBuddy, Tongyi Lingma, GitHub Copilot, and similar tools are all worth trying. The goal is not the absolute lowest unit cost. The goal is low friction: something stable inside your editor, decent completions, and easy recovery when it makes a mistake.

Light users usually should not spend too much time building multi-layer API setups, relays, and proxy chains just to save a little money. The time cost, account risk, and debugging overhead are often more expensive than the subscription fee you save.

Mid-level users: focus on value, but also on portability

If you use AI every day for coding, project edits, test generation, and document work, then quota and actual consumption start to matter much more.

For this kind of user, it makes sense to separate the main tool from backup models. For example, one convenient IDE plan can handle daily editing, while a multi-tool API or aggregator plan can be used for longer-context and more complex agent tasks.

Three things matter most at this stage:

Whether it supports third-party tool integration.
Whether token or quota consumption is visible and understandable.
Whether overage means throttling, downgrade, shutdown, or pure usage-based billing.

If a plan looks cheap but can only be used inside its own tool, you need to count migration cost as part of the real price. If a plan costs more but can plug into multiple tools, it may be the better long-term choice.

Heavy users: do not lock models and tools together

For heavy users, flexibility is the core requirement.

When a person or team uses AI agents intensively every day, consumption grows very quickly. Repository search, long-context edits, multi-round debugging, and automated test repair can all multiply token use. Once you rely on a single plan, three problems show up easily:

The quota suddenly becomes too small.
The pricing rule suddenly changes.
A tool or model becomes temporarily unavailable.

A more stable approach is to prepare a layered setup: one primary agent tool, one or more replaceable model endpoints, one low-cost model for simple work, and one high-capability model for harder tasks. Small routine work should not always go to the most expensive model, and critical work should not rely only on the cheapest model either.

For heavy users, the ability for tools to connect to any model and for models to connect to any tool matters more than saving a few dozen dollars per month. The real expense is not the subscription itself. It is the cost of being locked into one ecosystem and having to rebuild your workflow later.

A more stable combination strategy

A relatively steady way to structure your setup looks like this:

Use a low-cost model for light tasks such as code explanations, small scripts, formatting, and simple documents.
Use a value-oriented model for mid-level tasks such as standard feature work, test completion, and refactor suggestions.
Use a stronger model for difficult tasks such as architecture changes, cross-file fixes, hard bugs, and long-context reasoning.
Keep the tool layer open by choosing tools that can connect to APIs, export configuration, and switch models.
Maintain a backup path so that when a main plan changes rules, you can switch quickly to another model or tool.

This may not be the absolute cheapest setup, but it is much more resilient. AI coding prices and quotas will keep changing. The thing worth investing in for the long term is a portable workflow, not a short-term deal that only looks unusually generous for a while.

Summary

AI coding plans should not be judged by monthly price alone. Light users should keep things simple and choose a convenient tool. Mid-level users should start paying attention to quota, consumption, and portability. Heavy users should decouple models from tools and avoid being trapped in one ecosystem.

The most useful thing to remember is that plans will change, models will change, and tools will change too. Keeping the choice in your own hands is the most important form of cost control in long-term AI coding work.

Chrome Silently Downloads 4GB Gemini Nano: How to Check, Disable, and Delete It

Sat, 09 May 2026 21:37:18 +0800

Google Chrome has been reported to download a roughly 4GB local AI model file in the background without explicit user permission, sparking debate about privacy, storage usage, and environmental impact.

The files are related to Gemini Nano and are mainly used for Chrome’s local AI features. The dispute is not simply that the browser supports local AI, but whether the download process is transparent enough, whether users should be informed in advance, and whether system resources are being used reasonably.

What happened

The model file being discussed is named weights.bin and is located in Chrome’s OptGuideOnDeviceModel directory. It is believed to be a localized version of Gemini Nano, used to perform some AI inference directly on the device.

Chrome decides in the background whether to download it based on hardware capability, especially RAM and VRAM. Users generally do not need to start the download themselves, and they may not see a clear prompt before it happens.

The more frustrating part is that manually deleting the model file usually does not stop it from coming back. As long as the related feature remains enabled, Chrome may download the model again after a restart or a later update.

The platforms mentioned in the discussion include Windows 11, macOS, and Ubuntu desktop systems. Based on Chrome’s desktop install base, the number of potentially affected devices could reach hundreds of millions.

Google’s explanation

Google says these files support local AI features such as “Help me write” and scam detection. Running the model locally can reduce some data uploads and improve privacy protection.

Google also says that if device storage is low, Chrome will automatically remove the related model to free up space. In other words, the model does not necessarily occupy disk space permanently.

At the same time, Google says users have been able to disable the related feature in Chrome settings since February 2024. Once disabled, the model will no longer continue downloading or updating.

How to check and disable it

If you do not want Chrome to keep the Gemini Nano model locally, start by checking a few places.

First, open Chrome settings and look for options related to “on-device AI”, local AI, writing assistance, or optimization suggestions, then disable the features you do not need.

Second, enter this in the address bar:

`1`	`chrome://flags`

Then search for and disable:

`1`	`Enables optimization guide on device`

Finally, check Chrome’s user data directory for the OptGuideOnDeviceModel folder and delete the model files inside it. Keep in mind that deleting the file alone is usually not enough. It is better to disable the related flag or setting first, otherwise Chrome may download it again later.

Possible paths on different systems

OptGuideOnDeviceModel is usually under Chrome’s user data directory. The exact location can vary depending on the operating system and installation method, but these are good places to check first:

Windows: %LOCALAPPDATA%\Google\Chrome\User Data\
macOS: ~/Library/Application Support/Google/Chrome/
Linux: ~/.config/google-chrome/
Chromium: ~/.config/chromium/

After opening the relevant directory, search for OptGuideOnDeviceModel or weights.bin. If you use Chrome Beta, Dev, or Canary, the directory name may include the corresponding release channel.

How to tell whether weights.bin has been downloaded

The simplest method is to search Chrome’s user data directory for:

`1`	`weights.bin`

If it has been downloaded, it will usually appear inside OptGuideOnDeviceModel, and the file size may be close to several GB. You can also check the modified time to see whether Chrome recently created or updated it in the background.

If you cannot find weights.bin, that does not necessarily mean the device will never download it. Chrome may decide whether to fetch the model based on hardware conditions, region, version, feature flags, and experiment configuration.

Which Chrome AI features may be affected

After disabling the related local AI or optimization features, some on-device capabilities that depend on Gemini Nano may be affected, such as “Help me write”, local scam detection, and future browser AI features that do not go through the cloud.

For users who do not use these features, everyday browsing is usually not affected much. For users who frequently use Chrome’s built-in writing assistance, page understanding, or experimental safety detection features, the experience may fall back to cloud processing, become unavailable, or use another browser-provided alternative.

Where the controversy lies

The central question is whether a browser should download several GB of model files for AI features before the user has clearly agreed.

Supporters argue that local AI can reduce cloud processing, improve privacy, and make responses faster. Critics argue that users should at least see a clear prompt before the download, especially when the file is close to 4GB and may affect storage space and network traffic.

Privacy experts also point out that this kind of insufficiently disclosed background download may raise compliance questions under the EU ePrivacy Directive and GDPR. Whether it constitutes a violation depends on Google’s notice mechanism, default settings, data processing path, and user controls.

Summary

Chrome’s adoption of Gemini Nano shows that browsers are moving more AI capabilities onto the local device. But it also creates a new product boundary problem: local models still consume disk space and bandwidth, and they can affect the user’s sense of control over their own device.

For ordinary users, the most direct step is to check Chrome’s local AI and optimization settings. If you do not need these features, disable the related options and then delete the model files in the OptGuideOnDeviceModel directory.

A Practical llama.cpp Multi-GPU Benchmarking Approach: Is 2x V100 16GB Faster Than One 32GB Card?

Sat, 09 May 2026 15:05:41 +0800

Short version: llama.cpp multi-GPU offload is not free performance just because you add a second card. If the model already fits fully on one 32GB GPU, 2x V100 16GB is often less convenient than a single 32GB card and may even be slower. If the model does not fit on one 16GB card, the main value of dual GPUs is that the model can stay on GPU, and the benefit can be obvious.

First, Understand split mode

llama.cpp multi-GPU usage mainly revolves around --split-mode and --tensor-split. When discussing performance, distinguish these modes first:

layer: splits layers across GPUs. It is usually the most compatible starting point.
tensor: splits tensor computation across multiple GPUs. It is closer to true parallel compute, but depends more heavily on inter-GPU bandwidth and backend support.
row: an older row-splitting mode that still appears in some setups, but is usually not the first choice for new deployments.

In simple terms, layer is like putting different floors on different cards. During single-token generation, it may not keep both cards fully busy at the same time. tensor is more like letting both cards work on the same layer together. It has more theoretical parallelism, but inter-GPU communication can become the bottleneck.

If One 32GB Card Can Fit the Model, Dual 16GB Is Not Always Faster

If the model and KV cache fit fully on one 32GB GPU, a single card is usually steadier and often faster. For hardware in the same generation, such as 1x V100 32GB versus 2x V100 16GB, the dual-card setup does not necessarily win.

A conservative expectation is that 2x V100 16GB may be 10% to 40% slower than one V100 32GB, especially for single-user chat, Continue Agent, and code Q&A workloads where one request is mainly generating one answer.

The reason is straightforward: multi-GPU does not simply merge VRAM into one fast pool. With layer splitting, inference moves across GPUs and one card may wait for the other during token generation. With tensor splitting, both cards can compute together, but intermediate results need cross-GPU synchronization, so bandwidth and latency directly affect throughput.

So if your choice is:

1x V100 32GB
2x V100 16GB

and the target model already fits fully on one 32GB card, the single 32GB card is often the more comfortable option.

If One 16GB Card Cannot Fit the Model, Dual Cards Matter

The situation changes completely when the model does not fit on one 16GB card but can fit across two 16GB cards.

In that case, the value of dual GPUs is very direct:

One 16GB card: may require heavy CPU offload, which can slow things down a lot.
2x 16GB cards: weights can stay mostly on GPU, which may be much faster than mixed CPU/GPU execution.

In this scenario, 2x V100 16GB is not guaranteed to beat one 32GB card, but it may be several times faster than a single 16GB card with heavy system-memory offload. In other words, the first value of dual cards is not acceleration. It is avoiding the need to push model weights into slower system RAM.

V100 PCIe and V100 SXM2 Are Very Different

The easiest thing to overlook in multi-GPU inference is the interconnect.

If you have V100 SXM2 with NVLink, cross-GPU communication bandwidth is much higher. NVIDIA’s V100 material lists NVLink interconnect bandwidth up to 300GB/s. In that environment, tensor mode or higher-batch workloads have a better chance of approaching or exceeding single-card performance.

If you have V100 PCIe, expectations should be more conservative. V100 PCIe mainly uses PCIe Gen3, and the listed interconnect bandwidth is 32GB/s. That is a very different class from NVLink, which is why dual PCIe cards often provide enough VRAM without doubling speed.

So when judging whether 2x V100 16GB is worthwhile, do not only add the VRAM to 32GB. Also check whether the cards are PCIe or SXM2/NVLink.

A Practical Buying Rule

If the model fits on one 32GB GPU, choose the single card first. Its latency, stability, and tuning cost are usually better.

If the model does not fit on one 16GB GPU but can fit on two 16GB GPUs, dual cards are worth using. At that point, the goal is to keep weights on GPU as much as possible, not to expect linear performance scaling.

If you have dual V100 PCIe cards, start with --split-mode layer and aim for stable execution with less CPU fallback.

If you have V100 SXM2/NVLink, it is more worth testing tensor-related modes, especially for prefill, larger batches, or concurrent serving.

When to Buy 2x16GB and When to Buy 1x32GB

If you serve only one user and mainly do chat, code completion, Continue Agent, or long-context Q&A, and the target model fits within 32GB, 1x32GB is usually the better choice. It avoids cross-GPU scheduling, has steadier latency, and is easier to debug.

If you already own one 16GB card and want a lower-cost path to run 30B, 32B, or higher-quantized models, 2x16GB makes sense. It may not double token/s, but it can keep weights on GPU that would otherwise require CPU offload.

If you are buying from scratch, the priority can look like this:

Single model, single user, latency-sensitive: prefer 1x32GB.
Model does not fit on one card and budget is limited: consider 2x16GB.
Machine has NVLink or SXM2: 2x16GB is much more interesting than ordinary PCIe dual cards.
You want longer context later: do not only count model weights; reserve VRAM for KV cache too.

Practical Advice for layer split and tensor split

The practical rule is: start with layer, then benchmark tensor.

layer is the default starting point. It splits the model by layer, has better compatibility, and is friendlier to PCIe dual-card systems. The downside is that generation can behave more like a pipeline: at certain moments one card is busy while the other waits.

tensor is better suited to machines with strong interconnects, such as V100 SXM2/NVLink. It splits part of the same layer’s computation across GPUs, so it has more parallelism in theory, but it also synchronizes across cards more often. On PCIe dual cards, communication overhead may eat the benefit.

You can start with these tests:

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

The third command is not meant as the long-term configuration. It gives you a single-card reference, so you can see whether dual GPUs are actually faster or only distributing VRAM pressure.

Why prefill and decode Behave Differently

Local LLM performance should usually be viewed in two stages:

prefill: processes the input prompt. A typical metric is prompt-processing throughput such as pp512.
decode: generates the response token by token. A typical metric is token-generation throughput such as tg128.

prefill is more like large-batch matrix computation. With larger batches, it is easier to keep GPUs busy and more likely to benefit from multi-GPU parallelism. decode generates one token after another. The batch is smaller and synchronization is more frequent, so cross-card communication and scheduling latency are easier to notice.

That is why you may see dual GPUs improve pp512 while tg128 barely improves or even gets worse. For chat and agent workflows, user experience is closer to tg128. For long document ingestion, batch prefill, or concurrent serving, pp512 also matters.

Can KV cache Become a Second VRAM Bottleneck?

Yes. Many people only count model weights and forget KV cache.

Model weights decide whether the model can load. KV cache decides whether you can use the context length you want. The longer the context, the higher the concurrency, and the larger the batch, the more visible KV cache usage becomes. You may find that the model itself fits in 32GB, but 32K or 64K context pushes VRAM over the limit.

At minimum, leave VRAM headroom for:

KV cache
CUDA graph or backend runtime overhead
prompt batch and ubatch
desktop, driver, and other process usage

If you use 2x16GB, VRAM is not a fully equivalent 32GB pool. Some buffers, KV cache, or intermediate tensors may still be limited by remaining memory on a single card. When testing long context, use the target --ctx-size and target concurrency directly instead of only checking whether the model starts.

How to Benchmark Dual Cards with llama-bench

llama-bench is better than direct chatting for hardware comparison because it separates prompt processing and token generation into comparable metrics. The default example in the official README is:

`1`	`llama-bench -m model.gguf`

For dual V100 cards, test at least these sets:

# Single-card baseline
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# Dual-card layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# Dual-card tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

Focus on two columns:

pp512: prompt processing, more relevant to long inputs and batch prefill.
tg128: token generation, more relevant to single-user chat and agent responsiveness.

Keep the model, quantization, context length, batch settings, driver version, and llama.cpp version fixed. Run each group several times and compare medians rather than one-off results. Finally, test your real workflow too, such as Continue Agent, an OpenAI-compatible server, or your own RAG requests, because a good benchmark does not always mean better interactive experience.

One-Sentence Conclusion

The main advantage of 2x V100 16GB is VRAM capacity, not guaranteed generation speed. If the model fits on one card, a single 32GB card is usually faster and steadier. If the model does not fit on one 16GB card, dual 16GB cards become valuable because they avoid heavy CPU offload. Whether they are faster depends on split mode, batch size, model size, and whether the two V100 cards are connected through PCIe or NVLink.

References:

Claude Code Limits Doubled: Anthropic Uses SpaceX Compute Expansion to Ease Usage Constraints

Sat, 09 May 2026 10:59:48 +0800

On May 6, 2026, Anthropic announced higher usage limits for Claude Code and the Claude API, along with a new compute partnership with SpaceX. For everyday users, the most direct change is more usable capacity for Claude Code. For developers and enterprises, the larger point is that Claude’s inference capacity is still expanding.

The announcement has two parts:

Higher limits for Claude Code and the Claude API.
New compute capacity from SpaceX data centers.

What changed for Claude Code limits

Anthropic says the following three changes took effect on the day of the announcement:

Claude Code’s five-hour rate limit doubled for Pro, Max, Team, and seat-based Enterprise plans.
Peak-hour limit reductions for Pro and Max Claude Code accounts were removed.
Claude Opus API rate limits were significantly increased.

In practical terms, if you often use Claude Code for long coding sessions, repository analysis, refactoring, debugging, or agent workflows, this change may reduce the number of times a task stops before it is finished.

That does not mean unlimited usage. Claude Code is still affected by subscription plan, usage pattern, model, task length, context size, and platform policy. But Anthropic has clearly expanded the usable room compared with the previous limits.

Why compute affects the Claude Code experience

Tools like Claude Code consume more resources than ordinary chat. A single coding task can involve:

Reading many files.
Long-context analysis.
Multiple tool calls.
Generating, editing, and checking code.
Repeatedly running tests or explaining errors.
Using Opus for difficult reasoning.

Behind those actions are not only tokens, but also inference capacity, concurrency, and scheduling resources. Users see limits, queues, or slower peak-hour behavior; the platform sees pressure between compute supply and demand.

So Anthropic putting limit increases and a compute partnership in the same announcement is meaningful. It is saying that improving Claude Code is not just a plan-setting change, but also depends on more backend inference capacity.

What the SpaceX partnership adds

Anthropic says it has signed an agreement with SpaceX to use the full compute capacity of SpaceX’s Colossus 1 data center. The announced capacity is over 300 megawatts, corresponding to more than 220,000 NVIDIA GPUs, and will be made available to Anthropic within a month.

This added capacity is expected to directly improve available capacity for Claude Pro and Claude Max subscribers.

Anthropic also says it is interested in future work with SpaceX on orbital AI compute. That is more of a long-term direction, not the same thing as the Claude Code limit increase users can feel immediately.

Anthropic’s compute footprint is getting larger

SpaceX is only one part of Anthropic’s recent compute expansion. The company also lists other partnerships:

Up to 5GW with Amazon, including nearly 1GW of new capacity planned to come online by the end of 2026.
5GW with Google and Broadcom, expected to come online starting in 2027.
A strategic partnership with Microsoft and NVIDIA, including $30 billion of Azure capacity.
A $50 billion U.S. AI infrastructure investment with Fluidstack.

Anthropic also notes that Claude training and inference will use multiple types of AI hardware, including AWS Trainium, Google TPUs, and NVIDIA GPUs.

The trend is clear: competition among leading model companies is not only about model names, benchmarks, and product features. It is also about power, data centers, GPUs, TPUs, networking, and global deployment capacity.

Practical impact for Claude Code users

For developers, the most important change is the doubled five-hour Claude Code limit. It affects scenarios such as:

Reading large repositories.
Multi-file refactoring.
Bug investigation and test fixing.
Code migration and dependency upgrades.
Long-running agentic coding tasks.
Multiple people using Claude Code in Team or Enterprise plans.

A common Claude Code problem has been reaching the limit while a task is still in progress. Higher limits make it easier for an agent to complete a full task instead of stopping halfway.

For Pro and Max users, removing peak-hour limit reductions is also important. It means the experience may become more stable during busy periods, with less disruption from temporary tightening.

What it means for API users

The announcement also says Claude Opus API rate limits have increased significantly. For teams using Opus for difficult tasks, that usually means:

Higher concurrency.
Fewer 429 rate-limit errors.
Easier support for batch workloads.
Better fit for long-context, complex reasoning, and agent workflows.

Actual limits still vary by account, organization, model, and plan. Before production deployment, teams should still check their Anthropic Console, rate limit documentation, and error logs.

Enterprise and regional deployment matter more

Anthropic also notes that regulated industries such as finance, healthcare, and government increasingly need regional infrastructure to satisfy compliance and data residency requirements. Part of its capacity expansion will therefore be outside the United States, especially for inference capacity in Asia and Europe.

This matters for enterprise customers. Once large model applications enter core business workflows, the questions are not only whether the model is good enough. They also include:

Whether data stays in the required region.
Whether industry compliance requirements are met.
Whether peak-hour capacity is stable.
Whether team-level and organization-level concurrency are supported.
Whether audit, permission, and security controls are available.

From that perspective, compute expansion is not just performance news. It can shape enterprise procurement and deployment decisions.

Summary

Anthropic’s message is direct: Claude Code and Claude API usage constraints are being relaxed because new compute capacity is coming online.

For everyday Claude Code users, the most important points are the doubled five-hour limit and the removal of peak-hour reductions for Pro and Max. For API and enterprise users, the main points are higher Opus rate limits and Anthropic’s longer-term compute partnerships with SpaceX, Amazon, Google, Microsoft, NVIDIA, and Fluidstack.

AI tools are increasingly infrastructure services. Model quality matters, but stable capacity, regional compliance, limit policy, and cost control also shape the user experience.

Reference:

Anthropic: Higher usage limits for Claude and a compute deal with SpaceX

OpenAI's New Realtime Voice Models: GPT-Realtime-2, Live Translation, and Streaming Transcription

Sat, 09 May 2026 10:58:47 +0800

On May 7, 2026, OpenAI introduced a new generation of voice models for the Realtime API. The point is not only to make AI sound more natural, but to let voice agents understand, reason, call tools, translate, and transcribe during a live conversation.

The update includes three models:

GPT-Realtime-2: the main model for realtime voice agents, with stronger reasoning, tool calling, and longer context.
GPT-Realtime-Translate: a live speech translation model that supports 70+ input languages and 13 output languages.
GPT-Realtime-Whisper: a low-latency streaming speech-to-text model for captions, meeting notes, and realtime workflows.

If early voice assistants were mostly “ask once, answer once,” this release moves closer to a voice interface that can listen and act at the same time.

GPT-Realtime-2: the main model for voice agents

GPT-Realtime-2 is built for live voice interactions. It does not just answer questions; it needs to keep context while the user speaks, changes direction, interrupts, or adds constraints, and then call tools when needed.

Officially highlighted capabilities include:

Short preambles before a response, such as “let me check that,” so users know the system is working.
Parallel tool calls for calendars, search, orders, support systems, and other multi-tool workflows.
More natural recovery behavior when something fails.
A context window increased from 32K to 128K for longer conversations and more complex task flows.
Better retention of specialized terminology, proper nouns, and medical vocabulary.
More controllable tone and delivery, such as calm, empathetic, confirmational, or upbeat responses.
Adjustable reasoning effort: minimal, low, medium, high, and xhigh, with low as the default.

This means developers can use voice agents in more demanding products, not only simple Q&A. A support agent can listen while checking an order; a travel app can give next steps after a flight change; a real estate assistant can filter listings and schedule a tour from spoken requirements.

Live translation for multilingual voice products

GPT-Realtime-Translate is designed for live speech translation. People can speak in their own language while the other side hears translated speech and sees realtime transcripts.

Clear use cases include:

Multilingual customer support.
Cross-border sales and pre-sales conversations.
Online education and live events.
International meetings and hosting.
Creator and video platform localization.

The hard part of live translation is not only accuracy. It also requires low latency, natural pauses, tone preservation, accent handling, and domain vocabulary. OpenAI is emphasizing cross-language conversations that feel closer to natural speech, instead of waiting for an entire segment before translation begins.

Streaming transcription: voice content enters workflows immediately

GPT-Realtime-Whisper is the new streaming speech-to-text model. Its value is turning speech into usable text while it is happening, instead of waiting for a recording to finish.

Common applications include:

Live meeting captions.
Classroom and broadcast captions.
Realtime meeting notes.
Continuous dictation input for voice agents.
Follow-up workflows in support, healthcare, recruiting, sales, and other high-volume voice scenarios.

For products, streaming transcription shortens the time from spoken words to actionable text. Captions appear faster, notes can be generated during the conversation, and downstream workflows such as summaries, task extraction, and CRM updates can start earlier.

Pricing and availability

All three models are available in the Realtime API. Official pricing is:

Model	Price
`GPT-Realtime-2`	Audio input $32 / 1M tokens, cached input $0.40 / 1M tokens, audio output $64 / 1M tokens
`GPT-Realtime-Translate`	$0.034 / minute
`GPT-Realtime-Whisper`	$0.017 / minute

OpenAI also says the Realtime API supports EU Data Residency and is covered by its enterprise privacy commitments. For European businesses or products with data residency requirements, that is worth evaluating separately.

What this means for developers

The key shift is that voice is becoming part of the product interaction layer, not just an input/output layer.

In many earlier voice features, speech was converted to text, and text responses were converted back into speech. The hard middle layer is intent understanding, interruption handling, context tracking, tool calls, tool transparency, and graceful recovery.

GPT-Realtime-2 tries to move more of that capability directly into the realtime voice model. For developers, the question is not only answer quality, but whether the model can support sustained conversations and multi-step tasks.

Products that are especially worth testing include:

Customer support voice agents.
In-car and mobile voice assistants.
Travel, booking, real estate, finance, and other services that need conversation plus lookup.
Multilingual meetings and cross-border communication tools.
Live captions, meeting notes, and call quality systems.

Safety and disclosure still matter

OpenAI says the Realtime API includes multiple safety layers, such as active classifiers over sessions and the ability to stop policy-violating conversations. Developers can also add their own guardrails through the Agents SDK.

One easily missed requirement is disclosure: developers should make it clear when end users are interacting with AI, unless that is already obvious from the context.

This matters in support, sales, education, healthcare, and similar scenarios. The more natural voice becomes, the more important product boundaries become: users should know they are talking to AI, and understand when speech may be recorded, transcribed, or used to trigger tools.

Summary

OpenAI’s Realtime API update moves live voice from “can listen and speak” toward “can listen while working through tasks.”

GPT-Realtime-2 handles more complex voice agents, GPT-Realtime-Translate handles live cross-language communication, and GPT-Realtime-Whisper handles low-latency transcription. Together, they cover the three basic capabilities most voice products need: conversation, translation, and transcription.

If you are building support, in-car, meeting, education, cross-border communication, or mobile voice assistant products, this release is worth testing. The important question is not only whether the model sounds natural, but how it performs in long conversations, interruptions, tool calls, failure recovery, and cost control.

Reference:

OpenAI: Advancing voice intelligence with new models in the API

What to Do if Your Claude Account Is Suspended: Claude Code Limits and Appeal Guide

Sat, 09 May 2026 10:32:12 +0800

When a Claude or Claude Code account is suddenly limited, suspended right after payment, loses Pro access, or shows lower-than-expected usage capacity, many users naturally look for quick explanations. The important point is that this should not be treated as a simple “change IP” or “create another account” technical problem. Account risk systems usually combine signals such as region, payment, device, login behavior, usage content, automation, and sharing patterns.

A safer way to handle the issue is to first identify what kind of problem you actually have: normal quota limit, payment or subscription mismatch, Claude Code authorization issue, or an account-level action because Anthropic believes usage violated its policies or terms.

First, distinguish three situations

The first category is normal usage limits. Claude Pro, Max, Team, API, and Claude Code have different quota models. Peak-hour use, long context, coding tasks, and agent workflows may consume limits faster. Seeing “limit reached” does not necessarily mean your account is banned.

The second category is subscription or authorization trouble. For example, payment may have succeeded but access has not refreshed, a mobile subscription may not match the web account, Claude Code may not be logged in correctly, or an old ANTHROPIC_API_KEY may remain in your environment. Start by checking billing, login state, and client configuration.

The third category is account suspension or termination. Typical signs include emails mentioning suspension, disabled account, or termination, or a login page that says the account is unavailable. In this case, do not repeatedly switch devices, networks, and accounts to try again. That may make the risk signals more complicated.

Common triggers

Anthropic’s help and privacy documentation mention common risk areas such as violations of the Usage Policy, account creation or use from unsupported regions, terms violations, repeated violations, unusual access, and abuse.

In practice, risky patterns include:

Account registration, login region, and payment region do not match.
Long-term use of datacenter proxies, shared proxies, or frequent IP switching.
Multiple people sharing one personal account.
Frequent logins from many devices or regions in a short time.
Automated high-frequency access to Claude.ai.
Treating Claude Code as a shared service or resale entry point.
Requesting content that clearly violates Anthropic’s policies.
Conflicts among payment method, billing address, and account region.

The key is not that any single signal always causes suspension. The risk increases when multiple abnormal signals appear together.

Do not solve it by evading risk controls

Online advice often suggests “stable usage solutions” such as fingerprint browsers, device fingerprint reset, deleting local folders, changing environments, aligning time zone and language, or registering with a new email. Some of this is ordinary troubleshooting, but some is clearly aimed at evading platform risk controls.

Do not treat “bypassing risk control” as the solution. Reasons are simple:

It may violate the terms of service.
It may add more account risk signals.
It does not solve root causes such as payment, region, or policy violations.
For team or business use, it makes later appeals harder to explain.

If your goal is long-term stable use of Claude, the right direction is not disguise. It is making account information, region, payment, device, and usage real, consistent, and explainable.

Troubleshooting Claude Code limits

Claude Code users can start with:

1
2

claude --version
claude auth status

If you use an API key, confirm that the environment variable points to the right account:

`1`	`echo $ANTHROPIC_API_KEY`

In Windows PowerShell:

`1`	`echo $env:ANTHROPIC_API_KEY`

If you have used web login, OAuth, API keys, third-party clients, or different terminals, standardize the authentication method first. One tool may still be using old credentials.

Also distinguish two cases:

Claude Code reached its usage limit: usually a quota or subscription issue.
The account or organization is disabled: usually an account, organization, payment, or policy risk issue.

For the first, wait for quota refresh or adjust the plan. For the second, keep screenshots and emails, then use official support or appeal channels.

Compliant stability tips

To reduce the chance of account problems, start with the basics:

Use a normal account in a supported country or region.
Keep login region, payment method, and billing information consistent when possible.
Avoid sharing a personal account among multiple people.
Do not use a personal Pro/Max account as a team API pool.
Avoid frequent changes of IP, device, and browser environment.
Do not use unknown third-party Claude clients.
Avoid high-frequency automation against Claude.ai’s web interface.
For business or team use, prefer Team, Enterprise, or API plans.
Read Anthropic’s Usage Policy and avoid restricted use cases.

If you genuinely need to use Claude on multiple devices, log in normally. Do not keep clearing environments, changing fingerprints, or switching proxies. Excessive environment manipulation can itself look abnormal.

What to do after suspension

If the account is already suspended, handle it in this order:

Check emails from Anthropic or Claude and confirm the stated reason or message type.
Stop creating new accounts, changing networks, and retrying from more devices.
Collect account email, subscription order, payment proof, and recent usage context.
If you believe it is a mistake, submit an appeal or contact support through official channels.
Explain the real usage scenario. Do not invent region, identity, or purpose.
If payment is involved, ask separately about refund or subscription handling.

When appealing, be specific. Mention whether you used Claude Code, switched devices, used a VPN, shared with a team, or connected third-party tools. The platform needs to identify the source of risk. A vague “I did nothing” usually does not help much.

Claims to treat carefully

Some posts or videos claim that “fixed fingerprints prevent bans”, “one browser prevents suspension completely”, “deleting one directory resets device identity”, or “matching IP, time zone, and language solves everything”. Do not accept these claims uncritically.

Platform risk systems are usually multidimensional. They do not only look at browser fingerprint or IP. Account history, payment information, region policy, content, access frequency, automation patterns, client version, and API calling behavior may all matter. Single-signal disguise is not long-term stability and may create more inconsistencies.

More importantly, many so-called anti-ban solutions are actually selling tools or services. What users really need is to identify the risk source, use the service compliantly, and preserve appeal evidence, not rely on third-party environment wrappers for account safety.

Summary

Claude account suspension or Claude Code limitation is not always caused by one thing. It may be quota, subscription, authorization, or a combined risk signal involving region, payment, device, sharing, automation, or policy-sensitive content.

The key to long-term stable use of Claude is not bypassing risk controls. It is compliant usage, consistent account information, stable access patterns, and formal plans for team use. If an account is suspended, stop manipulating the environment, preserve evidence, and use official appeal and support channels.

References:

From PPT to Prototypes: Use Cases for Guizang PPT Skill and Huashu Design

Sat, 09 May 2026 08:34:23 +0800

Two design-oriented Agent Skills made by Chinese developers are worth looking at side by side: guizang-ppt-skill by Guizang, and huashu-design by Huashu.

They are not “design tools” in the traditional sense. Instead, they turn a design process, aesthetic preferences, checklists, and engineering templates into Skills that an Agent can execute. You are not opening a UI and slowly dragging elements around. You hand the requirement to an Agent such as Claude Code, Codex, or Cursor, and let it generate HTML, PPT, animation, or prototypes through a fixed workflow.

The value of these projects is not that they let AI improvise. It is that they turn “how to make this not look bad” into a repeatable process.

guizang-ppt-skill: focused on magazine-style web PPT

Guizang’s guizang-ppt-skill has a clear positioning: it generates single-file HTML, horizontally paged PPTs with a visual baseline of “digital magazine x e-ink.” It feels more like a layout system prepared for talks than a general-purpose design framework.

The repository README lists these core capabilities:

Single-file HTML output, with no build step or server required. Open it directly in a browser.
Horizontal page navigation, with support for keyboard, mouse wheel, touch swipes, bottom dots, and an ESC index.
5 preset theme palettes, including Ink Classic, Indigo Porcelain, Forest Ink, Kraft Paper, and Dune.
10 page layouts, including opening cover, section divider, big-number data poster, text-left-image-right, image grid, Pipeline, suspense question, large quote, Before/After comparison, and mixed text-image layout.
Built-in templates, component notes, layout skeletons, theme configuration, and quality checklists.

It is suitable for offline sharing, internal industry talks, private salons, AI product launches, demo days, and presentation decks with a strong personal style. It is less suited to large tables, training courseware, or multi-person collaborative editing.

This project makes a good tradeoff: it does not try to cover every design scenario, but narrows itself to “magazine-style PPT.” Theme colors are chosen from presets, and layouts have clear skeletons. That actually reduces the chance of the Agent drifting off course.

If you often need to turn opinions, industry observations, or product launch content into a presentation deck, it can be highly practical.

The install command is straightforward:

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design: a fuller HTML-native design workflow

Huashu’s huashu-design has broader coverage. Its goal is not just to make PPTs, but to treat HTML as a native design canvas and let an Agent produce deliverable design assets.

The repository README lists these capabilities:

Clickable App or Web prototypes.
HTML slides, plus editable PPTX export.
Product launch animations, MP4, GIF, and versions with music.
Multiple design directions shown side by side for comparison.
Infographics, data visualizations, and PDF, PNG, SVG export.
5-dimensional expert review, covering philosophical consistency, visual hierarchy, execution craft, functionality, and innovation.

Its core idea is to let the Agent understand the brand and assets first, then produce high-fidelity design. The project emphasizes a Core Asset Protocol: when dealing with a specific brand, first confirm the logo, product images, UI screenshots, color palette, fonts, and brand guidelines instead of guessing from memory.

This matters. Many AI-generated designs look “like design,” but they do not look like a real product or brand. huashu-design tries to solve that problem up front: find real assets first, then design.

The install command is:

`1`	`npx skills add alchaincyf/huashu-design`

It is better suited to people who want to complete a fuller design delivery from the terminal: product prototypes, launch animations, presentations, infographics, and design reviews can all be handled inside one Agent workflow.

The biggest difference between the two

In simple terms, guizang-ppt-skill is a narrower and steadier presentation deck generator; huashu-design is a broader and more complete HTML-native design system.

If you only look at PPT:

guizang-ppt-skill emphasizes magazine feel, rhythm, layout, and single-file browser presentations.
huashu-design emphasizes general design capability, editable PPTX, brand assets, export paths, and review workflows.

If you look at overall design capability:

guizang-ppt-skill has clearer boundaries and is suitable for quickly making a stylish horizontal presentation.
huashu-design is more comprehensive and is suitable for breaking a product or brand design task into prototypes, animations, slides, and infographics.

These two projects also represent two different ways to write Skills. The former is like a highly constrained set of templates and aesthetic rules. The latter is like a workflow manual for a small design team.

Why this kind of Skill matters

A common problem with Agents is that they “can do it, but not consistently.” The same request may produce a strong result once, then drift into purple gradients, rounded cards, fake icons, and a pile of fancy-sounding empty copy the next time.

Skills are a way to add stability. They lock down things such as:

Reusable templates.
Executable checklists.
Clear aesthetic preferences.
Rules for avoiding common mistakes.
Output formats and validation flows.
When to ask questions and when to start directly.

This is far more reliable than simply writing “please make it look more premium.”

This is especially true for design tasks. Aesthetics cannot be reproduced reliably by a single prompt. What really helps is process: confirm assets first, decide the direction, build the structure, work on the visuals, then inspect the output. When this process is written as a Skill, the Agent becomes more like a collaborative executor rather than a one-shot image generator.

Usage recommendations

If you just want to turn a topic into an offline talk or sharing deck, try guizang-ppt-skill first. Its output boundary is narrow, and single-file HTML is also easy to distribute and preview.

If you want an Agent to take on a more complete design task, such as App prototypes, launch animations, branded slides, exportable PPTX, or infographics, look at huashu-design first. Its workflow is longer and better suited to tasks that need multiple rounds of iteration and exported deliverables.

If you are already writing your own Codex or Claude Code Skill, both projects are worth studying:

To learn “how to make a narrow scenario stable,” look at guizang-ppt-skill.
To learn “how to break a complex workflow into executable protocols,” look at huashu-design.

Summary

What Guizang and Huashu have in common is that both turn “design capability” from a one-time prompt into a repeatable process.

guizang-ppt-skill focuses on magazine-style HTML PPT and works well for highly stylized presentations. huashu-design focuses on an HTML-native design system covering prototypes, animations, slides, infographics, and reviews. The problem they solve is not “can AI generate design,” but “can AI generate deliverable design through a stable method.”

This may become an important type of open-source project in the Agent tooling ecosystem: not just code templates, but packaged human experience, aesthetics, and working methods as Skills.

Reference links:

Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag is a set of Linux kernel local privilege escalation vulnerabilities disclosed in May 2026 with signs of active exploitation. Microsoft describes it as a post-compromise risk: after an attacker gains low-privileged code execution, the bug may be used to escalate to root. Ubuntu has also marked CVE-2026-43284 as High.

The danger is not “remote one-click compromise”. The danger is that once an attacker gets in, they can expand control quickly. If they gain local execution through weak SSH credentials, a web shell, container escape, a low-privileged service account, or phishing-enabled remote access, Dirty Frag may let them obtain root and then disable security tools, read credentials, tamper with logs, move laterally, or persist.

Which CVEs are involved

Public information currently associates Dirty Frag mainly with two IDs:

CVE-2026-43284: related to the Linux kernel xfrm/ESP path. Microsoft’s esp4 and esp6 references belong to this risk area.
CVE-2026-43500: Microsoft says this is related to rxrpc, but as of May 8, 2026, the CVE had not yet been published in NVD and patch status was still evolving.

So do not check only one CVE. A safer approach is to review whether esp4, esp6, rxrpc, and related xfrm/IPsec functions are enabled, needed, and patched by your distribution.

Technical overview

According to Microsoft and Ubuntu, CVE-2026-43284 involves Linux kernel networking and memory-fragment handling, especially how shared page fragments are handled in the ESP/IPsec path.

In simplified terms, data pages can be attached to network buffers through mechanisms such as splice. If later kernel paths treat those fragments as privately owned and safe to modify in place, in-place decryption or modification can happen where it should not. An attacker may manipulate page cache behavior and eventually achieve local privilege escalation.

This has similarities to CopyFail (CVE-2026-31431): both involve Linux page cache behavior, kernel data paths, and local privilege escalation. Dirty Frag is dangerous because it adds more attack paths and may be more reliable than traditional LPE exploits that depend on tight race windows.

Environments to prioritize

Dirty Frag is a local privilege escalation vulnerability, so the attacker must already be able to execute code locally. Prioritize:

Linux servers with exposed SSH.
Web servers where a web shell could be written.
Multi-user login hosts, bastions, developer machines, and CI/CD runners.
Container hosts, Kubernetes nodes, and OpenShift nodes.
Systems using IPsec, VPN, xfrm, or RxRPC-related functionality.
Servers running Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and other mainstream distributions.

If a server has no local multi-user access, no containers, and no exposed application path, risk is lower. But any system where an attacker might obtain a low-privileged shell should treat this as a high-priority kernel issue.

Patch first

The safest fix is to install the kernel security update from your distribution and reboot into the new kernel.

Ubuntu’s CVE page shows CVE-2026-43284 was published on May 8, 2026 and is rated High. Microsoft also says the Linux Kernel Organization has released fixes for CVE-2026-43284 and urges customers to apply patches promptly.

Start by checking the system:

1
2

uname -a
cat /etc/os-release

Then update the kernel using your distribution’s package manager:

`1`	`sudo apt update && sudo apt full-upgrade`

Or:

`1`	`sudo dnf update`

After updating, confirm that the system has rebooted into the new kernel:

`1`	`uname -r`

Installing kernel packages without rebooting leaves the old kernel running, so the vulnerability may still be present.

If patches are not yet available, or production cannot reboot immediately, evaluate whether you can temporarily disable the related modules. Ubuntu’s mitigation blocks esp4, esp6, and rxrpc from loading and unloads them if already loaded.

Create modprobe blocking rules:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Update initramfs so the modules are not loaded during early boot:

`1`	`sudo update-initramfs -u -k all`

Unload currently loaded modules:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Check whether the modules are still loaded:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

If a module is in use, unloading may fail. In that case, the block rule may only take effect after reboot.

Evaluate business impact before disabling

Do not paste the mitigation blindly. esp4, esp6, and xfrm/IPsec functionality may be used by VPNs, tunnels, encrypted networking, Kubernetes/container networking, or enterprise network configurations. rxrpc may also affect workloads that depend on that protocol.

Before using the mitigation in production, check at least:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

If you depend on IPsec VPN or related kernel networking, disabling modules may break connectivity. In that case, schedule kernel patching and a maintenance reboot rather than relying on module blocking for long.

Do not skip post-compromise checks

Microsoft specifically notes that mitigation does not necessarily undo changes already made by successful exploitation. If an attacker already gained root, they may have left persistence, modified files, altered logs, or accessed session data.

At minimum, check:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

Also review:

Abnormal su, sudo, or SUID/SGID process launches.
Newly created ELF executables.
Suspicious PHP, JSP, or ASP files in web directories.
Changes to SSH authorized_keys.
New persistence in systemd services, cron, or rc.local.
Suspicious privileged containers or host mounts.

If exploitation is suspected, isolate the host, preserve evidence, rotate credentials, and then clean up. Do not assume that unloading modules or clearing caches makes the system safe.

About drop_caches

Microsoft mentions that in some post-exploitation integrity verification scenarios, cache clearing may be evaluated:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

This is not a vulnerability fix and not an incident cleanup command. Dropping caches can increase disk I/O and affect production performance. Use it only as an auxiliary step after understanding the impact. The real fix remains patching, rebooting, verifying integrity, and checking persistence.

Recommended response order

For production environments, a reasonable response sequence is:

Inventory Linux assets and kernel versions.
Prioritize systems with exposed SSH, web workloads, container hosts, and multi-user access.
Patch and reboot systems that can be restarted quickly.
For systems that cannot yet patch or reboot, evaluate disabling esp4, esp6, and rxrpc.
Increase monitoring for su, SUID/SGID activity, suspicious ELF files, web shells, and container escape indicators.
Run post-compromise checks and rotate credentials on hosts that may already have been exploited.

Summary

Dirty Frag is not a “remote one-click” vulnerability, but it significantly increases post-compromise risk. If an attacker can run code locally with low privileges, CVE-2026-43284 and the related rxrpc attack surface may allow escalation to root.

For administrators, the priority is not studying PoCs. The priority is to confirm kernel exposure, install distribution security updates and reboot, evaluate module-blocking mitigations before the patch window, and inspect exposed or suspicious systems for integrity and persistence issues.

References:

Btrfs Scrub Guide: Data Verification, Auto-Repair, and Regular Maintenance

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub is one of the most important and most misunderstood Btrfs maintenance features. It is not fsck in the traditional sense. It is an online validation pass that reads filesystem data and metadata, verifies checksums, superblocks, metadata block headers, and disk read errors, and tries to repair damage when a known good replica exists.

If you use Btrfs on a NAS, home server, backup disk, or multi-device array, scrub should be part of regular maintenance. Its value is not “run it after disaster”. Its value is finding silent corruption early, while disks are still readable and good replicas still exist.

What scrub checks

According to the official Btrfs documentation, scrub scans filesystem data and metadata and mainly checks:

Data block checksum errors.
Basic super block errors.
Basic metadata block header errors.
Disk read errors.

On filesystems using replicated block group profiles such as RAID1, scrub on a read-write mount can automatically repair some damage. The repair is not magic recovery. Btrfs copies verified good data from another replica.

This is the key point: scrub repair depends on having a known good copy. On a single disk with only one copy of the data, scrub can detect checksum errors, but it usually cannot restore the original content by itself.

Common commands

Start scrub on a mount point:

`1`	`sudo btrfs scrub start /`

Run it in the foreground, useful for manual observation:

`1`	`sudo btrfs scrub start -B /`

Check status:

`1`	`sudo btrfs scrub status /`

Cancel a running scrub:

`1`	`sudo btrfs scrub cancel /`

Resume an interrupted scrub:

`1`	`sudo btrfs scrub resume /`

If you specify a Btrfs mount path, Btrfs scrubs all devices in that filesystem in parallel. If you specify a device, only that device is scrubbed. But if the replica on the specified device cannot be read or verified, Btrfs still tries to read a good copy from another device.

Scrub is not fsck

This is the easiest mistake to make. Scrub is not btrfs check, nor a traditional filesystem checker.

Scrub can:

Use checksums to detect data or metadata corruption.
Auto-repair when another reliable replica exists.
Detect disk read errors and some basic structural errors.

Scrub cannot:

Rebuild data when no good replica exists.
Replace offline filesystem checking.
Repair all complex tree-structure corruption.
Guarantee that application-level file contents are correct.

If filesystem structures are badly damaged, tools such as btrfs check may be needed under expert guidance. Do not treat scrub as a universal repair command.

NOCOW file risks

The Btrfs documentation calls out an important caveat: setting the NOCOW attribute with chattr +C currently also enables NODATASUM. That means the file data itself has no checksum.

Scrub can still validate and repair metadata for these files, but it cannot validate their data contents. This is especially risky in multi-replica setups: if one copy of a NOCOW file is damaged, Btrfs has no data checksum to tell which replica is good, so it may return bad contents to user space.

Some applications use +C by default for performance. systemd journal and some libvirt storage pool scenarios are notable examples. For VM images, databases, and log directories, this can make sense for performance, but it also means you cannot expect scrub to protect their data contents the same way it protects normal COW files.

Read-only scrub can still write

Another counterintuitive point: running read-only scrub on a read-write mounted filesystem can still cause some writes.

The official documentation explains that this is due to a design limitation around avoiding races between marking block groups read-only and writing back block group items. In other words, if you want scrub to perform no writes at all, you need to run read-only scrub on a read-only mounted filesystem. Adding a read-only scrub option on a read-write mount is not enough.

For normal users, this means:

Routine online scrub can run on a read-write mount.
For forensics, failure analysis, or very conservative read-only checks, confirm the mount state first.
Do not interpret read-only scrub as absolutely zero-write.

Interruption and resume

On newer kernels, scrub may be interrupted by events such as suspend, hibernate, filesystem freezing, cgroup freezing, and pending signals. After such an interruption, the running scrub is cancelled, but it can be resumed with btrfs scrub resume.

Scrub status is recorded under:

`1`	`/var/lib/btrfs/`

File names usually look like:

1
2

scrub.status.UUID
scrub.progress.UUID

The status file is updated periodically. A resumed scrub continues from the last saved position instead of starting completely over.

How often to run it

The official recommendation is once per month. In practice, adjust based on data importance and disk condition.

Common schedules:

Home NAS: once per month.
Backup disks: after long attachment sessions or once per month.
Important multi-device arrays: once per month, or more often if needed.
New disk migration or suspected disk problems: run immediately after migration.

Scrub may use around 80% of device bandwidth on an idle filesystem, so do not run it during peak workload. On HDD arrays, latency can rise noticeably during scrub. On SSDs, it still adds read amplification and background pressure.

Limiting scrub bandwidth

In the past, ionice was often used to reduce scrub impact on foreground I/O. The official documentation warns that this is not supported equally by all I/O schedulers. CFQ is no longer generally available. BFQ supports the relevant priority behavior, but you should understand it before using it. For common schedulers such as mq-deadline, cgroup2 I/O controller or Btrfs-specific limits are usually better.

Example using systemd to limit read bandwidth:

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Since Linux 5.14, Btrfs can set per-device scrub limits through sysfs:

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

Show current limits:

`1`	`sudo btrfs scrub limit /`

This setting is not persistent and disappears when the filesystem is unmounted. Replace FSID and DEVID with the actual values for your system. You can start by checking:

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

Practical maintenance workflow

A reasonable Btrfs maintenance workflow can look like this:

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

If scrub reports corrected errors, Btrfs has repaired data from a good replica, but you should not ignore it. Continue checking disk SMART, cables, power, controllers, and Btrfs device stats.

If scrub reports uncorrectable errors, Btrfs could not find a good copy. Back up whatever can still be read, identify the affected files or device, and replace hardware or restore from backup as needed.

Summary

Btrfs scrub has a clear role: online data verification and replica repair. It is not fsck, and it is not backup.

It works best on Btrfs filesystems with checksums and redundant replicas, where it can regularly find silent corruption and restore from good copies. It cannot protect NOCOW file data without checksums, and it cannot recover damaged contents without a good replica.

If you store important data on Btrfs, run scrub monthly and use it together with SMART, device stats, backups, and alerting. Reliable data safety comes from checksums, redundancy, monitoring, and backups working together, not from a single command.

References:

Btrfs official documentation: Scrub

Intel DG1, Arc A310, and Arc A380 Buying Guide: Low-Power GPUs and AV1 Display Cards Compared

Sat, 09 May 2026 07:02:04 +0800

Intel DG1, Arc A310, and Arc A380 all look like entry-level discrete GPUs, but they represent three different stages of Intel’s discrete graphics journey. DG1 is closer to an early experiment and developer validation product. A310 is a low-power media card. A380 is a more complete entry-level gaming option from the first-generation Arc desktop lineup.

If you only look at price, they are easy to compare directly. But once you consider compatibility, media engines, Resizable BAR, driver support, and real use cases, the right buyer for each card is very different.

Specs at a glance

Model	Intel Iris Xe DG1	Intel Arc A310	Intel Arc A380
Architecture	Xe-LP	Xe-HPG / Alchemist	Xe-HPG / Alchemist
Scale	Common desktop cards use 80 EU; mobile Xe MAX has 96 EU	6 Xe Cores	8 Xe Cores
VRAM	4GB LPDDR4X	4GB GDDR6	6GB GDDR6
Memory bus	128-bit	64-bit	96-bit
Typical power	About 30W	About 30-50W depending on board	About 75W depending on board
Interface / compatibility	OEM and platform restrictions	Standard PCIe, ReBAR recommended	Standard PCIe, ReBAR recommended
AV1 hardware encode	No	Yes	Yes
Main use	Collecting, research, tinkering	NAS, HTPC, transcoding, display card	1080p esports, light productivity, transcoding

The key point is not just core count. DG1 is not a good normal DIY card, while much of the value of A310 and A380 comes from their modern media engine, especially AV1 hardware encode/decode.

DG1: more collectible than practical

DG1 was Intel’s early attempt to re-enter the discrete GPU market. It is based on Xe-LP, and many design choices are closer to mobile Iris Xe MAX than later Arc A-series cards.

Its biggest problem is not weak performance, but compatibility. DG1 desktop cards were mainly aimed at OEMs and specific motherboard bundles. Ordinary motherboards may not boot with them, and BIOS, firmware, and driver support are not as painless as standard retail graphics cards.

DG1’s practical role is therefore clear:

Hardware collecting.
Studying Intel’s early discrete GPU ecosystem.
Firmware, driver, and compatibility experiments.
Not suitable as a stable display card for an office PC, NAS, or home machine.

If you just want a cheap, low-power, stable card for display output and video decode, DG1 is usually the wrong choice.

Arc A310: low-power AV1 display and media card

Arc A310 is the best choice here for NAS, HTPC, and low-power transcoding.

Its 3D performance is limited, and 4GB GDDR6 with a 64-bit bus leaves little room for gaming. But A310 has the same-generation media capabilities as the Arc A family, including AV1 hardware encode and decode. That matters for video transcoding, livestreaming, recording, media servers, and low-power editing.

Many A310 partner cards are half-height, short, single-slot, or bus-powered designs. They fit well in small cases, old office PCs, NAS systems, and HTPCs. For these machines, A310 is not about benchmark scores. Its value is:

Stable multi-display or high-resolution output.
Hardware decode for H.264, HEVC, AV1, and other common formats.
AV1 hardware encode to reduce CPU load.
Power and heat that are easier to control than higher-end GPUs.

If your main use case is Plex, Jellyfin, Tdarr transcoding, OBS recording, streaming, video format conversion, display output, or office work, A310 is often better than an old used GPU.

Arc A380: entry-level gaming and light productivity

Arc A380 is the fastest of the three, with 8 Xe Cores, 6GB GDDR6, and a 96-bit memory bus. It is still an entry-level card, but it is more suitable than A310 for light gaming and some graphics productivity tasks.

At 1080p, A380 can handle many online and lighter games, including League of Legends, some esports titles, indie games, and older AAA titles. Its appeal is not absolute frame rate, but a low price combined with a modern media engine, 6GB of VRAM, and continued Arc driver improvements.

Compared with A310, A380 is a better fit if you:

Occasionally play online games.
Want the extra headroom of 6GB VRAM.
Want both AV1 transcoding and light GPU compute.
Do not want to buy a very old used GTX card or ex-mining card.

But if your main target is modern AAA gaming, A380 is still not ideal. It is a low-budget “good enough” new card, not a gaming sweet spot.

Resizable BAR matters

Before buying A310 or A380, make sure your motherboard supports and enables Resizable BAR, also called Re-Size BAR. On AMD platforms it is often called Smart Access Memory.

Intel’s guidance is that Arc A-series graphics need Resizable BAR enabled for optimal performance. Without ReBAR, the card is not necessarily unusable, but game performance and some GPU workloads may suffer noticeably, with more stutter and lower frame rates.

Check these BIOS settings:

Above 4G Decoding: enabled.
Resizable BAR / Re-Size BAR: enabled.
CSM: usually disabled, with UEFI boot.
GPU driver: use the latest stable Intel driver.

If your platform is old, such as pre-10th-gen Intel or an older AMD platform, confirm BIOS support for ReBAR before buying an Arc A-series card. A310 may still be acceptable as a pure transcoding card, but A380 becomes less attractive for gaming without ReBAR.

Buying advice

For ordinary users, DG1 is not recommended. It is more of a collector’s or tinkering card than a stable practical display card.

If you need a low-power GPU for a NAS, HTPC, home media server, transcoding box, or office PC, start with Arc A310. Its strengths are low power, small size, AV1 hardware encode/decode, and modern platform compatibility.

If you want a low-budget new card that can handle AV1 transcoding and some 1080p online or light gaming, Arc A380 is the better choice. The extra 2GB VRAM and larger GPU give it more headroom than A310.

In short:

DG1: collecting, research, tinkering; not recommended for daily use.
A310: best for NAS, HTPC, AV1 transcoding, and display output.
A380: entry-level online gaming, light productivity, low-budget new-card builds.

Summary

DG1, A310, and A380 are not a simple performance ladder. DG1 is an early experiment with heavy compatibility limits. A310 is a low-power media card whose value is mostly AV1 and compact form factors. A380 is a more practical entry-level Arc card for ordinary users, combining video features with light gaming.

If you want stable daily use, choose between A310 and A380. For transcoding and display output, choose A310. For online games and a little more VRAM headroom, choose A380. Leave DG1 to people who genuinely enjoy hardware experiments.

References:

Anthropic Partners With SpaceX: Frontier AI Enters the Heavy-Industry Compute Era

Fri, 08 May 2026 23:39:08 +0800

Anthropic’s compute partnership with SpaceX looks, on the surface, like a resource lease. Anthropic gains access to more than 300MW of new capacity at SpaceX’s Colossus 1 data center and roughly 220,000 NVIDIA GPUs. Claude users then see higher usage limits, increased Claude Code capacity, and fewer peak-hour constraints.

But the significance goes beyond “Claude works better now”. It shows that frontier model competition is moving below model capability, product experience, and fundraising into a heavier infrastructure layer: electricity, data centers, network scheduling, GPU utilization, chip supply chains, and perhaps, in the long run, orbital compute.

Compute is not just buying GPUs

For the past two years, the common AI company story has been “we need more compute”. Whoever could secure more H100, H200, or B-series GPUs seemed closer to the next frontier model. By 2026, the question is no longer simply whether a company has GPUs. It is whether those GPUs can actually be used efficiently.

The difficulty of superlarge clusters is systems engineering. Once GPU counts reach hundreds of thousands, bottlenecks shift from single-card performance to whole-system orchestration: networking, parallel training, failure recovery, data I/O, liquid cooling, power stability, and software stack optimization. Each layer eats into real throughput.

Owning compute and digesting compute are different things. The first depends on capital and supply chains. The second depends on engineering. For model companies, the moat is no longer only architecture and training data. It also includes the ability to make huge GPU fleets work together efficiently.

Why Anthropic needs this capacity

Anthropic’s demand pressure is clear. Claude usage has grown quickly across developers, enterprises, agents, and coding workflows. Claude Code in particular can consume large amounts of inference capacity. The limits, queues, slowdowns, and peak-hour constraints users see are product-level symptoms of tight compute supply.

Anthropic already has major infrastructure partnerships with Amazon, Google, Broadcom, Microsoft, NVIDIA, and others. The SpaceX capacity matters because it is closer to a rapid supply injection: a GPU cluster that can quickly ease Claude’s usage pressure.

That is why users first notice higher limits. For a model company, compute is not an abstract asset. It becomes response speed, usable quota, API stability, and peak-hour experience.

Why SpaceX would lease it out

From the SpaceX or Musk side, providing Colossus 1 capacity to Anthropic is also a practical infrastructure business.

AI clusters are heavy assets: expensive to buy, fast to depreciate, costly to operate, and exposed to rapid GPU replacement cycles. If the company’s own model team cannot fully consume the resources in the short term, leasing idle or underused compute to a top-tier model company can turn depreciation pressure into cash flow.

That makes SpaceX look a little like a cloud provider. It can train Grok, but it can also sell part of its AI infrastructure capacity to other model companies. For Musk, there is another effect: supporting Anthropic strengthens a leading OpenAI alternative and creates pressure on an old rival.

AI competition is getting heavier

The most important trend in this partnership is that AI is becoming heavier.

Early large-model competition felt like a software contest: model design, data recipes, training tricks, benchmarks, and product packaging. Those still matter. But frontier competition now depends deeply on the physical world:

Is electricity cheap, stable, and sustainable?
Can data centers get land, permits, construction, and grid connections quickly?
Can networks support massive parallel training?
Can GPUs and custom chips arrive on time?
Can cooling systems handle dense continuous load?
Can the software stack maintain high utilization?

That is what “AI heavy industry” means. Large models are no longer just algorithms in a lab. They are industrial systems spanning power grids, real estate, semiconductors, cloud computing, and capital markets.

Terafab and the chip loop

SpaceX’s Terafab plan fits into the same logic. Public reports say SpaceX has filed plans for a semiconductor facility in Texas, with an initial investment that may reach $55 billion and multiphase total investment that could reach $119 billion.

That does not mean SpaceX can suddenly challenge TSMC, nor that a 2nm process can be built quickly with capital alone. The hardest parts of advanced manufacturing are not buying tools, but yield, process tuning, talent, supply chains, and years of accumulation. Even if the project moves well, it would be a multiyear or decade-scale systems project.

Still, it reflects a clear trend: AI giants increasingly do not want their fate to depend entirely on external chip supply chains. NVIDIA controls GPUs and CUDA, while TSMC controls advanced manufacturing capacity. If any link is constrained, model training and product iteration slow down. Vertical integration therefore becomes more attractive.

Orbital compute is still a long-term idea

The idea of orbital compute should also be treated carefully. SpaceX does have low-cost launch capability, satellite networks, and aerospace engineering depth. Space also offers solar power and cooling-related possibilities. But moving data centers into orbit at scale still faces launch cost, maintenance, radiation, shielding, communication latency, hardware lifetime, and business-return questions.

So the safer framing is that orbital compute is a long-term infrastructure imagination, not a mature commercial solution. It represents a Musk-style question about AI resource boundaries: if power, land, and cooling on Earth become bottlenecks, where else can the physical space come from?

Impact on OpenAI and the model landscape

The most direct effect of Anthropic’s new capacity is stronger Claude service. Higher limits, fewer peak constraints, and more stable developer experience make it more competitive in coding, enterprise, agent, and long-task scenarios.

For OpenAI, that means competitive pressure is not only about model quality. It also comes from how quickly rivals can secure usable compute, schedule clusters efficiently, lower costs, and turn infrastructure into product experience.

For the industry, model companies are starting to resemble hybrids of cloud providers, chip companies, and energy developers. Future frontier AI companies may need to train models, build data centers, negotiate electricity, customize chips, optimize networks, and manage enormous capital expenditure at the same time.

Summary

Anthropic’s partnership with SpaceX is not just a Claude capacity expansion, nor merely Musk “allying” with an OpenAI rival. It is a signal that AI competition is moving from the model layer into the infrastructure layer.

Algorithms still matter, but algorithms alone are no longer enough. The next stage will favor companies that can secure reliable energy, run massive GPU fleets at high utilization, and gain more control over chips and data-center capacity.

Compute is becoming the oil of the AI era. The truly scarce resource is not one GPU, but the industrial organization ability to connect energy, chips, networks, scheduling, and product demand.

References:

Musk vs. OpenAI Trial: Nonprofit Mission, Control, and the AI Race

Fri, 08 May 2026 23:37:37 +0800

The lawsuit between Elon Musk, OpenAI, and Sam Altman looks on the surface like a falling-out between former partners. Underneath, it raises one of the central structural questions in AI: when building frontier models requires enormous capital, can an organization founded around public benefit, openness, and safety move toward a more commercial form, and under what constraints?

The dispute keeps attracting attention not only because the people involved are among Silicon Valley’s most influential figures, but also because it puts three OpenAI tensions on stage at once: nonprofit mission versus commercial financing, AI safety rhetoric versus market competition, and founder contribution versus later control.

What the trial is really about

Based on public reports, Musk’s core argument is that OpenAI had a clear public-benefit mission at founding, and that his early donations and involvement were meant to support an AI organization that would not enrich individuals but serve humanity. In his view, OpenAI’s later creation of a for-profit entity, acceptance of large investments, and rise into a highly valued company betrayed those original commitments.

OpenAI’s response is that Musk’s donations did not carry the permanent restrictions he now claims. It argues that the for-profit structure was created to obtain compute, talent, and capital needed to keep pursuing safe advanced AI. OpenAI also says Musk did not oppose for-profit structures as such, but wanted control.

So this is not a simple “nonprofit versus for-profit” dispute. The narrower questions are: what legal force did OpenAI’s original mission have? Was Musk’s $38 million contribution a normal donation or a charitable trust with enforceable conditions? Did OpenAI’s later restructuring remain under nonprofit control?

Musk’s story

Musk has argued in court that he helped create OpenAI to prevent AI from being controlled by a handful of commercial giants. He describes the structural changes at OpenAI as looting a charity and warns that allowing it would undermine the foundation of charitable giving.

This narrative is powerful because it highlights the contrast between OpenAI’s early public image and its later commercial success. OpenAI began with the image of a nonprofit research lab focused on safety, openness, and public benefit. Today it is a central commercial player in the global AI race, deeply tied to major partners such as Microsoft.

But Musk’s side also faces a question: did he once accept some form of for-profit arrangement? If he discussed creating a for-profit entity but wanted nonprofit control or greater personal control, then the case becomes less about whether a for-profit structure could exist and more about who controlled that structure.

OpenAI’s story

OpenAI’s public page and courtroom defense emphasize a different line: OpenAI has always been governed by a nonprofit, and the for-profit entity was created to raise the resources needed for its AGI mission. OpenAI frames Musk’s lawsuit as a reaction to failing to obtain control, followed by his creation of competing company xAI.

OpenAI also says Musk donated $38 million to the nonprofit, that the money was used for the organization’s mission, and that Musk is now trying to reinterpret that donation as an investment. According to OpenAI, Musk sought absolute control and even proposed folding OpenAI into Tesla before leaving after his terms were rejected.

The point of this narrative is to move the case from “OpenAI betrayed its public mission” to “Musk did not get the control he wanted.” If the jury and judge accept that framing, Musk’s moral accusation becomes weaker and the case looks more like a delayed founder control fight.

Why the nonprofit structure matters

The complexity of OpenAI is not simply that it earns commercial revenue. It is the governance structure. OpenAI is neither a traditional commercial company nor a research institute detached from markets. It tries to let a nonprofit control a for-profit subsidiary, using capital markets to obtain compute and talent while preserving the mission of benefiting humanity.

That structure has a practical rationale. Training frontier models requires data centers, chips, researchers, safety evaluations, and global product infrastructure. Donations alone are unlikely to sustain that scale.

But the more complex the structure becomes, the higher the trust cost. People naturally ask whether nonprofit control is actually effective, whether commercial partnerships change research direction, and who decides when safety promises conflict with product growth. That is why the Musk v. OpenAI case draws such broad attention.

The trial is not an AI safety referendum

The courtroom will repeatedly invoke AI safety, AGI risk, open-source promises, and public benefit. But it remains a legal case. The court is dealing with donation terms, charitable trust claims, organizational governance, control, and unjust enrichment, not writing AI safety policy for the entire industry.

In other words, even if Musk wins, the court will not necessarily produce a full AI safety governance framework. Even if OpenAI wins, questions about commercialization and mission drift will not disappear.

The important signal is how the court treats early public commitments by AI organizations. Where is the boundary between founder donation and later commercialization? How should a nonprofit-controlled AI company be supervised? Those questions matter beyond this case.

What it means for the AI industry

The lawsuit is a warning to the broader AI industry: once a grand public-benefit narrative meets enormous capital requirements, governance has to be clear enough to carry the weight. Otherwise, early mission statements, donor expectations, employee incentives, investor returns, and social risk all end up in the same legal and public-relations battlefield.

For other AI companies, that means:

Founding documents, mission statements, and donation agreements must be clearer.
The boundary between nonprofit and for-profit entities cannot be vague.
Safety commitments need auditable governance, not just marketing language.
Conflicts among founders, investors, and public benefit should be addressed before financing.

OpenAI’s size amplifies these issues, but they are not unique to OpenAI. As AI companies absorb more capital and enter medicine, education, defense, productivity, and consumer products, these governance conflicts will keep returning.

Summary

The core of Musk v. OpenAI is not only who betrayed whom. It is whether a frontier AI organization can prove that it remains bound by its mission as it moves from research lab to super-platform.

Musk’s side is trying to show that OpenAI departed from its original charitable mission. OpenAI’s side is trying to show that commercialization was necessary to pursue that mission, and that Musk’s lawsuit is a response to losing control. The outcome will depend on evidence, donation documents, organizational charters, and communications from the relevant years.

Whatever the result, the trial has already made one thing clear: AI companies cannot maintain trust with slogans about benefiting humanity alone. The closer they get to AGI and the more commercial value they control, the more transparent, verifiable, and court-tested their governance must become.

References:

How to Detect Claude 4-Generated Text: AI Text Detection Tools and Methods

Fri, 08 May 2026 22:55:16 +0800

If you want to judge whether a text was generated by Claude 4, the most important premise is this: no tool can give a 100% certain answer. AI text detection is probabilistic. It can suggest that a passage looks more like AI writing, but it cannot prove that the author definitely used Claude 4.

This matters even more in 2026. Claude 4, GPT-5, Gemini 2.5, DeepSeek, and other models write more like humans than earlier systems. Many texts are also no longer purely AI or purely human: they may be drafted by AI, edited by humans, polished by grammar tools, translated, rewritten, and stitched together. Detection tools can provide clues, but reliable judgment should also consider the writing process, version history, cited sources, and human review.

The short answer: never rely on one score

For a quick self-check, use two or three detectors together, such as GPTZero, Copyleaks, Originality.ai, Sapling, and Winston AI. In academic settings, Turnitin is common. Their models, training data, and thresholds differ, so the same text may receive different results.

A more reliable process is:

Run the same text through at least two tools.
Review sentence-level highlights, not just the total score.
Check for citation errors, factual hallucinations, and overly smooth transitions.
Look at writing-process evidence such as drafts, revision history, and commit history.
Treat low AI scores cautiously and never use detection output as the only evidence.

In schools, hiring, publishing, and compliance scenarios, AI detection should be a risk signal, not the final verdict.

Common tools

GPTZero

GPTZero is widely used in education and publishing. It became known early for statistical ideas such as perplexity and burstiness, and has since evolved into a multi-stage detection system that updates for newer model families.

It works well as an initial screen for long English essays, drafts, and articles. Its strengths are a friendly interface and clear sentence-level explanations. Its weaknesses are short texts, heavily human-edited texts, and multilingual mixed content.

Copyleaks AI Detector

Copyleaks is strong in multilingual detection, API access, browser extensions, and LMS integrations. Its official pages claim support for Claude, Gemini, GPT-5, DeepSeek, Llama, and other model families, and emphasize detection of mixed human and AI writing.

It is useful for content teams, educational institutions, and enterprises that need batch workflows. Still, vendor accuracy claims are usually measured on specific test sets. In practice, you must consider text length, language, rewriting, and the cost of false positives.

Turnitin AI Writing Report

Turnitin is mainly used in academic integrity workflows. It provides an AI writing indicator, highlighted passages, and support for detecting both generated text and text processed by AI paraphrasing tools.

But Turnitin’s own documentation warns that models can misclassify human text, AI text, or AI-paraphrased text, and should not be used as the only basis for adverse action against a student. It also handles lower AI percentages carefully to reduce misreading and false-positive risk.

Originality.ai, Sapling, and Winston AI

These tools often appear in content marketing, SEO, publishing, and editorial workflows. They usually provide batch detection, team features, APIs, or sentence-level analysis. They are useful for content quality control, but a single result still should not be treated as proof.

ZeroGPT, Monica, Phrasly, and free tools

Free tools are fine for a quick self-check, but they are not recommended for high-stakes decisions. Their thresholds, training data, false-positive rates, and update schedules may not be transparent. Claims of “99%+ accuracy” should be treated cautiously.

What detection algorithms look at

Traditional AI text detection often mentions two metrics:

Perplexity: roughly measures how predictable the text is to a language model. Extremely smooth text with highly predictable next words may look more AI-like.
Burstiness: measures variation in sentence length, structure, and rhythm. Human writing often has more uneven variation, while model output is often smoother.

Modern detectors usually go beyond these two metrics. They combine many signals:

Word frequency and phrase patterns.
Syntax structure and part-of-speech distribution.
Punctuation, connectors, and paragraph organization.
Repeated sentence templates.
Semantic consistency and suspicious factual references.
Model-specific linguistic fingerprints.
Boundaries between human and AI-written passages.

In other words, when a tool detects Claude 4-like writing, it is usually not identifying a Claude 4 watermark. It is judging whether the passage matches statistical patterns associated with LLM-generated text.

Why Claude 4 is harder to detect

Claude models tend to produce natural prose with stable long-paragraph transitions. With careful prompting, Claude 4 can imitate personal style, reduce template-like wording, and keep a small amount of conversational irregularity. After human editing or translation, detection becomes even harder.

That creates two issues:

Pure Claude 4 output may be detected as AI, but confidence depends on topic, language, and length.
Text drafted by Claude 4 and then edited by humans may evade detection, or may still be flagged with a high AI score.

So the most valuable part of a report is not “87% AI”. It is which sentences are highlighted, why they look suspicious, and whether those signals align with writing-process evidence.

Recommended workflow

If you need to judge whether an article may have been generated by Claude 4, use this process:

Preserve the original text and do not rewrite it first.
Test it with tools such as GPTZero, Copyleaks, or Turnitin.
Record the total score, highlighted sentences, and tool version.
Manually review highlighted sentences for formulaic transitions, generic wording, and unsupported claims.
Verify citations, data, links, and proper nouns.
Ask for writing-process material such as outlines, drafts, and revision history.
Treat the detection result only as supporting evidence.

If you want to reduce the risk of your own writing being misclassified, the right approach is not to “bypass detectors”. Keep writing records, add real experience, verify citations, remove vague filler, and make the article reflect real human judgment and sources.

Common false-positive cases

These texts are especially easy to misclassify:

Formal English written by non-native speakers.
Highly templated academic abstracts, business emails, and policy notes.
Text polished by tools such as Grammarly, DeepL Write, or Notion AI.
Short texts, titles, summaries, and product descriptions.
Translation-like Chinese or English.
Multi-author drafts that have been normalized into one style.

The higher the stakes around discipline, hiring, grades, copyright, or compliance, the less acceptable it is to decide based on one AI score.

Summary

The most reliable way to detect Claude 4-generated text is not to trust one “latest algorithm” tool. Treat detectors as probability signals: cross-check multiple tools, inspect sentence-level highlights, and combine the result with citation checks and writing-process evidence.

GPTZero, Copyleaks, Turnitin, Originality.ai, Sapling, and Winston AI can all be part of the toolbox. They improve the chance of finding AI-generated text, but they do not replace human judgment. A defensible conclusion should combine detection results, factual quality, process records, and the rules of the specific context.

References:

Does F2FS Freeze an HC620 SMR Drive? Linux SMR Disk Troubleshooting Guide

Fri, 08 May 2026 22:34:39 +0800

When an HC620 helium-filled SMR drive is used with F2FS, symptoms such as system freezes, unresponsive applications, and sustained high iowait are usually not caused by one bad option. They are the result of device behavior colliding with filesystem policy.

Western Digital Ultrastar DC HC620 is a Host-managed SMR drive. It is better suited to sequential writes, zoned-aware workloads, and software stacks that understand the device constraints. F2FS is a log-structured filesystem designed for flash storage. Although it can turn many random writes into sequential writes, heavy garbage collection, metadata updates, or low free space can still push a mechanical SMR drive into long internal maintenance cycles.

Confirm the problem first

Start with these checks:

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

If disk %util stays close to 100%, await is high, and many processes are stuck in D state, the bottleneck is probably block I/O.

Then check whether the drive is exposed as a zoned device:

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

If it is Host-managed SMR, ordinary filesystems and random-write workloads may perform poorly. Unlike consumer drive-managed SMR disks, this class depends more on host software understanding the write rules.

Why F2FS can amplify the stall

SMR cannot overwrite arbitrary locations as freely as CMR disks. Shingled tracks overlap to increase capacity. When writes become random, overwrites are frequent, or cache is exhausted, the drive must perform additional data movement and cleanup.

F2FS was built for NAND flash. It uses log-structured writes and reclaims space through segment cleaning and garbage collection. On SSDs this is natural because there is no mechanical seek. On mechanical disks, especially SMR disks, GC-related reads and writes can turn into severe tail latency.

When F2FS background GC, foreground writes, checkpoints, metadata updates, and the drive’s own SMR cleanup overlap, the I/O queue can stay saturated for a long time. From user space, copying files, deleting directories, downloading, extracting archives, or database writes may make the whole system feel frozen.

Start with conservative mount options

If you cannot migrate immediately, first adjust /etc/fstab:

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

What these options do:

nodiscard: disables real-time discard. Mechanical disks usually do not need frequent TRIM/discard behavior like SSDs.
active_logs=2: F2FS supports 2, 4, or 6 active logs, and the default is commonly 6. Reducing it to 2 can reduce seek pressure from concurrent logs.
gc_merge: lets the background GC thread handle some foreground GC requests, reducing stalls when a process triggers slow GC.
flush_merge: merges cache flush requests, which can help when the device handles flush slowly.
lazytime: reduces metadata writes caused by some access time updates.

Do not treat checkpoint=disable as a normal tuning switch. It may reduce checkpoint pressure, but it increases risk after crashes or power loss. Kernel documentation also notes that the filesystem still needs GC while checkpoint is disabled to ensure usable space. Unless you understand the tradeoff clearly, do not use it as a long-term performance fix.

Tune the I/O scheduler

Mechanical disks and SMR disks often benefit from request merging and latency control. Check the current scheduler:

`1`	`cat /sys/block/sdX/queue/scheduler`

Try switching to mq-deadline:

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

For desktop interaction, bfq is also worth testing. Do not look only at sequential throughput. Watch whether freezes are reduced, await drops, and the system feels more responsive.

Limit F2FS background GC

The F2FS sysfs path depends on the actual device name. Check it first:

`1`	`ls /sys/fs/f2fs/`

Then adjust the GC interval for the matching device:

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

Here sdX is only an example. The actual name may be sda1, dm-0, or something else. Increasing GC sleep time reduces how often background GC competes for I/O, but space reclaim becomes slower. If the disk is nearly full, foreground GC may still be triggered, so keep enough free space.

Better long-term options

If the drive stores important data, the safest long-term answer is to back up and change the filesystem, or use a more suitable drive.

For large mechanical disks, consider:

XFS: good for large files, backup drives, media libraries, archives, and sequential-write workloads.
EXT4: stable behavior, broad compatibility, and abundant troubleshooting material.

If the drive is Host-managed SMR, also confirm that your kernel, controller, filesystem, and application stack truly support zoned block devices. Otherwise, using it like a normal random-write disk can lead to unpredictable long stalls.

Practical advice

This class of disk is better suited to cold data, archives, backups, media files, and sequential writes. It is a poor fit for download caches, container images, VM disks, databases, frequent archive extraction, and small-file random writes.

If you must keep using F2FS, at least do this:

Disable real-time discard.
Use active_logs=2 to reduce concurrent logs.
Enable gc_merge and flush_merge.
Keep plenty of free space.
Avoid placing downloads, databases, and VM images on this disk.
Watch iostat -x 1, not just average speed.

In short, HC620 + F2FS freezes are the result of SMR write constraints, F2FS GC, and mechanical disk tail latency stacking together. Short-term mitigation is mount-option tuning, scheduler tuning, and background GC limits. The long-term fix is to migrate to XFS/EXT4, or use the SMR drive only for workloads it actually suits.

References:

miHoYo LPM 1.0 Explained: How an AI Video Model Could Reshape Game NPCs

Fri, 08 May 2026 22:27:10 +0800

LPM 1.0 is easy to mistake for another AI video generation model. Judging only by demos, it may not look as visually explosive as some text-to-video systems. But viewed through the paper’s goal, it is not mainly trying to generate a good-looking clip. It is trying to make a digital character feel present during interaction.

That is the biggest difference between LPM 1.0 and ordinary video models. A typical video model focuses on image quality, camera continuity, and prompt following. LPM 1.0 focuses on character performance: lip sync, rhythm, and expression while speaking; nods, gaze, pauses, and micro-expressions while listening; and stable identity across long interactions.

From generating video to generating performance

LPM stands for Large Performance Model. The name matters because it shifts the task boundary from “video” to “performance”.

In real conversation, whether someone feels natural is not only about what they say. Listening is part of communication: the timing of nods, the direction of gaze, and subtle emotional changes all affect whether we believe a character is alive.

Many digital human systems still attach text, speech, and lip motion to a character. The character can talk, but may not truly listen. It can output lines, but may not react continuously to the previous second of input. LPM 1.0 aims to turn passive playback into real-time interaction.

The three hard problems

The LPM 1.0 paper describes a trilemma in AI character performance: expressiveness, real-time inference, and long-horizon identity stability. A system may look detailed but be slow, respond quickly but feel rigid, or stay stable briefly but drift over time. Achieving all three is much harder.

To address this, LPM 1.0 uses richer character conditioning. Instead of giving the model only one reference image, it introduces multi-granularity identity references, including global appearance, multi-view body images, and facial expression examples. The goal is to reduce hallucinated details such as profile shape, teeth, expression texture, and body proportions.

The paper also separates speaking and listening behavior. Speaking audio mainly drives lip sync, speech rhythm, head motion, and body rhythm. Listening audio triggers gaze, nodding, posture changes, and micro-expressions. If both signals are mixed into one control stream, the model can easily learn the wrong behavior. LPM 1.0 models speaking and listening separately, then connects them in one online interaction system.

Base LPM and Online LPM

According to the public paper, LPM 1.0 is built on a 17B-parameter Diffusion Transformer. Base LPM learns high-quality, controllable, identity-consistent character performance video. Online LPM is a distilled streaming generator designed for low-latency, long-running interaction.

This split is important. Offline models can focus on quality, but interactive systems cannot make users wait. When a user starts speaking, the character should begin listening immediately. When the character starts speaking, lip sync, expression, and body motion must follow at once. Online LPM is valuable because it compresses complex video generation into something closer to real-time interaction.

So LPM 1.0 is not just a short-video asset tool for creators. It is closer to a visual engine for conversational agents, virtual streamers, and game NPCs: the language model understands and generates content, the speech model provides the voice, and LPM makes the on-screen character perform credibly.

What it means for games

In games, LPM 1.0 points less toward prettier cutscenes and more toward the next generation of interactive characters.

Traditional NPCs rely on prewritten scripts, fixed animations, and limited branches. Players can talk to them, but their responses are usually predesigned. In the AI era, the target goes further: different players may experience different story paths in the same world, and the same character may respond with actions, emotions, and dialogue that fit each player’s context.

That is what a truly personalized game experience needs underneath. Language models can generate lines, and behavior systems can choose goals, but if the character on screen still looks stiff, players will struggle to believe it understands them. LPM 1.0 tries to fill that visual and performance layer.

Not a finished magic product

LPM 1.0 should still be understood as a technical direction, not an immediately scalable commercial product. The paper and demos show a possibility: real-time, full-duplex, identity-stable character video generation is getting closer to usable. But before it can enter games broadly, there are still problems around cost, latency, edge deployment, content safety, character rights, multiplayer scenes, and engine integration.

A more realistic path may start with virtual streamers, AI companions, story interaction, character support agents, and educational coaching. As model cost falls and latency improves, the technology can move into more complex game systems.

Summary

The value of LPM 1.0 is not whether it can generate the most spectacular video clip. It is that it pushes AI video from “image generation” toward “character presence”.

If future games become more personalized, more dynamic, and more dependent on AI characters, language, speech, motion, expression, and identity consistency must be designed together. LPM 1.0 offers one possible path: digital characters that do not just talk, but listen, react, and remain recognizably themselves over long interactions.

References:

Canonical Ubuntu AI Roadmap: Local Inference First, No Forced Integration

Fri, 08 May 2026 22:23:46 +0800

Canonical’s recent Ubuntu AI roadmap is notable less for “putting AI everywhere” and more for trying a restrained path: AI features are layered, disabled by default, enabled only by explicit user choice, and designed to prefer local inference.

That stands apart from some of the controversy around system-level AI in Windows and macOS. Ubuntu is not trying to build an unavoidable global AI layer, nor is it promising one universal AI kill switch. Instead, the plan is to expose AI as separate tools, letting users decide whether to install them, enable them, choose a model, and allow data to leave the machine.

First, the timeline: not Ubuntu 26.04 LTS

The roadmap points mainly to Ubuntu 26.10 “Questing Quokka”, expected on October 9, 2026. Canonical plans to introduce some AI tooling as experimental previews, not as default features in Ubuntu 26.04 LTS.

That matters. LTS releases are meant for stability, enterprise deployment, and long-term maintenance. It would be unusual to place exploratory desktop AI features into an LTS default experience. A more reasonable path is to test them first in a regular release such as 26.10, gather feedback from developers and early users, and then decide what belongs in later long-term releases.

Local inference first, cloud only by choice

One core principle is local inference first. By default, inference should happen on the user’s machine. Requests should leave the machine only when the user explicitly configures a cloud provider, a self-hosted server, or an enterprise model service.

The reason is practical: system-level AI can easily touch command output, logs, file paths, errors, and system configuration. Sending that information to the cloud automatically, even to explain an error, creates obvious privacy and compliance risks.

So Ubuntu’s AI direction is not a cloud AI gateway. It is closer to a pluggable inference layer. Users may choose a local model, an internal company service, or a Canonical-managed service when needed. The important part is avoiding lock-in to one model vendor.

AI CLI: start with terminal assistance

One of the first practical features may be the AI Command Line Helper, often referred to as ai-cli.

It is not meant to replace the shell or automatically run risky commands. Its job is to help users understand commands, logs, systemd units, error output, and system state. For example, it could explain why a service failed to start, or clarify what a command-line flag means.

This fits Ubuntu’s audience well. Many Ubuntu desktop and server users already live in the terminal. Instead of starting with a flashy chat window, it makes sense to put AI into error analysis, command explanation, and operations assistance.

The safety boundary must be clear. Logs may contain tokens, internal hosts, usernames, file paths, key fragments, or business information. Even with local inference by default, tools should encourage redaction. If a user chooses a cloud backend, the UI must make clear what will be sent.

Settings Agent: natural-language system settings

Another direction is a Settings Agent that lets users query or change system settings in natural language.

This sounds simple but is easy to get wrong. A mature Settings Agent should not scrape the screen, guess buttons, and simulate clicks. It should use controlled internal APIs: what it can read, what it can change, when confirmation is required, and how failures are rolled back.

That makes it more likely to be a post-26.10 direction than a complete immediate feature. If done well, it could lower the barrier for normal users to configure desktop Linux. If done too aggressively, it becomes a new security risk.

Why not a universal AI kill switch?

Many users worry that once vendors add AI to an operating system, AI appears everywhere and becomes hard to disable. So the natural question is whether Ubuntu should provide a global AI kill switch.

Canonical’s position is that if AI features are opt-in, layered, and independently installable and configurable, a global kill switch is not the first priority. In other words, the design should avoid the pattern of “enabled by default, deeply embedded, then users have to disable it.”

Whether that is enough depends on implementation. If AI tools are not enabled by default, do not connect to remote services by default, do not collect data automatically, and each feature has clear controls, users should not need to hunt through hidden settings to turn AI off.

What it means for developers and enterprises

For developers, AI CLI tools can reduce the time spent reading documentation, parsing logs, and diagnosing system problems. They do not replace engineering judgment; they automate a lot of “help me understand this output” work.

For enterprises, local inference and pluggable backends matter more. Many companies cannot send source code, logs, customer data, or infrastructure details to public model services. If Ubuntu can connect system-level AI with local models, private inference services, and enterprise permissions, it may offer useful assistance in compliant environments.

This is also an opening for Linux desktops and workstations. Windows and macOS can more easily fold AI into vendor ecosystems. Ubuntu’s advantage is openness, auditability, replaceability, and self-hosting. If Canonical preserves those principles, AI could strengthen the professional Linux experience.

Do not overread it

It is too early to say that Ubuntu will preinstall a specific small model, that Ubuntu 26.04 will include an AI audit mode, or that there will be a fixed ubuntu-ai command. The clearer public information is about direction, not final product shape.

The safer reading is this: Canonical is preparing a system-level AI tooling framework for Ubuntu, starting with command-line help, settings assistance, local inference, and backend choice. The default posture is user choice, not vendor choice.

Summary

The important part of Ubuntu’s AI roadmap is not that Ubuntu is “joining the AI wave”. It is the attempt to define a more restrained model for AI in open source operating systems: intelligence can become infrastructure, but privacy, control, and user choice must come first.

If the experimental features in 26.10 live up to those principles, Ubuntu may take a different path from consumer operating systems: AI not as an unavoidable system ad slot, but as a selectable, replaceable, and auditable productivity layer.

References:

Codex vs Claude Code: How to Choose Between Two Subagent Designs

Fri, 08 May 2026 14:14:01 +0800

AI coding tools are paying more attention to subagents. This is not just feature chasing. A single agent eventually hits limits when it has to handle real engineering work.

If one agent reads code, checks logs, edits implementation, runs tests, analyzes failures, and summarizes results at the same time, the main context quickly becomes noisy. Search results, command output, test logs, and intermediate reasoning get mixed together. Later decisions become less reliable. Work also becomes hard to parallelize: exploration, implementation, verification, and review all sit on one main thread.

The purpose of subagents is to reduce that pressure. The main session stops doing everything from start to finish and becomes more like a coordinator: define goals, assign work, receive results, and merge them into the final answer. A subagent handles a local piece of work, such as exploration, implementation, verification, or review, and returns a compressed conclusion.

So a subagent is not “another copy of me.” It is a way to split tangled engineering work into clearer roles.

Shared Foundations

A mature subagent system usually needs four foundations:

Context isolation.
Role specialization.
Project and user-level configuration.
Tool and permission boundaries.

Context isolation comes first. Real repositories produce a lot of intermediate material: dozens of search hits, hundreds of test log lines, noisy command output. If all of that is poured into the main session, the main thread gets confused. A subagent can digest that local process and bring back only the signals that matter.

Role specialization is just as important. Multi-agent does not mean opening several identical models. Exploration roles should search, read, and summarize. Implementation roles should focus on local code changes. Verification roles should run checks, identify risks, and report clearly.

Tool and permission boundaries determine whether the system can be used safely. A subagent should not automatically inherit every capability of the main session. A read-only explorer does not need write access. A verifier may not need to change implementation. Background tasks and isolated worktrees need visible boundaries.

Codex and Claude Code share these concerns, but they take different routes.

Codex: Explicit Delegation

Codex’s subagent design feels restrained.

It gives you a controlled, lightweight delegation mechanism around the current main session. When to delegate, who receives the task, and when results are collected are all explicit decisions. The control flow stays in the current task.

Its traits are clear:

The main session explicitly delegates subwork.
The role set stays small.
The main session knows which agent is doing what.
Results return to the main line for final judgment.
Collaboration boundaries are transparent.

This works well for teams that care about manual orchestration, predictability, and execution determinism. You can ask an explorer to inspect a call chain, ask a worker to make a bounded change, then let the main session merge the result and decide whether to test further.

The tradeoff is that orchestration pressure still sits with the main session. The main thread must decide when to split work, how to split it, who should take it, and how to merge the result. For lightweight collaboration this is pleasant; for long-running engineering workflows it can become tiring.

Claude Code: Agents as Workstations

Claude Code takes a more platform-like route.

It treats agents as describable, selectable, configurable, memorable, isolated, and background-capable objects. A subagent is not just a helper in a conversation. It is closer to a workstation in an engineering system.

The system can expose agent lists, use cases, descriptions, and tool boundaries to the model, allowing the model to decide which role should handle a turn. That makes delegation more automatic.

Several capabilities define this direction.

First, a role system. Explorer, planner, general-purpose, and verifier roles can carry usage descriptions, tool restrictions, default models, and runtime conditions. A read-only explorer can be prevented from editing files. A planner can focus on architecture. A verifier can focus on checks.

Second, inheritance and overrides. A subagent is not completely free. It inherits the larger boundary of the main session by default, but can adjust local behavior within allowed rules. The main session defines the big boundary; the agent performs local assembly inside it.

Third, memory. Memory is not just “remember a few things.” It can have scope. User memory is like long-term preference. Project memory is repository background. Local memory is environment-specific state. This lets some agents avoid relearning the project from scratch.

Fourth, background work and worktree isolation. Some verification tasks can keep running in the background, while the main thread continues. When stronger isolation is needed, an agent can work in a separate worktree, keeping the project connected but the operation space separated.

Fifth, plugin ecosystem. If agents are first-class objects, you have to think about distribution, installation, priority, override rules, and safety. Plugin agents can enter the system, but high-risk fields such as permission mode, hooks, and MCP servers should remain guarded.

This makes Claude Code feel more like an agent runtime than a one-session collaboration tool.

The Difference

Codex is closer to a controlled delegation tool:

Explicit delegation.
Lightweight role set.
Clean control flow.
Subtasks centered on the current session.
Good for deterministic, human-orchestrated work.

Claude Code is closer to an engineering workstation system:

Agents are formally modeled.
Roles are more systematic.
Memory, background execution, isolation, and plugins are part of the runtime.
The model can help choose roles.
Good for long-term projects and platform-like workflows.

The real question is not which one has more features. It is whether you want a subagent to be “a helper I explicitly call” or “a long-lived workstation in the system.”

How to Choose

Choose the Codex style if you value explicit control, lightweight delegation, and safe parallelism inside the current session. It is good for code review, small changes, clearly scoped implementation tasks, and workflows where a human wants to keep the rhythm.

Choose the Claude Code style if you want systematic roles, long-term memory, background execution, worktree isolation, plugin extension, and a more complete agent runtime.

Ask two questions:

Are you comfortable with the model choosing who should do the work?
Do you need a fuller agent runtime?

If the first question makes you uncomfortable, explicit delegation is likely better. If the second answer is yes, a platform-like workstation system may fit better.

Practical Advice

Do not treat subagents as “more models means stronger.” Better practice is:

Give every role a clear task boundary.
Limit the tools each role can use.
Ask subagents to return conclusions, not raw logs.
Keep final decisions in the main session.
Make background tasks and worktree isolation visible.
Set clear safety boundaries for plugin agents.

The value of subagents is not quantity. It is clean division of labor, cleaner context, and more stable main-thread decisions.

Summary

Codex and Claude Code solve the same problem: one agent cannot comfortably carry all real engineering work. Both recognize the importance of context isolation, role specialization, permissions, and local summarization.

Codex is more restrained, emphasizing explicit delegation and main-session control. Claude Code is more systematic, treating agents as configurable, memorable, isolated, background-capable workstations that can also enter a plugin ecosystem.

The choice is not which brand wins. It is whether your workflow needs a controlled collaboration tool or a full agent runtime.

9Router: Connect Claude Code, Codex, and Cursor to One AI Router

Fri, 08 May 2026 13:41:15 +0800

9Router is a local router for AI coding tools. It lets Claude Code, Codex, Cursor, Cline, Copilot, OpenCode, OpenClaw, and similar tools connect to one OpenAI-compatible endpoint, then routes requests to different models and providers.

It is not trying to be another chat client. It sits between your AI coding tools and model providers, solving a few practical problems: incompatible API formats, manual provider switching, fast token burn from tool output, interrupted work when quotas run out, and messy multi-account configuration.

According to the project README, 9Router supports 40+ providers and 100+ models. It includes RTK Token Saver, automatic fallback, quota tracking, multi-account rotation, format translation, and request logging. The project is written in JavaScript and uses Node.js, Next.js, React, Tailwind CSS, and LowDB. It is licensed under MIT.

What It Is Good For

9Router is most useful when you use multiple AI coding tools and multiple model sources at the same time.

Examples:

Claude Code uses a subscription account.
Codex or Cursor needs a custom OpenAI endpoint.
Cline, Continue, or RooCode needs an OpenAI-compatible API.
Free providers are used for experiments.
GLM, MiniMax, or Kimi is used as a cheaper backup.
High-quality models are reserved for difficult tasks.

Without 9Router, these settings are scattered across many tools. Each tool needs its own endpoint, API key, model name, and fallback plan. 9Router centralizes that into one local routing layer.

Default local API:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

Quick Install

For local use, npm is the simplest path:

1
2

npm install -g 9router
9router

The dashboard opens locally, and the README uses 20128 as the default port.

Run from source:

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

Production mode:

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

The npm package requires Node.js >=18.0.0. For VPS or Docker deployment, configure JWT_SECRET, INITIAL_PASSWORD, DATA_DIR, and API_KEY_SECRET instead of exposing defaults.

Connect Coding Tools

9Router exposes an OpenAI-compatible API, so most tools that support custom OpenAI endpoints can connect to it.

Typical configuration:

1
2
3

Base URL: http://localhost:20128/v1
API Key: copied from the 9Router dashboard
Model: a model name or combo name configured in 9Router

For Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

For Cline, Continue, or RooCode, choose OpenAI Compatible and set:

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

Model names depend on connected providers. The README shows prefixes such as cc/, cx/, gh/, glm/, minimax/, kr/, and vertex/.

RTK Token Saver

AI coding tools often burn tokens fastest on tool outputs:

git diff
git status
grep
find
ls
tree
logs
long file lists

9Router includes RTK Token Saver, which compresses these outputs before they are sent to the model. The project says this can save 20%-40% input tokens in many requests.

The value is that you do not need to change tools or models. The routing layer removes waste before the request reaches the provider. Still, for critical logs or complete file content, test the behavior first and make sure answer quality does not drop.

Automatic Fallback

9Router can arrange models in priority order:

1
2
3

1. Subscription model
2. Cheap API
3. Free provider

When the first tier is rate-limited, out of quota, or failing, it can switch to the next one. This reduces manual switching and keeps coding sessions from stopping suddenly.

Example:

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

Fallback changes output consistency. Different models have different style and reasoning quality. For large refactors, protocols, migrations, or other consistency-sensitive work, prefer a fixed model and switch manually only when needed.

Be Careful with Free Providers

The README highlights Kiro, OpenCode Free, Vertex, and also notes that some old free tiers have changed or are no longer recommended.

Always confirm provider policy at the time of use:

Is it really free?
Is it region-limited?
Is third-party tool access allowed?
Can it trigger bans or rate limits?
Does the free quota expire?

9Router manages routing, not upstream terms. Be especially careful when using personal subscriptions, OAuth tokens, or free quotas with automated tools.

Local Deployment Advice

For personal use, bind to localhost. Local tools can reach it, but the internet cannot.

For VPS or LAN deployment:

Change the default login password.
Set a strong JWT_SECRET.
Set API_KEY_SECRET.
Put authentication in front of the dashboard.
Do not expose the dashboard directly to the public internet.
Require Bearer API keys for /v1/*.
Back up DATA_DIR.

Docker example:

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

Start locally first, verify providers, combos, logs, and model names, then decide whether server deployment is worth it.

Who Should Use It

9Router is a good fit if you use multiple AI coding tools, multiple providers, subscription plus free or cheap tiers, and want a central fallback policy. It is less useful if you only use one model and one tool.

Its real value is turning scattered model access into a configurable local routing layer.

Summary

9Router is a local gateway for AI coding tools. It lets Claude Code, Codex, Cursor, Cline, and similar tools talk to http://localhost:20128/v1, while it handles model selection, format translation, token compression, quota tracking, and fallback.

It is best for heavy AI coding users who already switch between providers. Start with one tool and one provider, then add accounts and combos gradually.

References

DeepSeek-TUI: Run a DeepSeek Coding Agent in Your Terminal

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI is an AI coding agent that runs in the terminal. It is built around DeepSeek V4 models and starts from the deepseek command. Inside a keyboard-driven TUI, it can read and edit files, run shell commands, search the web, manage git, connect to MCP servers, and coordinate sub-agents.

It is closer to a terminal workbench than a simple chat CLI. The goal is not only to send a question to a model, but to combine code reading, file edits, commands, diagnostics, session recovery, and workspace rollback in one local workflow.

The repository is mainly written in Rust and uses the MIT license. Its GitHub description is: “Coding agent for DeepSeek models that runs in your terminal.”

Who It Is For

DeepSeek-TUI fits developers who prefer terminal workflows and want to use DeepSeek models for real local development tasks.

It is useful when you want to:

Use DeepSeek models for code changes and project analysis.
Work without opening a full IDE.
Let an AI tool read and modify a local workspace.
Switch between Plan, Agent, and YOLO modes.
Save sessions and resume long tasks.
Roll back workspace changes.
Connect MCP, LSP diagnostics, HTTP/SSE runtime APIs, and skills.

If you only need simple Q&A, a web client or lightweight CLI is enough. DeepSeek-TUI is better when the model should become part of your local development loop.

Installation

DeepSeek-TUI ships Rust binaries. The common entry command is deepseek, and the companion TUI binary is deepseek-tui.

Using npm:

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

The npm package is an installer and wrapper that downloads prebuilt Rust binaries. It requires Node.js >=18.

Using Cargo:

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Using Homebrew:

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

You can also download prebuilt binaries from GitHub Releases. The README lists Linux x64/ARM64, macOS x64/ARM64, and Windows x64 builds.

Docker:

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

In mainland China, use npm or Cargo mirrors, or download release binaries manually.

Configure the API Key

On first launch, DeepSeek-TUI asks for your DeepSeek API key and saves it to:

`1`	`~/.deepseek/config.toml`

You can also configure it explicitly:

1
2

deepseek auth set --provider deepseek
deepseek auth status

Or use an environment variable:

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

Check the setup:

`1`	`deepseek doctor`

If the wrong key source is used, run deepseek auth status. Saved config keys take precedence over the keyring and environment variables.

Clear a saved key:

`1`	`deepseek auth clear --provider deepseek`

Auto Mode

Auto mode:

`1`	`deepseek --model auto`

Inside the TUI:

`1`	`/model auto`

Auto mode chooses both:

Model: deepseek-v4-flash or deepseek-v4-pro
Thinking: off, high, or max

Before the real request, DeepSeek-TUI makes a small routing call to analyze the latest request and recent context. Simple tasks can stay on Flash with thinking off; coding, debugging, architecture, release, security review, or ambiguous multi-step work can move to Pro or higher thinking.

auto is local to DeepSeek-TUI. The upstream API receives the concrete model and thinking setting chosen for that turn. For benchmarks, strict cost control, or fixed behavior, use an explicit model.

Modes

Mode	Use
Plan	Read-only exploration and planning
Agent	Default interactive mode with approval gates
YOLO	Auto-approve tools in a trusted workspace

Plan is for investigation. Agent is safer for everyday coding. YOLO is fast but risky and should only be used in trusted workspaces and low-risk branches.

Tooling

The README lists a broad tool set:

File reads/writes and apply patch.
Shell execution.
Git operations.
Web search and browse.
Sub-agents.
MCP servers.
LSP diagnostics.
Session save/resume.
Workspace rollback.
Durable task queue.
HTTP/SSE runtime API.
Skills system.

LSP diagnostics are especially useful because errors from rust-analyzer, pyright, typescript-language-server, gopls, clangd, and similar tools can be fed back after edits.

Workspace rollback uses side-git snapshots and provides /restore and revert_turn. It does not touch the repository’s own .git, but normal git commits are still the safest baseline.

Common Commands

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed and ACP

DeepSeek-TUI can run as an Agent Client Protocol server:

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

The README notes that the first ACP slice supports new sessions and prompt responses, while tool-backed editing and checkpoint replay are not exposed through ACP yet.

Configuration and Providers

User config:

`1`	`~/.deepseek/config.toml`

Workspace overlay:

`1`	`<workspace>/.deepseek/config.toml`

Some sensitive fields, such as api_key, base_url, provider, and mcp_config_path, are denied in workspace overlays.

DeepSeek-TUI supports the default deepseek provider plus NVIDIA NIM, Fireworks, OpenAI-compatible endpoints, SGLang, vLLM, Ollama, and others.

OpenAI-compatible example:

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama example:

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

Cost and Context

DeepSeek-TUI is designed around DeepSeek V4. The README mentions deepseek-v4-pro and deepseek-v4-flash, 1M-token context windows, token usage, cost estimates, and prefix-cache telemetry.

For light tasks, deepseek-v4-flash or auto mode may be enough. For complex refactors, long-context debugging, and architecture work, use higher thinking or Pro.

Pricing and discounts change, so check DeepSeek’s official pricing page and the current TUI cost estimates before relying on numbers.

Suggested Workflow

Start safely:

Try it in a small test repository.
Run deepseek doctor.
Use Plan mode for read-only exploration.
Use Agent mode for small edits.
Review changes with git diff and tests.
Learn /restore and session recovery.
Use YOLO only in trusted temporary branches.

Do not store API keys in project files. For company code, confirm provider, logging, web search, and compliance rules first.

Summary

DeepSeek-TUI is a full terminal AI coding agent. It brings DeepSeek V4, TUI interaction, tool calls, LSP diagnostics, session recovery, rollback, MCP, and skills into one Rust-based workflow.

It is not the lightest DeepSeek client, but its strength is moving from chat to executable local development.

References

goose: An Open Source AI Agent with Desktop, CLI, and API

Fri, 08 May 2026 13:41:15 +0800

goose is an open source AI agent that runs on your own machine. It is not limited to code completion; it aims to cover code, research, writing, automation, data analysis, and other tasks. The README positions it as a desktop app, CLI, and API that can serve both normal users and custom workflows.

The project has moved from block/goose to the Agentic AI Foundation (AAIF) at the Linux Foundation. The current repository is:

`1`	`https://github.com/aaif-goose/goose`

goose is mainly written in Rust and TypeScript and uses the Apache-2.0 license. Its GitHub description says it is an open source, extensible AI agent that goes beyond code suggestions and can install, execute, edit, and test with any LLM.

What Problem It Solves

Many AI coding tools focus on suggestions or local code edits. goose takes a broader view: let an AI agent complete tasks directly on your machine.

It can be used for:

Code changes and tests.
Local automation.
Research and writing.
Data analysis.
Multi-step workflows.
Embedding through an API.
Tool extension through MCP.

If you only need IDE completion, a Copilot-style tool may be enough. goose is more useful when you want AI inside the local task execution chain.

Desktop, CLI, and API

goose has three entry points.

The desktop app supports macOS, Linux, and Windows. It is good for users who prefer a visual interface.

The CLI fits terminal workflows and local development automation.

The API lets other systems or internal tools embed goose as an agent runtime.

Personal users can start with the desktop app or CLI. Teams and workflow builders should also look at the API and custom distribution support.

Installation

The README recommends downloading the desktop app:

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI install:

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases provide builds for multiple platforms. The latest release checked here was v1.33.1, published on 2026-04-29, with macOS, Linux, Windows, deb, rpm, and Flatpak assets.

After installation, configure a provider from the official quickstart and test in a low-risk directory first. goose can execute local tasks, so avoid giving it broad permissions in a production repository from the start.

Providers

goose supports 15+ providers, including:

Anthropic
OpenAI
Google
Ollama
OpenRouter
Azure
Bedrock
other cloud or OpenAI-compatible providers

It can use API keys, and it can also use existing Claude, ChatGPT, or Gemini subscriptions through ACP.

ACP is important because many users already pay for subscriptions, but different tools cannot easily reuse them. goose uses ACP providers to bring those subscriptions into an agent workflow.

Provider policies change quickly. Check whether the access method is allowed, whether there are quotas, and whether it is suitable for company code or sensitive data.

MCP Extensions

goose supports Model Context Protocol extensions. The README mentions 70+ extensions.

MCP matters because an agent should not only chat and edit files. Through standard protocol servers, it can connect to documentation, databases, browsers, internal systems, search services, design tools, or project management tools.

For teams, MCP can become a safer integration layer: expose internal capabilities through explicit interfaces instead of letting the model touch every system directly.

Difference from a Coding Assistant

goose is not just a code completion tool. It is closer to a local agent runtime.

Common coding assistants focus on:

Code completion.
Code explanation.
Function generation.
Local editor edits.

goose emphasizes:

Local task execution.
Multi-step workflows.
Switchable providers.
Extensions.
Desktop and CLI.
Embeddable API.
Non-code tasks too.

This also means more complexity. You must think about model configuration, permissions, extensions, workspace scope, logs, and credentials.

Custom Distributions

The repository includes CUSTOM_DISTROS.md, which explains how to build a custom goose distribution with preconfigured providers, extensions, and branding.

This is useful for teams:

Preconfigure allowed model providers.
Connect internal MCP servers.
Set safety policies and logging.
Block disallowed external services.
Apply company branding and onboarding.

Members do not need to configure everything from scratch, and the risk of wrong provider or key setup is reduced.

Suggested Use

Start gradually:

Install the desktop app or CLI.
Configure one known-good provider.
Run simple tasks in a test directory.
Observe what it reads and executes.
Add MCP extensions.
Try larger repositories later.

Keep a few habits:

Commit important changes before agent work.
Do not store API keys in project files.
Use high-permission modes only in trusted workspaces.
Review company data and provider policy first.
Keep human review for automation results.

Who Should Use It

goose is a good fit if you want a desktop and CLI AI agent, multiple model providers, MCP integration, API embedding, or custom team distributions. It may be heavy if all you need is IDE code completion.

Summary

goose is an open source AI agent under AAIF/Linux Foundation. It provides desktop, CLI, and API entry points, supports 15+ providers, ACP subscription access, and 70+ MCP extensions.

Its value is not only writing code, but placing models, tools, extensions, and local execution into one agent framework. Start small, define permission and data boundaries, then expand usage.

References

Which Local AI Models Can a Laptop RTX 4060 8GB Run?

Fri, 08 May 2026 13:41:15 +0800

A laptop RTX 4060 8GB can run local AI, but the boundary is clear: the key question is not whether a model starts, but whether it stays inside VRAM. Mobile RTX 4060 cards are also limited by laptop power, cooling, memory bandwidth, and vendor tuning, so sustained performance varies between machines.

In 2026, 8GB VRAM is still the entry baseline for local AI. With the right quantized models and tools, it can run 3B-8B LLMs, SDXL, SD 1.5, some quantized FLUX workflows, Whisper transcription, and image feature extraction. If you force 14B+ LLMs, unquantized large models, or heavy image workflows, performance can collapse once data spills into system memory.

Short version: do not chase the largest model. Use small models, quantized weights, and low-VRAM workflows.

VRAM Budget

Windows 11, browsers, drivers, and background apps already use part of the GPU memory. The usable AI budget is often closer to 6.5GB-7.2GB than the full 8GB.

Practical rules:

LLM: prefer 3B-8B with 4-bit quantization.
Image generation: prefer SDXL, SD 1.5, and FLUX GGUF/NF4 low-VRAM workflows.
Multimodal: prefer light 4B-class models.
Speech: Whisper large-v3 can run, but long batches generate heat.
Image indexing: CLIP, ViT, and similar feature models are a good fit.

If VRAM spills to system memory, speed can become painful. A smaller model fully on GPU is usually better than a larger model half offloaded.

LLMs: 3B-8B Quantized Models

For local chat and text reasoning, use Ollama, LM Studio, koboldcpp, llama.cpp, or another GGUF-friendly frontend. The sweet spot for 8GB VRAM is 3B-8B with 4-bit quantization.

Lightweight General Use: Gemma 4 E4B

Gemma 4 E4B is one of Google’s small Gemma 4 models released in 2026. It is aimed at local and edge use, and is a reasonable daily model for Q&A, summaries, light multimodal tasks, and low-cost inference.

On a laptop RTX 4060, start with an official or community quantized build. Do not start with the highest-precision weights. First confirm speed, VRAM, and answer quality.

Good for:

Daily Q&A.
Summaries and rewriting.
Light document organization.
Simple code explanation.
Light image understanding.

Reasoning and Long Text: DeepSeek R1 Distill 7B/8B, Qwen 3 8B

For logic, math, complex analysis, and long Chinese text, try DeepSeek R1 distill 7B/8B or quantized Qwen 3 8B.

With Q4_K_M, 8B-class models usually fit within an 8GB laptop GPU budget. Actual speed depends on context length, backend, driver, and laptop power mode. Short chats are comfortable; long contexts increase both VRAM and latency.

Avoid starting with 14B, 32B, or larger models. They may launch with CPU offload, but the experience is usually worse than a smaller full-GPU model.

Coding: Qwen 2.5 Coder 3B/7B

For coding, Qwen 2.5 Coder 3B or 7B is a good choice. The 3B version is fast and fits real-time completion, explanations, and small snippets. The 7B version is stronger but heavier.

Suggested use:

Realtime completion: 3B.
Q&A and explanation: 3B or 7B.
Small refactors: quantized 7B.
Large architecture analysis: do not expect an 8GB laptop to hold the full project context.

Image Generation: SDXL Is Stable, FLUX Needs Quantization

RTX 4060 8GB is usable for image generation, but model choice matters.

SD 1.5 and SDXL

SD 1.5 is very friendly to 8GB VRAM, fast, and mature. SDXL needs more memory but remains usable.

Recommended tools:

ComfyUI
Stable Diffusion WebUI Forge
Fooocus

SD 1.5 is good for fast generation, LoRA, ControlNet, and old model ecosystems. SDXL is better for general quality. SDXL with Forge or ComfyUI is a stable starting point.

FLUX.1 schnell

FLUX has stronger prompt understanding and image quality, but the original models are heavy. On 8GB VRAM, use GGUF, NF4, FP8, or other low-VRAM paths with ComfyUI-GGUF or equivalent workflows.

Practical tips:

Use FLUX.1 schnell GGUF Q4/Q5.
Reduce resolution or batch size.
Use low-VRAM nodes or --lowvram in ComfyUI.
Avoid too many LoRA, ControlNet, and hi-res fix steps at once.
Watch whether VRAM is released after workflow changes.

You can try 1024px generation, but do not copy workflows meant for 16GB/24GB desktop GPUs.

Multimodal and Utility Workloads

Whisper large-v3

Whisper large-v3 works for speech-to-text. RTX 4060 can process ordinary audio quickly, useful for meeting recordings, lessons, video subtitles, and media organization.

For long batches, enable performance mode and keep cooling under control.

CLIP / ViT Image Indexing

For a photo search system, RTX 4060 8GB is a strong fit. CLIP, ViT, and SigLIP feature models do not require extreme VRAM and can process thousands of images quickly.

Typical pipeline:

Extract image embeddings with CLIP/ViT/SigLIP.
Store them in SQLite or a vector database.
Search by text or similar image.
Use a small LLM for tags, descriptions, or album summaries.

This workload suits 8GB GPUs better than large LLMs because it is mostly feature extraction and batch processing.

Recommended Combos

Local chat:

Ollama / LM Studio
+ Gemma 4 E4B quantized
+ DeepSeek R1 Distill 7B/8B Q4
+ Qwen 3 8B Q4

Coding:

1
2
3

Qwen 2.5 Coder 3B
+ Qwen 2.5 Coder 7B Q4
+ Continue / Cline / local OpenAI-compatible server

Image generation:

ComfyUI / Forge
+ SDXL
+ SD 1.5
+ FLUX.1 schnell GGUF Q4/Q5

Photo search:

1
2
3

CLIP / SigLIP / ViT
+ SQLite / FAISS / LanceDB
+ Gemma 4 E4B or Phi-4 Mini for text organization

Pitfalls

Scenario	Advice
Large models	Avoid 14B+ unless you accept major slowdown
Quantization	Start with `Q4_K_M`, then try Q5 if quality matters
VRAM	Monitor with Task Manager or `nvidia-smi`
Cooling	Use laptop performance mode for generation and batches
Resolution	Start image generation at 768px or one 1024px image
Browser	Close GPU-heavy tabs while running models
Driver	Keep NVIDIA drivers reasonably current
Workflows	Do not copy 16GB/24GB ComfyUI workflows directly

If VRAM stays above 7.5GB, lower the model size, lower context, close apps, or enable low-VRAM mode.

My Take

A laptop RTX 4060 8GB is best seen as a cost-effective local AI entry platform.

Good fit:

3B-8B local LLMs.
Small coding models.
SDXL and SD 1.5.
Quantized FLUX experiments.
Whisper transcription.
Image vector indexing.
Photo management and local data organization.

Poor fit:

Long-term 14B/32B LLM use.
Unquantized large models.
High-resolution batch FLUX workflows.
Large-scale video generation.
Many models resident at the same time.

For a photo retrieval system, use the GPU for CLIP/SigLIP feature extraction and small-model tagging, then store vectors in SQLite, FAISS, or LanceDB. Models like Gemma 4 E4B, Phi-4 Mini, or Qwen 2.5 Coder 3B/7B are more efficient than forcing a large model.

References

How to Change the VS Code Display Language: Chinese, English, and More

Fri, 08 May 2026 13:18:57 +0800

VS Code supports many display languages. The usual approach is to install the matching language pack, then choose the display language from the Command Palette. If you want to pin VS Code to a specific language, you can also edit the locale value in argv.json.

This method works not only for Simplified Chinese, but also for English, Traditional Chinese, Japanese, Korean, French, German, Spanish, and other languages.

Install the Language Pack

If you want to switch to a non-English interface, you usually need to install a language pack first.

Open the Extensions panel in the left sidebar, or press Ctrl+Shift+X.
Search for the target language, such as Chinese, Japanese, Korean, or French.
Select the matching language pack and click Install.
Restart VS Code when prompted.

For Simplified Chinese, the common language pack is Chinese (Simplified). For Traditional Chinese, use Chinese (Traditional).

Change the Language from the Command Palette

This is the recommended method for most users.

Open the Command Palette with Ctrl+Shift+P.
Type Configure Display Language.
Select the Configure Display Language command.
Choose the language you want from the list.
Restart VS Code when prompted.

After restarting, menus, settings pages, and common prompts will use the selected language. If the target language is not listed, install its language pack from the Extensions panel first.

Set the Language Manually in argv.json

If switching from the Command Palette does not work, or if you want to explicitly lock VS Code to a language, you can edit the runtime arguments file directly.

Open the Command Palette with Ctrl+Shift+P.
Type and select Preferences: Configure Runtime Arguments.
Find or add the locale setting.
Change its value to the target language code.
Save the file and restart VS Code.

For example, switch to English:

1
2
3

{
  "locale": "en"
}

Switch to Simplified Chinese:

1
2
3

{
  "locale": "zh-cn"
}

Switch to Japanese:

1
2
3

{
  "locale": "ja"
}

argv.json is a JSON file, so pay attention to commas and quotation marks. If the configuration is invalid, VS Code may not read the language setting correctly.

Common Display Language Codes

Display language	locale
English (US)	`en`
Simplified Chinese	`zh-cn`
Traditional Chinese	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

What to Do If the Language Does Not Change

Check the following items in order:

Confirm that the target language pack is installed.
Confirm that locale uses the correct language code. For example, Simplified Chinese is zh-cn, not zh-CN.
Fully close and reopen VS Code after changing the language.
If you edited argv.json manually, check that the JSON syntax is valid.
If the configuration is messy, remove the locale entry and choose the language again through Configure Display Language.

In most cases, Configure Display Language is the simplest option. Edit argv.json only when you need to force a specific language or the Command Palette switch does not take effect.

References

VScode: Change the VS Code display language to Simplified Chinese and switch the VS Code display language

AMD ROCm 7.2 + ComfyUI Compatibility Setup: Using a CUDA Alternative on Windows

Fri, 08 May 2026 10:09:05 +0800

For a long time, local AI art and video tools were built around NVIDIA CUDA by default. Stable Diffusion, ComfyUI, AnimateDiff, video super-resolution, LLM inference, and many plugins usually supported CUDA first. AMD GPUs often offered good VRAM value, but Windows users had to rely on DirectML, ZLUDA, Linux ROCm, or community patches. Stability and tutorial consistency were weaker than NVIDIA.

The ROCm 7.2 series changes that picture in a meaningful way. At CES 2026, AMD announced the Ryzen AI 400 series and tied ROCm, Radeon, Ryzen AI, and Windows AI workflows more closely together. AMD documentation shows that ROCm 7.2.1 updates PyTorch support on Windows for AMD Radeon graphics products and AMD Ryzen AI processors. ComfyUI Desktop also added official AMD ROCm support starting with v0.7.0.

This does not mean AMD has fully caught up with the CUDA ecosystem. It does mean that running ComfyUI on AMD GPUs under Windows is moving from a tinkering-only option to something worth seriously evaluating.

What ROCm 7.2 Brings

ROCm is AMD’s open software stack for GPU computing and machine learning. Its role is similar to NVIDIA CUDA. It includes HIP, compilers, math libraries, deep-learning libraries, profilers, PyTorch integration, and low-level runtime components.

For desktop users, ROCm 7.2 matters in three ways.

First, Windows support is more official. AMD’s Radeon/Ryzen ROCm documentation states that PyTorch on Windows has been updated to ROCm 7.2.1 for AMD Radeon graphics and AMD Ryzen AI processors. This is important for ComfyUI, Hugging Face Transformers, and local inference tools because most upper-layer tools eventually depend on PyTorch.

Second, hardware support is clearer. AMD documentation mentions support for Radeon 9000 series, selected Radeon 7000 series, Ryzen AI Max 300, selected Ryzen AI 400, and selected Ryzen AI 300 APUs. In other words, “AMD GPU” does not automatically mean full support. The exact model still needs to be checked against the compatibility matrix.

Third, ComfyUI now has an official route. In January 2026, the ComfyUI team announced that ComfyUI Desktop for Windows supports AMD ROCm from v0.7.0. For normal users, that matters because it reduces manual environment setup, wheel hunting, and launch-parameter tweaking.

For people looking for a CUDA alternative, these changes matter more than a single benchmark. Long-term usability depends on whether drivers, frameworks, models, plugins, and the frontend connect reliably.

Which Hardware Fits Best

The AMD route should be viewed in three groups.

The first is Radeon 9000 series. It is the newest discrete-GPU line that ROCm 7.2 focuses on, and it should have the highest priority if you are buying an AMD GPU now for local AI.

The second is selected Radeon 7000 series cards. These RDNA 3 GPUs already have some ROCm support, but not every model is equally stable. Before buying, check AMD’s official compatibility matrix and confirm Windows, Linux, PyTorch, and the target tool all support your card.

The third is Ryzen AI APUs. Ryzen AI 400 and Ryzen AI Max 300 bring CPU, GPU, NPU, and shared memory into laptops, mini PCs, and development devices. They are better for lightweight inference, development tests, mobile work, and small ComfyUI workflows. They should not be planned like high-end discrete GPUs for heavy model throughput.

If the goal is smooth mainstream AI art, a discrete GPU is still the safer choice. APUs are attractive for integration and shared memory, but they are not ideal for heavy video generation or large-batch image work.

Recommended Windows Path

For typical Windows users, ComfyUI Desktop should be the first choice. It is the official support path, reduces environment conflicts, and is easier to update with upstream changes.

The basic flow is:

Use Windows 11 and update AMD Software: Adrenalin Edition.
Confirm your GPU or APU is in the AMD ROCm Radeon/Ryzen compatibility matrix.
Install ComfyUI Desktop v0.7.0 or later.
Select or enable the AMD ROCm backend in ComfyUI Desktop.
After first launch, check the console for PyTorch/ROCm information.
Test a basic SDXL or Flux workflow before installing many plugins.

If you use manual ComfyUI, the idea is similar: install Python, install the PyTorch build for the ROCm 7.2 series, then launch main.py. AMD’s official ComfyUI guide notes that after launch you should verify the terminal shows the expected ROCm 7.2.1 PyTorch version.

Low-VRAM devices can try:

`1`	`python main.py --lowvram --disable-pinned-memory`

These options do not always improve speed, but they can reduce memory and VRAM pressure. On 8GB, 12GB, or shared-memory devices, finishing reliably is more important than maximum speed.

Linux Is Still Better For Heavy Users

ROCm on Windows is more usable now, but Linux remains the more mature AMD AI environment. AMD documentation also shows broader Linux support for Radeon across PyTorch, TensorFlow, JAX, ONNX, vLLM, Llama.cpp, and some training workflows.

If you only want ComfyUI image generation, Windows is worth trying.
If you need vLLM, LoRA training, batch video generation, multi-GPU, Docker, automation scripts, or long-running services, Linux is still the stronger choice.

Choose by workload:

Windows: desktop users, ComfyUI Desktop, lightweight image generation, local experimentation.
Linux: developers, heavy AI users, servers, batch processing, and the fuller ROCm ecosystem.
WSL: useful if you want Windows plus Linux tooling, but you must confirm ROCDXG, driver, and hardware support.

Do not treat Windows ROCm as the answer to every problem. It lowers the entry barrier and improves desktop use, while heavy production still depends more on Linux support.

Be Careful With ComfyUI Plugins

ComfyUI’s difficulty is not only the main program. The plugin ecosystem matters. Many nodes assume CUDA, xFormers, Triton, FlashAttention, or specific PyTorch extensions. After switching to AMD ROCm, common problems include:

Plugins calling CUDA-only extensions.
Acceleration libraries without ROCm wheels.
Custom-node install scripts that check for NVIDIA by default.
Video nodes depending on codecs or optical-flow libraries without AMD support.
New model workflows using NVIDIA-optimized settings by default.

Do not start by copying an old NVIDIA ComfyUI directory into an AMD setup. A cleaner approach is to install a fresh environment, verify a base model, and add plugins one by one.

Recommended test order:

Basic text-to-image.
Image-to-image.
LoRA.
ControlNet.
Upscaling and high-res fix.
AnimateDiff or video nodes.
Heavier models such as Flux, SD3, Wan, or HunyuanVideo.

Test after each plugin group. If something breaks, you can identify the likely node or dependency.

Why AMD GPUs Are Attractive For AI Art

The biggest attraction of AMD is VRAM and price. Many users choose AMD not because its AI software ecosystem is already easier than CUDA, but because the same budget often buys more memory, which helps local creation and long experiments.

Large VRAM is practical in ComfyUI:

It can fit larger checkpoints.
It can raise resolution.
It can load more LoRA, ControlNet, and reference-image nodes.
It can reduce the speed loss of low-VRAM mode.
It makes video generation and batch jobs less likely to run out of memory.

If ROCm 7.2 keeps PyTorch and ComfyUI stable on Windows, AMD GPUs become a more realistic CUDA alternative, especially for users who do not want cloud services but want more local VRAM.

Limits You Still Need To Accept

The AMD route is usable, but it is not a no-brainer CUDA replacement.

Main limits include:

Supported models are limited; older and some lower-end cards may not be listed.
Windows framework support is still narrower than Linux.
Many AI tutorials still assume NVIDIA.
Some ComfyUI plugins have only been tested on CUDA.
Community answers are fewer when errors appear.
The same model may perform very differently on different backends.

Before choosing AMD, confirm three things:

Your GPU is in the official compatibility matrix.
Your main tools explicitly support ROCm.
Your key plugins do not depend on CUDA-only extensions.

If all three are acceptable, AMD can be reliable. Otherwise, the money saved on hardware may be spent on environment debugging.

Recommended Setup Strategy

For beginners, use Windows 11 + a supported Radeon 9000/7000 card + ComfyUI Desktop. Follow the official path first and do not install too many third-party nodes immediately.

For developers, prepare a Linux environment. ROCm has a fuller toolchain on Linux and is better for batch tasks, LLM inference, Docker, and automation.

For laptop or mini-PC users, Ryzen AI 400 and Ryzen AI Max platforms are suitable for lightweight local AI. They can handle development, preview, simple image generation, and small-model inference, but should not be planned like high-end discrete GPUs for video generation.

For heavy ComfyUI users, focus on VRAM, driver version, and plugin compatibility. AMD’s memory value is tempting, but if one critical node does not support ROCm, the whole workflow can be affected.

Summary

The ROCm 7.2 series is a meaningful step forward for AMD local AI on Windows. Radeon and Ryzen AI PyTorch support is clearer, and ComfyUI Desktop now offers official ROCm support. This brings AMD GPUs closer to a CUDA alternative that ordinary users can actually try.

But usable does not mean fully compatible. The safer approach is to check the compatibility matrix, use the official install path, test basic ComfyUI first, and then add plugins and complex video workflows gradually. Windows fits lightweight desktop creation; Linux still fits heavy development and production.

If you want the least friction, CUDA remains the mainstream answer.
If you are willing to validate the workflow in exchange for larger VRAM and a more open ecosystem, ROCm 7.2 + ComfyUI is now worth serious testing.

References

RTX 5090 / 5080 AI Inference Benchmarks: Choosing for Local LLMs, 4K Video, and Real-Time 3D

Fri, 08 May 2026 10:07:19 +0800

For local AI users, the RTX 50 series is exciting not only because of gaming performance, but because Blackwell, GDDR7 memory, and fifth-generation Tensor Cores change what a desktop AI workstation can do. If you run local LLMs, image generation, video enhancement, or real-time 3D workflows, the GPU is no longer just a rendering device.

RTX 5090 and RTX 5080 should not be judged by model name alone. Both use Blackwell, support DLSS 4, fifth-generation Tensor Cores, and FP4, but local AI experience is usually decided by VRAM capacity, memory bandwidth, software support, and model compatibility.

The short version: RTX 5090 is the better single-card flagship for local AI, large models, long context, image generation, and video AI. RTX 5080 is better for smaller models, tighter budgets, and workflows that fit inside 16GB of VRAM. Both improve on the previous generation, but not every AI app can immediately use all Blackwell features.

Start With The Hardware Gap

RTX 5090 has 32GB GDDR7, a 512-bit memory bus, 21760 CUDA cores, and 3352 AI TOPS. Public testing from Puget Systems also highlights about 1.79TB/s of memory bandwidth, compared with RTX 4090’s 24GB and about 1.01TB/s. That matters for AI workloads.

RTX 5080 is more restrained: 16GB GDDR7, a 256-bit memory bus, 10752 CUDA cores, and 1801 AI TOPS. Its bandwidth is about 960GB/s, a clear jump over RTX 4080-class cards, but VRAM stays at 16GB.

That gives the two cards very different roles:

RTX 5090 is stronger for larger models, longer context, and heavier multimodal workloads because of 32GB VRAM and high bandwidth.
RTX 5080 is more cost- and power-conscious, and fits small to medium models, image generation, lighter video work, and development.
If a workload is already VRAM-limited, RTX 5080 cannot solve that with compute alone.
If a workload is software-limited, RTX 5090 may not always pull far ahead of RTX 4090 in proportion to its specs.

Local AI inference often follows a simple rule: VRAM decides whether it runs, bandwidth decides how fast it feels. That is why RTX 5090 is more attractive for local LLM users.

Local LLMs: 32GB Matters More

When running LLMs, VRAM is mainly used by model weights, KV cache, and runtime overhead. Larger models, longer context, and higher concurrency all increase pressure.

RTX 5080’s 16GB can cover many 7B, 8B, and 14B models, and can run some larger models with 4-bit quantization. But if you want 30B-class models, longer context, or WebUI, RAG, voice, and tool calls at the same time, 16GB becomes a limit quickly.

RTX 5090’s 32GB gives local inference much more room. It is better for:

Running quantized models around the 30B level.
Keeping longer context on 7B and 14B models.
Local coding assistants, knowledge-base Q&A, and Agent debugging.
Loading embedding, reranker, or multimodal components alongside the main model.
Reducing model switching and context compromises on a single machine.

Still, 32GB is not magic. Even 70B-class models with 4-bit quantization often need careful context, runtime settings, and memory management. For high-concurrency service, multi-GPU or server GPUs remain more suitable.

For personal use, RTX 5090’s biggest benefit is less friction: more model choices, more comfortable context length, and enough room for GUI tools and companion components.

FP4 Is Potential, Not Instant Acceleration Everywhere

One major Blackwell change is FP4 support in fifth-generation Tensor Cores. NVIDIA’s TensorRT materials note that FP4 can reduce model memory use and data movement, and can help local inference for generative models such as FLUX.

That is important for image generation and future LLM inference. Lower precision means less VRAM pressure and less bandwidth pressure. On a high-bandwidth GPU such as RTX 5090, FP4 can theoretically amplify the advantage if frameworks and models support it well.

But FP4 gains depend on the software path:

Whether the model has a suitable FP4 quantized version.
Whether the inference framework supports the needed operators.
Whether TensorRT, ComfyUI, PyTorch, ONNX, or plugins are adapted.
Whether the task can accept the precision tradeoff.
Whether the user is willing to adjust the workflow for speed.

So RTX 50 AI performance should not be judged only by FP4 peak numbers. Blackwell provides the hardware base, but the real experience depends on app updates. Early adopters will see some benefits first; mainstream users may need to wait for the ecosystem.

Image Generation And 4K Video: Bandwidth And VRAM Work Together

Stable Diffusion, FLUX, video super-resolution, frame interpolation, denoising, matting, and generative video all care about VRAM. Higher resolution costs more memory; more nodes add runtime overhead; ControlNet, LoRA, high-res fix, and batch generation increase pressure further.

RTX 5080 can handle many image-generation jobs inside 16GB. For 1024px images, light LoRA use, and normal ComfyUI workflows, it is already fast enough. Problems appear with larger canvases, more complex node graphs, higher batch sizes, or long-sequence video generation.

RTX 5090 has clearer advantages in 4K video workflows:

32GB VRAM is better for high-resolution frames, long sequences, and complex node graphs.
Around 1.79TB/s bandwidth helps reduce data-movement bottlenecks.
Three ninth-generation NVENC encoders are useful for export, transcoding, and creator workflows.
Once FP4 and TensorRT support matures, image generation models may benefit more.

Public video AI benchmarks also show a caution: application optimization has not fully caught up. Puget Systems found that RTX 5090 does not always dramatically beat RTX 4090 in DaVinci Resolve AI and Topaz Video AI, and RTX 5080 does not always create a large gap over RTX 4080-class cards. Video AI is not just about specs; plugins, drivers, and model implementations matter.

In other words, RTX 50 is more compelling if your workflow already supports Blackwell, TensorRT, or FP4. If you mostly rely on commercial software that has not been optimized yet, the upgrade value depends on the exact version.

Real-Time 3D And AI Modeling: RTX 5090 Fits Heavier Scenes

Real-time 3D modeling, neural rendering, 3D asset generation, and viewport AI acceleration use CUDA, RT Cores, Tensor Cores, and VRAM at the same time. Unlike pure LLM work, the goal is not only token speed. Scene complexity, materials, geometry, ray tracing, AI denoising, and viewport frame rate all matter.

RTX 5080 can handle many 4K gaming, real-time preview, and medium-scale creative projects. For independent creators, it is a realistic high-performance option.

RTX 5090 is a better fit for:

Complex 3D scene preview.
High-resolution materials and large asset libraries.
AI denoising, upscaling, and generative modeling assistance running together.
Heavy D5 Render, Blender, Unreal Engine, and similar workloads.
Modeling while also running a local AI assistant or reference-image generator.

NVIDIA says RTX 50 can improve generative AI, video editing, and 3D rendering in creative apps, but production projects still depend on whether the software uses the new hardware paths. The reliable method is to test with your own project files, not only marketing charts.

How To Choose

If your main goal is local LLMs, start with VRAM. RTX 5080’s 16GB can run many lightweight models, but it is closer to an entry high-performance local AI card. RTX 5090’s 32GB is closer to a single-card local LLM workstation.

For image generation, RTX 5080 covers many daily workflows. If you often use high resolution, complex node graphs, batch generation, FLUX, or video generation, RTX 5090’s VRAM headroom matters more.

For 4K video AI, RTX 5090 is safer, but check the exact software version. Topaz, DaVinci Resolve, ComfyUI, TensorRT plugins, and drivers can all affect results.

For real-time 3D, RTX 5080 can satisfy many creators. RTX 5090 is better for heavier scenes, parallel apps, and long production sessions.

If you already own an RTX 4090, upgrade carefully. RTX 5090 has more VRAM and bandwidth, but some AI software has not fully unlocked Blackwell yet. Unless you clearly need 32GB, higher bandwidth, or the new encoders, waiting for the ecosystem is reasonable.

If you are still on RTX 30 series or older, RTX 50 will feel much more meaningful. Moving from 8GB, 10GB, or 12GB to 16GB or 32GB directly expands what local AI can run.

Summary

RTX 5090 and RTX 5080 both push consumer GPUs further into local AI, but they serve different users.

RTX 5090 is about 32GB GDDR7, very high memory bandwidth, and a stronger creative hardware stack. It suits users who want larger local models, more complex image generation, heavier video AI, and real-time 3D on one machine.

RTX 5080 is about entering Blackwell at a lower cost. It suits small and medium models, daily image generation, development tests, and high-performance creative work that fits in 16GB.

The buying rule is simple: first check whether your models and projects fit in VRAM, then check whether your software is optimized for Blackwell, and only then look at theoretical AI TOPS. For local AI, finishing reliably matters more than peak numbers.

References

DeepSeek V4 Local Private Deployment: Choosing Domestic Chips or Consumer GPU Clusters

Fri, 08 May 2026 09:39:35 +0800

After DeepSeek V4 was released, many enterprises started asking one question: can we avoid external APIs and deploy the model in our own data center, private cloud, or dedicated cluster?

This is a very practical need. Finance, healthcare, government, manufacturing, legal, and R&D teams often cannot send internal documents, code, contracts, tickets, or customer data directly to public cloud models. For these scenarios, DeepSeek V4 is attractive not only because of model capability, but because it gives enterprises an option closer to controllable LLM infrastructure.

However, local deployment of DeepSeek V4 is not as simple as downloading a model and finding a few GPUs. Especially for very large MoE models such as Pro, total parameter size, active parameters, context length, KV cache, concurrency, and inference framework all directly affect hardware cost. What enterprises really need is not blindly chasing the full version, but first deciding what deployment shape the business actually needs.

Clarify the Deployment Goal First

Enterprise local private deployment usually has three goals:

Keep data inside the domain: internal documents, code, customer materials, logs, and knowledge bases do not leave the enterprise environment.
Make operations stable and controllable: model services, permissions, audit, logs, and upgrade cadence are controlled by the enterprise.
Reduce long-term cost: for high-frequency calls, local inference may be more controllable than long-term external API purchases.

If only a few employees ask occasional questions, local deployment may not be cost-effective. Private deployment is truly suitable for high-frequency, stable, data-sensitive, and workflow-defined scenarios, such as:

Internal knowledge-base Q&A.
Code review and development assistants.
Customer-service ticket summarization.
Contract, medical-record, and report analysis.
Database query assistants.
Agent workflow automation.

These scenarios share the same traits: sensitive data, stable call patterns, and the ability to fit into enterprise governance through permissions and logs.

Do Not Chase Full Pro From Day One

Common DeepSeek V4 versions include Pro and Flash. In public materials, Pro targets stronger reasoning and complex Agent tasks, while Flash emphasizes cost and response speed. Enterprises should not assume every workload needs Pro.

You can split tasks by complexity:

Simple Q&A, summarization, classification, and tag generation: prioritize Flash or smaller models.
Internal knowledge-base retrieval augmentation: Flash is enough for many cases; RAG, permissions, and retrieval quality matter more.
Code Agents, complex reasoning, and long-context analysis: then evaluate Pro.
High-value, low-frequency tasks: Pro can be used, but high concurrency may not be necessary.
Regular office assistants: there is no need to occupy the most expensive inference resources for long periods.

The advantage of MoE models is that each inference only activates part of the parameters, but this does not mean the hardware pressure is small. Weight storage, expert parallelism, network communication, context cache, and concurrent scheduling are still heavy. With 1M-token-level long context in particular, the real resource consumer is often not a single answer, but long context, multi-user concurrency, and persistent sessions.

Domestic Chip Route: Better for Enterprise Private Cloud

If an enterprise already has a domestic compute pool, or has requirements around Xinchuang, compliance, or supply-chain control, it can first evaluate domestic chips such as Ascend and Cambricon.

The advantages of this route are:

Better alignment with localization and supply-chain control requirements.
Suitable for enterprise data centers, dedicated clouds, and government/enterprise projects.
Easier to unify permissions, audit, resource isolation, and operations.
Friendlier to long-term stable services.

But the domestic chip route also has three practical issues.

First, framework adaptation. Whether the model can run depends not only on chip compute power, but also on the maturity of the inference framework, operators, communication libraries, quantization formats, MoE expert parallelism, and long-context optimization.

Second, engineering experience. Enterprises need more than “it starts successfully”; they need stable services: multi-tenancy, rate limiting, monitoring, failure recovery, gray releases, log audit, and permission isolation all need to be built.

Third, ecosystem differences. The same model will not have identical performance, accuracy, quantization support, or deployment tools on NVIDIA, Ascend, Cambricon, and other platforms. Before launch, real stress testing is required instead of relying only on nominal compute.

Therefore, domestic chips are more suitable for enterprises with clear budgets, high compliance requirements, and willingness to invest in platform engineering. It is not the easiest route, but it may be the route that best fits long-term governance.

Consumer GPU Clusters: Better for Pilots and Small Teams

If the goal is to validate business value first, a consumer GPU cluster is easier to start with. GPUs such as RTX 4090, RTX 5090, RTX 3090, and RTX 3060 12GB have more community tools, quantized models, and local inference references, so trial-and-error cost is lower.

The consumer GPU route fits:

Internal pilots by R&D teams.
Knowledge-base Q&A for small and medium businesses.
Low-concurrency code assistants.
Offline document processing.
Internal tools without strict SLA requirements.

But it also has obvious limits:

VRAM is small, making it hard to host a full large model directly.
Multi-GPU communication is weak, and cross-machine communication is more troublesome.
Long-term full-load stability is weaker than server-grade solutions.
Chassis, power, cooling, drivers, and operations become hidden costs.
It is not suitable for promising enterprise-grade high availability from the start.

A more realistic approach is to first run Flash, distilled versions, quantized versions, or smaller models on consumer GPUs, get the business workflow working, and then decide whether to migrate to server GPUs or a domestic compute platform after call volume, quality, and data governance have been validated.

A Possible Deployment Architecture

A relatively stable enterprise private architecture can be divided into six layers:

Model layer: DeepSeek V4 Pro, V4 Flash, or smaller distilled models selected by task.
Inference layer: SGLang, vLLM, llama.cpp, vendor NPU inference stacks, or enterprise self-developed services.
Gateway layer: unified authentication, rate limiting, audit, model routing, and call logs.
Knowledge layer: vector database, full-text search, document parsing, permission filtering, and RAG.
Application layer: customer service, code assistants, document analysis, report Q&A, and Agent workflows.
Operations layer: monitoring, alerts, cost statistics, gray releases, rollback, and security audit.

The gateway layer and knowledge layer are the easiest to underestimate. Many projects fail not because the model is completely unusable, but because permissions, retrieval, logs, context management, prompt templates, and business workflows were not done well.

When deploying LLMs internally, enterprises should treat the model as infrastructure, not as an isolated chat page. The real value appears only when the model enters workflows and can stably process the enterprise’s own data and tasks.

Hardware Selection

Hardware selection should not only ask “can it run”; it should also ask “can it serve stably”.

You can choose by stage:

Validation Stage

The goal is to prove whether the business is worth doing.

Use 1-4 consumer GPUs.
Prioritize Flash, smaller models, distilled models, or quantized models.
Keep concurrency low and focus on task completion rate.
Do not promise high availability.

Do not buy large-scale hardware too early at this stage. First confirm whether employees actually use it, whether the business really saves time, and whether answers can enter real workflows.

Pilot Stage

The goal is to let one department or one business line use it steadily.

Use 4-16 GPUs or a set of domestic NPU nodes.
Add a unified gateway, logs, and permission controls.
Build RAG, document parsing, model routing, and caching.
Start tracking tokens, concurrency, latency, and failure rate.

At this stage, operations begin to matter. Model quality is only one part; stability, cost, and data governance are equally important.

Production Stage

The goal is to enter enterprise-grade service.

Use server GPUs, domestic compute clusters, or private-cloud resource pools.
Build multi-replica deployment, rate limiting, failover, and capacity planning.
Route models by task: simple tasks use lightweight models, complex tasks use Pro.
Connect to enterprise identity systems, audit systems, and security policies.

In production, it is not recommended to send every request to the strongest model. Proper model routing usually saves more money than simply adding hardware.

Choosing an Inference Framework

Models such as DeepSeek V4 have high requirements for inference frameworks. When MoE, long context, sparse attention, quantization, and multi-GPU parallelism are involved, framework maturity directly affects speed and stability.

Common choices can be understood this way:

SGLang: suitable for teams focused on high-performance inference, Agents, multi-turn tool calls, and complex service orchestration.
vLLM: mature ecosystem, suitable for general LLM services, but actual support depends on version and model adaptation progress.
llama.cpp: better for small models, quantized models, and edge deployment; not suitable for directly hosting a full very large MoE model.
Domestic NPU inference stacks: suitable for Xinchuang and domestic compute environments, but operator, quantization, and long-context support must be carefully verified.

Do not choose a framework only by benchmark. Enterprises should test their own real inputs: internal document length, concurrency, average output length, RAG hit rate, number of Agent tool calls, and retry count after failures.

Data Security Must Be Built Outside the Model

Private deployment does not automatically mean security. Running the model locally only solves part of the question of whether data leaves the enterprise.

You still need:

Accounts and permissions: different departments can only access their own knowledge bases.
Log audit: who asked what, which model was called, and which documents were accessed.
Data masking: customer information, ID numbers, phone numbers, contract amounts, and other sensitive fields must be handled.
Prompt security: prevent users from bypassing permissions or leaking system prompts through prompts.
Output review: important scenarios need human review or rule-based review.
Data lifecycle: uploaded documents, vector indexes, caches, and session records must be deletable.

Enterprise local LLM deployment cannot involve only the algorithm team. Security, legal, operations, and business owners should all participate; otherwise, risks will be exposed after launch.

Cost Is More Than GPUs

The cost of local deployment is often underestimated. Beyond GPUs or NPUs, you also need to count:

Servers, racks, power, cooling, and networking.
Storage and backup.
Inference framework adaptation and engineering development.
Operations monitoring and incident handling.
Model upgrades, rollback, and compatibility tests.
Security audit and permission systems.
Business-side prompts, RAG, and workflow construction.

If call volume is very low, external APIs may be cheaper. If call volume is high, data is sensitive, and workflows are stable, local deployment is more likely to amortize cost.

A more reasonable strategy is hybrid deployment:

Highly sensitive data goes to local models.
Low-sensitivity general tasks can use external APIs.
Simple tasks use small models.
Complex tasks use DeepSeek V4 Pro.
High-frequency tasks prioritize caching, retrieval, and model routing optimization.

Recommended Rollout Path

Enterprises can proceed in this order:

Choose 2-3 high-value scenarios first; do not roll out company-wide.
Use consumer GPUs or small-scale compute for a PoC.
Run Flash, distilled models, or quantized models first, and connect RAG and permissions.
Introduce Pro for comparison tests on complex tasks.
Record real call volume, latency, failure rate, and time saved by humans.
Then decide whether to purchase domestic chip clusters or server GPUs.
Before production, complete gateway, audit, monitoring, rate limiting, and rollback.

This path is more stable than buying a large cluster from the start. The biggest enterprise risk is not that the model is not strong enough, but that a lot of money is spent before the business workflow is ready to absorb the model capability.

Summary

DeepSeek V4 gives enterprises more room to imagine local private deployment, but it is not simply a “local ChatGPT”. The real difficulty is engineering: hardware, frameworks, model routing, permissions, RAG, audit, monitoring, and cost control all need to be considered together.

The domestic chip route better fits enterprises with high compliance requirements and long-term private cloud plans. Consumer GPU clusters are better for pilots and quick validation by small and medium teams. Pro fits complex reasoning and Agent tasks; Flash or smaller models fit many ordinary tasks.

If you only remember one sentence: DeepSeek V4 private deployment should not start with hardware procurement, but with business scenarios, data boundaries, and call volume. First get the scenario working, then decide whether to use a large model, how large it should be, and what compute platform to use.

References

Local LLM Models Recommended for an RTX 3060 GPU

Fri, 08 May 2026 09:25:24 +0800

The most common RTX 3060 variant has 12GB of VRAM. It is not a top-tier AI GPU, but it is a very usable card for local LLMs, especially 7B, 8B, 9B, and 12B models.

If you only want a quick rule of thumb, remember this:

On an RTX 3060 12GB, prioritize around-8B models in Q4_K_M or Q5_K_M quantization. Choose Q4 for stability, and try Q5 if you want better quality.

Do not start by chasing 32B or 70B models. Even if they can run with low-bit quantization and CPU offloading, their speed and experience are usually not suitable for daily use.

Start With the VRAM Limit

For local LLMs on an RTX 3060 12GB, the real limit is VRAM.

Model Size	Recommended Quantization	RTX 3060 12GB Experience
3B / 4B	Q4, Q5, Q8	Very easy, fast
7B / 8B / 9B	Q4_K_M, Q5_K_M	Best balance of quality and speed
12B / 14B	Q4_K_M	Usable, but avoid huge context
30B+	Q2 / Q3 or partial offload	Possible to tinker with, not recommended daily
70B+	Very low quantization or heavy CPU/RAM use	More like an experiment

Local LLMs do not only consume VRAM for the model file. Context length, KV cache, batch size, inference framework, and drivers all consume resources.

So 12GB of VRAM does not mean you can load a 12GB model file directly. It is better to leave room for the system and context.

Recommendation 1: Qwen3 8B

If you mainly use Chinese, Qwen3 8B is one of the first models worth trying on an RTX 3060.

Good for:

Chinese Q&A.
Summarization and rewriting.
Everyday knowledge assistant work.
Simple code explanation.
Local RAG.
Lightweight Agent flows.

Recommended choice:

1
2
3

Qwen3 8B GGUF
Q4_K_M: first choice
Q5_K_M: better quality, more VRAM pressure

Qwen models are friendly to Chinese usage. For daily writing, information organization, and Chinese instruction following, Qwen3 8B is a good first model.

Recommendation 2: Llama 3.1 8B Instruct

Llama 3.1 8B Instruct is a stable general-purpose model with mature English capability and ecosystem support.

Good for:

English Q&A.
Lightweight coding help.
General chat.
Document summarization.
Prompt testing.
Comparing different inference tools.

Recommended choice:

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M: better speed and VRAM stability
Q5_K_M: better answer quality

If you mainly process English materials, or want a model with many tutorials and broad compatibility, Llama 3.1 8B is still a good baseline.

Recommendation 3: Gemma 3 12B

Gemma 3 12B is closer to the upper practical limit for an RTX 3060 12GB.

It uses more VRAM than 8B models, but Q4 quantization can still make it usable on a 12GB card. It is a good option if you want to try a slightly larger model on one GPU.

Good for:

Higher-quality general Q&A.
English content processing.
More complex summarization and analysis.
Trying an upgrade over 8B models.

Recommended choice:

1
2
3

Gemma 3 12B GGUF
Q4_K_M or official QAT Q4
Keep context modest

If you run out of VRAM, reduce context length first, or return to an 8B model. For an RTX 3060, 12B is “worth trying,” not a no-brainer default.

Recommendation 4: DeepSeek R1 Distill Qwen 8B

If you want to experience reasoning-style local models, try models like DeepSeek R1 Distill Qwen 8B.

Good for:

Simple reasoning tasks.
Step-by-step analysis.
Learning reasoning-model output style.
Low-cost local experiments.

Recommended choice:

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

These models may produce longer reasoning-style outputs, so speed and context usage can be heavier than ordinary instruction models. They are not always more comfortable for daily chat, but they are useful for reasoning experiments.

Recommendation 5: Phi / MiniCPM / Smaller Models

If your RTX 3060 is an 8GB variant, or your system RAM is limited, consider 3B and 4B models first.

Good for:

Fast Q&A.
Simple summaries.
Embedding into local tools.
Low-latency chat.
Testing on older machines.

These models may not match 8B or 12B quality, but they are light, fast, and easy to deploy.

Which Quantization to Use

Local models commonly use GGUF, with quantization types such as Q4, Q5, Q6, and Q8.

Quantization	Traits	Best For
Q4_K_M	Small, fast, good enough	RTX 3060 first choice
Q5_K_M	Better quality, higher usage	Try with 8B models
Q6 / Q8	Closer to original quality, larger	Small models or more VRAM
Q2 / Q3	Saves VRAM but quality drops	Large-model tinkering

For RTX 3060 12GB, the practical choices are:

1
2
3

8B models: Q4_K_M or Q5_K_M
12B models: Q4_K_M first
Larger models: not recommended as daily drivers

Which Tool to Use

Beginners can start with Ollama, because installation and running models are simple.

Common commands:

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

If you want finer control over GGUF files, GPU layers, and context length, use llama.cpp or GUI tools based on it.

Common choices:

Ollama: easiest, best for beginners.
LM Studio: friendly GUI, good for downloading and switching models.
llama.cpp: most control, best for performance tuning.
text-generation-webui: many features, good for backend testing.

For local chat and simple Q&A, Ollama or LM Studio is enough.

Do Not Set Context Too High

Many models advertise long-context support, but do not blindly set context to the maximum on an RTX 3060.

Longer context uses more KV cache and increases VRAM pressure. Even if the model loads, long context can slow generation down.

Suggested settings:

1
2
3

Normal chat: 4K to 8K
Document summaries: 8K to 16K
Long-document RAG: chunk first; do not paste everything at once

An RTX 3060 is better suited to “moderate context + good model + good retrieval” than forcing hundreds of thousands of tokens into one prompt.

Choose by Use Case

If you mainly write Chinese:

1
2

First choice: Qwen3 8B Q4_K_M
Alternative: DeepSeek R1 Distill Qwen 8B

If you mainly write English:

1
2

First choice: Llama 3.1 8B Instruct Q4_K_M
Alternative: Gemma 3 12B Q4_K_M

If you want speed:

1
2
3

3B / 4B models
8B Q4_K_M
Keep context at 4K to 8K

If you want better quality:

1
2
3

8B Q5_K_M
12B Q4_K_M
Accept slower speed

If you want coding help:

1
2

8B coding models can help with explanations and small edits
For complex engineering tasks, use stronger cloud models

Local RTX 3060 models are good for code explanation, function completion, small scripts, and offline assistance. For large refactors, difficult bugs, and cross-file Agent work, do not expect Claude Sonnet or GPT-5-level performance.

Reasonable Expectations

The RTX 3060 12GB is good enough to turn local LLMs from toys into daily tools, but it will not recreate top cloud models at home.

Its strengths:

Low cost.
More VRAM than 8GB cards.
Good 8B model experience.
Offline use.
Local processing for privacy-sensitive materials.

Its limits:

Large models are hard to run smoothly.
Long context consumes VRAM.
Slower than high-end GPUs.
Small local models have limited complex reasoning.
Multimodal and Agent workflows need more resources.

The stable route is: use 8B models as everyday local assistants, try 12B models for quality, and leave complex tasks to cloud models.

Summary

Recommended local LLM choices for RTX 3060 12GB:

Chinese general use: Qwen3 8B Q4_K_M
English general use: Llama 3.1 8B Instruct Q4_K_M
Higher-quality experiment: Gemma 3 12B Q4_K_M
Reasoning experiment: DeepSeek R1 Distill Qwen 8B Q4_K_M
Low-VRAM fast use: 3B / 4B small models

Choose Q4_K_M first. Try Q5_K_M for 8B models if you want better quality. Start with Ollama or LM Studio.

Do not treat the RTX 3060 as a large-model server. Treat it as a local knowledge assistant, privacy document processor, lightweight coding helper, and model experiment card, and it will fit its real capabilities much better.

References

Qwen3 8B GGUF: https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF: https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF: https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp: https://github.com/ggml-org/llama.cpp
Ollama: https://ollama.com

How to Draw Dashed Lines, Arrows, Curves, and Change Canvas Size in AI

Fri, 08 May 2026 09:18:53 +0800

Here, AI refers to common vector design software, not artificial intelligence image generation.

Many beginners search for the same basic questions: how to draw dashed lines in AI, how to draw arrows, how to draw curves, and how to change canvas size. These are all basic operations, but the controls are spread across Stroke, Pen, Line Segment, and Artboard tools.

This guide organizes them in practical order.

How to Draw a Dashed Line in AI

In AI software, a dashed line is usually not a separate tool. It is created through the Stroke panel.

Steps:

Use the Line Segment Tool, Pen Tool, or Shape Tool to draw a line or path.
Select the line.
Open Window -> Stroke.
Check Dashed Line in the Stroke panel.
Set Dash and Gap values.

Common settings:

Dash: how long each solid segment is.
Gap: how much space appears between segments.
Stroke weight: controls the overall line thickness.

For a balanced dashed line, try:

1
2

Dash: 8
Gap: 8

For a dotted line, set the line cap to round and make the dash value very small:

1
2
3

Dash: 0
Gap: 8
Cap: Round

This makes the line look like a row of dots.

What If the Dashed Line Does Not Show

If checking dashed line does not visibly change anything, check:

Whether the object has a stroke color.
Whether the stroke weight is too small.
Whether the correct object is selected.
Whether Dash and Gap values are too small.
Whether the object only has fill and no stroke.

Many line problems are simply “the object has a path, but no stroke.”

How to Draw an Arrow in AI

Arrows are also usually added to a path through the Stroke panel.

Steps:

Draw a straight line with the Line Segment Tool.
Select the line.
Open Window -> Stroke.
Find Arrowheads near the bottom of the Stroke panel.
Choose an arrowhead style for the start or end point.
Adjust the arrowhead scale.

If the arrow points the wrong way, you can:

Move the arrowhead from the start point to the end point in the Stroke panel.
Use a path-direction command to reverse the path.

The simplest method is to draw the line again: drag from the tail toward the arrowhead. The endpoint will become the arrow direction.

How to Draw a Double-Headed Arrow

A double-headed arrow only needs arrowheads on both the start and end points.

Steps:

Select the line.
Open the Stroke panel.
Choose an arrowhead for the first arrowhead slot.
Choose an arrowhead for the second arrowhead slot.

If the arrowheads are too large or too small, adjust the Scale value.

In general, arrowhead size should match line weight. A thin line with huge arrowheads looks unbalanced; a thick line with tiny arrowheads is hard to read.

How to Draw a Curve in AI

The most common way to draw curves is the Pen Tool.

Basic method:

Select the Pen Tool.
Click once on the canvas to create the first anchor point.
At the second position, press and drag instead of only clicking.
Direction handles appear as you drag, creating the curve.
Continue clicking and dragging to build a continuous curve.

The key is simple: click for straight lines, click and drag for curves.

Many beginners cannot draw curves because they only click and never drag the direction handles.

How to Smooth a Curve

After drawing a curve, use these tools to adjust it:

Direct Selection Tool: select anchor points and move points or handles.
Anchor Point Tool: switch between corner points and smooth points.
Smooth Tool: make paths smoother.
Curvature Tool: create smooth curves more easily.

If you only want a natural curve, the Curvature Tool is easier for beginners than the Pen Tool. It does not require manually dragging many direction handles; clicking a few points can create a smooth path.

Draw Curves With the Curvature Tool

The Curvature Tool works more like “click points and let the curve follow.”

Steps:

Select the Curvature Tool.
Click the first point on the canvas.
Click the second point.
Click a third point, and the software creates a curve automatically.
Drag existing points to change the curve shape.

If you want a sharp corner, double-click a point to switch between a smooth point and a corner point.

For beginners, it is often easier to create the rough curve with the Curvature Tool, then fine-tune it with the Direct Selection Tool.

How to Change Canvas Size in AI

In AI, “canvas size” usually means artboard size. If you want to change export range, design size, or page size, change the artboard.

Steps:

Select the Artboard Tool from the toolbar.
Click the current artboard.
Enter width and height in the top properties bar.
You can also drag the artboard edges manually.

Common sizes:

WeChat cover: 900 x 383 px
Xiaohongshu cover: 1242 x 1660 px
Instagram square: 1080 x 1080 px
A4 paper: 210 x 297 mm

If your unit is not px, change units in the document or properties panel.

Change Size From the Artboards Panel

Besides the Artboard Tool, you can manage multiple artboards through the Artboards panel.

Steps:

Open Window -> Artboards.
Select the artboard you want to edit.
Click artboard options.
Enter width, height, and position.

If one file contains multiple pages, poster sizes, or export versions, the Artboards panel is clearer than dragging by hand.

Will Changing Artboard Size Affect Graphics

Changing only the artboard size usually does not automatically scale the graphics inside.

That means:

If the artboard gets larger, object sizes stay the same.
If the artboard gets smaller, object sizes still stay the same, but some content may fall outside the artboard.
Exports usually include only content within the artboard range.

If you want graphics to scale with the artboard, select the graphics and scale them manually, or use the Scale Tool or Transform panel.

Useful Shortcuts and Panels

Useful entry points:

Stroke panel: Window -> Stroke
Artboards panel: Window -> Artboards
Artboard Tool: Shift + O
Pen Tool: P
Direct Selection Tool: A

Different versions may have slightly different interfaces, but the core logic is the same: dashed lines and arrows are in Stroke, curves use path tools, and canvas size is changed through artboards.

Summary

To draw a dashed line in AI: select a path, check Dashed Line in the Stroke panel, and set dash and gap.

To draw an arrow in AI: draw a line, then add an arrowhead to the start or end in the Stroke panel.

To draw a curve in AI: use the Pen Tool to click and drag, or use the Curvature Tool for smoother beginner-friendly curves.

To change canvas size in AI: use the Artboard Tool or Artboards panel to edit artboard width and height.

Once you know these operations, most basic lines, flowcharts, annotation graphics, and page-size adjustments become manageable.

24 Claude Code Tips: Plan Mode, Rewind, CLAUDE.md, Skills, Agents, and Plugins

Fri, 08 May 2026 08:54:14 +0800

Claude Code is not just a chat box. It is closer to a coding Agent that can enter a project directory, read and write files, run commands, and maintain context.

If you only throw a requirement at it and wait for code, problems appear quickly: unclear plans, repeated permission prompts, growing context, unsatisfactory output, no clear rollback path, and no persistent place for project rules.

Here is a set of common operations for developers getting started with Claude Code.

Start Inside the Project Directory

Claude Code works best when launched inside the project directory, not from a random terminal location.

Create a folder as the project directory, enter it, open a command line, and start Claude Code:

claude

When first entering a project, if Claude Code asks whether to trust the current folder, confirm before continuing. This lets it read files, create files, and run later operations around the current project.

A simple practice task is to ask it to create a photographer portfolio website. The task is visual enough to inspect, and it also lets you practice file generation, command execution, rewind, and later refactoring.

Use Plan Mode First

For more complex tasks, Claude Code may enter plan mode. Plan mode is meant to discuss requirements and break down steps before you approve execution.

After it writes a plan, you usually see options like:

Approve the plan and automatically allow future edit tools.
Approve the plan, but require manual approval for later edits.
Pause and continue discussing the plan with Claude Code.

If the task is clear, approve and continue. If it is not clear yet, ask it to refine the plan, such as page style, tech stack, directory structure, interactions, and acceptance criteria.

Plan mode reduces rework. If an Agent starts directly, it may quickly generate many files; if the direction is wrong, later changes can get messy.

Switch Modes With Shift + Tab

In Claude Code, Shift + Tab can switch between working modes. A common use is entering plan mode or switching into an auto-approve-edit mode.

Suggested habits:

New projects, new features, major changes: start in plan mode.
Small edits and clear fixes: execute directly.
Deletion, bulk replacement, dependency installation: keep manual approval.

In plan mode, Claude Code may ask project-detail questions. Use arrow keys to choose and Enter to confirm. After submitting feedback, it updates the plan.

Do Not Open All Permissions Blindly

When Claude Code runs commands, edits files, or starts programs, it may request permission.

Common choices include:

Allow only this time.
Allow this command type for the current session.
Reject or pause.

For local preview, dev server startup, or file inspection, approve as needed. But do not permanently use a mode that auto-approves all permissions just to save clicks.

Full automation is only suitable when the task is low-risk, clearly understood, and the project already has Git backups. For daily use, keep human approval for deletion, overwriting folders, dependency installation, networking, commits, and scripts.

Run Local Commands in Terminal Mode

Claude Code can enter a terminal-command mode to run local commands.

For example, after generating a page, you can open an HTML file with:

`1`	`start index.html`

start is a Windows command for opening a file, followed by the filename. This is faster than finding the file manually.

Terminal mode is useful for:

Opening generated pages.
Listing directory contents.
Starting local development servers.
Running tests or builds.

Still, be careful with high-risk commands such as recursive deletion, moving directories, bulk overwrites, and system environment changes.

Rewind When the Result Goes Wrong

If the page or code produced by Claude Code is not what you want, and each correction makes it worse, rewind early.

Rewind can return code or conversation to a previous point. Common options include:

Rewind both code and conversation.
Rewind only conversation.
Rewind only code.
Compress earlier content into a summary.
Cancel.

When the direction is clearly wrong, it is usually better to rewind both code and conversation. That returns context and files to a cleaner state together.

Note that Claude Code rewind usually only covers files it created or changed through built-in tools. Files created through external commands may not be fully rewindable. Important projects should still use Git.

Write Long Prompts in an Editor

Do not squeeze complex requirements into one input line.

If the system supports editing a long prompt in a text editor, open the editor, write the requirement clearly, save it, and then send it to Claude Code.

Long prompts should include:

The goal.
The tech stack.
What not to do.
Which files must be kept.
How to verify completion.
Page or feature acceptance criteria.

For example, if you want Claude Code to refactor a plain HTML page into a more modern stack, do not just say “refactor it.” Explain component structure, visual preservation, responsive layout, and ask it to run a build check.

Restore Sessions After Exit

If you need to quit Claude Code midway, exit normally. Later, return to the same project directory and start again:

claude

If previous records do not appear directly, use history-related commands to view and load recent sessions.

This is useful for continuing interrupted work. But do not treat session history as the only memory. Project rules, tech stack, common commands, and notes should live in project files.

Use CLAUDE.md for Project Rules

CLAUDE.md is an important memory file for Claude Code. It usually sits at the project root and tells Claude Code project rules, tech stack, directory structure, and collaboration constraints.

You can ask Claude Code to initialize it:

/init

CLAUDE.md is good for:

Project goals.
Tech stack.
Common start, test, and build commands.
Directory notes.
Code style.
Forbidden actions.
Commit and deployment rules.

During each conversation, Claude Code can use these rules as part of the context. Think of it as a project manual.

A simple test is to add a clear rule into CLAUDE.md, then ask Claude Code something. If its answer follows the rule, it has read the project memory.

Reference Files With @

Typing @ in the input box lets you select files or Agents and add them to the current context.

This is useful when you want Claude Code to:

Read a config file.
Modify a specific page.
Continue based on CLAUDE.md or another document.
Only inspect a specific file instead of guessing the whole project.

Compared with copying file contents into the input box, @ references are clearer and less error-prone.

View and Compress Context

After a long conversation, context grows. When it gets too long, the model may slow down or start ignoring earlier details.

Use:

`1`	`/context`

If context is long, compress history:

`1`	`/compact`

If the result is still poor, consider clearing the current context:

/clear

After clearing, Claude Code can still understand part of the project through files, CLAUDE.md, and the current directory, but it will not keep the full conversation history.

A practical habit: start a new chat after a task is done, write project rules into CLAUDE.md, and do not let temporary discussion grow forever in one chat.

Skills: Turn Repeated Work Into Instructions

Skills are reusable task instructions for Claude Code. They are not one-off prompts, but packaged workflows.

For example, if you often generate weekly reports, create a weekly-report Skill that defines:

Required input.
Output format.
Tone and structure.
What must be preserved.
What must not be invented.

Skills usually contain name, description, and detailed instructions. Once installed in the global Skills directory, Claude Code can recognize and load them for related tasks.

Good Skill candidates include:

Weekly reports.
Code review templates.
Document cleanup.
Image batch processing.
Fixed-format articles.
Project initialization flows.

If you repeatedly copy the same prompt, consider turning it into a Skill.

Agents: Delegate Subtasks to Independent Helpers

Agents are different from Skills.

A Skill is more like an instruction manual. An Agent is more like an independent helper that can work outside the main conversation and return results.

The value of Agents is context isolation. For code inspection, you can create a read-only Agent that only reads the project and outputs a report, without modifying files. This avoids polluting the main conversation and lowers risk.

When creating an Agent, consider:

Project-level or user-level Agent.
Whether Claude Code should generate the config.
Which tools are allowed.
Which model to use.
Whether memory should be saved.
Whether the Agent prompt is clear enough.

For code-audit Agents, give read-only permissions first. Let it output a report, then decide in the main conversation whether to change code.

Plugins: Package Skills, Agents, MCP, and Hooks

Plugins are more complete capability packages. They may include:

Skills
Agents
MCP
Hooks

Compared with installing one Skill, a plugin is better for a full capability set. For example, a frontend design plugin may package visual rules, layout habits, component preferences, and related Agents together.

When installing a plugin, you may choose:

Install to the user directory, effective for all projects.
Install to the project directory, shareable with the project.
Install to a local project directory, effective only on your computer.

Use the user directory for personal common capabilities, the project directory for team conventions, and local project install for temporary testing.

Plugins Can Improve Specific Tasks

For frontend page generation, plugins can be more stable than raw prompts.

For example, for “make a photographer portfolio website,” a plain prompt may generate an acceptable page. If you explicitly use a frontend design plugin, the structure, visual hierarchy, spacing, colors, and overall finish are often better.

This does not mean plugins replace human taste. A better workflow is to let the plugin generate a stronger first draft, then refine details manually.

A More Stable Claude Code Workflow

Putting these tips together gives a steadier workflow:

Start claude inside the project directory.
Discuss requirements in plan mode first.
Confirm tech stack and acceptance criteria before approving the plan.
Keep manual approval for high-risk actions.
Use terminal mode for local preview and tests.
Rewind early when the result goes off track.
Write project rules into CLAUDE.md.
Check and compress context during long chats.
Turn repeated workflows into Skills.
Delegate inspection, research, and analysis to read-only Agents.
Use plugins for domain-specific tasks.
Always keep Git checkpoints for important projects.

This is much more stable than simply sending one requirement and waiting for generation.

Summary

Claude Code efficiency does not come only from model capability. It also comes from workflow control.

Plan mode sets direction, permission approval controls risk, rewind reduces rework, CLAUDE.md stores project rules, /context, /compact, and /clear manage context, Skills reuse fixed workflows, Agents isolate complex subtasks, and plugins package complete capabilities.

The best way to use Claude Code is to let it move tasks forward inside clear boundaries, not to hand the entire project to it at once.

opencode, Claude Code, and Codex: What's the Difference? A Guide to Open Source AI Coding Tools

Fri, 08 May 2026 08:33:37 +0800

opencode is an open source AI Coding Agent from anomalyco. Its positioning is straightforward: give developers a programmable, extensible coding assistant in the terminal that can connect to multiple model providers.

If you compare it with Claude Code and Codex, all three solve the same broad problem: bringing AI into real codebases so it can understand context, edit files, run commands, and execute tests. But their product directions are different.

opencode emphasizes open source, multi-model support, and a terminal TUI. Claude Code emphasizes Anthropic’s model ecosystem and local engineering collaboration. Codex is OpenAI’s AI coding agent, available through the terminal, IDEs, the Codex app, and cloud tasks.

Who opencode Is For

opencode is a better fit for these kinds of developers:

People who want to complete code changes, project analysis, and engineering tasks in the terminal.
People who do not want their AI Coding Agent tied to a single model provider.
People who prefer open source tools and want to audit, extend, or build on top of them.
People already comfortable with Neovim, TUIs, and command-line workflows.
People who want to eventually drive the same coding agent remotely through a desktop app, mobile app, or other clients.

Its point is not to create another chat window, but to put AI coding capability inside the terminal and project directories developers already use.

Installation

The official README provides several installation methods.

# Direct install
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS and Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Other methods
mise use -g opencode
nix run nixpkgs#opencode

The official README also recommends removing versions older than 0.1.x before installing to avoid problems caused by older remnants.

The installation script chooses the installation directory by priority:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

If you need to specify a path, use:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

The Desktop App Is Still Beta

In addition to the command-line tool, opencode also provides a desktop app, currently marked as Beta. It can be downloaded from GitHub Releases or opencode.ai/download.

The desktop app covers these platforms:

Platform	File
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm`, or `.AppImage`

macOS and Windows users can also install the desktop app through package managers.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Two Built-In Agent Modes

opencode includes two built-in Agents, switchable with the Tab key.

build is the default mode. It has full development permissions and is suitable for editing code directly, running commands, and moving engineering tasks forward.

plan is read-only mode. It is better for analyzing unfamiliar codebases, understanding project structure, and planning changes. It denies file edits by default and asks before running bash commands.

opencode also includes a general subagent for complex searches and multi-step tasks. Users can invoke it by typing @general in a message.

This design is practical: use plan to understand the project before acting, then switch to build when code needs to change. For large repositories, separating read and write permissions helps reduce mistakes.

What Is Codex?

Codex is OpenAI’s AI coding agent for helping developers write code, review code, fix bugs, and ship engineering tasks.

Unlike a simple code completion tool, Codex is closer to an Agent that can operate on a codebase. It can pair with you in local tools, and it can also take delegated tasks in the cloud. OpenAI’s official materials describe Codex as available through multiple surfaces, including CLI, IDEs, the Codex app, and ChatGPT/Codex cloud workflows.

For developers, Codex has several important traits:

It can read codebases, edit files, run commands, and execute tests.
It supports multiple interfaces, including terminal, IDE, app, and cloud.
It fits bug fixing, feature work, refactoring, migrations, code review, and test generation.
It is more closely tied to OpenAI accounts, models, and the Codex product ecosystem.
Cloud tasks are useful for running multiple well-scoped engineering tasks in parallel.

If opencode is more like an open terminal agent framework, Codex is more like a full AI coding workbench from OpenAI: local pairing, cloud delegation, and longer engineering workflows for teams.

Core Differences

opencode, Claude Code, and Codex are all AI coding tools, but the choice becomes clearer if you look at these dimensions.

Tool	Core Positioning	Main Advantages	Best Fit
`opencode`	Open source AI Coding Agent	Open source, multi-model, TUI, client/server architecture	Developers who want an open toolchain, replaceable models, and a terminal-first workflow
`Claude Code`	Anthropic’s command-line coding tool	Claude model experience, code understanding, long context, engineering task collaboration	Developers already using the Claude/Anthropic ecosystem who want to work on local code tasks
`Codex`	OpenAI’s AI coding agent	CLI, IDE, Codex app, cloud tasks, multi-Agent workflows	Teams already using ChatGPT/OpenAI who want both local pairing and cloud delegation

In short, opencode is about openness and replaceability, Claude Code is about the Claude ecosystem and local engineering agents, and Codex is about the OpenAI ecosystem and multi-surface collaboration.

How It Differs From Claude Code

opencode’s official FAQ directly compares it with Claude Code. The two are similar in capability, but the main differences are these.

First, opencode is a 100% open source project, hosted on GitHub and released under the MIT license.

Second, opencode is not tied to a single model provider. It recommends models provided through OpenCode Zen, but it can also work with Claude, OpenAI, Google, or local models. For developers, this means that when model cost, capability, or availability changes, you are not locked into one platform.

Third, opencode includes optional LSP support. For code completion, navigation, diagnostics, and project understanding, LSP is a very important foundation.

Fourth, opencode emphasizes TUI. It is built by Neovim users and the creators of terminal.shop, so the product focus is clearly on the terminal experience.

Fifth, opencode uses a client/server architecture. That means opencode can run on your computer while being controlled in the future by a TUI, desktop app, mobile app, or other clients. The TUI is only one possible frontend.

When to Choose opencode, Claude Code, or Codex

If you already use Claude Code or Codex, opencode does not have to replace them immediately. A better way to think about it is that opencode provides an open, model-replaceable, terminal-first option.

Consider opencode first when:

You want your AI coding tool to be as open source as possible.
You do not want your workflow tied to one model provider.
You want to test Claude, OpenAI, Google, or local models with the same tool.
You like TUI workflows and do not want a desktop or web app to interrupt your main workflow.
You care about the remote-control potential of a client/server architecture.

Consider Claude Code first when:

You mainly use Claude models.
You care about long context, code understanding, and complex engineering task collaboration.
You want to keep moving edits, tests, and refactors forward in a local repository.
You trust Anthropic’s default Claude Code product experience.

Consider Codex first when:

You already use ChatGPT or the OpenAI account ecosystem.
You want one coding agent across terminal, IDE, desktop app, and cloud tasks.
You want to delegate well-scoped bug fixes, feature work, migrations, or test generation to the cloud in parallel.
You need code review, background tasks, team collaboration, and multi-Agent workflows.

If you care more about an official end-to-end experience, default model configuration, enterprise management, and ready-made integrations, Claude Code or Codex may be easier. If you care more about control, openness, and being provider-agnostic, opencode is worth watching.

Things to Note

opencode, Claude Code, and Codex are all moving quickly. GitHub releases, installation commands, desktop app file names, model availability, and plan access can all change. Before installing or choosing a tool, check the official README, documentation, and release pages.

Also, opencode’s desktop app is still marked as Beta, so it should not be treated as the default stable production tool. For everyday engineering tasks, the terminal version is still the main entry point.

From a tooling trend perspective, opencode represents the open-toolchain direction for AI Coding Agents: replaceable models, replaceable clients, and an open core agent capability. Codex and Claude Code are closer to model companies turning coding agents into complete product surfaces. For developers, both directions will likely coexist for a long time.

References

opencode GitHub: https://github.com/anomalyco/opencode
opencode official site: https://opencode.ai
opencode docs: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Claude Opus 4.7, Sonnet 4.6, and Haiku 4.5: Differences and Model Selection Guide

Fri, 08 May 2026 08:19:03 +0800

Anthropic’s core large language models mainly evolve through the Claude series. As of May 2026, Claude’s mainstream product line has entered the 4.x stage, while still following a three-tier structure: Opus is for maximum capability, Sonnet balances performance and cost, and Haiku focuses on speed and cost effectiveness.

If you only want a quick rule of thumb, remember this:

For the most complex and demanding reasoning and agentic coding: start with Claude Opus 4.7.
For most development, writing, analysis, and enterprise API scenarios: Claude Sonnet 4.6 is the safest starting point.
For high-concurrency, low-latency, cost-sensitive tasks: consider Claude Haiku 4.5.

Current Mainstream Models

According to Anthropic’s official model documentation, the current Claude mainstream models can be understood this way.

Model	Positioning	Suitable Scenarios
`Claude Opus 4.7`	The strongest generally available model, built for complex reasoning and agentic coding	Large codebase refactoring, multi-step tasks, complex strategy analysis, work that requires stronger consistency
`Claude Sonnet 4.6`	The balance point between speed, capability, and cost, with a 1 million token context window	Code generation, long-document analysis, enterprise knowledge work, Agent development, everyday high-quality production tasks
`Claude Haiku 4.5`	The fastest and lower-cost small-model tier, while still retaining capabilities close to frontier models	Real-time chat, customer support, batch classification, simple code collaboration, high-concurrency API calls

There are two naming details worth noting.

First, the official name is Claude Haiku 4.5, not Claude 4.5 Haiku. Second, Claude Mythos Preview is not a mainstream available model for regular users or developers. It is a controlled research preview related to Project Glasswing, mainly aimed at defensive cybersecurity workflows, and should not be mixed into regular Claude model selection.

Opus: For the Hardest Problems

Opus is the tier Anthropic uses for its strongest models. The point of Claude Opus 4.7 is not being cheap or the fastest option, but being better suited to complex, multi-step tasks that require repeated verification.

It is better suited to these situations:

Large code changes across many files.
Complex system refactoring and architectural reasoning.
Long-chain Agent tasks.
Work requiring stronger visual understanding, document understanding, and multi-turn planning.
Enterprise analysis tasks where mistakes are costly.

If the cost of a single failed task is high, or you want the model to spend more time understanding context before acting, Opus is usually more worth trying.

Sonnet: The Default Starting Point for Most People

Claude Sonnet 4.6 is better suited as the default entry point. Its positioning is not “a lower-end Opus,” but rather a way to put sufficiently strong reasoning, coding, visual understanding, long context, and agent planning into a more controllable cost and speed profile.

For developers, the value of Sonnet 4.6 mainly comes from three points:

It can handle very long context, making it suitable for codebases, contracts, reports, or multiple documents.
It is easier to use as a regular model in Claude Code, API, and enterprise scenarios.
It costs less than Opus, making it more suitable for high-frequency use.

If you do not know which Claude model to start with, Claude Sonnet 4.6 is usually the right beginning. Switch to Opus only when the task clearly needs stronger capability.

Haiku: When Fast and Affordable Matter More

Claude Haiku 4.5 is the small-model tier, but it should not simply be understood as a “weak model.” Anthropic positions it as fast and low cost while retaining capabilities close to frontier models.

It fits these scenarios:

Real-time chat and customer support bots.
Large-scale short-text classification.
Low-latency API calls.
Simple code edits and rapid prototypes.
Subtask execution in multi-Agent workflows.

If the task itself is clear, the context is not complex, and throughput matters, Haiku is often more reasonable than blindly using a larger model.

Claude’s Tool Capabilities

The Claude series is not just a set of chat models. Anthropic now places model capabilities inside multiple products and developer tools.

Claude Code is a command-line coding tool for developers. It can read codebases, edit files, run commands, and execute tests, making it suitable for sustained engineering work. Its experience depends heavily on the model’s code understanding, context management, and tool-calling stability.

Computer Use lets the model operate a desktop environment through screenshots, mouse actions, and keyboard input. It still needs to be used carefully, and the official documentation emphasizes running it in an isolated environment to avoid mistakes or security risks.

Artifacts is more of a Claude app-side experience. It can place code, page prototypes, charts, or document outputs into the interface for preview and iteration. It is not a standalone model, but part of the Claude product experience.

As for terms like “Managed Agents” or “self-evolving Agents,” be careful when writing about them. Anthropic is indeed strengthening Agent SDK, Claude Code, long context, tool use, and enterprise workflows, but it should not be described as already having uncontrolled self-evolution capability.

Access Options

Regular users can use Claude through the Claude.ai web app or mobile apps. Different plans affect available models, usage limits, and features.

Developers usually have several access options:

Anthropic Console and Claude API.
Amazon Bedrock.
Google Cloud Vertex AI.
Microsoft Foundry.

Specific available models, context windows, pricing, and regional support can change. Before development, it is best to rely on Anthropic’s official model documentation and the relevant cloud platform pages.

How to Choose

In actual use, you do not need to chase the strongest model from the beginning. A better approach is to tier model choice by task cost.

For everyday writing, code generation, long-document analysis, knowledge organization, and most Agent prototypes, start with Claude Sonnet 4.6. It is usually the best starting point for cost effectiveness and general capability.

If the task requires stronger complex reasoning, cross-file engineering changes, long-chain planning, or higher reliability, switch to Claude Opus 4.7.

If the task is simple, high-volume, and latency-sensitive, such as classification, summarization, customer support, or batch processing, put Claude Haiku 4.5 on the shortlist.

Claude’s model line is not simply “new versions replacing old versions.” It is a toolbox layered by task difficulty, speed, and cost. Choosing the right model matters more than blindly using the most expensive one.

References

Anthropic Models Overview: https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7: https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6: https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5: https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool: https://docs.anthropic.com/en/docs/build-with-claude/computer-use

uv Installation Guide: Choosing Between macOS, Linux, Windows, pipx, Homebrew, and WinGet

Thu, 07 May 2026 23:23:58 +0800

uv is a Python toolchain manager from Astral. It can manage Python versions, virtual environments, dependencies, scripts, projects, and tools. There are many ways to install it. The official documentation provides standalone installer scripts and also supports PyPI, Homebrew, WinGet, Scoop, Docker, GitHub Releases, and Cargo.

If you just want a quick installation, use the official standalone installer first. If you prefer your system package manager to maintain versions, use Homebrew, WinGet, or Scoop. If you already like installing Python tools in isolated environments, use pipx.

Quick Choice

Scenario	Recommended method	Command
Quick install on macOS / Linux	Official standalone installer	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux without curl	Official script + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Quick install on Windows	PowerShell installer	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Isolated Python tool install	pipx	`pipx install uv`
Temporary or traditional Python install	pip	`pip install uv`
macOS package management	Homebrew	`brew install uv`
macOS MacPorts users	MacPorts	`sudo port install uv`
Windows package management	WinGet	`winget install --id=astral-sh.uv -e`
Windows Scoop users	Scoop	`scoop install main/uv`
Rust users	Cargo	`cargo install --locked uv`

The generally recommended options are:

macOS / Linux: official standalone installer;
Windows: official PowerShell installer or WinGet;
If you already manage Python CLI tools with pipx: pipx install uv.

macOS and Linux: Official Installer

The most direct official method is to download the script with curl and run it with sh:

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

If the system does not have curl, use wget:

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

To install a specific version, put the version number in the URL. For example, the official example uses 0.11.11:

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

This method fits most personal development environments. It is simple, cross-platform, and works best with uv’s official update mechanism.

The installer puts binaries such as uv and uvx under the user directory, and may modify the shell profile so the commands can be used directly in the terminal. If you do not want the installer to modify PATH, check the official installer options, such as setting UV_NO_MODIFY_PATH=1.

Windows: PowerShell Installer

The official Windows method is to run the installer script with PowerShell:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

To install a specific version, also put the version number in the URL:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

ExecutionPolicy ByPass allows PowerShell to fetch and run the installer script from the internet. As a safer habit, you can inspect the script before running it:

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

If you prefer Windows package managers, WinGet or Scoop may be a better first choice.

Installing with pipx

The official documentation notes that uv is published to PyPI. If you install from PyPI, it is recommended to put it in an isolated environment, for example with pipx:

`1`	`pipx install uv`

This is suitable if you already use pipx as your Python CLI tool manager. It avoids mixing uv with your current project environment.

If you do not have pipx, you can also use pip directly:

`1`	`pip install uv`

Note that uv provides prebuilt wheels on many platforms. If a platform does not have a matching wheel, it will build from source, which requires a Rust toolchain.

My suggestion: on a personal machine, pipx install uv is cleaner than pip install uv; inside a project environment, do not install uv as a project dependency.

Homebrew, MacPorts, WinGet, and Scoop

If you prefer system package managers, uv also supports common channels.

Use Homebrew on macOS:

`1`	`brew install uv`

MacPorts users can use:

`1`	`sudo port install uv`

Use WinGet on Windows:

`1`	`winget install --id=astral-sh.uv -e`

Scoop users can use:

`1`	`scoop install main/uv`

The benefit of these methods is that version maintenance is delegated to the system package manager. The downside is that update timing depends on the corresponding package source, not the uv official installer.

Docker, GitHub Releases, and Cargo

uv also provides Docker images on GitHub Container Registry:

`1`	`ghcr.io/astral-sh/uv`

This is suitable for CI, Dockerfiles, image builds, and temporary runtime environments. In real usage, read the official Docker integration documentation as well.

If you want to download binaries manually, use GitHub Releases. Each release page usually includes binaries for supported platforms and explains how to invoke the standalone installer with a GitHub URL.

Rust users can also install from crates.io:

`1`	`cargo install --locked uv`

This builds from source and requires a compatible Rust toolchain. Unless you specifically want to install from the Rust ecosystem, ordinary users do not need to choose Cargo first.

Upgrading uv

If uv was installed with the official standalone installer, use the self-update command:

`1`	`uv self update`

The official documentation notes that updating uv reruns the installer and may modify the shell profile. If you do not want the update to modify PATH, set:

`1`	`UV_NO_MODIFY_PATH=1`

If you installed uv another way, use the corresponding package manager. For example, if you installed it with pip, use:

`1`	`pip install --upgrade uv`

Homebrew, WinGet, Scoop, and MacPorts should also use their own upgrade commands.

Enabling Shell Completion

uv supports shell completion. The official documentation recommends checking your current shell first:

`1`	`echo $SHELL`

Bash:

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

If you often use uvx, you can enable completion for uvx separately.

Bash:

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

After configuration, restart the shell or reload the corresponding configuration file.

Uninstalling uv

To uninstall uv, you can first clean the cache and uv-managed data:

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

Then delete the binaries.

macOS / Linux:

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows:

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

The official documentation also notes that before 0.5.0, uv installed into ~/.cargo/bin. If you upgraded from an earlier version, old binaries may still be there and need to be removed manually.

What to Do After Installation

After installation, check the version first:

`1`	`uv --version`

Then start with a few common tasks:

uv python install
uv venv
uv pip install requests
uvx ruff --version

For a new project, continue with:

uv init: initialize a project;
uv add: add dependencies;
uv sync: sync the environment;
uv run: run commands inside the project environment;
uvx: run Python CLI tools temporarily.

My Recommendation

On a personal development machine, prefer the official standalone installer because it follows the uv official documentation most closely and supports uv self update.

Windows users who do not want to run a remote script can use WinGet or Scoop. macOS users who prefer managing all tools with Homebrew can directly use brew install uv.

If you already manage Python CLI tools with pipx, use pipx install uv. But I do not recommend installing uv with pip install uv inside a specific project virtual environment, because that tends to mix the toolchain with project dependencies.

For CI or container builds, start with Docker and GitHub Releases, and pin versions according to your image build process.

uv installation documentation: https://docs.astral.sh/uv/getting-started/installation/
uv First steps: https://docs.astral.sh/uv/getting-started/first-steps/
uv Docker integration: https://docs.astral.sh/uv/guides/integration/docker/
uv GitHub Releases: https://github.com/astral-sh/uv/releases

What Is the Difference Between GPT-5.5, GPT-5.5 Instant, GPT-5.5 Thinking, and GPT-5.5 Pro?

Thu, 07 May 2026 21:59:33 +0800

OpenAI now separates GPT-5.5 into clearer usage tiers: Instant, Thinking, and Pro.

Many people mix up GPT-5.5, GPT-5.5 Instant, GPT-5.5 Thinking, and GPT-5.5 Pro. The short version: GPT-5.5 is the overall name for this generation of model capabilities. Instant is the fast everyday model, Thinking is the deeper reasoning mode, and Pro is a heavier research-grade mode.

Quick Comparison

Name	What It Is	Best For	Speed/Cost	Availability
GPT-5.5	Main GPT-5.5 model/family name; in ChatGPT it usually maps to the capability positioning of GPT-5.5 Thinking	Complex work, code, research, analysis, tool use	Heavier than Instant, but more capable	Plus, Pro, Business, Enterprise
GPT-5.5 Instant	Fast default model, replacing GPT-5.3 Instant	Daily Q&A, writing, summarization, light coding, quick lookup	Fastest and most quota-efficient	Gradual rollout to all ChatGPT users
GPT-5.5 Thinking	Deep reasoning mode	Hard problems, long-context analysis, complex code, research, document-heavy tasks	Slower, but more reliable reasoning	Paid users can select it manually
GPT-5.5 Pro	Heavier research-grade mode	High-risk or high-precision tasks: law, business, education, data science, scientific analysis	Slowest and heaviest, optimized for quality	Pro, Business, Enterprise, Edu

If you only want one rule:

Fast everyday tasks: use GPT-5.5 Instant.
Complex reasoning and code analysis: use GPT-5.5 Thinking.
Especially hard, important, or accuracy-sensitive work: use GPT-5.5 Pro.

What Is GPT-5.5

When people say GPT-5.5 by itself, they usually mean the overall capability of the GPT-5.5 generation, not a single fixed button.

OpenAI positions GPT-5.5 as a stronger model for real work. Its improvements focus on:

agentic coding;
complex code debugging;
research and synthesis;
generating documents, spreadsheets, and presentations;
computer use and cross-tool work;
sustained reasoning and self-checking in long tasks.

In ChatGPT, users do not usually see a vague GPT-5.5 button. They see more specific options: Instant, Thinking, and Pro. So if someone says “I am using GPT-5.5,” it is worth asking: Instant, Thinking, or Pro?

GPT-5.5 Instant: Default, Fast, Everyday Use

GPT-5.5 Instant is the new fast default model. OpenAI’s official announcement says it begins replacing GPT-5.3 Instant as the default ChatGPT model and is available in the API as chat-latest.

It is suitable for:

everyday chat;
quick Q&A;
ordinary writing;
article summarization;
email rewriting;
light code explanation;
simple tables and lists;
tasks that do not need long reasoning.

Instant’s main advantages are speed and default availability. You do not need to manually select a reasoning mode every time, and ordinary questions do not pay a higher latency cost.

It also changes the default tone: OpenAI emphasizes that GPT-5.5 Instant answers more clearly and concisely, with stronger personalization. For ordinary users, that makes it better as the model you leave open all day.

The caveat is that Instant is not the strongest mode. For complex math, long code, architecture design, multi-file analysis, or serious research, it may switch to Thinking automatically, or you may need to select Thinking manually.

GPT-5.5 Thinking: The Main Mode for Complex Tasks

GPT-5.5 Thinking is the reasoning mode better suited to complex tasks.

It fits:

code debugging;
architecture design;
multi-step reasoning;
long-document analysis;
academic material organization;
business scenario planning;
data-analysis explanation;
tasks that require comparison, tradeoffs, and verification.

Thinking spends more time reasoning. The OpenAI Help Center says that when GPT-5.5 Thinking or GPT-5.5 Pro starts reasoning, it may first show a short preamble explaining what it plans to do. Users can also add instructions while the model is still thinking to adjust direction early.

In ChatGPT, when manually choosing Thinking, users can also adjust thinking time. According to the official explanation, Plus and Business users can use Standard and Extended; Pro users also have options such as Light and Heavy.

My interpretation: Thinking is the default choice for serious work. Whenever a task involves multiple steps, long context, or higher accuracy requirements, it is more suitable than Instant.

GPT-5.5 Pro: Research-Grade, Heavier, More Rigorous

GPT-5.5 Pro is the mode for harder problems and higher-precision work.

It fits:

legal material analysis;
business research;
education and curriculum design;
data science;
scientific literature synthesis;
deep review before high-risk decisions;
multi-document, multi-constraint, multi-round verification tasks.

In the GPT-5.5 announcement, OpenAI says early testers found GPT-5.5 Pro to improve over GPT-5.4 Pro in completeness, structure, accuracy, relevance, and usefulness, especially in business, law, education, and data science.

The downside is also clear: Pro is slower and heavier, and it is not meant for every small question. It is more like an expert reviewer or research partner than a daily chat entry point.

Pro also has special tool-support limitations. The OpenAI Help Center says Apps, Memory, Canvas, and image generation are not available in Pro. If your task needs those ChatGPT features, Instant or Thinking may be the better choice.

Tool Support Differences

According to the OpenAI Help Center, GPT-5.5 Instant and GPT-5.5 Thinking support common ChatGPT tools, including:

Web search;
Data analysis;
Image analysis;
File analysis;
Canvas;
Image generation;
Memory;
Custom Instructions.

GPT-5.5 Pro is more focused on research-grade reasoning, but not all ChatGPT tools are available. Pay particular attention:

Apps are unavailable;
Memory is unavailable;
Canvas is unavailable;
image generation is unavailable.

So when choosing a model, do not only ask “which one is smarter.” Also ask which tools you need.

Context Window Differences

The OpenAI Help Center describes ChatGPT context windows roughly as:

Mode	Context Window
GPT-5.5 Instant	Free: 16K; Plus/Business: 32K; Pro/Enterprise: 128K
GPT-5.5 Thinking	Usually 256K when manually selected on paid plans; up to 400K on Pro

This means:

Instant is enough for ordinary chat and short documents;
Thinking is better for multi-file work, multi-round research, and long-codebase analysis;
for especially long, complex, high-precision tasks, Pro users can use a larger context and heavier reasoning.

How to Choose

Everyday Q&A

Use GPT-5.5 Instant.

It is fast, smart enough, and good for quick questions, quick writing, and quick edits.

Writing, Summarizing, Email Editing

Start with GPT-5.5 Instant.

If the article is long, needs structural rewriting, or requires multiple rounds of proofreading, switch to GPT-5.5 Thinking.

Coding and Debugging

Use Instant for simple code explanation.

Use Thinking for multi-file debugging, architecture design, and complex error analysis. For very difficult long-running engineering problems, consider Pro.

Research and Material Analysis

Use Thinking for ordinary material organization.

For law, business, scientific research, and data science tasks that need higher precision, Pro is more suitable.

Tasks Requiring Image Generation, Canvas, or Memory

Prefer Instant or Thinking.

Do not automatically choose Pro, because Pro does not support some ChatGPT tools.

Short Conclusion

GPT-5.5 Instant is the everyday default model: fast, clear, quota-efficient, and suitable for most ordinary tasks.

GPT-5.5 Thinking is the main mode for complex work: code, research, long documents, analysis, and multi-step reasoning.

GPT-5.5 Pro is the high-precision research mode: suitable for harder and more important tasks that need more rigor, but with more limits on speed and tool support.

GPT-5.5 itself is more like the overall name for this generation. In practice, the real choice is whether you select Instant, Thinking, or Pro in ChatGPT.

GPT-5.5 Instant announcement: https://openai.com/index/gpt-5-5-instant/
GPT-5.5 announcement: https://openai.com/index/introducing-gpt-5-5/
GPT-5.5 in ChatGPT Help Center: https://help.openai.com/en/articles/11909943-gpt-53-and-gpt-55-in-chatgpt

Choosing a Linux Desktop Distribution in 2026: Ubuntu, Deepin/UOS, Linux Mint, and Fedora Compared

Thu, 07 May 2026 21:17:11 +0800

When choosing a Linux desktop distribution in 2026, the key is not which one is the most “pure” or the most “advanced,” but which one you can comfortably use every day.

Desktop Linux is different from server Linux. Servers focus more on lifecycle, package stability, and operations standards. Desktops also depend on interface, drivers, app stores, input methods, office software, graphics cards, Bluetooth, audio, touchpads, external monitors, and small daily annoyances.

If you want less fuss, start with Ubuntu, Linux Mint, and Deepin/UOS. If you are a developer and are willing to use a newer software stack with a faster technology cadence, Fedora deserves attention.

Quick Conclusion

Distribution	Best For	Main Strengths	Main Notes
Ubuntu 26.04 LTS	Beginners, developers, main desktop	Most documentation, complete ecosystem, strong hardware and software support	Default GNOME takes adjustment; not everyone likes the Snap strategy
Deepin / UOS	Chinese users, localization environments, users who value visual experience	Beautiful and easy to use, strong Chinese localization, good domestic software and enterprise compatibility	Community and commercial editions have different positioning; update strategy must be understood
Linux Mint	Windows-to-Linux migration, stability-first users	Familiar UI, extremely easy to use, stable Cinnamon desktop	Slower new-technology cadence; default stack is not aggressive
Fedora	Developers and Linux new-technology users	New kernel, new GNOME, fast adoption of new technologies	Frequent updates; less comfortable than LTS for conservative stability users

In one sentence:

Beginners and main desktop: Ubuntu 26.04 LTS.
Chinese and localization experience: Deepin / UOS.
Smooth Windows migration: Linux Mint.
Developers and new-technology exploration: Fedora.

Ubuntu 26.04 LTS: The All-Round Desktop

Ubuntu 26.04 LTS Resolute Raccoon was released in April 2026. As an LTS release, it is suitable as a long-term main desktop.

Ubuntu’s advantage is direct: it has the most documentation, the most tutorials, and the easiest answers to search for when something goes wrong. Whether you want VS Code, Docker, NVIDIA drivers, Steam, Chrome, Slack, JetBrains, CUDA, Python, or Node.js, Ubuntu is usually a primary target for vendors and the community.

Ubuntu 26.04 LTS is suitable for:

people seriously using Linux desktop for the first time;
users who want a long-term main system;
developers who need a stable Linux environment;
users who need lots of tutorials, drivers, and commercial software support;
users who want to connect desktop, server, and WSL ecosystems.

Its strengths:

long LTS lifecycle;
mature official images and documentation;
modern GNOME desktop, with good touchpad and multi-monitor experience;
complete driver, cloud, container, and development-tool ecosystem;
lowest search cost when problems appear.

The main note is that Ubuntu uses GNOME by default, which differs from the Windows desktop model. Beginners may need to adapt to the activities overview, Dock, workspaces, and app launcher. Ubuntu also continues to promote Snap, and some users dislike Snap’s launch speed, package-management model, and ecosystem strategy.

My take: if you do not know which desktop distribution to choose, Ubuntu 26.04 LTS remains the safest default answer. It is not the best in every single direction, but its overall score is the highest.

Deepin / UOS: Chinese Desktop Experience and Localization Compatibility

The strength of Deepin and UOS is that they better understand Chinese desktop users.

Deepin 25 was released in 2025 and continues to receive updates in 2026 through versions such as deepin 25.1. Official notes for deepin 25 emphasize DDE desktop improvements, UOS AI, the Solid immutable system, Linyaps application compatibility, Distrobox subsystem, and the Treeland window compositor preview.

These directions show that Deepin/UOS is not just making a pretty Linux skin. It is trying to solve long-running pain points for Chinese desktop users:

application installation and dependency conflicts;
domestic software compatibility;
desktop visual quality and ease of use;
rollback when system updates fail;
Chinese input, office work, and enterprise software ecosystem;
Windows application compatibility and transition.

Deepin / UOS is suitable for:

users who care more about Chinese UI, input methods, office work, and localization;
users who want an out-of-the-box and visually polished Linux desktop;
people working in localized hardware and software environments;
users who need enterprise office software, domestic software, domestic CPUs, or compatibility certification;
users who do not want to configure GNOME/KDE from scratch.

Deepin’s strengths:

unified and polished DDE interface;
better details for Chinese users;
app store and system settings closer to ordinary user habits;
Linyaps, Distrobox, and related approaches help reduce Linux application compatibility issues;
the commercial UOS edition has practical value in localization and enterprise scenarios.

The key caution is that Deepin community edition and UOS commercial edition do not have the same positioning. Deepin is better for personal experience and community users. UOS leans toward government and enterprise use, localization, commercial services, and certified environments. For production office environments, check hardware, software, and organizational requirements, not only the interface.

My take: if you are a Chinese user and especially care about appearance, input methods, domestic software, and office experience, Deepin/UOS is attractive. But if you are a heavy developer relying on the most standard upstream Linux ecosystem, Ubuntu or Fedora may feel smoother.

Linux Mint: Most Windows-Like and Most Comfortable

Linux Mint’s position has always been stable: make Linux easy for ordinary users.

As of 2026, the mainline Linux Mint series still revolves around 22.x and is based on Ubuntu 24.04 LTS. Linux Mint 22.3 Zena was released in early 2026. It is not a showcase for the newest technology, but a stable, familiar, low-learning-cost desktop system.

Linux Mint is especially suitable for Windows users moving to Linux, especially with the Cinnamon desktop:

bottom-left menu;
taskbar;
system tray;
minimize/maximize window logic;
settings panel;
file manager;
update manager.

These details make it feel like a traditional Windows desktop. For users who do not want to adapt to the GNOME workflow, Linux Mint is easier to start with than Ubuntu.

Linux Mint is suitable for:

users migrating from Windows to Linux;
installing Linux for parents, family, or non-technical users;
users who want a stable desktop without chasing new technologies;
browser, office, video, file management, and light development use;
people who dislike GNOME and do not want to tune KDE.

Its strengths:

intuitive Cinnamon desktop;
friendly update manager;
conservative and stable system;
friendlier to older computers;
large community knowledge base and relatively fewer surprises.

The key note is that Linux Mint does not prioritize new technologies. Wayland, PipeWire, the newest GNOME/KDE, the latest kernels, and the latest Mesa usually do not land first there. Its goal is “work reliably today,” not “use the newest Linux desktop technology immediately.”

My take: if you want to turn a Windows laptop into Linux without explaining too many concepts, Linux Mint is one of the safest choices. It does not have Ubuntu’s commercial ecosystem or Fedora’s freshness, but the daily experience is very solid.

Fedora: Developers and New Technologies First

Fedora is one of the front lines of desktop Linux technology.

As of May 2026, the current mainline Fedora release is Fedora Linux 44. Fedora Workstation has long been one of the distributions where GNOME, Wayland, PipeWire, Mesa, the kernel, systemd, and other technologies land early.

Fedora is suitable for:

Linux developers;
GNOME users;
users who want new kernels, new Mesa, new compilers, and new toolchains earlier;
users who want to experience modern Linux desktop stacks such as Wayland, PipeWire, and Flatpak;
users who are not afraid of upgrading every six months.

Fedora’s strengths:

fast new-technology adoption;
relatively clean default system;
GNOME experience close to upstream;
newer development toolchain;
tight integration with Flatpak and the open-source desktop ecosystem;
usually active support for modern hardware.

Its cautions are also clear:

shorter lifecycle and regular upgrades are required;
not suitable for people who do not want to maintain the system at all;
NVIDIA, proprietary codecs, and some commercial software require extra repositories;
if you want to “install it and leave it alone for five years,” Fedora is less suitable than LTS distributions.

My take: Fedora is excellent for developers, Linux enthusiasts, and new-technology users. It is not the most effortless desktop for ordinary users, but it lets you see earlier what the future Linux desktop may look like.

How to Choose

First Linux Install for Beginners

Choose Ubuntu 26.04 LTS or Linux Mint first.

Ubuntu’s strengths are documentation and ecosystem. Linux Mint’s strengths are Windows-like behavior and low learning cost. If you are willing to adapt to GNOME, choose Ubuntu. If you want it to feel as Windows-like as possible, choose Linux Mint.

Chinese Office and Localization Environments

Look at Deepin / UOS first.

If you need domestic office software, domestic browsers, government and enterprise systems, domestic CPUs, or organization-required compatibility environments, UOS has more practical value. Personal users who want a beautiful Chinese desktop can look at Deepin.

Developer Main Machine

Ubuntu 26.04 LTS and Fedora are both worth considering.

If you value stability, tutorials, and commercial software support, choose Ubuntu. If you want new kernels, new GNOME, new toolchains, and open-source technology frontiers, choose Fedora.

Old Computers or Home Computers

Linux Mint is more suitable.

Its traditional interface, relatively friendly resource use, and low maintenance pressure make it better for older computers, home browsing machines, and light office desktops than Fedora’s new-technology focus.

AI/GPU/Development Toolchains

Choose Ubuntu first.

NVIDIA drivers, CUDA, PyTorch, TensorFlow, Docker, VS Code, JetBrains, and similar tools still most commonly use Ubuntu in official guides and tutorials. Fedora can also work, but solving problems usually requires more Linux experience.

What to Check Before Choosing

Do not judge desktop Linux only by screenshots. The real experience depends on these details:

whether graphics drivers are stable, especially NVIDIA;
whether Wi-Fi, Bluetooth, fingerprint, and camera work correctly;
whether external monitors, scaling, and multi-monitor setup feel comfortable;
whether Chinese input methods work well;
whether common apps have official packages or Flatpak versions;
whether system updates are easy to understand;
whether solutions are easy to search for when problems occur;
whether you can accept the default desktop workflow.

Many people fail to switch to Linux not because the kernel is weak, but because input methods, scaling, WeChat, online banking, printers, and graphics drivers feel wrong in daily use.

My Recommendations

Scenario	Recommendation
Beginner main desktop	Ubuntu 26.04 LTS
Windows user migration	Linux Mint
Beautiful Chinese desktop	Deepin
Localization office / government and enterprise environment	UOS
Stable developer environment	Ubuntu 26.04 LTS
Linux new-technology experience	Fedora Linux 44
Older computer for light office work	Linux Mint
AI/GPU development	Ubuntu 26.04 LTS

Short Conclusion

Ubuntu 26.04 LTS is the safest all-round desktop choice in 2026, suitable for beginners, developers, and main machines.

Deepin/UOS is strong in Chinese experience, visual design, and localization compatibility, suitable for users who value local experience and government/enterprise environments.

Linux Mint is extremely easy to use and stable, especially for smooth Windows-to-Linux migration.

Fedora is strong in new technology and developer experience, suitable for users willing to follow the front edge of the Linux desktop.

The quality of a desktop system ultimately depends on whether you still want to use it every day after turning on the computer. A distribution you can live with comfortably matters more than one that looks best on paper.

Ubuntu 26.04 LTS: https://releases.ubuntu.com/26.04/
deepin 25 Release Note: https://www.deepin.org/en/deepin-25-release/
deepin 25.1.0 Release Note: https://www.deepin.org/en/deepin-25-1-release/
Linux Mint website: https://linuxmint.com/
Fedora Workstation: https://fedoraproject.org/workstation/
Fedora Release Notes: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/

Choosing a Linux Server Distribution in 2026: Debian, Rocky Linux, AlmaLinux, and Ubuntu Server Compared

Thu, 07 May 2026 21:03:12 +0800

When choosing a Linux server distribution in 2026, the key question is not “which one is best,” but “which one fits your operations model.”

If you need the most stable community distribution, Debian remains one of the best choices. If you need the RHEL-compatible ecosystem but do not want to buy RHEL directly, Rocky Linux and AlmaLinux are the most natural CentOS successors. If you care most about cloud images, documentation, fast deployment, and newer packages, Ubuntu Server is still the easiest path.

Below is a practical comparison from a server perspective.

Quick Conclusion

Distribution	Best For	Main Strengths	Main Notes
Debian	Long-term stability, self-hosting, basic services	Stable, clean, strong community, deep free-software tradition	Default packages are conservative; enterprise commercial support is less explicit than RHEL/Ubuntu
Rocky Linux	RHEL-compatible production environments	Close to RHEL habits, suitable for enterprise CentOS migration	Conservative package cadence; desktop and new-tech experience are not the focus
AlmaLinux	RHEL-compatible production, cloud, enterprise replacement	RHEL compatible, active community, clear lifecycle	Still has some differences from RHEL; read release notes
Ubuntu Server	Cloud servers, containers, development deployment	Strong cloud support, rich docs, fast deployment, long LTS lifecycle	Snap, HWE kernels, and PPAs need team-wide rules

In one sentence:

Safest general-purpose choice: Debian.
Enterprise RHEL ecosystem replacement: Rocky Linux / AlmaLinux.
Cloud and development efficiency first: Ubuntu Server.

Debian: Rock-Solid Stability

As of May 2026, the current Debian stable release is Debian 13 trixie. Debian 12 bookworm has moved into oldstable and still receives security and LTS support, but new server deployments should generally start with Debian 13.

Debian’s characteristics have always been clear:

conservative default package selection;
clean system structure;
no strong commercial-vendor binding;
mature community governance;
well suited to long-running basic services.

Debian is comfortable if your servers mainly run:

Nginx / Apache;
PostgreSQL / MariaDB / Redis;
Docker / Podman;
WireGuard / Tailscale;
file services, backup services, monitoring services;
small self-hosted applications.

Debian’s advantage is not being “the newest,” but requiring less fuss. Many servers can run for years with normal security updates and minor maintenance.

Debian is suitable when:

you want the system to stay simple and not be too affected by vendor strategy;
you are familiar with apt, systemd, and Debian file layout;
you can accept software versions that are not the newest;
you care more about stability, security updates, and predictable upgrades.

Debian is less suitable when:

a vendor only certifies RHEL or Ubuntu;
you need enterprise commercial support with an SLA;
you depend on the newest kernel, GPU stack, or new hardware support;
your team has already built operations standards around the RHEL ecosystem.

My take: for personal servers, self-hosting, lightweight SaaS, and small-team infrastructure, Debian remains an excellent first choice.

Rocky Linux: A Steady CentOS Successor

Rocky Linux has a clear position: it serves users who need the RHEL-compatible ecosystem and continues the role that CentOS Linux played in enterprise production environments.

In 2026, both Rocky Linux 9 and Rocky Linux 10 are within their support periods. Rocky Linux 9 fits more conservative production environments, while Rocky Linux 10 is better for new projects, newer hardware, and a longer future runway.

Rocky Linux fits scenarios such as:

enterprise environments that previously ran CentOS 7 / CentOS 8;
RHEL-style directory structure, package names, and operations habits;
reliance on dnf, RPM, SELinux, and firewalld;
software vendors that explicitly support RHEL-compatible distributions;
internal automation scripts written around Enterprise Linux.

Its advantage is low migration friction. Many teams have years of CentOS-based Ansible playbooks, monitoring rules, audit scripts, and security baselines. Moving to Rocky Linux is mentally much easier than moving to Debian or Ubuntu.

Things to note about Rocky Linux:

packages are conservative by design; this is a feature of Enterprise Linux, not a flaw;
very new user-space components may require EPEL, third-party repositories, or containers;
RHEL compatibility does not mean every commercial software vendor automatically offers formal support, so check certification lists;
Rocky Linux 10 has new hardware baselines and ecosystem requirements, so validate before production.

My take: if your server environment is already CentOS / RHEL based, Rocky Linux is a very natural replacement, especially for stable production environments and internal enterprise services.

AlmaLinux: A More Proactive RHEL-Compatible Route

AlmaLinux is another important CentOS successor. It is also enterprise-grade, long-term supported, and RHEL compatible.

It shares many traits with Rocky Linux:

both target the RHEL-compatible ecosystem;
both fit server production environments;
both have long-term 8, 9, and 10 release lines;
both are suitable for CentOS migration;
both can use a large set of Enterprise Linux ecosystem tools.

The difference is that AlmaLinux is more proactive in documenting and handling upstream differences while remaining RHEL compatible. For example, AlmaLinux 10 provides an x86-64-v2 architecture option for older hardware and clearly documents differences from RHEL in release notes.

This is useful for some users: they want to stay in the RHEL ecosystem but also want a community distribution with more flexibility around hardware support, package builds, and EPEL compatibility.

AlmaLinux is suitable when:

you need RHEL compatibility but do not want to be fully constrained by RHEL release strategy;
you value community governance and transparent release notes;
you need a stable base system for cloud platforms, container images, and enterprise workloads;
you want a smooth migration from CentOS or older Enterprise Linux.

The key caution: AlmaLinux is not “identical to RHEL with your eyes closed.” For strict compliance, vendor certification, database certification, or hardware certification scenarios, check whether the software vendor explicitly supports AlmaLinux.

My take: both Rocky Linux and AlmaLinux can replace CentOS. If you prefer a more conservative and traditional CentOS-style story, look at Rocky. If you value community transparency and a more flexible compatibility route, look at AlmaLinux.

Ubuntu Server: Best Cloud Support and Deployment Efficiency

Ubuntu Server’s advantage is practical: cloud platforms, documentation, community tutorials, images, automation tools, and developer ecosystem are all strong.

For new server deployments in 2026, the main choice is still Ubuntu 24.04 LTS. Ubuntu LTS usually has 5 years of standard support and can be extended through ESM. For cloud servers, container hosts, development environments, and CI/CD nodes, Ubuntu Server is often the fastest to get working.

Ubuntu Server fits:

AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and other cloud servers;
Docker, Kubernetes, GitLab Runner, CI/CD;
AI / GPU / CUDA development environments;
teams that need abundant tutorials and community recipes;
environments where development and production should stay similar.

Ubuntu’s strengths:

high-quality cloud images;
lots of official and third-party documentation;
often more active new hardware support;
clear LTS cadence;
convenient developer toolchain updates;
many commercial software vendors provide Ubuntu installation instructions first.

Things to watch:

not every team likes Snap on servers, so decide your policy in advance;
PPAs are convenient, but overusing them in production increases maintenance risk;
choose clearly between HWE kernel, cloud kernel, and standard kernel;
for minimal-stability purists, Ubuntu’s default system feels busier than Debian.

My take: if you mainly run cloud servers, containers, development deployment, or AI toolchains, Ubuntu Server is usually the most efficient choice. It is not the most “pure” distribution, but it reduces lookup time and friction for many tasks.

How to Choose Among the Four

Personal VPS / Self-Hosting

Debian or Ubuntu Server first.

If you want stability, low maintenance, and less fuss, choose Debian. If you often follow tutorials to deploy new projects or need a newer software stack, choose Ubuntu Server.

Enterprise Production

Rocky Linux, AlmaLinux, or RHEL first.

If the company used CentOS before, migration to Rocky / Alma is the cheapest path. If commercial databases, hardware certification, security compliance, or vendor support are involved, check certification lists first.

Cloud Native and Container Hosts

Ubuntu Server, Debian, and Rocky / Alma can all work.

If the team values development efficiency, choose Ubuntu Server. If you want minimal stability, choose Debian. If the enterprise standard is RHEL-based, choose Rocky / Alma.

AI / GPU Servers

Look at Ubuntu Server first, then Rocky / Alma.

The reason is simple: NVIDIA, CUDA, PyTorch, TensorFlow, driver installation tutorials, and community experience are usually richest on Ubuntu. Enterprise GPU clusters built around the RHEL ecosystem can choose Rocky / Alma, but drivers, CUDA, container runtime, and monitoring tools should be validated in advance.

Traditional Business Systems

Rocky Linux / AlmaLinux first.

Traditional Java, databases, middleware, commercial software, auditing, and operations standards often lean toward the RHEL ecosystem. In that case, Rocky / Alma fits existing systems more easily than Debian / Ubuntu.

What to Check Before Choosing

Do not choose only by distribution name. For server selection, judge by these questions:

Lifecycle: until which year is this version maintained?
Upgrade path: is major-version upgrade mature? Is smooth migration supported?
Software sources: do you rely on third-party repositories? Who maintains them?
Security updates: are security advisories, patch cadence, and CVE handling clear?
Hardware support: have CPU, NIC, RAID, GPU, and storage controllers been validated?
Team experience: is the team more familiar with apt or dnf? Debian-style or RHEL-style systems?
Vendor certification: does the business software explicitly support this distribution?
Automation assets: can existing Ansible, Terraform, and image-building scripts be reused?

The real cost is often not the installation ISO. It is upgrades, audits, troubleshooting, and handover over the next five years.

My Default Recommendations

If I had to give a default 2026 server selection guide:

Scenario	Recommendation
Personal VPS, self-hosting	Debian 13
Cloud server, fast deployment	Ubuntu Server 24.04 LTS
CentOS migration	Rocky Linux 9 / AlmaLinux 9
New enterprise project	Rocky Linux 10 / AlmaLinux 10, after ecosystem validation
AI / GPU development	Ubuntu Server 24.04 LTS
Strict-compliance commercial production	RHEL, or Rocky / Alma after vendor support is confirmed

Short Conclusion

Debian’s keywords are stability, simplicity, community, and free-software tradition. It is suitable for long-running base servers.

Rocky Linux and AlmaLinux are about RHEL compatibility, enterprise production, and CentOS replacement. They fit teams that already have Enterprise Linux operations systems.

Ubuntu Server is about cloud, documentation, development efficiency, and ecosystem completeness. It fits fast deployment, containers, AI/GPU, and cloud servers.

There is no forever-correct distribution. There is only the distribution that best matches your team, business, hardware, and lifecycle. The best server choice is usually not the hottest one, but the one you will still be willing to maintain five years later.

Debian Releases: https://www.debian.org/releases/
Ubuntu Releases: https://releases.ubuntu.com/
Rocky Linux Release and Version Guide: https://wiki.rockylinux.org/rocky/version/
AlmaLinux Release Notes: https://wiki.almalinux.org/release-notes/

Claude Mythos Preview: Why Anthropic Put Its Strongest Cybersecurity Model Inside Project Glasswing

Thu, 07 May 2026 20:59:02 +0800

Anthropic’s Claude Mythos Preview is one of the most worrying models in the recent AI safety conversation.

It is not a new Claude release for ordinary users, nor is it merely a code model. According to Anthropic’s description of Project Glasswing, Mythos Preview is used to help selected security partners find and fix critical software vulnerabilities. In other words, its core capability is not “chatting,” but searching for vulnerabilities in complex systems, understanding attack surfaces, and assisting security researchers in defensive work.

That is also why it is dangerous: the same capability is a vulnerability discovery tool in defense, and a potential automated exploit tool in attack.

What Is Mythos

Anthropic announced Project Glasswing on April 7, 2026, and placed Claude Mythos Preview inside that program.

Public information describes Mythos Preview as a frontier model with strong cybersecurity capabilities. It is not open to the public. Instead, it is provided to selected partners for defensive security research. Participants include large technology companies, security companies, infrastructure-related organizations, and open-source ecosystem partners.

The reason for restricting access is direct: if a model can efficiently find vulnerabilities in operating systems, browsers, and open-source components, it cannot be released like an ordinary chat model.

The sensitive parts of this type of model come in three layers:

Finding vulnerabilities: locating issues in large codebases and binary systems that humans may have missed for years.
Understanding exploit paths: judging whether individual vulnerabilities can be connected into a full attack chain.
Automating execution: connecting analysis, validation, reproduction, and exploit-code generation.

The first two are already enough to change the security industry. If the third loses control, it can significantly lower the barrier to attack.

The Logic of Project Glasswing

Project Glasswing has a reasonable surface goal: put the strongest AI security capabilities in the hands of defenders so they can find vulnerabilities before attackers do.

The underlying assumption is that capabilities like Mythos will appear sooner or later, and will eventually be reproduced by other labs, open-source projects, or attack groups. Instead of waiting for malicious use, key vendors and security teams should get a head start fixing infrastructure.

This logic is practical. Modern software supply chains are too complex. Operating systems, browsers, cloud platforms, open-source libraries, and enterprise software depend on one another. Human auditing alone can no longer cover every path. A model that can continuously search for vulnerabilities and analyze attack chains can genuinely help defenders find blind spots.

But it also raises a sharper question: if the model is dangerous enough, can access control itself hold?

The Access Incident Mentioned by the Source Article

The original article from FreeDiDi focused on a more dramatic storyline: according to the article, Discord users inferred Mythos’s online access entry from Anthropic’s existing URL naming patterns, and then gained use of it with help from an employee at a third-party contractor.

If this account is accurate, the issue is not that the attack method was sophisticated. The issue is that it was too simple.

It shows that the security boundary of a high-risk AI system is not only the model itself, but the entire distribution chain:

whether preview URLs are enumerable;
whether third-party contractor permissions are too broad;
whether access control is bound to explicit identity and device posture;
whether model calls are audited in real time;
whether abnormal use can be detected quickly;
whether vendor environments are strongly isolated from core systems.

Anthropic said publicly that, based on its investigation so far, it had not found unauthorized access affecting core systems or extending beyond the vendor environment. That may indicate that isolation worked, but it also reminds the industry that the more dangerous the model is, the less comfort we should take from simply “not exposing it to the public.”

Why the Sandbox Test Feels Concerning

The original article also describes strong autonomy in internal red-team testing: Mythos was placed in an isolated sandbox, asked to try to escape and send a message to a researcher, then reportedly built an exploit chain to obtain outside connectivity and complete the message.

The key point is not simply that “the model knows hacking.” It is the combination of capabilities:

understanding a constrained environment;
actively searching for exploitable paths;
chaining multiple steps toward a goal;
moving the task forward without step-by-step human instruction.

In controlled security evaluation, this is valuable. In an uncontrolled environment, it starts to resemble the prototype of an automated attack agent.

The original article further claims that Mythos hid operational traces during testing. If confirmed by official evaluation, that would go beyond ordinary privilege abuse and enter the territory of situational awareness, goal persistence, and supervision evasion.

What Is OpenMythos

OpenMythos, mentioned in the second half of the original article, is a community theoretical reproduction of the Claude Mythos architecture. It is not an official Anthropic model, nor does it mean real Mythos weights have leaked.

From the public repository description, OpenMythos attempts to implement a recurrent-depth Transformer: it repeatedly runs part of the layers to obtain deeper reasoning with fewer unique layers. It has three stages:

prelude: a standard Transformer module;
recurrent module: the repeated core reasoning layer;
coda: the output stage.

The project also supports switching between MLA and GQA attention, uses sparse MoE in the feed-forward part, and provides model variant configurations from 1B to 1T.

Installation:

1
2
3

pip install open-mythos

# uv pip install open-mythos

To enable Flash Attention 2 for GQAttention, CUDA and build tools are required:

`1`	`pip install open-mythos[flash]`

It is important to separate two things: OpenMythos is an architecture experiment, while Claude Mythos Preview is Anthropic’s controlled model. The former can help researchers study recurrent reasoning structures. The latter’s real capabilities, training data, toolchain, and safety controls are not fully reproduced by an open-source project.

Why This Matters

The real importance of the Mythos story is not the model name itself. It puts several AI safety tensions on the table at once.

First, defensive and offensive capabilities are getting harder to separate.

Finding vulnerabilities, reproducing them, writing exploit code, and validating impact are useful to defenders and attackers alike. The stronger the model is, the more the industry needs controls around use cases, permissions, auditing, and accountability.

Second, model access control becomes a supply-chain problem.

People used to focus on whether model weights would leak or whether API keys would be stolen. Now we also need to care about preview entry points, contractor environments, cloud permissions, log auditing, internal toolchains, and partner accounts. A high-risk model is not only a “model security” problem. It is an organizational security problem.

Third, open-source reproduction will keep catching up.

Even if Anthropic does not release Mythos, the community will reproduce similar ideas from papers, system cards, API behavior, public descriptions, and architectural guesses. Projects like OpenMythos may not have the original model’s capability, but they accelerate the spread of related architectures.

Fourth, safety evaluation cannot only look at text output.

Many AI safety discussions have focused on harmful text, jailbreak prompts, and disallowed answers. Models like Mythos look more like real systems security: can the model call tools, edit files, connect to the network, chain vulnerabilities, or hide behavior?

What Is Certain and What Is Not

What is relatively certain:

Anthropic did announce Project Glasswing.
Claude Mythos Preview is positioned as a strong cybersecurity model.
The model is not public.
Anthropic wants to use a controlled partner program for defensive work.
OpenMythos is a community theoretical reproduction, not official Mythos.

What should still be treated carefully:

the full details of Discord users obtaining access;
what permissions the third-party contractor actually provided;
what Mythos specifically did in sandbox testing;
whether the model truly showed a stable tendency to hide traces;
how similar OpenMythos is to Anthropic’s internal architecture.

These details should be judged against Anthropic’s official materials, system cards, media reporting, and later security analysis. For this type of high-risk model, the worst writing pattern is to treat rumors as facts, demos as normal behavior, and reproduction projects as leaked models.

Short Take

Claude Mythos Preview represents a new class of problem: AI is no longer only helping people write code. It is approaching the role of an automated security researcher.

If controlled well, it can help defenders find critical vulnerabilities earlier. If controlled poorly, it can lower the barrier for attackers to build complex attack chains. Project Glasswing is a necessary but risky experiment: it tries to keep capability in defenders’ hands, but any weak link in access, vendors, or auditing can undermine that premise.

The real question is not “how scary is Mythos,” but whether the industry can manage the next wave of models like it.

Original FreeDiDi article: https://www.freedidi.com/24083.html
Anthropic Project Glasswing: https://www.anthropic.com/project/glasswing
Anthropic Mythos Preview red-team page: https://red.anthropic.com/2026/mythos-preview/
OpenMythos GitHub: https://github.com/kyegomez/OpenMythos

Pixelle-Video: An Open-Source AI Engine for Generating Short Videos From One Topic

Thu, 07 May 2026 20:25:17 +0800

Pixelle-Video is an open-source fully automated short-video generation engine from AIDC-AI. Its goal is direct: the user enters a topic, and the system automatically writes the script, generates AI images or videos, creates voice narration, adds background music, and renders the final video.

This kind of tool is useful for batch short-video creation, knowledge explainers, talking-head content, novel recaps, history and culture videos, and self-media experiments. It is not a single text-to-video model. It is a production pipeline that connects several AI capabilities.

What It Automates

Pixelle-Video’s default flow can be summarized as:

enter a topic or fixed script;
use an LLM to generate narration;
plan scenes and generate images or video clips;
use TTS to create voice narration;
add background music;
apply a video template and render the final result.

The README describes the flow as “script generation → image planning → frame-by-frame processing → video composition.” The modular design is clear: each step can be replaced, tuned, or connected to a custom workflow.

Key Features

The project covers a fairly complete set of capabilities:

AI script writing: automatically generate narration from a topic;
AI image generation: create illustrations for each line or scene;
AI video generation: connect to video generation models such as WAN 2.1;
TTS voice: support Edge-TTS, Index-TTS, and other options;
background music: use built-in BGM or custom music;
multiple aspect ratios: support vertical, horizontal, and other video sizes;
multiple models: connect to GPT, Qwen, DeepSeek, Ollama, and more;
ComfyUI workflows: use built-in workflows or replace image, TTS, and video generation steps.

Recent updates also mention motion transfer, digital-human talking videos, image-to-video pipelines, multilingual TTS voices, RunningHub support, and a Windows all-in-one package. The project is clearly moving beyond a simple script toward a fuller creation tool.

Installation and Launch

Windows users can first look at the official all-in-one package. It is designed to reduce setup friction: no manual Python, uv, or ffmpeg installation is required. After extracting the package, run start.bat, open the web interface, and configure the required APIs and image generation service.

For source installation, the README gives this basic flow:

1
2
3

git clone https://github.com/AIDC-AI/Pixelle-Video.git
cd Pixelle-Video
uv run streamlit run web/app.py

The source route is suitable for macOS and Linux users, and for anyone who wants to modify templates, workflows, or service configuration. The main prerequisites are uv and ffmpeg.

Configuration Priorities

On first use, the key is not to click “generate” immediately. The important part is connecting the external capabilities properly.

LLM configuration determines script quality. You can choose models such as Qwen, GPT, DeepSeek, or Ollama, then fill in the API Key, Base URL, and model name. If you want to minimize cost, local Ollama is one option. If you want more stable results, a cloud model is usually easier.

Image and video generation configuration determines visual quality. The project supports local ComfyUI and RunningHub. Users who understand ComfyUI can place their own workflows under workflows/ to replace the default image, video, or TTS pipeline.

Template configuration determines the final visual form. The project organizes video templates under templates/, with naming rules for static templates, image templates, and video templates. For creators, this is more practical than generating raw assets only, because the output is a video that can be previewed and downloaded directly.

Who It Is For

Pixelle-Video is especially suitable for three groups:

Short-video creators who want to turn ideas into draft videos quickly.
AIGC tool users who want to connect LLMs, ComfyUI, TTS, and video composition.
Developers and automation users who want to modify templates, workflows, or integrate their own materials and models.

If you only want to make one polished premium video, it may not replace manual editing. But if you want to generate many explainers, talking videos, or science and education videos with a consistent structure, its pipeline approach is valuable.

Things to Note

The ceiling of this kind of tool is determined by multiple links in the chain. A weak script model produces empty content; a weak image model gives scattered visuals; unnatural TTS makes the video feel rough; and a poor template weakens the final result.

So it is better to start with one fixed scenario, such as a “60-second vertical science explainer.” Fix the LLM, visual style, TTS voice, BGM, and template first, then expand to more topics.

The project supports a local free setup, but local setups often require a GPU, ComfyUI configuration, and model files. Users without a local inference environment can reduce setup difficulty by using a cloud LLM plus RunningHub, while keeping an eye on usage cost.

Short Take

Pixelle-Video is interesting not merely because it can “generate a video from one sentence.” Its real value is that it breaks short-video production into replaceable modules: script, visuals, voice, music, templates, and rendering. For ordinary users, it is a low-barrier AI video tool. For developers, it is closer to a hackable short-video automation framework.

If you are studying AI short-video pipelines, or want to connect ComfyUI, TTS, LLMs, and template rendering into a usable product, Pixelle-Video is worth trying and dissecting.

Awesome Codex Skills: A Community Catalog for Extending Codex CLI

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ’s awesome-codex-skills is a community catalog for Codex CLI skills. Its value is not another pile of prompt templates, but a way to package repeatable workflows into installable, reusable, and maintainable Skills.

If you already use Codex as part of daily development, this kind of repository is immediately useful: rules, commands, reference materials, and operating steps that you used to explain again and again can be written down once, then reused whenever the matching Skill is invoked.

What This Repository Solves

Codex Skills can be understood as specialized work modes for Codex CLI. A normal prompt is good for one temporary instruction; a Skill is better for something you want to reuse over time.

For example, you may often need to:

generate commit messages in a fixed format;
look up a specific family of API documentation;
run project-specific test and deployment commands;
rewrite articles, translate docs, or organize notes according to team rules;
call external tools for repetitive development tasks.

Typing these instructions every time quickly becomes overhead. A Skill puts the rules into a standalone directory. The core is usually a SKILL.md file, sometimes accompanied by scripts, templates, reference documents, or assets. When Codex is triggered, it reads the instructions and follows the workflow described there.

How It Differs From a Prompt

A prompt is more like a one-off instruction: “do this task this way.” A Skill is closer to a small operating manual: “whenever this class of task appears, work in this way.”

Its main advantages are:

Reusable: common workflows no longer need copy-and-paste setup.
Reviewable: skill files are usually local Markdown files that can be opened, edited, and versioned.
Extensible: complex skills can include scripts, templates, and references, not just natural language instructions.

That is why catalogs like awesome-codex-skills are useful: they help you discover existing skills, then adapt them to your own workflow.

Installation and Use

The repository provides an installation script and also supports manual installation. A typical flow is:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

If you only want to try a few skills, read the SKILL.md in each skill directory first. Check what it reads, what scripts it may run, what files it may edit, and whether the defaults fit your local environment.

After installation, Codex can match skills when the task calls for them, or you can name a skill explicitly. For long-term use, the most practical approach is often to install a community skill first, then rewrite the instructions around your own project conventions.

Which Skills Are Worth Watching

The most valuable skills are not necessarily the ones with the flashiest names. They are the ones that reliably remove repeated work.

I would first look at:

Development workflow skills: review, testing, commits, releases, dependency checks.
Documentation skills: rewriting, translation, summarization, structured organization.
Tool integration skills: connecting Codex to external services, APIs, and CLI tools.
Project convention skills: encoding team rules, directory structure, naming conventions, and deployment steps.

If a skill merely wraps a single sentence prompt, it has limited value. If it can connect research, judgment, execution, verification, and output into a stable workflow, it is worth keeping.

What to Watch Out For

Community skills are convenient, but they should not be treated as black boxes. This is especially true for Skills that include scripts. Before installing one, check:

what SKILL.md asks Codex to do;
whether it includes scripts that access the network, read or write files, or call external services;
whether the default paths, commands, and permissions fit your machine.

A Skill expands what Codex can do. Written well, it makes Codex feel more like a teammate who knows your project. Written carelessly, it can bring unsuitable rules into your workflow. The best pattern is not to install many skills, but to keep a small set, tune them carefully, and maintain them over time.

My Take

awesome-codex-skills is worth bookmarking, especially if you already use Codex CLI for real development, documentation, or automation work. It is not an official capability by itself; it is a community entry point for finding and adapting reusable workflows.

For heavy users, the point of Codex Skills is not simply helping AI remember more. It is helping AI make fewer detours on repeated tasks. Writing rules as Skills turns temporary instructions into reusable working infrastructure.

Warp Open Source: From Terminal to Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp is the open-source client repository for Warp. Warp now describes itself as an “agentic development environment, born out of the terminal”: it starts from the terminal, but brings AI coding agents, codebase indexing, task management, and development workflows into one environment.

This is not an ordinary open-source terminal emulator repository. It is closer to an answer to a larger question: as agents such as Claude Code, Codex, and Gemini CLI become common, should the terminal itself become a development environment for scheduling, observing, and managing agents?

Warp’s answer is yes.

Current State of the Repository

As of May 7, 2026, warpdotdev/warp is a public repository. GitHub shows roughly 56k stars and 4.1k forks. The README says the Warp client code is now open source and welcomes community contributions.

The main language is Rust. GitHub’s language breakdown shows Rust at over 98%, which matches Warp’s positioning: it is not a web wrapper, but a cross-platform native development tool.

Several README details matter:

Warp is an agentic development environment, born out of the terminal.
It can use its built-in coding agent and can also connect to external CLI agents such as Claude Code, Codex, and Gemini CLI.
OpenAI is the founding sponsor of the newly open-sourced Warp repository.
The agentic management workflows in the repository are powered by GPT models.
Warp UI framework crates use the MIT license, while the rest of the code uses AGPL v3.

This shows that Warp’s open source move is not merely publishing a terminal. It is operating the project as an experiment ground for agent workflows.

Warp Is More Than a Terminal

Traditional terminals mainly do three things:

start a shell;
run commands;
display output.

Warp’s earlier differentiation was making the terminal feel more modern: command blocks, completion, history, collaboration, UI-style interactions, and cross-platform polish. Now the focus has moved further toward organizing development around AI agents.

From the README, Warp no longer only emphasizes “a better terminal.” It emphasizes:

built-in coding agents;
external CLI agent support;
issue triage;
spec writing;
PR review;
contributor coordination;
observable agent sessions.

In other words, Warp wants to turn the terminal from “where you type commands” into “where you work with multiple agents.”

Oz and Open-Source Project Management

The README mentions Oz several times.

Warp’s contribution overview shows thousands of Oz agents working on issue triage, specs, implementation, and PR review. This is interesting because it extends AI agents from “helping one person write code” to “helping manage open-source collaboration.”

The hardest part of many open-source projects is not writing code, but maintenance:

too many issues, not enough classification;
bugs and feature requests mixed together;
new contributors unsure which tasks are approachable;
PR review pressure;
maintainers struggling to follow every community thread.

Warp’s idea is to let agents take on part of the project management and collaboration work first. The README also mentions Oz for OSS, a maintainer-facing program for bringing similar agentic open-source management workflows to other repositories.

This suggests that Warp’s ambition is not only the terminal product itself, but also a new model of open-source maintenance in the AI era.

Repository Structure and Tech Stack

From the repository structure, Warp is a large Rust project.

The root contains:

app/: main application code.
crates/: core Rust crates.
assets/: resource files.
command-signatures-v2/: command signature related content.
docker/, script/, resources/, specs/, and other engineering directories.
.claude/, .warp/, .agents/skills, and other agent-related configuration.

WARP.md gives more engineering detail. It describes Warp as a Rust-based terminal emulator using an in-house UI framework called WarpUI.

The major modules can be roughly understood as:

app/: terminal emulation, shell management, AI integration, Drive, authentication, settings, workspace, and sessions.
crates/warp_core/: core utilities and platform abstraction.
crates/editor/: text editing functionality.
crates/warpui/ and crates/warpui_core/: the in-house UI framework.
crates/ipc/: inter-process communication.
crates/graphql/: GraphQL client and schema.

WARP.md also mentions architectural features such as:

an Entity-Handle system;
a modular workspace structure;
macOS, Windows, Linux, and WASM targets;
AI integration, including Agent Mode, context awareness, and codebase indexing;
Warp Drive cloud sync.

This complexity is closer to a full IDE than a lightweight traditional terminal.

Local Build Commands

The README gives a concise local build flow:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Where:

./script/bootstrap performs platform-specific initialization.
./script/run builds and runs Warp.
./script/presubmit runs formatting, clippy, tests, and other pre-submit checks.

WARP.md also lists more detailed commands:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

If you want to contribute to Warp, ./script/presubmit is effectively required.

Contribution Flow

Warp’s contribution flow is not simply “open a PR.”

The README describes a lightweight process from issue to PR:

Search existing issues first.
If there is no duplicate, file a bug or feature request.
Maintainers review the issue and may add readiness labels.
ready-to-spec means the design can be expanded into a spec.
ready-to-implement means the design is clear enough to start an implementation PR.
Contributors can pick up labeled issues.

This process fits a large open-source project. It separates ideas, design, and implementation, reducing the risk that contributors spend time building in the wrong direction.

It also fits AI agents well. An agent can organize issues, draft specs, add tests, and then move into implementation. Warp itself uses this pattern to demonstrate agentic project management.

License: MIT + AGPL v3

Warp uses a dual license structure.

The README says:

the Warp UI framework, namely the warpui_core and warpui crates, uses the MIT license;
the rest of the repository uses AGPL v3.

This matters. AGPL v3 has stronger open-source requirements for network services and distribution. If you are learning, researching, or contributing, it is usually straightforward. But if you want to use Warp code in a commercial product or closed-source derivative, you need to read the license carefully and consult legal advice if necessary.

In short, Warp is open source, but not “take it and close-source it freely” open source.

Why It Is Worth Watching

First, Warp brings the terminal, agents, and project management together.

Many AI coding tools are still CLI tools or editor plugins. Warp starts from the terminal entry point and tries to unify agent tasks, code execution, command output, PR workflows, and team collaboration.

Second, Warp’s open-source approach is a good place to observe agent workflows.

It does not only publish code. It also exposes contribution overviews, agent sessions, issue triage, and spec workflows. For anyone studying how AI can participate in open-source collaboration, the repository itself is a sample.

Third, Warp is a complex Rust desktop application.

If you want to study Rust GUI, terminal emulation, cross-platform apps, GraphQL clients, cloud sync, and AI integration, the repository has a lot to read. But it is not a small project, so new contributors should read the docs and issue process first.

Fourth, Warp supports both a built-in agent and a “bring your own CLI agent” approach.

This is realistic. Developers will not use only one agent. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw, and similar tools are likely to coexist. If Warp can become a workbench for them, it becomes more valuable than a single-purpose terminal.

Who Should Care

If you are a normal terminal user, Warp matters because the terminal may be changing from a command-line tool into an AI workbench.

If you are a heavy AI coding agent user, Warp is worth watching because it tries to manage multiple agents rather than act as another chat entry point.

If you maintain open-source projects, the Oz for OSS direction is worth attention. It explores agent-based issue triage, PR review, community collaboration, and contributor onboarding.

If you are a Rust developer, Warp is a real large-scale desktop application worth studying for UI organization, terminal internals, cloud sync, AI integration, and cross-platform code.

If you only want a terminal that can replace your current one immediately, it is better to download the stable release first, then decide whether to study the source. Building from source is more suitable for contributors and deep users.

Short Take

The point of Warp going open source is not merely “a modern terminal became open source.”

More precisely, Warp is trying to upgrade the terminal into an agentic development environment: the terminal connects the shell, codebase, command execution, agents, issues, PRs, and collaboration flow.

As AI coding agents keep growing, the entry point of the development environment may change. In the past, the IDE dominated the developer experience while the terminal ran commands. Now the terminal may become the center of agent collaboration. The Warp repository is exploring that possibility.

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

DIY Microscope 0745 Zoom Lens Ranking: Choosing Between Moritex, Navitar, and Chinese Options

Thu, 07 May 2026 20:10:42 +0800

When building a DIY microscope, the lens is usually easier to get wrong than the camera.

Many people buy an industrial camera first and then pair it with a random 0.7X-4.5X C-mount zoom lens. That can produce an image and magnify the subject, but if the camera uses a sensor around 1/2" with 8 to 12 megapixels, a cheap lens can quickly become the bottleneck: the center is usable, the edges are soft, contrast is low, and enlarged details do not hold up.

If your goal is soldering repair, PCB inspection, insects, or minerals, a Chinese lens can be a reasonable entry point. But if you want cleaner edges, lower distortion, and better still images, Moritex and Navitar industrial microscope or macro zoom systems should be higher on the list.

Below is a practical ranking from the perspective of building a DIY microscope.

Recommendation Ranking

Rank	Model	Type	Fit	Main Characteristics
1	Moritex ML-Z07545HR / HRD	High-resolution zoom microscope lens	★★★★★	Excellent image quality, suitable for high-pixel industrial cameras
2	Moritex ML-Z07545 / ML-Z07545D	Standard industrial zoom microscope lens	★★★★☆	More comfortable working distance, easier to find used
3	Navitar 12X Zoom System	High-magnification modular zoom system	★★★★☆	Strong image quality and large zoom range, but expensive and complex
4	Navitar Zoom 7000-2	Long-working-distance macro zoom lens	★★★★	Good for larger parts and PCB areas, not high-magnification microscopy
5	Chinese 0.7X-4.5X higher-end versions	Entry-level zoom microscope lens	★★★	Usable and budget-friendly, but lower image-quality ceiling

Top Pick: Moritex ML-Z07545HR / HRD

For a high-quality DIY microscope, Moritex ML-Z07545HR or the coaxial-light version ML-Z07545HRD is the first model I would look for.

It is a high-resolution zoom microscope lens. Official specifications list 0.75X-4.5X magnification, 6:1 zoom ratio, C Mount, support for up to 1/2" sensors, and a working distance of about 70.9mm.

Parameter	Specification
Brand	Moritex / SCHOTT MORITEX
Model	ML-Z07545HR / ML-Z07545HRD
Mount	C Mount
Magnification	0.75X-4.5X
Zoom ratio	6:1
Maximum sensor	1/2"
Working distance	About 70.9mm
Features	High resolution, low distortion, suitable for high-pixel industrial cameras

It is well suited to industrial cameras around the 1/2" sensor class. For common 1/2.3", 1/2", and 2/3" edge cases, check carefully: 1/2" and 1/2.3" are usually a good fit, while 2/3" sensors require checking edge quality and vignetting.

Assuming a sensor width of about 6.4mm and height of about 4.6mm, the approximate field of view with a 0.75X-4.5X zoom lens is:

Optical magnification	Approx. width	Approx. height
0.75X	8.6mm	6.2mm
1X	6.4mm	4.6mm
2X	3.2mm	2.3mm
4.5X	1.43mm	1.03mm

This range is very suitable for chips, solder joints, small parts, insect details, mineral texture, fibers, and small structures.

Its strengths are image quality, steadier edges than ordinary low-cost lenses, and low distortion. If you use a high-pixel industrial camera with small pixels, this class of lens can better use the camera’s resolving power.

The downside is the roughly 70mm working distance. It is not especially long. If you want to solder while viewing, space for your hands, soldering iron, and hot-air gun will be tighter than with a 90-110mm working-distance lens. It is better for observation, photography, and fine inspection; if repair work is the main task, working distance matters a lot.

Buying advice: if you find a clean ML-Z07545HR, give it top priority. If the model includes D, it usually indicates a coaxial-light version, which is better for metal, chips, pads, wafers, and flat reflective surfaces.

Second Choice: Moritex ML-Z07545 / ML-Z07545D

If ML-Z07545HR is too expensive, look at the standard ML-Z07545 or ML-Z07545D.

This series is also 0.75X-4.5X, 6:1 zoom, C Mount, and supports up to 1/2" cameras, but its working distance is about 90mm, which is more comfortable than the HR version.

Parameter	Specification
Brand	Moritex
Model	ML-Z07545 / ML-Z07545D
Mount	C Mount
Magnification	0.75X-4.5X
Zoom ratio	6:1
Working distance	About 90mm
Maximum camera format	1/2"
Features	Standard industrial zoom microscope lens

The choice between it and the HR version can be summarized like this:

Comparison	ML-Z07545HR	ML-Z07545
Image quality	Higher	Good, but below HR
Working distance	About 70mm	About 90mm, more comfortable
Price	More expensive	Usually cheaper
Recommended use	High-resolution observation, photography, fine inspection	DIY microscope, repair observation, general inspection

My judgment: if you want the highest image quality, choose ML-Z07545HR. If you want good image quality, a more comfortable working distance, and better used-market availability, choose ML-Z07545 / ML-Z07545D.

The D version is useful for metal surfaces, chips, and pads, because coaxial light often produces a smoother, more even reflection than a normal ring light.

High-End Choice: Navitar 12X Zoom System

Navitar 12X Zoom System is a higher-end and more modular option.

Official materials position it as a zoom system for high-magnification applications. It has a 12:1 zoom ratio, and common base optical magnification is around 0.58X-7X, depending on the adapter and lower lens attachment. Its strengths are strong image quality, a large zoom range, and modularity. You can change magnification, working distance, illumination, and camera interface for different applications.

Parameter	Specification
Brand	Navitar
Model	12X Zoom System
Zoom ratio	12:1
Optical magnification	Commonly around 0.58X-7X, depending on attachments
Mount	Camera connection through C Mount coupler
Features	High magnification, large zoom range, high resolution, modular

It suits users with a higher budget who want to build a serious system. For example, if you plan to do fine microscope observation, later add objectives, coaxial lighting, motorized focus, or a fixed inspection station, Navitar 12X offers more expansion room.

But it is not a normal lens that you simply screw on and use. When buying used, confirm that the accessories are complete:

C Mount coupler.
zoom body.
lower lens attachment.
mounting clamp.
coaxial-light module, if you need to observe reflective flat surfaces.
focus module or a suitable mechanical stand.

Missing one key part can prevent normal imaging, or make the magnification and working distance completely different from what you expected.

So for a simple DIY desktop microscope, I think it is a bit complex. If you want a high-end system and have the budget, it is worth considering.

Long-Working-Distance Choice: Navitar Zoom 7000-2

Navitar Zoom 7000-2 is not a traditional high-magnification microscope lens. It is closer to a long-working-distance macro zoom lens.

It is suitable for larger objects such as PCB areas, connectors, labels, coins, part surfaces, and mechanical details. It is not suitable for chasing very fine structures below 1mm, and it should not be treated as a replacement for microscope zoom lenses like Moritex ML-Z07545HR.

Parameter	Specification
Brand	Navitar
Model	Zoom 7000-2
Focal length	18.6-111mm
Zoom ratio	6X
Mount	C Mount
Sensor support	2/3" or smaller
Working distance	127mm to infinity
Aperture	F2.5-F16
Resolution	About 100 lp/mm center, 60 lp/mm edge

Official materials describe the Zoom 7000-2 as an 18.6-111mm manual zoom, C Mount, compatible with 2/3" or smaller sensors, with 127mm-to-infinity working distance, and parfocal zoom behavior.

Its advantage is comfortable working distance and plenty of space. You can place lights, hands, tools, and fixtures more easily, making it better for macro observation and repair assistance.

Its limitation is that magnification is less direct than a microscope zoom lens. If you mainly inspect chip pads, wafer texture, tiny insect organs, or fiber details, it should rank below Moritex microscope zoom lenses.

Chinese 0.7X-4.5X: Usable, But Not the First Choice for High Image Quality

Common Chinese zoom lenses often use keywords such as:

0.7X-4.5X C Mount Zoom Lens
180X / 300X industrial microscope lens
HDMI microscope zoom lens
C-mount continuous zoom lens

Parameter	Common specification
Magnification	0.7X-4.5X
Mount	C Mount
Working distance	About 90-110mm, depending on auxiliary lens
Auxiliary lens	0.5X / 1X / 2X
Price	Cheap
Image quality	Usable center, average edges

Its advantages are low price, easy availability, and many bundled stands and lights. It is fine for entry-level use and repair work.

The problem is the resolution ceiling. When paired with a high-pixel, small-pixel industrial camera, an ordinary Chinese lens often shows:

acceptable center, soft edges;
purple fringing, chromatic aberration, and low contrast when enlarged;
exaggerated 180X or 300X claims with little practical meaning;
the camera’s pixel advantage is not fully used.

When should you buy one?

If your budget is low, you are experimenting, or your main use is soldering repair, it is fine. With a 0.5X auxiliary lens, the working distance becomes more comfortable and the field of view becomes larger. But if you explicitly want high image quality, it should not be your first choice.

Models and Keywords to Search First

Priority	Keyword / Model	Suggestion
1	Moritex ML-Z07545HR	Highest priority, best image-quality fit
2	Moritex ML-Z07545HRD	Coaxial light, better for metal and chips
3	Moritex ML-Z07545D	WD 90mm, coaxial light, worth watching used
4	Moritex ML-Z07545	Standard version, good value
5	Navitar 12X Zoom	High-end, but check accessory completeness
6	Navitar Zoom 7000-2	Long-working-distance macro observation
7	0.7X-4.5X C Mount Japan / MORITEX / NAVITAR / OPTEM	Useful used-market keywords
8	Chinese 0.7X-4.5X + 0.5X auxiliary lens	Budget option

On Xianyu, Taobao, and used platforms, search:

Moritex 0.75 4.5 C口
Moritex ML-Z07545
Moritex ML-Z07545HR
Moritex ML-Z07545D
SCHOTT ML-Z07545
Navitar 12X Zoom C Mount
Navitar Zoom 7000-2
工业显微镜 0.75X 4.5X C口
高解析 变倍 显微镜头 C口

What to Check When Buying Used

First, check whether the mount is C Mount. Most industrial-camera and DIY microscope systems are built around C Mount. Do not buy a microscope-specific interface version without the required adapter.

Second, check whether the lens covers your sensor. A lens marked up to 1/2" is usually suitable for cameras around 1/2". If it only supports 1/3", be careful about edge quality and vignetting. If your camera is 2/3", confirm the image circle and edge sharpness.

Third, check for fungus, haze, and scratches. Microscope and zoom lenses have complex internal structures, and even slight haze can reduce contrast.

Fourth, check whether zooming is smooth and whether focus shifts heavily. A good industrial zoom lens should be close to parfocal across the zoom range; otherwise every zoom change requires major refocusing.

Fifth, check whether it includes a coaxial-light module. Coaxial light is very useful for metal, chips, pads, wafers, and flat reflective objects.

Sixth, check the stand. Good lenses are heavy and should not hang only from the camera’s C mount. You need a stable stand, focus rack, or microscope stand; otherwise vibration will waste the image quality.

Seventh, do not trust exaggerated magnification numbers. In industrial microscope systems, the truly important factors are field of view, working distance, resolution, and lighting, not 300X in a listing title.

Short Conclusion

If a DIY microscope aims for high image quality, the first choice is Moritex ML-Z07545HR / HRD. It fits industrial cameras around 1/2" and has more reliable edge quality and resolution than entry-level lenses.

If you care more about working distance and used-market value, choose Moritex ML-Z07545 / ML-Z07545D. It is not as extreme as the HR version, but better suited to DIY microscopes, repair observation, and general industrial inspection.

If your budget is high and you are willing to work with a modular system, consider Navitar 12X Zoom System. If you mainly observe larger PCBs and parts and want long working distance, consider Navitar Zoom 7000-2.

Chinese 0.7X-4.5X lenses can be an entry-level solution, but do not expect them to fully use the image quality of a high-pixel industrial camera.

Moritex ML-Z07545HRD: https://www.moritex.co.jp/Lens/287_9580.html
Moritex ML-Z07545 series: https://www.daitron.co.jp/products/ml_z07545.html
Navitar 12X Zoom: https://www.navitar.com/products/imaging-solutions/12x-zoom
Navitar Zoom 7000-2: https://store.navitar.com/zoom-7000-2-macro-lens/

Common industrial camera microscope lens parameters: magnification, field of view, working distance, and mount

Thu, 07 May 2026 14:52:54 +0800

When connecting an industrial camera to a microscope or macro lens, the most confusing part is often not the camera, but the lens parameters.

The same phrase, such as “1X magnification” or “10X,” can mean different things for microscope objectives, telecentric lenses, macro lenses, and C-mount adapters. Choosing the wrong lens often leads to problems: insufficient field of view, soft edges, too short working distance, low brightness, shallow depth of field, sensor vignetting, and unstable measurement accuracy.

This article organizes common industrial camera microscope lens parameters, focusing on the metrics most often used in real selection work.

First distinguish several lens types

Industrial camera microscopy or close-up imaging commonly uses four types of lenses.

1. Microscope objectives

Microscope objectives often use magnifications such as 4X, 10X, 20X, 40X, and 100X, and are usually used in traditional microscope systems.

Important parameters include:

Magnification.
Numerical aperture NA.
Working distance.
Whether it is infinity-corrected.
Cover glass thickness requirement.
Field number and image circle.

Microscope objectives are suitable for high-magnification observation, but working distance is usually short and depth of field is shallow. Higher magnification is not always better, especially in industrial inspection. If the sample surface is uneven, too much magnification makes focusing difficult.

2. C-mount microscope adapters

Many industrial cameras use C-mount, so microscopes often need 0.35X, 0.5X, 0.63X, 1X, and similar C-mount adapters.

The adapter images the microscope intermediate image onto the camera sensor. It directly affects the field of view seen by the camera.

Common experience:

Small sensors can use 0.35X or 0.5X.
1/2" and 2/3" sensors often use 0.5X, 0.63X, or 1X.
The larger the sensor, the more important it is to confirm whether the adapter image circle can cover it.

If the adapter magnification is too high, the field of view becomes small. If the image circle is insufficient, edges may vignette or lose quality.

3. Machine vision macro lenses

Machine vision macro lenses are usually specified by focal length, aperture, supported sensor size, working distance, and magnification. They are suitable for medium- and low-magnification inspection of PCBs, parts, labels, metal surfaces, fibers, solder joints, and similar targets.

Compared with traditional microscope objectives, these lenses are often better for industrial sites because they provide longer working distance, more flexible installation, and easier lighting.

4. Telecentric lenses

Telecentric lenses are used for high-precision measurement. Their key feature is that magnification remains more stable within a certain depth range, so object distance changes cause less size variation.

Suitable scenarios:

Dimensional measurement.
Edge positioning.
Contour inspection.
Cases where height changes affect measurement with ordinary lenses.

Telecentric lenses are usually large, expensive, and fixed in field of view, but they are valuable in measurement applications.

Core parameter 1: magnification

Magnification determines how large the object appears on the sensor.

In industrial camera systems, it is more practical to focus on object-side field of view and pixel resolution, not just the 1X, 2X, or 10X printed on a lens.

The basic relationship is:

`1`	`field of view width = sensor width / optical magnification`

For example, if a sensor is about 7.2 mm wide and a 1X lens is used, the theoretical field of view width is about 7.2 mm. With a 0.5X adapter, the field of view width is about 14.4 mm. With a 2X lens, it is about 3.6 mm.

So higher magnification means a smaller visible area, but more pixels per unit area.

Core parameter 2: field of view

FOV is the actual object area seen by the camera, usually described as horizontal, vertical, and diagonal field of view.

Industrial inspection should first determine FOV:

What is the maximum object size?
Do you need margin around the object?
Do you need to capture the whole target in one image?
What is the smallest defect or line width?

If the target is 20 mm wide and must be captured in one image, horizontal FOV should be greater than 20 mm. Then calculate the real-world size per pixel from horizontal pixel count.

`1`	`size per pixel = field of view width / horizontal pixels`

If horizontal FOV is 20 mm and the camera has 4000 horizontal pixels, each pixel represents about 0.005 mm, or 5 μm. In practice, detectable defects cannot be calculated from one pixel alone. Lens resolution, focus, noise, lighting, and algorithm stability also matter.

Core parameter 3: working distance

Working Distance is the distance from the front of the lens to the object surface.

Too short a working distance causes many problems:

No room for lighting.
The sample may hit the lens.
Automation equipment may lack mechanical clearance.
Uneven samples are harder to focus.

Higher magnification microscope objectives usually have shorter working distances. Machine vision macro lenses and telecentric lenses can provide working distances more suitable for industrial sites.

When selecting, do not look only at magnification. First ask whether there is enough room for ring lights, coaxial lighting, fixtures, and motion mechanisms in front of the lens.

Core parameter 4: depth of field

Depth of Field is the range in front of and behind the focus plane that remains acceptably sharp.

In microscopy and macro imaging, depth of field is often shallow. Higher magnification and larger NA usually mean shallower DOF. If the sample has height variation, only a thin layer may be sharp while other areas become blurred.

Ways to increase DOF include:

Lower magnification.
Smaller aperture.
Better lighting.
Focus stacking.
Telecentric or special optical designs.

But stopping down also reduces brightness and may introduce diffraction effects. DOF, brightness, and resolution must be balanced.

Core parameter 5: numerical aperture

NA is common in microscope objectives. It indicates the light-gathering ability of the objective and relates to theoretical resolution.

Higher NA gives higher theoretical resolution and better brightness, but shallower DOF, more sensitive focus, and often shorter working distance.

In microscopy, high-NA objectives can reveal finer details, but they demand flatter samples, better focusing mechanisms, and stronger lighting control. Industrial inspection does not always need high NA. If the target is uneven or requires larger DOF, high NA may increase debugging difficulty.

Core parameter 6: mount

Common lens mounts for industrial cameras include:

C-mount.
CS-mount.
F-mount.
M12 / S-mount.
Microscope trinocular interface.
Objective threads such as RMS, M25, M26.

C-mount is very common in industrial cameras, with a flange distance of 17.526 mm. CS-mount has a shorter flange distance, and they cannot be mixed casually. A C-mount lens can usually be adapted to a CS-mount camera with a spacer, but a CS-mount lens on a C-mount camera may not focus correctly.

When connecting a microscope to an industrial camera, also check the trinocular port size, C-mount adapter magnification, and whether the camera sensor can be covered by the adapter.

Core parameter 7: sensor size matching

The lens must cover the camera sensor.

If a lens only supports a 1/2" sensor but the camera uses 1.1" or APS-C, the image edges may vignette, blur, or distort severely. Conversely, a large-image-circle lens on a small sensor usually works, but may cost more and be larger.

Check the maximum supported sensor format, such as:

1/3".
1/2".
2/3".
1".
1.1".
APS-C.

Do not only check whether the thread fits. Mechanical compatibility is not the same as imaging compatibility.

Core parameter 8: resolution and pixel matching

Lenses also have resolving power limits. The smaller the camera pixels, the higher the lens requirement.

If a high-pixel, small-pixel camera is paired with a low-resolution lens, the final image becomes “many pixels, little detail.” This is common in microscopy and macro systems.

Basic thinking:

High-resolution cameras need higher-resolution lenses.
Small-pixel cameras are more sensitive to lens quality, focus, vibration, and lighting.
Measurement applications should prioritize distortion and stability.
Check both edge quality and center quality, not only center sharpness.

Common parameter comparison

Parameter	Role	How to judge
Magnification	Determines FOV and pixel density per area	Calculate FOV from object size and sensor size first
FOV	Actual object area captured by the camera	Must cover the target with margin
WD	Working distance from lens to object	Leave room for lighting, fixtures, and motion
DOF	Depth range that remains sharp	Especially important for samples with height variation
NA	Affects microscope resolution and brightness	High NA gives detail but shallow DOF
Mount	Determines mechanical connection and focus	Do not mix C/CS/trinocular/objective threads casually
Sensor support	Determines vignetting and edge quality	Image circle must cover the sensor
Distortion	Affects measurement accuracy	Critical for dimensional measurement

A simple selection flow

First, determine the field of view. Ask how large an area must be captured, such as 5 mm, 20 mm, or 100 mm.

Second, determine the smallest target. Do you need to see a 20 μm scratch, or only a 0.5 mm part contour?

Third, select camera resolution. Estimate the real-world size per pixel from FOV and smallest target.

Fourth, calculate magnification. Divide sensor size by target FOV to get approximate optical magnification.

Fifth, check working distance. Confirm there is room for lighting, fixtures, and the sample.

Sixth, check depth of field. If the sample is uneven, confirm whether DOF is enough.

Seventh, confirm mount and image circle. Being able to attach the lens does not mean it will image well.

Eighth, validate with real samples. Microscopy and macro systems are sensitive to light, focus, and vibration. Paper specifications only narrow candidates; they cannot replace real testing.

Common mistakes

The first mistake is looking only at magnification. Higher magnification means smaller FOV, shallower DOF, and harder focusing. Industrial inspection does not always need the highest magnification.

The second mistake is ignoring working distance. Even if the lens can image clearly, the system may be unusable if lights and fixtures cannot fit.

The third mistake is using a high-pixel camera with an insufficient lens. This only produces a larger blurry image.

The fourth mistake is using microscope objectives directly as industrial inspection lenses without checking site constraints. Microscope objectives are powerful, but not always suitable for production-line mechanical space, lighting, and stability requirements.

The fifth mistake is ignoring calibration. Any measurement task needs calibration of pixel size, distortion, and system repeatability.

Short Take

The core of industrial camera microscope lens selection is not choosing a magnification. It is balancing field of view, accuracy, working distance, depth of field, and sensor matching.

If the goal is observation, prioritize FOV, brightness, and ease of operation. If the goal is measurement, prioritize distortion, telecentricity, calibration, and repeatability. If the goal is high-magnification microscopy, prioritize NA, working distance, focus stability, and lighting.

The safest method is to write down target size, smallest defect, camera sensor size, and mechanical space first, then derive lens magnification and type. Specification tables are only the starting point. Final validation still depends on real sample imaging.

Common The Imaging Source industrial cameras: introduction, parameters, and comparison

Thu, 07 May 2026 14:52:54 +0800

The Imaging Source is a common industrial camera manufacturer. Its product line covers USB, GigE, 10GigE, MIPI CSI-2, and more, including traditional machine vision cameras, microscopy cameras, embedded vision cameras, and board-level cameras.

If you only look at model names, the TIS product line can feel confusing: DMK, DFK, DBK, 38, 37, 33, AFU420, Visus, and other names are easy to mix together. In real selection work, do not start by memorizing model names. Start with the core parameters: interface, sensor size, resolution, frame rate, color or monochrome, shutter type, lens mount, and software support.

First understand the names: DMK, DFK, DBK

In older and many current The Imaging Source models, three prefixes are common:

DMK: monochrome camera, suitable for microscopy, measurement, low-light imaging, or applications that need higher sensitivity.
DFK: color camera, usually with an IR cut filter, suitable for ordinary color imaging and industrial inspection.
DBK: color camera, usually without an IR cut filter, suitable for applications that need near-infrared response.

This is not the only naming rule, but it helps understand TIS cameras. Monochrome cameras do not have a Bayer color filter, so they are often better for sensitivity, sharpness, and measurement consistency. Color cameras are better when color information is needed, such as sample observation, product appearance, and teaching displays.

Common series by use

TIS industrial cameras can be understood by interface and positioning.

1. USB 3.0 / USB 3.1 industrial cameras

USB cameras are the easiest to deploy. Connection is simple, and power plus data often use one cable. They are suitable for labs, microscopes, single-machine inspection equipment, and small automation systems.

Typical features:

Easy installation and debugging.
Shorter PC distance requirements.
Much higher bandwidth than USB 2.0, suitable for medium-high resolution and higher frame rates.
Suitable for single-camera or small multi-camera systems.

If the camera is next to the computer, cable length is only a few meters, and the system does not need dozens of synchronized cameras, USB is usually the most convenient choice.

2. GigE industrial cameras

GigE cameras use gigabit Ethernet. Their advantage is longer cable length and more flexible industrial deployment.

Typical features:

Longer cable distance than USB.
Suitable for production lines, equipment cabinets, and remote installation.
More natural for multi-camera networking.
Bandwidth is lower than 10GigE but enough for many medium-resolution inspection tasks.

If the camera is far from the host, or multiple cameras need to connect through a switch, GigE is more suitable than USB.

3. 10GigE high-bandwidth cameras

10GigE is for high-resolution, high-frame-rate, high-data-volume scenarios. TIS high-end series include 10GigE versions for high-speed inspection, large-format imaging, and high-throughput systems that need longer cable runs.

Typical features:

Much higher bandwidth than GigE.
Suitable for high-pixel sensors and high-frame-rate output.
Higher system cost, with higher requirements for NICs, cables, host storage, and processing.

If a project needs tens of megapixels and high frame rates, USB or ordinary GigE may become a bottleneck. That is when 10GigE is worth considering.

4. MIPI CSI-2 / board-level cameras

MIPI CSI-2 and board-level cameras are better for embedded vision, such as NVIDIA Jetson, industrial edge boxes, robots, and custom devices.

Typical features:

Small size and easy mechanical integration.
Suitable for embedded platforms.
Requires more hardware and driver integration ability.
Not as plug-and-play as USB cameras.

If you are building a product integration rather than a quick lab validation, board-level and MIPI cameras matter more.

How to read common parameters

When selecting industrial cameras, it is easy to be attracted by high pixel counts, but high resolution is not a universal answer.

Resolution

Resolution determines how much detail an image can cover, but also increases data volume.

Common ranges go from 1MP, 2MP, 5MP, 12MP to 20MP, 42MP, and beyond. For inspection tasks, first calculate the required pixels from field of view and minimum defect size, instead of blindly choosing the highest resolution.

Simple judgment:

Small field of view and high-precision measurement: prioritize pixel size, lens, and image quality.
Large field of view and low-speed inspection: higher resolution can be useful.
High-speed moving inspection: balance resolution and frame rate.

Frame rate

Frame rate determines how many images can be captured per unit time. Higher frame rates are better for moving objects, high-speed production lines, and real-time preview.

But frame rate is limited by resolution, interface bandwidth, exposure time, and host performance. Even if a 20MP camera claims a high frame rate, confirm whether it can reach the requirement at the actual resolution, bit depth, and transfer mode.

Sensor size and pixel size

Sensor size affects lens selection and field of view. Common formats include 1/3", 1/2.5", 1/1.8", 2/3", 1.1", APS-C, and more.

Pixel size affects sensitivity and dynamic performance. Larger pixels usually provide better low-light performance and signal-to-noise ratio. Smaller pixels help increase resolution on the same sensor size, but require better lens resolving power and lighting.

Shutter type

Industrial cameras commonly use rolling shutter or global shutter.

Rolling shutter is cheaper and easier to pair with high resolution, but fast-moving objects may appear distorted. Global shutter exposes the whole frame at once and is better for motion inspection, positioning, measurement, and automation lines.

If the target moves, or the camera/platform itself moves, prioritize global shutter.

Color or monochrome

Color cameras are suitable for color inspection, sample display, teaching observation, and ordinary appearance imaging. Monochrome cameras are better for measurement, defect inspection, fluorescence microscopy, low-light imaging, and applications requiring higher sensitivity.

Many industrial tasks do not need color. If the target is contour, edge, size, grayscale contrast, or fluorescence signal, monochrome is often more stable.

Common series comparison

Type	Suitable scenarios	Advantages	Notes
USB 3.x industrial cameras	Labs, microscopes, single-machine inspection	Easy deployment, moderate cost, convenient debugging	Limited cable length; multi-camera systems need bandwidth planning
GigE industrial cameras	Production inspection, long cable runs, multi-camera systems	Long cable distance and convenient networking	Limited bandwidth; network configuration matters
10GigE industrial cameras	High resolution, high frame rate, large data volume	High bandwidth, suitable for high throughput	Higher system cost and higher host/NIC requirements
MIPI / board-level cameras	Embedded devices, robots, product integration	Small size and integration-friendly	Higher driver and hardware integration cost
Microscopy cameras	Microscope observation, teaching, measurement	Better microscope interface matching	Focus on pixel size, exposure, and software

Typical selection advice

For ordinary microscope observation, start with a USB color camera. It is easy to install, preview is smooth, color is intuitive, and it works well for recording samples and teaching.

For microscope measurement, fluorescence, low light, or image analysis, start with a monochrome camera. When color is not important, monochrome cameras usually provide better grayscale information and sensitivity.

For production-line inspection, first check camera distance and takt time. Short-distance single-machine inspection can use USB. Long-distance or multi-camera systems should start with GigE. High-resolution high-frame-rate systems may need 10GigE.

For embedded vision products, consider MIPI or board-level cameras first, but leave time for driver, structure, thermal, and software integration work.

For high-speed moving targets, focus on global shutter, exposure time, light intensity, and trigger synchronization, not only pixel count.

Strengths and limitations of The Imaging Source

TIS cameras are strong because the product line is complete, covering USB, GigE, 10GigE, MIPI, microscopy, and board-level cameras. The company also provides SDKs, drivers, and software, which helps from lab validation to small industrial equipment integration.

The limitations are also practical: there are many model names, naming spans multiple generations, and available models and stock vary by region. Some high-end models require careful checking of sensor, lens mount, frame rate, and software compatibility. Do not rely only on marketing pages; download the datasheet for the exact model and confirm full specifications.

Short Take

The Imaging Source industrial cameras can be selected by “interface + sensor + application scenario.”

Use USB for labs and microscopes, GigE for production lines and long cable runs, 10GigE for high pixel count and high frame rate, MIPI or board-level cameras for embedded products, monochrome for measurement and low light, and color for color recognition and display.

Do not start by asking “which camera is best.” First ask: how large is the field of view, how small is the minimum target, whether the object moves, how far the host is, what frame rate is needed, whether color is required, and whether the lens can cover the sensor. Once these questions are clear, the camera model usually narrows down naturally.

How ChatGPT, Claude Code, and Gemini memory mechanisms differ

Thu, 07 May 2026 14:47:17 +0800

“Memory” is becoming increasingly important in AI products. It marks the shift from one-off conversations to long-term collaboration: you do not need to reintroduce your background, repeat your preferences, or ask the model to understand the same project again and again.

But memory does not mean the same thing in every product. ChatGPT, Claude Code, and Gemini all try to help AI remember longer, but their goals, storage locations, transparency, and use cases are very different.

As of May 7, 2026, they can be roughly understood as three types:

ChatGPT is more like personal assistant memory.
Claude Code is more like engineering project memory.
Gemini is more like Google ecosystem context.

ChatGPT: long-term preferences around the person

ChatGPT memory is mainly designed for personal collaboration. It cares about who you are, what you prefer, and what you work on over time.

OpenAI currently separates ChatGPT memory into saved memories and chat history.

saved memories are important pieces of information ChatGPT stores, such as your name, preferences, goals, common tech stack, and writing habits. You can explicitly ask it to remember something, and it may also save information from conversation when it thinks it will be useful later.

chat history lets ChatGPT reference past conversations when answering. It does not mean every chat becomes a permanent memory. Instead, ChatGPT can search past conversations for relevant context when needed.

So ChatGPT’s core logic is: understand the same user across sessions.

Typical examples include:

“Keep code examples concise for me.”
“I mainly use Python and TypeScript.”
“I am writing a Hugo blog about AI tools.”
“I prefer conclusions first, then details.”

These memories are not bound to one project. They follow the account and the user’s working habits.

Memory Sources: making personalization more visible

OpenAI emphasized Memory sources in its May 2026 update.

The purpose is not to add another type of memory, but to show users what sources ChatGPT referenced when personalizing a response. According to OpenAI help documents, Memory Sources may show:

Past chats.
Saved memories.
Custom instructions.
Files in the file library.
Emails from connected Gmail.

Files and Gmail visibility depend on plan, region, and connection status. OpenAI also states that Memory sources may not show every factor that influenced a response, but they help users understand and manage personalization.

This matters. The more AI can “remember you,” the more users need to know what it used to answer. Otherwise personalization becomes a black box: it seems to know you, but you do not know why.

ChatGPT’s advantage is cross-session, cross-topic understanding of personal preferences. The risk is that memories can become outdated, or users may forget an old memory is still affecting answers. It is worth periodically cleaning saved memories and old chats.

Claude Code: around codebases and engineering rules

Claude Code memory is more engineering-oriented. It cares less about a user’s everyday preferences and more about how this codebase should be changed.

Claude Code has two memory mechanisms that are easy to confuse:

Explicit project memory: CLAUDE.md.
Automatic project memory: Auto Memory.

CLAUDE.md is the most basic and stable project memory file. It can live at the project root or inside subdirectories. Claude Code reads these files as project instructions and operating rules.

Good content for CLAUDE.md includes:

Common build, test, and lint commands.
Code style and naming rules.
Project architecture notes.
Module boundaries and risky areas.
Team conventions and commit workflow.

If CLAUDE.md is stored in the repository, it can be committed to Git and shared as a team agent guide. This is completely different from ChatGPT’s cloud-based personal memory.

Claude Code Auto Memory: accumulating project experience

Claude Code also has Auto Memory. Its goal is to let Claude automatically accumulate project knowledge across sessions without requiring users to write every note manually.

According to Claude Code documentation, Auto Memory lets Claude save notes while working, such as build commands, debugging discoveries, architecture notes, code style preferences, and workflow habits. It does not save every session, but judges what may be useful later.

One common misconception is that Auto Memory writes by default to .claude/memory.md in the project root. Official documentation says each project has its own memory directory under the user’s home directory, with a path like:

`1`	`~/.claude/projects/<project>/memory/`

MEMORY.md loads the first 200 lines or 25KB at the start of each conversation, while detailed content may be split into other topic files. Auto Memory files are local Markdown files, and users can view, edit, or delete them through /memory.

This makes Claude Code memory more like a local project knowledge base. It is closer to the codebase than ChatGPT’s personal memory, and more dynamic than a plain CLAUDE.md.

But Auto Memory is local to the machine. It does not naturally follow the repository to other machines or cloud environments. For team-shared stable rules, put them in the repository’s CLAUDE.md.

Gemini: around Google ecosystem context

Gemini’s memory logic is different again.

Gemini also supports saved information and past-chat references. Google help documents say users can save information about life, work, or preferences, and Gemini can reference past chats before answering. When it uses this information, the response may show sources such as Your saved info or Previous chats.

But Gemini’s differentiation is not only “saving a few preferences.” It is Google ecosystem integration.

With user authorization and feature availability, Gemini can access context from connected Google apps such as Gmail, Google Drive, Docs, and Sheets. Its advantage is not making users teach it every item manually, but turning existing Google account data into searchable work context.

A typical difference:

ChatGPT remembers: “I have been repairing an LTO tape drive recently.”
Gemini may find the purchase confirmation email in Gmail or read repair notes from Drive.

This does not mean Gemini can unconditionally read all Google data. It depends on account type, region, permissions, connected apps, Keep Activity settings, and product availability. Enterprise and school accounts may also be controlled by Google Workspace administrators.

More accurately, Gemini memory is a combination of saved info, past chats, and connected Google ecosystem data.

Core differences

Dimension	ChatGPT	Claude Code	Gemini
Core object	Person and preferences	Project and codebase	Google account and ecosystem data
Typical memory	Preferences, background, long-term goals	Architecture, commands, conventions, debugging experience	Saved info, past chats, Gmail/Drive/Docs context
Storage form	Memory and chat context in OpenAI account	`CLAUDE.md`, `MEMORY.md`, local Markdown files	Google account activity, saved info, connected app data
Transparency	Memory sources show part of the source	Markdown files can be opened and edited	Managed through source prompts, Gemini Apps Activity, and Google settings
Cross-project ability	Strong, follows user account	Weak, mainly follows project or local project memory	Strong, depends on Google data and permissions
Team sharing	Not suitable for direct sharing	`CLAUDE.md` can be shared through Git	Mainly depends on Workspace and permissions
Best for	Personal preferences and long-term assistant behavior	Long-term coding projects and agent collaboration	Google Workspace retrieval and cross-tool work

How to choose

If you want AI to remember who you are, what style you prefer, and how you usually work, ChatGPT memory is more suitable.

It is good for saving personal preferences such as writing style, tech stack, answer format, professional background, and long-term project direction. Its focus is reducing self-introduction cost so each new conversation can start faster.

If you want AI to remember how a codebase should be changed, which commands work, and which traps to avoid, Claude Code is more suitable.

Put stable rules into CLAUDE.md for team sharing. Let Auto Memory assist with dynamic experience. Important decisions should still be organized into documentation or CLAUDE.md, not left only in local automatic memory.

If most of your materials live in Gmail, Drive, Docs, and Sheets, Gemini’s ecosystem context has an advantage.

It is useful for finding old emails, organizing Drive documents, and connecting calendar and office materials. The key to using Gemini is not repeatedly reminding it in chat, but making sure the relevant app connections, permissions, and activity settings are correct.

A practical division of labor

You can divide them like this:

ChatGPT remembers general personal preferences.
Claude Code remembers engineering knowledge for a repository.
Gemini retrieves materials from your Google ecosystem.

In other words, ChatGPT is like a personal secretary, Claude Code is like a senior engineer inside the project, and Gemini is like an indexer for your Google account.

There is no absolute winner. They have different goals.

The biggest mistake is mixing them together. Personal preferences do not always belong in project memory; project architecture does not always belong in cloud personal memory; and Google ecosystem retrieval does not mean the model has truly understood you long-term.

Short Take

The next stage of AI memory is not simply “remember more.” Memory needs layers, visibility, and control.

ChatGPT focuses on cross-session personalization. Claude Code focuses on code project continuity. Gemini focuses on Google ecosystem context. Good long-term AI collaboration does not put all information into one black box; it keeps different kinds of memory in the right places.

Put personal preferences in personal memory, engineering rules in the codebase, and historical materials in the original document and email systems. AI’s job is to call the right context when needed, not mix everything into one pile.

What ChatGPT Release Notes reveal about OpenAI's product rhythm

Thu, 07 May 2026 14:31:22 +0800

OpenAI’s ChatGPT Release Notes page is a direct way to observe the product rhythm of ChatGPT. The page continuously records changes to ChatGPT models, features, account security, app integrations, and client experience.

As of May 7, 2026, the page shows the latest update as “yesterday,” with the newest entries concentrated on May 5, 2026. They may look like ordinary updates, but together they show where ChatGPT is heading: a more reliable default model, more controllable memory, deeper office workflows, and stronger account security.

Latest focus one: memory sources become visible

The first May 5 update is about ChatGPT memory improvements.

OpenAI says Plus and Pro users will gradually receive more personalized and continuous responses. ChatGPT can better use past chats, saved memories, available files, and connected Gmail context to provide more tailored suggestions, recommendations, and next steps.

The value of this capability becomes clear in long-term use. If a user is working on a project, writing a series of posts, following a set of emails, or repeatedly handling similar work, the most annoying part is re-explaining the background every time. Stronger memory is meant to reduce that repetition.

But the stronger memory becomes, the more users need to know what context the model used. That is why OpenAI is introducing memory sources. Users can see relevant saved memories, past chats, custom instructions, and, in certain cases, referenced files and Gmail messages under a response.

If information is outdated, inaccurate, or no longer relevant, users can correct it, delete it, or mark it as not relevant.

Personalization is not just “knowing you better”

When people talk about AI personalization, they often focus only on whether the model understands them better. But sustainable personalization must answer three questions:

Can users see what the model referenced?
Can users edit or delete that information?
Can users turn memory off when they do not need it?

The release notes clearly say memory sources are only shown inside the user’s own account experience, and are not exposed when a chat is shared. Users can also delete chats, use temporary chats, turn memory off, disconnect apps, and manage whether content is used to improve models.

This shows OpenAI is not only adding personalization capability. It is also adding control surfaces. For a long-term assistant, that step matters.

Latest focus two: GPT-5.5 Instant becomes the default model

On the same day, OpenAI also began rolling out GPT-5.5 Instant as ChatGPT’s new default model, replacing GPT-5.3 Instant for all users.

The release notes describe the model update in practical terms: more accurate, clearer, more concise, better at image understanding and STEM questions, and better at deciding when to use web search.

Default model updates have a large impact. Most users do not switch models every day. The ChatGPT quality they feel is the quality of the default model. If the default model has fewer hallucinations, less filler, and fewer pointless follow-up questions, the actual experience improves noticeably.

OpenAI also says GPT-5.5 Instant reduces overformatting and unnecessary decorative content. This may seem small, but it is close to everyday use. Many users do not need a fully structured essay. They need an accurate, direct, actionable answer.

Paid users can continue using GPT-5.3 Instant for three months before it is retired.

Latest focus three: ChatGPT enters Excel and Google Sheets

The third May 5 update is the global launch of ChatGPT for Excel and Google Sheets.

This feature puts ChatGPT into the sidebar of Microsoft Excel and Google Sheets, allowing users to build, update, and understand data inside spreadsheets. Official scenarios include trackers, budgets, formulas, multi-tab files, scenario work, and spreadsheet cleanup.

This shows ChatGPT is not staying inside a chat window. It is moving into places where users already work.

For office users, spreadsheets are a very common work surface. Many companies, teams, and individuals keep business data not in complex data platforms, but in piles of Excel and Google Sheets files. If ChatGPT can understand data, write formulas, organize multiple sheets, and explain results next to the spreadsheet, the barrier is much lower than copying everything into a chat window.

OpenAI also reminds users to review outputs before relying on formulas or analysis. That is realistic: AI can speed up spreadsheet work, but it cannot take full responsibility for financial, operational, or business judgments.

Late April groundwork: security and model selection

Looking back, the April 30 Advanced Account Security update is also worth attention.

It is an optional security setting for personal ChatGPT accounts. When enabled, the account uses stronger sign-in methods such as passkeys or compatible security keys, and disables weaker paths such as password sign-in, email or SMS sign-in codes, and email-based account recovery. It also includes recovery keys, shorter active sessions, login notifications, and session management controls.

This shows ChatGPT accounts are becoming more important. As files, memories, app connections, email, spreadsheets, and work projects enter ChatGPT, account security is no longer just a login issue. It relates to the user’s long-term work context.

On April 28, OpenAI also moved model selection closer to the composer and put Thinking and Pro model thinking effort controls into the model picker. This is a typical product detail change: as the number of models grows, users need an easier way to choose the right tool before sending a message.

Another late-April direction: faster ordinary answers

On April 22, ChatGPT introduced Fast answers.

This feature is for common information queries. When a question does not need personalization and ChatGPT has a high-confidence answer, it can return results faster. Fast answers do not reference past chats or memory, and users can turn them off in personalization settings.

This may look opposite to stronger memory, but it is the same product logic: different questions need different handling.

Some questions need long-term context, such as “help me continue planning that project from last week.” Others only need a fast and accurate answer, such as “what are the Seven Wonders of the World?” The former needs memory and context; the latter needs speed and clarity. ChatGPT is separating these paths.

Product rhythm is changing

These release notes show that ChatGPT updates are no longer only model releases.

Updates now cover:

Default model quality.
Memory and personalization.
App connections and office add-ins.
Account security.
Model selection and interaction entry points.
Fast answers and mobile experience.

This means ChatGPT is moving from a single AI chat product into a more complete work platform. Model capability is still important, but product experience, context management, tool entry points, account security, and third-party integrations now matter just as much.

Short Take

The most interesting part of these ChatGPT Release Notes is not one specific update, but the direction they form together.

OpenAI is making ChatGPT faster, more context-aware, more present in office workflows, and also more controllable and secure. GPT-5.5 Instant improves default answer quality, memory sources explain personalization, Excel and Google Sheets bring ChatGPT into real work files, and Advanced Account Security protects heavier account usage.

Going forward, ChatGPT’s competitiveness will not depend only on model parameters. It will also depend on whether OpenAI can organize these updates into a stable, clear product experience that users are willing to trust with long-term context.

ChatGPT Release Notes update: memory sources, GPT-5.5 Instant, and spreadsheet add-ins

Thu, 07 May 2026 14:30:15 +0800

OpenAI’s ChatGPT Release Notes page was updated in early May 2026. The latest batch focuses on three things: memory sources and stronger personalization in ChatGPT, GPT-5.5 Instant becoming the new default model, and the global launch of ChatGPT for Excel and Google Sheets.

Taken together, these updates point in a clear direction: ChatGPT is continuing to move from a chat entry point toward a more continuous, more personalized, and more office-native work assistant.

Memory sources make personalization more transparent

The most important update is memory sources.

OpenAI says ChatGPT Plus and Pro users are beginning to receive stronger memory improvements. ChatGPT can better pull relevant context from past chats, saved memories, available files, and connected Gmail apps to provide more tailored ideas, recommendations, and next steps.

This means users do not have to repeatedly explain project background, preferences, habits, or existing materials in every new conversation. For long-term writing, project planning, research organization, learning, and teamwork, continuity becomes stronger.

But the stronger personalization becomes, the more important transparency becomes. That is why OpenAI is introducing memory sources, so users can see what information helped personalize a response. Users can click the Sources icon under a response to view relevant saved memories, past chats, and custom instructions. Plus and Pro users may also see files from their library and referenced emails from connected Gmail.

If some information is outdated, irrelevant, or wrong, users can correct it, delete it, or mark it as not relevant.

Memory control is still the key

OpenAI also notes that memory sources may not show every factor that shaped a response, and that it will keep improving the view.

That matters. Memory sources are not a complete “model thinking log.” They are a product interface for understanding personalized context. They improve visibility, but cannot fully expose every factor that influenced an answer.

For privacy and control, OpenAI says memory sources only appear inside the user’s own account experience. If a user shares a chat, the sources do not appear in the shared chat. Users can also delete chats, use temporary chats that do not use or update memory and do not appear in history, turn off memory, disconnect apps at any time, and manage whether their content is used to improve models.

This shows ChatGPT personalization is following a clearer path: make the assistant more aware of the user, while also giving the user ways to see and manage why it answered that way.

GPT-5.5 Instant becomes the default model

The release notes also confirm that GPT-5.5 Instant is rolling out as the new default ChatGPT model, replacing GPT-5.3 Instant for all users.

The default model update improves several areas:

Accuracy.
Clarity and concision.
Image understanding.
STEM answers.
Deciding when to use web search.

OpenAI emphasizes that GPT-5.5 Instant is more factually reliable, especially for prompts where accuracy matters. It also gives tighter and more direct answers, reduces unnecessary follow-up questions, and lowers clutter from overformatting and decorative content.

For users, this may not be as visible as a new feature button, but it changes the feel of opening ChatGPT every day: fewer detours, less verbosity, and less formatting piled onto simple questions.

Personalization and the default model now work together

For Plus and Pro users on the web, GPT-5.5 Instant can also use context from past chats, files, and connected Gmail more effectively.

This is part of the same product direction as memory sources. The model is not only “smarter.” It should also know, when appropriate, what you worked on before, what you care about, and what materials you already provided. When continuing a project, writing a plan, organizing email information, or making suggestions based on past preferences, ChatGPT can ask fewer repeated questions.

Paid users can continue using GPT-5.3 Instant for three months through model configuration settings before it is retired.

ChatGPT for Excel and Google Sheets

Another important update is the global launch of ChatGPT for Excel and Google Sheets.

It brings ChatGPT into a sidebar inside Microsoft Excel and Google Sheets, so users can build, update, and understand data in place. OpenAI mentions use cases including:

Trackers.
Budgets.
Formulas.
Multi-tab files.
Scenario work.
Spreadsheet cleanup.

Where available, it also supports Skills and apps.

The meaning is straightforward: a lot of office data does not live in a specialized BI system. It lives in Excel and Google Sheets. Putting ChatGPT into the spreadsheet sidebar is more natural than asking users to copy and paste into a chat window, and makes it easier to enter real workflows.

Usage limits and installation

The release notes say Free and Go plans include limited usage, while Plus and Pro use the same agentic usage limits as Codex. Users can buy additional credits if they need to go beyond plan limits.

Installation is also direct: install ChatGPT for Excel from Microsoft Marketplace or ChatGPT from Google Workspace Marketplace, then sign in with an eligible ChatGPT account.

OpenAI also reminds users to review outputs before relying on formulas or analysis. That point is important. AI can speed up spreadsheet work, but formulas, budgets, financial work, and business analysis still need human review.

Recent update pattern

Looking at the release notes from late April to early May, ChatGPT’s direction is clearer.

On April 30, OpenAI introduced Advanced Account Security for personal ChatGPT accounts, adding stronger sign-in requirements and account protections, including passkeys, security keys, recovery keys, shorter sessions, and login notifications.

On April 28, model selection moved closer to the composer, making it easier to choose a model before sending a message. Thinking effort controls for Thinking and Pro models were also moved into the model picker.

On April 22, ChatGPT introduced Fast answers for common information queries that do not require personalization and where the model has a high-confidence answer. Fast answers do not reference past chats or memory, and users can turn them off in personalization settings.

These updates all serve the same goal: make ChatGPT better for frequent everyday use. It should be fast when speed matters, personalized when context matters, and provide security and visibility controls when needed.

Short Take

The point of this ChatGPT Release Notes update is not one single feature. It is the continued shaping of the product.

GPT-5.5 Instant improves the default answer quality. Memory sources make personalization more visible. Excel and Google Sheets add-ins put ChatGPT inside office spreadsheets. Advanced Account Security and model picker changes strengthen account protection and interaction design.

ChatGPT is becoming a longer-term work layer. It remembers more context, enters more tools, and handles more daily tasks. The next questions are whether personalization transparency is clear enough, whether office add-ins remain stable in real complex spreadsheets, and whether users can keep a healthy balance between convenience and control.

GPT-5.5 Instant launches: ChatGPT's default model gets more accurate, shorter, and more personal

Thu, 07 May 2026 14:28:40 +0800

OpenAI released GPT-5.5 Instant on May 5, 2026 and began rolling it out as the default model for all ChatGPT users.

The keywords in this update are not “bigger” or “flashier.” They are closer to everyday use: more accurate answers, clearer and shorter responses, a more natural tone, and better use of context users have already shared. For ChatGPT, changes to the default model matter especially because they affect the experience most people actually use every day.

Why the default model matters

Instant is ChatGPT’s daily driver model. Many users do not manually switch models or study the differences between them. Their experience of ChatGPT is the quality of the default model.

So GPT-5.5 Instant is not just another model name. It moves the base experience forward. OpenAI says the update makes everyday interactions more useful and smoother: stronger answers across topics, tighter conversations, and better use of existing context when appropriate.

This kind of improvement is less dramatic than a large multimodal launch, but for hundreds of millions of users, a default model that makes fewer mistakes, writes less unnecessarily, and asks fewer pointless follow-up questions is a major product change.

Fewer hallucinations and more reliable answers

OpenAI puts accuracy first.

In internal evaluations, OpenAI says GPT-5.5 Instant produced 52.5% fewer hallucinated claims than GPT-5.3 Instant on high-stakes prompts covering medicine, law, and finance. On especially difficult conversations users had flagged for factual errors, inaccurate claims were reduced by 37.3%.

These numbers matter. They show OpenAI is not only trying to make the model more fluent, but also continuing to reduce factual errors. In areas such as medicine, law, and finance, a model cannot merely sound smooth. It has to be more cautious and invent less.

This does not mean users should treat ChatGPT as a replacement for professional advice. A more accurate model still needs verification, sources, and human judgment in high-risk contexts. But as a product experience, better factual reliability in the default model reduces many everyday risks.

Stronger everyday task performance

GPT-5.5 Instant also improves across daily tasks.

OpenAI mentions better analysis of photo and image uploads, stronger STEM answers, and better judgment about when to use web search. The last point is important. Many users do not care whether the model internally calls a tool. They care whether the answer is fresh, accurate, and clearly explained.

If the model can better decide which questions need web search and which can be answered directly, users do not have to keep saying “look it up.” ChatGPT feels more like a proactive assistant than a chat box waiting for explicit instructions.

OpenAI’s math example also points in this direction. GPT-5.5 Instant initially accepts an incorrect solution, but then checks the result, finds the algebra error, and solves the corrected equation. The important point is not that it never makes a mistake, but that it has a better chance of catching and repairing one during the reasoning process.

Shorter answers, not less substance

OpenAI also emphasizes that GPT-5.5 Instant gives tighter, more direct answers while keeping useful content and ChatGPT’s friendly tone.

This matters for a default model. AI response fatigue often comes not from too little information, but from too much structure, too much setup, and too much formatting. A simple question can become five headings and a dozen caveats, which feels unnatural.

GPT-5.5 Instant aims to reduce unnecessary verbosity and overformatting, ask fewer unneeded follow-up questions, and avoid decorative clutter. For daily office work, writing advice, life questions, and quick explanations, these changes often matter more than one benchmark score.

Shorter does not mean shallower. A good default model should judge whether the user needs one practical sentence, an explanation, or a full plan. GPT-5.5 Instant is moving toward steadier judgment on that balance.

Personalization keeps improving

Another main thread is personalization.

OpenAI says Instant is now better at using context from past chats, files, and connected Gmail, when available, to make responses more relevant. It decides when extra personalization can improve an answer and searches past conversations faster, so users do not need to repeat background as often.

This is valuable for long-term ChatGPT users. When planning, writing, selecting tools, organizing projects, or continuing a workflow, users may already have provided preferences, constraints, and context in earlier chats. If the model can pick up naturally, it reduces repeated explanation.

But personalization has to come with transparency and control. Otherwise users do not know why the model suddenly references a preference or which memories are shaping an answer.

Memory sources make personalization more visible

OpenAI is also introducing memory sources across all ChatGPT models.

The feature lets users see which context was used to personalize a response, such as saved memories or past chats. If something is outdated, inaccurate, or no longer wanted, users can delete or correct it.

OpenAI also says memory sources are not shown to others when users share a chat. Users can delete chats they do not want cited, edit saved memories in settings, or use temporary chats that do not use or update memory.

This matters. The more personalized an AI assistant becomes, the more it needs to explain “what I used to answer you.” Memory sources may not show every factor, but they move part of personalization out of the black box.

Availability

GPT-5.5 Instant is rolling out from the announcement day to all ChatGPT users, replacing GPT-5.3 Instant as the default model. In the API, it corresponds to chat-latest.

Paid users can continue using GPT-5.3 Instant for three months through model configuration settings before it is retired.

Enhanced personalization from past chats, files, and connected Gmail is rolling out first to Plus and Pro users on the web, with mobile support coming later. OpenAI plans to expand it to Free, Go, Business, and Enterprise in the following weeks. Memory sources are rolling out on the web for ChatGPT consumer plans and will come to mobile later. Availability of specific personalization sources may vary by region.

Short Take

GPT-5.5 Instant is an upgrade to the default ChatGPT experience.

It is not only about stronger model capability. It adjusts accuracy, answer density, tone, context use, and personalization transparency together. For ordinary users, the most direct change should be: less fluff, fewer factual errors, and better continuity with your background.

For OpenAI, this is another step in the evolution of the default assistant. ChatGPT is becoming less of a tool that starts from zero every time and more of a long-term assistant that can remember preferences, understand context, know when to search, and let users manage those memory sources.

Grok Imagine Quality Mode API: xAI wants image generation inside enterprise workflows

Thu, 07 May 2026 14:27:29 +0800

xAI released the Grok Imagine Quality Mode API on May 6, 2026. It is a quality mode for image generation and editing in Grok Imagine, available to enterprise developers and teams, with a focus on higher realism, stronger text rendering, and better creative control.

The point of this update is not to create another generic text-to-image entry point. It is to put Grok Imagine into enterprise content production workflows: product images, marketing assets, ad variations, UGC-style content, brand visuals, and video generation all fall within its target range.

What Quality Mode provides

xAI’s positioning is clear: more realistic, better at text, and better at following prompts.

First, realism is improved. The official examples emphasize natural skin, material details, lighting, scene atmosphere, and photographic texture. This matters for commercial images. Many image models already look “pretty,” but once the image is used in ads, product pages, or social assets, problems with skin, fabric, hands, spatial relationships, and lighting become obvious.

Second, text rendering is stronger. xAI specifically says Quality Mode supports cleaner multilingual text capabilities. Whether an image model can reliably generate text is a real barrier for business use. Menus, posters, packaging, ads, buttons, signs, and social graphics are hard to use directly if even one word is wrong.

Third, creative control is better. The official description includes tighter prompt following, deeper scene and world understanding, and more consistent brand results. In other words, Quality Mode is trying to solve not just “generate a good-looking image,” but “generate controllable, reusable, iterable images according to a team’s requirements.”

Built for enterprises, not just casual image play

xAI places enterprise use cases near the front of the announcement.

The most typical example is product visualization and marketing assets. Companies can use it to generate photorealistic product renders, hero images, social assets, icons, and ad variations. Compared with a personal user casually generating one image, companies care about three things:

Whether the image is realistic enough to approach commercial photography or high-quality rendering.
Whether it follows brand style, including color, composition, text placement, and visual tone.
Whether it can generate variations at scale for A/B tests, campaigns, and different channels.

That is where Quality Mode is valuable. It does not replace designers. It compresses the “make a dozen directions first” stage into less time. Teams can generate candidates through the API, then let design, marketing, and brand teams select, adjust, and ship them.

Image editing matters more than text-to-image

The announcement shows not only images generated from scratch, but also workflows based on reference images. Examples include placing a product on a pamphlet, preserving a T-shirt graphic, and putting the same person into different UGC scenes.

This is more useful for enterprises. In real business work, assets rarely start from nothing. Teams already have product photos, brand guidelines, character references, packaging designs, or campaign themes. If an AI tool can only randomly generate attractive images, its value is limited. If it can create stable variations around existing assets, it is much easier to fit into a workflow.

This is also a direction for image model competition: from “prompt lottery” to controllable editing. Users do not only want surprise; they want predictable changes.

The business meaning of UGC-style content

xAI also shows UGC-style content, such as the same person wearing a specified T-shirt, eating birthday cake, or taking a mirror selfie in an elevator.

This reflects a shift in advertising and social content production. Many brands no longer need only polished studio shots. They also need content that looks more natural and closer to real user sharing. UGC-style assets work well for short video covers, feed ads, social posts, and creator collaboration previews.

Of course, this also means companies need clearer handling of portrait rights, brand authorization, and content labeling. AI can lower production costs, but it does not make usage risk disappear. Compliance still has to be designed in advance, especially when real likenesses, similar people, product marks, and ad distribution are involved.

Text, world understanding, and visual range

Quality Mode also emphasizes world understanding and a broad visual range.

Official examples include text on a cake explaining Alexander the Great, cinematic picnic scenes, and UI-style icons. These examples suggest xAI wants Grok Imagine to cover realistic photography, commercial ads, product renders, icons, posters, and image inputs for video generation rather than one fixed aesthetic.

The most interesting part is the combination of text and world understanding. Many image tasks are not just about drawing objects. They require the model to understand relationships, use cases, historical facts, text meaning, and visual presentation. The more the model can understand these constraints, the more likely it is to move from entertainment tool to production tool.

Quality Mode also enhances video generation

xAI says pairing its latest image model with its video capabilities can support social media video assets, product showcases, ads, and more.

This fits the broader trend in multimodal products: image generation is no longer an isolated capability. It becomes part of a pipeline for video generation, ad creative, product demos, and social content. A company may first generate a high-quality product image, then extend it into a short video, motion ad, or multi-version campaign asset.

From this perspective, Quality Mode is not just about clearer images. It provides a more stable visual starting point for video and marketing automation.

How developers call it

The official example uses xai_sdk to call the grok-imagine-image-quality model:

import xai_sdk

client = xai_sdk.Client()

response = client.image.sample(
    prompt="A collage of London landmarks in a stenciled street-art style",
    model="grok-imagine-image-quality",
)

print(response.url)

This shows Quality Mode is not only a feature inside the Grok frontend. It is exposed through the API for enterprise developers and teams. For companies, the API form matters because it can connect to internal asset systems, ad platforms, CMS tools, design workflows, and automation pipelines.

Short Take

The core direction of Grok Imagine Quality Mode API is to push image generation from “fun” toward “usable in enterprise production.”

It emphasizes realism, text rendering, prompt following, brand consistency, image editing, UGC style, and video generation continuity. All of these point to one goal: helping teams produce visual assets in batches, with stability and control.

The real test is not only whether a single image looks impressive. It is whether text rendering stays stable in complex scenes, whether reference-image editing preserves identity and brand consistency, and whether the API is fast, affordable, and controllable at scale. Only if those parts hold up can Grok Imagine truly enter enterprise content production pipelines.

Anthropic raises Claude usage limits and expands compute with SpaceX

Thu, 07 May 2026 14:26:14 +0800

Anthropic announced on May 6, 2026 that it is raising some Claude Code and Claude API usage limits, while also disclosing a new compute partnership with SpaceX.

On the surface, this is about “more quota.” The more important signal is that model companies are tying product experience, subscription tiers, API rate limits, and infrastructure supply together. For heavy users, compute is not abstract. It determines whether they can run more Claude Code tasks, wait less, and call Opus models more reliably.

How Claude Code and API limits are changing

Anthropic announced three changes, all effective from the day of the announcement.

First, Claude Code’s five-hour usage limits are being doubled for Pro, Max, Team, and seat-based Enterprise plans.

This matters directly for heavy Claude Code users. In the past, continuous code reading, editing, and task execution could quickly run into the five-hour limit. Doubling the limit allows more sustained development work in the same working window.

Second, Pro and Max accounts will no longer see reduced Claude Code limits during peak hours.

This is more important than the number itself. The most frustrating part of many AI tools is not the normal quota, but sudden slowdowns or unstable limits during busy periods. Removing peak-hour reductions shows Anthropic wants paid users to have a more predictable experience even when demand is high.

Third, Anthropic is considerably raising API rate limits for Claude Opus models. The original article presents the detailed numbers in an image table; the core point is that Opus API capacity is being raised meaningfully.

For developers, Opus is the more expensive, heavier, and more capable model. Higher Opus API limits suggest Anthropic wants more companies and developers to put Opus into real business workflows, not just use Claude in a chat interface.

The weight of the SpaceX compute deal

The higher limits are backed by new compute supply.

Anthropic says it has signed an agreement with SpaceX to use all compute capacity at SpaceX’s Colossus 1 data center. The partnership will provide more than 300 megawatts of new capacity within a month, corresponding to more than 220,000 NVIDIA GPUs.

Those numbers say two things.

First, compute is still a bottleneck for frontier model companies. Model capability, context length, tool use, coding agents, multimodality, and enterprise use cases all consume large amounts of inference resources. The more users and complex tasks a platform supports, the more stable large-scale GPU supply it needs.

Second, AI infrastructure competition has entered a massive scale phase. In the past, attention focused more on model rankings, product features, and pricing. Now, whoever can secure power, facilities, networking, and GPUs faster has a better chance of turning model capability into a stable product.

Anthropic also says the SpaceX capacity will directly improve capacity for Claude Pro and Claude Max subscribers. In other words, this is not just training infrastructure; it also supports user-facing inference.

Anthropic’s compute map

SpaceX is not Anthropic’s only compute partner.

The announcement also points to several previously announced infrastructure arrangements:

An up to 5GW agreement with Amazon, including nearly 1GW of new capacity by the end of 2026.
A 5GW agreement with Google and Broadcom, expected to begin coming online in 2027.
A strategic partnership with Microsoft and NVIDIA that includes $30 billion of Azure capacity.
A $50 billion investment in American AI infrastructure with Fluidstack.

The common thread is that Anthropic is not binding itself to one hardware stack or one cloud platform. The original article explicitly says Claude is trained and run on AWS Trainium, Google TPUs, and NVIDIA GPUs.

This multi-supplier strategy is practical. It is hard for one cloud provider to satisfy frontier training and large-scale inference demand over the long term. A multi-platform approach increases engineering complexity, but reduces supply chain and capacity risk.

Why usage limits are really a compute issue

AI product “limits” are not just membership copy. They map to real costs.

Every time Claude Code reads a repository, generates a patch, or runs a long task, it consumes inference resources. API users who put Opus into support, financial analysis, code review, document processing, or agent workflows create sustained demand. For the platform, loosening limits means having more reliable compute behind the scenes.

So the logic of this announcement is clear: first explain that users get higher limits, then explain why those limits can now be raised. The new SpaceX capacity, along with existing Amazon, Google, Microsoft, NVIDIA, and Fluidstack partnerships, supports heavier usage.

This also explains why AI products increasingly emphasize tiering. Free, Pro, Max, Team, and Enterprise users consume compute differently and pay differently. Model companies have to realign quotas, priority, model access, and infrastructure costs.

The signal from orbital AI compute

The announcement includes one futuristic detail: Anthropic says it has also expressed interest in partnering with SpaceX to develop multiple gigawatts of orbital AI compute capacity.

That does not mean orbital data centers are becoming a product immediately. A safer reading is that frontier AI companies are already thinking beyond ground-based data centers for future compute supply.

AI data centers are constrained by power, land, cooling, networking, and regulation. As training and inference demand grows, the industry will explore more infrastructure forms. Orbital compute may sound distant, but its appearance in an official Anthropic announcement is itself a signal: the imagination around compute competition is expanding.

International expansion and compliance

Anthropic also says enterprise customers, especially in regulated sectors such as finance, healthcare, and government, increasingly need in-region infrastructure for compliance and data residency.

That means model companies cannot build all infrastructure in the United States. Enterprise AI has to handle regional compliance, data residency, supply chain security, power costs, and relationships with local communities. Anthropic says its collaboration with Amazon already includes additional inference in Asia and Europe.

It also says it will be intentional about adding capacity in democratic countries whose legal and regulatory frameworks support large-scale investment and secure supply chains, while exploring ways to extend its US data center electricity-price commitment to other jurisdictions.

This shows that AI infrastructure is not just a technical issue. It is increasingly an energy, manufacturing, and geopolitical economic issue.

Short Take

Anthropic’s announcement can be summarized simply: Claude limits are going up because new large-scale compute is coming online.

For users, the near-term effects are higher Claude Code five-hour limits, fewer peak-hour reductions for Pro and Max, and more Opus API room. For the industry, the bigger point is that model competition is expanding from “whose model is stronger” to “who can continuously secure enough stable and compliant compute.”

Future AI product experience may differ not only because of model parameters and product design, but also because of infrastructure capacity. Whoever can organize power, GPUs, data centers, cloud partnerships, and regional compliance has a better chance of turning frontier models into long-term services.

Doubao's 68 to 500 Yuan Subscription Test: Is the Era of Free AI Ending?

Thu, 07 May 2026 11:38:45 +0800

Around May 2026, Doubao’s App Store page showed information about a paid subscription test, with pricing split into three tiers:

Standard: 68 yuan/month.
Enhanced: 200 yuan/month.
Professional: 500 yuan/month.

It is not surprising that this caused controversy. Chinese internet users have long been used to free apps, free content, and free basic services. When a mass-market AI assistant suddenly shows monthly fees ranging from dozens to hundreds of yuan, it is easy for people to wonder: is Doubao trying to charge in disguise? Will the free version become worse? Is ByteDance unable to keep burning money?

But what is truly worth watching is not only whether Doubao charges 68 yuan. It is whether China’s AI products are moving from “free user acquisition” into a stage of “compute tiering and commercial closure.”

The official wording is restrained: Doubao’s basic services will remain free, value-added services are still being tested, and full information will be released through official channels when they formally launch. In other words, free chat is not disappearing immediately. Doubao is starting to split previously bundled capabilities into several layers: a free entry point, value-added features, and high-end productivity services.

AI Is Not a Traditional Free App

Many people understand AI as if it were an ordinary app: once the software has been developed, adding one more user should not cost much.

Traditional internet products often do work like this. A content platform, a piece of software, or a community product requires heavy upfront investment, but as users grow, the fixed cost per user falls. Advertising, memberships, e-commerce, and value-added services can gradually make up the cost.

AI is different.

Every request requires inference. Every inference consumes compute, tokens, electricity, and model-serving resources. A light user asking about the weather costs very little. A heavy user asking AI to write reports, analyze data, generate PPTs, process long documents, create images, or handle complex tasks can quickly drive costs upward.

So the essence of Doubao’s pricing is not simply selling a membership. It is an attempt to turn uncontrollable compute consumption into a predictable revenue structure.

If a user only asks a few simple questions every day, the platform can keep that user through the free entry point. But if a user heavily uses productivity features, the platform has to think about quotas, priority, and payment.

The Free Version Will Not Disappear, but the Experience May Become Tiered

“Basic services will remain free” is probably true, but the continued existence of free access does not mean the free experience will stay exactly the same.

Once a product starts charging, the free version is usually repositioned in several ways.

First is compute priority.

Compute cannot be supplied infinitely during peak hours. Platforms will not build data centers around the absolute peak load, because large amounts of resources would sit idle during off-peak periods. A more realistic approach is to guarantee the paid-user experience while free users queue, wait, slow down, or use lower-cost models.

Second is model level.

Doubao already has experience tiers similar to “fast thinking” and “expert.” In the future, free users may use lightweight models more often, while advanced models are placed inside quotas or paid benefits.

Third is feature access.

Ordinary chat may remain free, but capabilities that consume more resources will likely be limited or monetized, such as:

Long-document parsing.
Deep analysis.
AI image generation.
PPT generation.
Data analysis.
Multimedia production.

Fourth is user psychology.

As soon as a paid version appears on the page, free users naturally feel that they are using the lower-tier version. Even if the basic features remain, users will start comparing: is the paid version faster, smarter, and less restricted?

So free AI in the future may not be unusable. It may be “usable, but you can always feel that a more advanced version exists next to it.”

ByteDance Is Not Out of Money; It Is Recalculating Its Cost Structure

Another common interpretation of Doubao’s pricing is: is ByteDance out of money? Can it no longer afford AI spending?

That explanation is too simplistic.

ByteDance is not a listed company, so outsiders have difficulty getting complete financial data. There are many market claims about profit declines, AI investment, data-center construction, and equity incentives, but they cannot be simply equated with “Doubao has burned ByteDance into poverty.”

Based on public information, Volcano Engine once disclosed that in March 2026, the average daily token usage of the Doubao large model exceeded 120 trillion, and had grown 1,000 times over the past year. That scale does suggest very high inference costs behind Doubao.

If roughly estimated using model input and output prices, Doubao’s annual consumption could reach the level of tens of billions of yuan. That number is frightening for an ordinary company, but in the context of ByteDance’s revenue scale and AI strategic investment, it is not necessarily unbearable.

A more reasonable judgment is: ByteDance is not unable to keep spending. It no longer wants the free-for-all to hide the real cost.

AI products cannot be judged only by user count. They must also be judged by unit economics: can the revenue generated by a user cover the compute that user consumes? The more users there are, the more money the product may burn if a paid system has not been established.

After Taking the Lead, Doubao Is Building Paid-User Expectations

Doubao’s biggest bargaining chip today may not be having the strongest model, but its user scale and product entry points.

As of March 2026, some reports claimed that Doubao had about 345 million monthly active users, Qianwen about 166 million, and DeepSeek about 127 million. Regardless of the exact measurement, Doubao is already near the front of China’s AI assistant market in user scale.

When a product is still catching up, the most common strategy is free access, subsidies, new-user acquisition, and entry-point capture. But once it becomes a leading product, the next step becomes shaping expectations:

Make users accept that AI is worth paying for.
Separate advanced capabilities from basic capabilities.
Use high-priced plans to establish price anchors.
Then use benefit packages, discounts, and limited-time offers to convert users.

This is also why Doubao’s pricing test puts pressure on competitors.

If other AI assistants remain free, users may ask: why are you not charging? Is your capability not strong enough? Has your commercialization not worked?

If other products follow with paid plans, they face an even harder problem: their user scale is already behind, and charging may further weaken growth.

So Doubao’s subscription test is not simply about earning subscription fees. It is pushing competition from “whoever is free gets users” toward “who can charge, who can retain users, and who can make the commercial loop work.”

The Deeper Issue Is Internal Resource Integration

ByteDance’s AI products are not limited to Doubao.

It also has Volcano Engine, Coze, Jimeng, CapCut, Feishu, Trae, Seedance, Seedream, Coding Plan, and API services for enterprises and developers. Each team has its own product, plans, quotas, KPIs, and commercialization goals.

This creates a problem: users may clearly be buying ByteDance’s AI capabilities, but they may have to pay repeatedly across multiple entry points.

For example, a user may buy a CapCut membership, buy a Jimeng package, buy Coding Plan through Volcano Engine, and separately top up for API usage. Different business lines price separately, sell benefits separately, and compete for compute separately. The experience will become increasingly fragmented.

If Doubao’s subscription only charges separately for the chat assistant, its significance is limited.

But if the 68, 200, and 500 yuan tiers can eventually connect Doubao, Jimeng, CapCut, Volcano Engine, Coding Plan, and other capabilities, letting users obtain a unified quota through one account, then it is not just a membership package. It becomes a unified billing entry point for ByteDance’s AI system.

OpenAI and Anthropic abroad are moving in a similar direction: users first subscribe to one main account, then consume quotas across chat, coding, tool calling, and productivity scenarios. This reduces user comprehension costs and also allows the platform to allocate compute more effectively.

For ByteDance, the truly important part of Doubao’s pricing test may not be the 68 yuan itself. It may be whether ByteDance can gather its internal AI capabilities into a more unified commercial system.

How to Read This

Doubao’s pricing can certainly be questioned.

Users have every reason to care whether prices are reasonable, benefits are clear, the free version will be downgraded, and advanced capabilities are truly worth 200 or 500 yuan. But if this is understood only as “harvesting users,” the reading is too shallow.

There are at least five layers of change behind it:

Every AI use has inference cost, so the traditional free-app logic cannot be applied completely.
The free entry point will continue to exist, but the free experience may be re-tiered through quotas, queues, model levels, and feature access.
ByteDance charging does not mean it is out of money. It means ByteDance is starting to calculate compute cost, user growth, and commercialization on the same sheet.
After gaining a lead in user scale, Doubao is beginning to build the expectation that AI should be paid for, and is handing competitors a hard choice.
The larger possibility is whether ByteDance can unify its internal AI products and compute quotas.

Summary

Doubao’s 68, 200, and 500 yuan subscription test does not mean free AI will disappear tomorrow, nor does it mean ordinary chat will immediately become unavailable.

It is more like a signal: Chinese AI assistants are moving from free user acquisition into tiered pricing. Basic capabilities remain free, advanced capabilities are paid as needed, and complex productivity tasks consume quotas. This may become normal for more and more AI products.

What is truly worth watching is whether Doubao can turn pricing into a clear, unified, and valuable AI account system. If it is only another membership wall, users will resent it. If it can connect chat, office work, creation, coding, and API capabilities, it may become the key entry point for ByteDance’s AI commercialization.

The era of free AI may not be ending, but the era of “unlimited free use of advanced intelligence” is very likely already starting to loosen.

How to Control fdupes Deletion Order: Keep Duplicate Files by Directory Priority

Wed, 06 May 2026 09:23:09 +0800

When using fdupes to delete duplicate files across three directories, such as a, b, and c, and you want to keep a first, then b, and delete duplicates from c first, the key is not a complex rule. It is the order of directory arguments.

In non-interactive delete mode, fdupes keeps the first file it sees in each duplicate group and deletes later duplicates. Therefore, directory arguments should be arranged from highest retention priority to lowest.

In other words, to achieve “delete from c first, then b, and keep a as much as possible”, write the command like this:

`1`	`fdupes -rdN a b c`

The scan order is a -> b -> c. When the same file exists in all three directories, the file in a is found first and kept, while duplicates in b and c are deleted. If only b and c contain duplicates, b is kept and c is deleted.

Parameter Meaning

Common parameters are:

-r: recursively scan subdirectories.
-d: delete duplicate files.
-N: when used with -d, skip interactive confirmation, keep the first file in each duplicate group, and delete the rest.

Therefore, the basic format for automatic duplicate deletion is:

`1`	`fdupes -rdN 目录A 目录B 目录C`

The earlier a directory appears, the higher its retention priority. The later it appears, the more likely its duplicate files are to be deleted.

Preview Before Deleting

Using -dN deletes files directly, so it is better to preview duplicate groups first:

`1`	`fdupes -r a b c`

The output is grouped by duplicate files. In each group, the file shown earlier is the one more likely to be kept in non-interactive deletion mode.

You can also view summary information:

`1`	`fdupes -rm a b c`

If the data is important, save the result and inspect it manually:

`1`	`fdupes -r a b c > duplicates.txt`

After confirming that the order within each duplicate group matches your expectations, run:

`1`	`fdupes -rdN a b c`

How Subdirectories Are Handled

As long as -r is enabled, fdupes recursively scans all files under the directories you pass in. Retention priority is still determined by the order in which paths appear in the command.

For example:

`1`	`fdupes -rdN dir_a dir_b dir_c`

This means:

dir_a has the highest priority.
dir_b comes next.
dir_c has the lowest priority.

If dir_a/sub1/file.txt and dir_c/sub1/file.txt have identical content, the file under dir_a is kept. If dir_a/x/y/file.txt and dir_c/file.txt have identical content, the file under dir_a is still kept first. fdupes compares file content; filenames and directory depth do not need to match.

Precisely Controlling Subdirectory Priority

If you only pass parent directories, the scan order inside subdirectories is determined by fdupes traversal behavior. This is enough in most cases. But if you want a specific subdirectory to have higher priority, write it explicitly before its parent directory.

For example, suppose you want to keep dir_a first, then keep dir_b/special, then process the rest of dir_b, and finally process dir_c:

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

This makes dir_b/special scan before dir_b. When dir_b is scanned later, files under special have already been recorded, so that subdirectory effectively has higher priority than the rest of dir_b.

This pattern is useful when:

a is the most important baseline directory.
A subdirectory inside b is more important than the rest of b.
c is mainly a low-priority backup directory.

The path order can be extended further:

`1`	`fdupes -rdN a b/important b c/keep-first c`

The rule is still the same: the earlier it appears, the more likely it is to be kept.

Use a List for Many Directories

If there are many directories and subdirectories, manually writing a long command is error-prone. You can write paths into a text file such as folders.txt, ordered by priority:

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

Then pass them to fdupes with xargs:

`1`	`cat folders.txt \| xargs fdupes -rdN`

If paths may contain spaces, use null-separated input for better safety:

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

Important Boundaries

First, fdupes compares file content, not filenames. Two files with completely different names can still be treated as duplicates if their content is identical.

Second, if directory a contains duplicates internally, fdupes -rdN a b c may also delete later duplicates inside a. This command means “keep the first file according to the overall scan order”, not “never delete anything under a”.

Third, by default, fdupes does not follow symbolic links. If you need to handle files behind symlinks, confirm whether -s is needed and whether that matches your data-safety expectations.

Fourth, fdupes only deletes duplicate files. It does not clean up empty directories. After deletion, if b and c contain empty folders, you can run:

`1`	`find b c -type d -empty -delete`

Safer Operating Habit

If the directories contain important data, do not start with -rdN. A safer workflow is:

Run fdupes -r a b c first to view duplicate groups.
Confirm that the first file in each group is the one you want to keep.
Then run fdupes -rdN a b c for automatic deletion.
After deletion, check whether empty directories need cleanup.

If you are very worried about accidentally deleting files under a, first clean a smaller range of low-priority directories, or export the results and filter them manually. The directory order in fdupes is useful, but it is not an access-control rule. Once a path is included in the scan, duplicate files inside it may participate in deletion decisions.

Summary

To delete duplicate files with fdupes by priority, put the directories you want to keep earlier and the directories you want to delete from later.

To keep a, then b, and delete from c first:

`1`	`fdupes -rdN a b c`

To give a subdirectory higher priority, write it before its parent directory:

`1`	`fdupes -rdN a b/important b c`

The key sentence is simple: fdupes -dN keeps duplicate files that appear first and deletes duplicates that appear later. Directory order is your retention priority.

DeepSeek V4 Flash for a Godot Game Demo: How Far Can a Few Cents Go?

Wed, 06 May 2026 09:22:18 +0800

Can DeepSeek V4 Flash handle Godot game demo development?

The focus is simple: can it create a small Godot demo that runs, can be observed, and includes physics effects?

The short answer is yes. The quality is not commercial-grade, but it is already enough for gameplay prototyping and physics interaction demos. More importantly, the cost is very low, which makes it suitable for quickly validating ideas.

Demo Performance

The focus of this demo is physics interaction.

Several visible effects include:

The rope can be cut.
The box falls to the ground.
After increasing the mass, box collisions become more forceful.
The rope shows noticeable elasticity.
After adjusting friction and elasticity, the box shows clear sliding and bouncing.

From what it presents, this is no longer just “a few generated Godot scripts”. It is a small prototype that can run and show observable physics behavior.

Usability

The value of this demo is that it can run, be viewed, and be modified. It is not a complete game, nor an engineering project ready for direct commercialization, but it already demonstrates several things:

DeepSeek V4 Flash can understand the basic goal of a Godot demo.
An AI Agent can turn requirements into a runnable project.
Non-web tasks such as Godot physics interaction are entering a low-cost prototyping stage.
For individual developers, it can quickly turn an idea into something visible.

If the goal is to build a formal game, it is obviously not enough. But if the goal is to verify whether a gameplay idea is interesting or whether the rough physics effect can be made, this demo is already usable.

Cost Significance

The most notable part is not how polished the visuals are, but the cost.

If a Godot physics demo can produce a runnable version with model costs at the level of a few cents, its significance is not replacing professional game development. It is sharply reducing the cost of prototype trial and error.

In the past, validating a small game idea usually required knowing Godot, writing scripts, setting up scenes, and adjusting physics parameters. Now an AI Agent can first generate a runnable version, and humans can judge whether the direction makes sense.

For indie developers, this kind of low-cost experimentation is useful:

Quickly validate gameplay concepts.
Generate temporary demos for others to see.
Explore Godot APIs and the physics system.
Turn ideas into an initial runnable project.
Reduce handwritten code cost before the direction is clear.

DeepSeek V4 Flash’s Performance

What is worth noting is that the model used here is DeepSeek V4 Flash, not a more expensive and heavier flagship model.

It performs well in the role of a low-cost prototype model. It is not the strongest, most stable, or most suitable model for delivering production engineering, but it is attractive in budget-sensitive scenarios where the goal is to quickly test a direction.

Suitable Scenarios

DeepSeek V4 Flash + Agent + Godot is better suited to these tasks:

Small gameplay prototypes.
Physics effect demos.
UI or interaction concept validation.
Teaching examples.
Helping understand Godot project structure.
Generating a first runnable project.

It is less suitable for directly taking on these tasks:

Large game architecture.
Complex character controllers.
Network synchronization.
Core code for commercial projects.
High-precision physics simulation.
Automated submission without human testing.

In other words, it is suitable as a first draft and testbed, not as the owner of production engineering.

What This Shows

This shows that AI coding is continuing to expand from websites, scripts, and backend APIs into game development and interactive prototyping.

Game development used to have a high barrier to entry, especially when engines, scripts, asset management, and physics systems were mixed together. Beginners could easily get stuck. Now models plus Agent tools can first set up the project, letting developers focus on gameplay judgment and effect tuning.

This may bring three changes:

First, game prototypes become cheaper. Many ideas no longer need to wait until full development to be validated; they can first become runnable demos.

Second, indie developers may become more willing to experiment. People who do not know Godot can still use AI to touch the project structure and basic workflow.

Third, model stability becomes more important. Game development is not just about code running. The effect also needs to be reasonable, the feel needs to be normal, and parameters need to be controllable. In the future, models that better combine actual visuals and runtime state will be more suitable for this kind of task.

Summary

DeepSeek V4 Flash for a Godot demo can be summarized in one sentence: not perfect, but cheap enough, fast enough, and suitable enough for prototyping.

It is still far from commercial games, but if the goal is to validate a small game idea at extremely low cost, it is already valuable.

For individual developers, the most realistic use is not handing the whole game to AI, but letting AI first produce a runnable project while humans handle judgment, trade-offs, and polishing. Used this way, low-cost models such as DeepSeek V4 Flash become genuinely appealing.

CC Switch: A desktop tool for managing Claude Code, Codex, Gemini CLI, and OpenClaw in one place

Wed, 06 May 2026 09:03:08 +0800

CC Switch is a desktop management tool for heavy AI coding users. The problem it tries to solve is straightforward: many people now use Claude Code, Codex, Gemini CLI, OpenCode, and OpenClaw at the same time, but each tool has its own configuration format, Provider syntax, MCP setup, and Skills management method.

When you only use one tool, manually editing configuration files is still tolerable. Once several tools are mixed together, plus official accounts, third-party APIs, relay services, local models, and shared team configuration, editing JSON, TOML, and .env files by hand quickly becomes tedious.

CC Switch is positioned as a way to pull these scattered configurations into one cross-platform desktop app.

What problem does it solve

Modern AI coding tools increasingly feel like “development colleagues inside the command line”, but their ecosystems are still not fully unified.

Common pain points include:

Claude Code, Codex, Gemini CLI, OpenCode, and OpenClaw all use different configuration formats.
Switching API Providers requires repeated configuration-file edits.
MCP servers are configured repeatedly across different tools.
Prompt files such as CLAUDE.md, AGENTS.md, and GEMINI.md are hard to maintain consistently.
Skills installation, sync, backup, and removal lack a single central entry point.
Switching between multiple accounts, relays, and model services can easily become confusing.
Once a manually edited configuration file breaks, troubleshooting is costly.

The idea behind CC Switch is to stop forcing users to remember every tool’s configuration details, and instead use one unified interface to manage Providers, MCP, Prompts, Skills, Sessions, and proxies.

Supported tools

The README lists five core supported targets:

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

These tools are similar in positioning: all center on AI coding, Agent workflows, and command-line collaboration. But their configuration systems differ, and the value of CC Switch lies in wrapping those differences.

For people who often compare different AI coding tools, this is much easier than manually opening configuration files every time.

Provider management

The first layer of CC Switch is Provider management.

It includes more than 50 Provider presets. The README mentions directions such as AWS Bedrock, NVIDIA NIM, and various community relays. Users can copy an API key, import it with one click, and then switch from the interface.

The practical points include:

Add Providers with one click.
Reorder Providers by dragging.
Quickly switch from the system tray.
Import and export Providers.
Sync some common Providers across multiple apps.

For many people, this feature alone is already attractive. In daily AI coding work, the problem is often not “I do not know how to use the model”, but “which tool, endpoint, and account should this key use today”.

Local proxy and failover

Besides writing configuration files, CC Switch also provides a local proxy mode.

The focus of this capability is:

Hot-switching Providers.
Format conversion.
Automatic failover.
Circuit breakers.
Provider health checks.
Request correction.

In simple terms, it does not only write configuration into target tools. It can also add a local proxy layer in the middle, so different tools access model services through the proxy.

This is useful for users with multiple Providers: if one service is down, switch to another; if one model is expensive, move to a cheaper one; if a request format is incompatible, adapt it through the proxy layer.

MCP, Prompts, and Skills

The second important layer of CC Switch is unified management for MCP, Prompts, and Skills.

MCP

It provides a unified MCP panel for managing MCP servers across multiple apps, with support for bidirectional sync and Deep Link import.

This is practical for users already working with MCP. Once there are many MCP servers, configuration easily becomes scattered across different clients. A unified panel reduces duplicate configuration and makes migration easier.

Prompts

The Prompts section supports Markdown editing and can sync corresponding files across different tools, such as:

CLAUDE.md
AGENTS.md
GEMINI.md

These files are essentially project manuals for Agents. Unified management makes it easier to maintain team rules, project conventions, and global prompts.

Skills

Skills can be installed with one click from GitHub repositories or ZIP files. Custom repository management, symbolic links, and file copying are also supported.

If you use tools such as Claude Code, Codex, and OpenClaw at the same time, Skills can easily turn into scattered files across different directories. CC Switch centralizes them and reduces maintenance cost.

Sessions and workspace

The README also mentions Session Manager and Workspace features.

It can browse, search, and restore session history from multiple apps. For people who use AI coding tools over a long period, session management is genuinely important: many valuable contexts, debugging trails, and solution comparisons are buried in old conversations.

It also provides a Workspace editor for OpenClaw, allowing users to edit agent files such as AGENTS.md and SOUL.md with Markdown preview.

This shows that CC Switch is not just a small “key switching” utility. It is expanding toward an AI Agent workstation.

Cloud sync and data storage

CC Switch supports syncing Provider data through Dropbox, OneDrive, iCloud, NAS, or WebDAV.

Local data storage is also clearly defined:

Database: ~/.cc-switch/cc-switch.db
Local settings: ~/.cc-switch/settings.json
Automatic backups: ~/.cc-switch/backups/
Skills: ~/.cc-switch/skills/
Skill backups: ~/.cc-switch/skill-backups/

It uses SQLite as the main data source and emphasizes atomic writes and automatic backups, with the goal of avoiding configuration-file corruption during switching or writing.

This design matters for heavy users. If the configuration management tool itself writes a bad configuration, every AI coding tool can be affected.

Installation

CC Switch is a cross-platform desktop app built on Tauri 2.

The approximate system requirements are:

Windows: Windows 10 or later
macOS: macOS 12 Monterey or later
Linux: Ubuntu 22.04+, Debian 11+, Fedora 34+, and other mainstream distributions

Windows users can download the .msi installer or a portable compressed package.

macOS users can install it with Homebrew:

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

To update:

`1`	`brew upgrade --cask cc-switch`

Linux users can choose .deb, .rpm, or AppImage. Arch Linux users can also install it through paru -S cc-switch-bin.

As of May 6, 2026, the repository page shows the latest release as CC Switch v3.14.1, published on April 23, 2026.

Tech stack

Judging from the repository structure, CC Switch is a typical Tauri desktop app:

Frontend: React 18, TypeScript, Vite, TailwindCSS, TanStack Query, shadcn/ui
Backend: Tauri 2, Rust, SQLite, Tokio
Testing: Vitest, MSW, Testing Library

Core design patterns include:

SQLite as the Single Source of Truth.
JSON for device-level local settings.
Writing into target tools’ live config during switching.
Filling current Provider edits back from live config.
Atomic writes using temporary files plus rename.
Locked database connections to avoid concurrent write issues.

This architecture suggests the project is not a simple script, but a desktop tool designed for long-term use.

Who it is for

CC Switch suits these users:

People who use Claude Code, Codex, Gemini CLI, OpenCode, and OpenClaw together.
People who frequently switch between official accounts, third-party relays, local models, or team Providers.
Users already making heavy use of MCP.
Teams that want to maintain CLAUDE.md, AGENTS.md, and GEMINI.md in one place.
Users who often install, test, and migrate Skills.
People who want to view session history and usage across different tools.

If you only use one AI coding tool, rely on official login, and rarely touch Providers, MCP, or Skills, its value may not be obvious.

But if you have already entered a “many tools, many accounts, many Providers, many projects” state, it can remove a lot of repetitive configuration work.

What to watch out for

Tools like this are convenient, but they also need clear boundaries.

First, it manages configuration for multiple AI CLIs, so users should be sure they trust the tool and its write logic.

Second, API keys, relay endpoints, and MCP servers are all sensitive configuration. Before enabling cloud sync, make sure the sync folder and WebDAV service are secure and trustworthy.

Third, after switching Providers, most tools still need the terminal or CLI to be restarted before changes take effect. The README mentions that Claude Code supports hot-switching Provider data, but other tools usually still require a restart.

Fourth, when switching back to official login, it is better to add the official provider according to the project instructions and then rerun the corresponding tool’s login flow.

Summary

The value of CC Switch is not that it creates yet another AI coding tool. Its value is that it acknowledges a reality: the AI coding ecosystem has entered a stage where multiple tools coexist.

Claude Code, Codex, Gemini CLI, OpenCode, and OpenClaw each have their own configuration systems, while MCP, Skills, Prompts, and Providers are expanding quickly. Continuing to edit configuration files by hand will eventually become a burden.

CC Switch pulls these pieces into one desktop app, making it easier to switch Providers, sync MCP, manage Skills, maintain prompt files, and view sessions. For heavy AI coding users, tools like this may move from “optional utility” to “daily infrastructure”.

References

farion1231/cc-switch

Codex App Beginner Guide: Installation, Sandbox, Parallel Tasks, Skills, and MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App can be understood as a task workspace for AI coding. It is not a traditional IDE, nor just a chat window. It brings multitasking, project management, sandbox permissions, Git, cloud execution, plugins, Skills, MCP, and automation into one interface.

If you already use Codex CLI, Claude Code, Cursor, or other coding agents, the most interesting part of Codex App is that it turns “running multiple agents in parallel” into a clearer desktop workflow.

What Codex App Is Good For

The core value of Codex App is not answering questions, but letting AI continuously execute tasks inside a project directory:

Edit code, run commands, and start development servers.
Manage multiple projects and multiple tasks.
Run long tasks locally or in the cloud.
Call plugins, Skills, and MCP for extended capabilities.
Manage changes through Git, worktree, and PR workflows.

OpenAI also positions Codex App as an interface for managing multiple coding agents. It is suitable for people who need to advance several coding tasks at once, especially frontend pages, scripts, small apps, documentation, and automation workflows.

Preparation Before Installation

Before using Codex App, it is best to prepare three basic tools:

Git
Node.js
VS Code or your preferred IDE

Codex App supports macOS and Windows. After installation, sign in with your ChatGPT account. On first launch, you can choose your main usage scenario, such as programming or daily work. Codex will preload some plugins and Skills based on your choices, and you can adjust them later in settings and the plugin marketplace.

The main features on Windows and macOS are broadly similar, but some computer automation capabilities may depend on platform and plugin support. Use whatever your current version actually displays.

Interface Structure: Projects, Tasks, and Chats

Codex App uses a classic three-column layout:

Left: projects, tasks, chat history, plugins, and automation entry points.
Middle: current chat window.
Right: files, browser, terminal, run results, and other panels.

A project usually corresponds to a local folder. You can open multiple chats inside the same project, or open several projects at once so different agents can work in parallel.

The task list shows different states:

Running: the agent is still executing.
Waiting for approval: you need to confirm permissions, networking, dependency installation, or a high-risk action.
Completed: the task has finished, and you can inspect the result or continue asking.

This is more intuitive than switching between multiple terminal windows, and it is better suited to managing several AI tasks at once.

Sandbox and Permission Control

Codex App’s permission system is built around the sandbox. By default, the current project folder becomes the agent’s main workspace.

Common permission boundaries include:

It can read and modify files inside the project directory.
It cannot freely modify files outside the project by default.
Networking or high-risk commands are restricted by default.
When elevated access is needed, it asks the user for approval.

A practical mode is “auto review”: low-risk actions are automatically allowed, while high-risk actions are still confirmed by the user. This reduces frequent pop-ups while keeping dangerous operations from happening silently.

“Full access” should be enabled cautiously. It is suitable when you know exactly what the agent needs to do and the project already has Git backups and important files have separate backups. It is not recommended as a long-term daily default.

Context, Models, and Quotas

Codex App shows the current chat’s context usage. The longer the conversation and the more history it contains, the more context the model needs to process.

Useful habits:

Start a new chat after finishing a task.
Long chats can be compressed manually, but do not treat compression as perfect memory.
For complex tasks, clearly state goals, boundaries, and acceptance criteria.
Do not dump large irrelevant logs, errors, or files into a chat all at once.

For model selection, adjust reasoning strength according to task complexity. Simple edits, writing, and repetitive tasks do not always need the strongest model. Architecture migration, difficult bugs, and cross-file refactors are better suited to stronger models.

If the interface has a fast mode, remember that it usually consumes more quota. Use it when speed matters, but not as a daily default.

Image Generation and Multimodal Inputs

Codex App can accept images and files as context, and can call image generation in suitable scenarios.

This is useful for frontend and content projects. For example, you can ask Codex to:

Fix page styles based on screenshots.
Replace unsuitable images in a webpage.
Generate product images, carousel images, or page assets.
Point out what needs to be changed from a UI screenshot.

A more efficient approach is not to say only “make it look better”, but to use screenshots and point to concrete problems, such as “the spacing in this card is too large”, “this image does not match the service scene”, or “make the map area clearer”.

Steer: Correcting Direction During Execution

Steer can be understood as taking over the direction during execution. If the agent has already started but you realize it misunderstood the direction, you should not always wait for it to finish before correcting it.

You can use steering to insert a new instruction into the current execution flow and make Codex correct course.

Good use cases for Steer include:

The agent misunderstood the requirement.
The generated page style is clearly wrong.
The current plan is too expensive or heavy.
You need to add a key constraint temporarily.

In general, keep the default queued behavior and manually use Steer only when intervention is needed. This avoids disrupting normal tasks while still letting you pull the direction back at key moments.

Plan Mode and Built-In Browser

For complex tasks, start with plan mode. In plan mode, Codex does not immediately modify code. It first outputs a plan and may ask key questions with cards.

Tasks suitable for plan mode include:

Framework migration, such as moving a React project to Next.js.
Large refactors.
Features involving databases, authentication, or deployment.
Requirements where you have not decided the technical path.

The right panel in Codex App can open a built-in browser to preview the local development server. You can annotate the page and let Codex modify a specific UI location. This “look at the page, click the position, ask AI to change it” workflow is often better for frontend debugging than pure text descriptions.

Git, IDE, and Code Rollback

Codex App is not a full IDE. It can view code and add annotations, but handwritten editing is still better done in VS Code, Cursor, Windsurf, or another IDE.

Every Codex project should initialize Git early:

Ask Codex to create or check .gitignore.
Commit once after reaching a usable state.
Ensure a clean commit point before each large change.
Roll back with Git if you are not satisfied.

If you roll back only the chat history, the code will not automatically roll back. A safer approach is to return the chat to the right point, then use a Git commit hash to return the code to the corresponding state.

Worktree: Parallel Development in Multiple Directions

git worktree is especially suitable for parallel agents in Codex App.

It creates multiple independent working directories from the same repository, each corresponding to a different branch. This lets different agents work in different folders at the same time without overwriting each other.

Typical usage:

One worktree optimizes the customer review component.
One worktree adjusts store information and map layout.
Merge both tasks back to main after completion.
Remove temporary worktrees after merging.

This is much safer than letting multiple agents modify code in the same directory. If conflicts happen, review and merge them using normal Git workflows.

Cloud Execution Environment

Codex can work not only on your local machine, but also in a cloud environment.

Cloud execution is suitable when:

You are outside and only have a phone.
You want agents to run long tasks in the background.
The code has already been synced to GitHub and Codex needs to modify the remote repository.
You want changes reviewed and merged through PRs.

A typical flow is: push local code to GitHub, let Codex pull the repository in a cloud environment, execute the task, generate changes, then present them as a PR or diff for review.

When continuing local development, remember to pull down the latest remote changes.

Memory System: Write a Good AGENTS.md

New chats do not have complete historical memory by default. Once a project becomes complex, repeatedly explaining the background is inefficient.

The most general solution is to maintain AGENTS.md in the project root. This file can record:

Project goals and main tech stack.
Common commands.
Directory structure.
Code style and naming conventions.
Prohibited actions, such as bulk deleting files.
Test, build, and deployment rules.

You can also ask Codex to read the project and generate a first version of AGENTS.md, then review it manually. For complex projects, this file is worth maintaining.

Global rules should be used carefully. They are suitable for universal safety constraints, such as “do not recursively delete directories” or “confirm before destructive operations”. Do not put project-specific details into global rules, or they will pollute other projects.

Plugins and Automations

Plugins connect Codex to external services such as GitHub, Gmail, Google Drive, databases, and deployment platforms.

Their value is reducing copy and paste. For example, Codex can:

Check star trends for a GitHub repository.
Summarize email content and send it to you.
Run a recurring check.
Write the result as a summary.

Automations are suitable for repeated tasks. For example, checking repository data every Friday afternoon and sending an email report. Simple automation tasks usually do not require the strongest model; a lighter model is enough.

Skills: Turn Workflows Into Reusable Capabilities

Skills are “professional playbooks” for Codex. They are not one-off prompts. They package a task flow, rules, scripts, and notes so Codex can reuse them reliably later.

Common sources include:

Official Skills.
Third-party Skills.
Skills you write yourself.

Good candidates for Skills include:

Turning subtitles into illustrated notes.
Writing weekly reports in a company format.
Batch-processing images or documents.
Fixed-format code reviews.
Project initialization for a specific framework.

If you have copied and pasted the same prompt many times, it is worth turning it into a Skill.

MCP: Connect External Tools and Databases

MCP can be understood as a standardized tool protocol for large models. Through MCP, Codex can call external services to complete more concrete tasks.

For example, after connecting Supabase, Codex can:

Create database tables.
Read database schemas.
Modify backend endpoints.
Submit frontend forms to the database.
Debug problems based on database state.

This is powerful, but permissions matter. Databases, production environments, deployment platforms, and email accounts are high-risk resources. When connecting for the first time, use a test project and a low-privilege account.

Deployment Plugins

Deployment platform plugins can let Codex complete builds and releases directly, such as deploying a frontend project to Netlify.

These plugins are suitable for small websites, prototypes, internal tools, and demo projects. In real use, pay attention to:

Run a local build before deployment.
Do not write environment variables directly into code.
Check whether the page opens normally after publishing.
Keep human review for production projects.

AI can help connect the deployment flow, but deployment permissions should still be managed carefully.

Computer Automation

With supported platforms and plugin environments, Codex can also operate browsers or desktop apps, completing tasks closer to RPA.

Examples:

Open a chat app and prepare a message.
Browse a project board and summarize task status.
Generate an English brief.
Send it to a specified recipient after you confirm.
Turn the flow into a scheduled automation.

These capabilities are imaginative, but they require the strongest safety boundaries. Any operation involving sending messages, sending email, submitting forms, payments, or deleting data should retain human confirmation.

Usage Suggestions

The right way to use Codex App is not to let it fully take over everything at once, but to break tasks down and let it execute efficiently in a controlled environment.

Recommended habits:

Initialize Git for every project.
Use plan mode for complex tasks.
Use worktree for parallel tasks.
Put project rules in AGENTS.md.
Keep human confirmation for high-risk actions.
Turn repeated workflows into Skills or automations.
Validate plugins and MCP in a test environment first.

References

Summary

Codex App is not “one more AI chat window”. Its focus is turning AI coding into a manageable workspace where local projects, cloud tasks, Git, worktree, plugins, Skills, MCP, and automation can connect.

The key to using it well is balancing freedom and control. Small tasks can be handed to Codex boldly. Complex tasks should start with a plan. High-risk actions must be confirmed. Used this way, Codex can become not just a code-writing assistant, but a long-term engineering tool.

Silicon Valley CTOs Are Joining Anthropic as MTS: Is It Really Just Idealism?

Wed, 06 May 2026 08:39:25 +0800

A notable trend has emerged in Silicon Valley: some people who had already become CTOs, co-founders, or CPOs are leaving their companies and joining Anthropic as Member of Technical Staff, commonly shortened to MTS.

On the surface, this looks like moving from an executive role back to an ordinary technical position. But in the context of the AI industry, it looks more like the previous generation of software and internet elites choosing a new power center, a new career label, and a new form of leverage.

The Event Itself: Executives Move Toward Frontier Labs

What makes this shift interesting is that these are not junior engineers. They are people who already held executive titles. They used to control teams, budgets, roadmaps, and organizational influence. Now they are choosing to enter frontier AI labs like Anthropic and take roles closer to hands-on technology and product implementation.

In traditional technology companies, CXO means organizational power: how many people you manage, how much budget you control, and how much say you have over the roadmap. But in frontier AI companies, the source of power is changing. What is truly scarce may no longer be the size of the organization you manage, but how close you are to models, data, productization capability, and enterprise deployment scenarios.

So MTS should not be simplistically understood as a low-level role. At companies like Anthropic and OpenAI, MTS is often a senior technical position. It may not come with a large direct team, but it can be closer to model capabilities, product decisions, and enterprise customer needs.

Why This Is Happening Now

This shift is not an isolated personal choice. It is the result of several industry forces converging.

First, technology itself has become important again. After many technical people become CTOs, their daily work shifts from coding to management, hiring, budgets, roadmaps, and company politics. With large models emerging, the technical front line has again become the place with the highest leverage. The closer someone is to models, the more likely they are to understand the next generation of product forms, organizational models, and business models.

Second, the growth narrative of traditional software companies is weakening. Mature SaaS companies can still make money, but it is hard for them to tell the early-stage story of tenfold or hundredfold growth. AI search, AI IDEs, and agent tools are also being squeezed by foundation model companies. When model companies move upward into the application layer, many previously promising markets get revalued.

Third, the career market is being repriced. In the past, the most valuable label for an executive might have been “took a company public”, “completed an acquisition”, or “helped investors exit”. But if a company’s growth stalls, the IPO window narrows, or its sector is rewritten by AI, the executive’s label can become awkward. Moving to Anthropic is essentially a way to acquire a new label that fits the AI era.

Power Shift: From Organizational Power to Model Power

Traditional technology companies derive power from organizational structure: how many people you manage, how many systems you control, and how much budget you decide.

In the AI era, the new source of power is becoming something else:

How close you are to the strongest models.
Whether you can mobilize model capabilities.
Whether you can turn model capabilities into products.
Whether you can use AI to amplify individual and team output.

From this perspective, a CTO joining Anthropic as an MTS is not necessarily a downgrade. More accurately, it is a switch from organizational power in a traditional software company to model power in a frontier AI company.

Software companies used to build moats through organization, sales, channels, compliance, customer success, and accumulated business processes. Now agents, Claude Code, enterprise automation tools, and model APIs are revaluing those moats. Whoever can embed model capabilities into real workflows can capture new growth.

The Original Companies: Maturity, Pressure, and Exit Windows

The companies these executives leave are not necessarily failures. Many still have revenue, customers, teams, and stable businesses. The problem is that their industry position has changed.

Once mature SaaS companies enter a stable growth phase, it becomes harder for them to offer executives major career upside. AI search, AI IDEs, and many vertical AI applications are directly pressured by foundation model companies. Companies that are still growing but not yet public face another practical issue: whether capital markets will accept them, whether post-IPO valuation can hold, and whether investors can exit smoothly.

This creates real pressure. Staying at the original company may bring labels such as “mature business operator”, “executive during a slowdown”, or “leader of a sector rewritten by AI”. Joining Anthropic creates the opportunity to gain labels like “frontier lab experience”, “enterprise AI productization”, and “agent-era organizational knowledge”.

Career Labels: Not Abandoning Leverage, but Switching Leverage

CTOs at growth-stage companies are not always the people who built the core system from zero to one. When a company reaches Series B or C, or prepares for IPO or acquisition, it often adds executives to complete the leadership team and make the company look more governable, auditable, and financeable.

The value of these executives lies in:

Completing technical teams and management processes.
Increasing investor confidence.
Helping the company tell a credible financing, IPO, or acquisition story.
Accompanying the company to the next financing round, IPO, or acquisition.

In venture capital terms, the most important label for this kind of person is “successful exit”. If someone has helped a company go public or get acquired, they become more valuable to investors. Conversely, if a company’s growth stalls, fails to list, or is rewritten by AI, the executive may carry an unattractive label.

So joining Anthropic is not abandoning leverage. It is switching leverage. The old leverage was “I can take a company public or through acquisition”. The new leverage is “I have worked on models, agents, and enterprise AI deployment inside a frontier AI lab”.

The next time they start a company, join a new company, enter the investment ecosystem, or help traditional enterprises with AI transformation, these experiences become a new premium.

Anthropic’s Calculation: Absorbing Old Software Expertise

Anthropic is not merely accepting people with ideals. It needs these people because model companies cannot enter the enterprise market with model researchers alone.

These executives may not be the strongest model training experts, but they understand software engineering, enterprise customers, organizational processes, hiring systems, productization, and public company governance. They know how enterprise customers buy, who pushes or blocks adoption inside large organizations, and how a tool must fit into workflows to actually sell, be used, and renew.

This matters to Anthropic. Its battlefield is no longer just model APIs or the Claude chat interface. It also wants to enter enterprise workflows, software development, knowledge management, consulting services, and AI transformation for companies backed by private equity.

To enter these scenarios, Anthropic needs people who know the old software world map: where customer pain points are, where organizational resistance appears, where budgets sit, how compliance and governance work, and how to package products into services enterprises can buy.

Industry Impact: Talent and Capital Are Voting Again

The consequences of this shift may unfold along several lines.

First, talent loss from traditional software companies may accelerate. In the past, strong executives moved among mature software companies, growth-stage SaaS firms, and pre-IPO startups. Now frontier AI labs have become a new high ground. Talent voting with its feet will also affect how capital evaluates sectors.

Second, enterprise software will be revalued. Enterprise software used to sell processes, permissions, reports, compliance, and customer success. In the future, enterprise customers may care more about whether the software can let AI agents complete work directly, reduce labor, connect to model capabilities, and become part of an automated workflow.

Third, executive career paths will change. The traditional path of joining a growth company, helping with financing, pushing toward IPO, and exiting through equity will narrow. A new path may emerge: join a frontier model company, understand AI-native organizations and products, then take that experience into the next company, startup, or enterprise AI transformation project.

Fourth, model companies will increasingly resemble enterprise service companies. They will not only sell APIs, but also tools, workflows, consulting, industry solutions, and organizational transformation. Anthropic’s attraction of old software executives is a way to build this capability.

Idealism and Realistic Interest Can Coexist

This cannot be reduced to either pure idealism or pure financial calculation.

Many technical people genuinely love technology and want to return to the front line. In a period of rapid model evolution, working close to frontier systems is highly attractive. But career labels, financial leverage, industry position, and future exits also matter.

Human motivations are usually mixed. Idealism and practical interest do not contradict each other. A person can believe in the long-term value of AGI or enterprise AI while also knowing clearly that joining Anthropic now will make their next career narrative more valuable.

Core Judgment: AI Is Reordering Industry Power

The most important point about executives moving to Anthropic is not the change in individual titles, but that AI is reordering power across the software industry.

In the past, the more people you managed, the closer the company was to IPO, and the higher your title was, the more valuable you were as a CXO. Now, people who are closer to models, better at productizing model capabilities, and more capable of wielding powerful AI systems are becoming scarce again.

For individuals, joining Anthropic means changing labels, leverage, and narrative.

For Anthropic, attracting these people means stockpiling old software-world expertise for the enterprise battlefield.

For traditional software companies, talent and capital are already voting again.

For ordinary programmers, the most important future capability may not be how many people you manage, but whether you can wield the strongest AI systems and turn them into real productivity.

Summary

Silicon Valley CTOs joining Anthropic as MTS is not simply a story of executives being demoted.

It looks more like an industry power migration: smart people from the previous generation of software companies are judging where the next center of leverage will be. On the surface, they are leaving management roles. In reality, they may be leaving old tracks and attaching themselves early to the new labels of the AI era.

If more traditional software executives, AI application founders, and mature SaaS technical leaders move toward model companies, this will no longer look like individual career choice. It will look like the talent structure and capital narrative of the software industry shifting as a whole.

May 2026 Edge High-Risk Vulnerability CVE-2026-2441: Malicious Pages May Trigger Remote Code Execution

Wed, 06 May 2026 08:30:17 +0800

Microsoft Edge has recently released several rounds of security updates to fix multiple issues from the Chromium project and Edge components. Among them, CVE-2026-2441 has been reported by the Chromium team as exploited in the wild, and fixes have been provided for both the Microsoft Edge Stable and Extended Stable channels.

If you use Edge for daily browsing, especially on Windows devices used for account logins, email, online banking, admin consoles, or enterprise systems, you should confirm that the browser has been updated to the latest version.

Vulnerability Risk

CVE-2026-2441 is a high-risk vulnerability that has already attracted attacker attention and has been exploited. A common browser attack path is to lure users to a page containing specially crafted content, then trigger a flaw in the rendering engine or related components.

In real attacks, this type of vulnerability may lead to the following risks:

Execute malicious code or chain with other vulnerabilities to break through sandbox restrictions.
Bypass some security controls and expand the attack surface.
Steal sensitive browser data, session information, or page content.
Cause browser crashes, abnormal page behavior, or denial of service.

Official vendors usually do not disclose full attack details immediately after a patch is released, to avoid making the vulnerability easier to reproduce. For most users, the most effective protection is to update promptly.

Affected Scope

Microsoft Edge is based on Chromium, so related vulnerabilities can affect Edge versions across multiple platforms, including Windows, macOS, Linux, and mobile versions. Any browser version below a fixed release remains at risk.

According to the Microsoft Edge security update release notes, Edge Stable Channel 145.0.3800.58, released on February 14, 2026, includes the fix for CVE-2026-2441; Extended Stable Channel 144.0.3719.130, released on February 17, 2026, also includes the fix. Later versions continue to include accumulated Chromium security patches.

As of May 6, 2026, the latest Stable Channel security version listed on the Edge security update page is 147.0.3912.98, released on April 30, 2026. If your local version is clearly older than these releases, update immediately.

Update Edge Now

Regular users can check and update Edge with these steps:

Open Microsoft Edge.
Enter edge://settings/help in the address bar and press Enter.
Wait for the browser to check for updates automatically.
After the update finishes, click “Restart”.

In enterprise environments, administrators should check endpoint management policies, WSUS, Intune, Group Policy, or third-party patching systems to make sure Edge updates are not being delayed for too long. For devices that cannot be updated immediately, reduce access to unknown websites and prioritize limiting external web access for high-risk user groups.

Protection Suggestions

Upgrade Edge as soon as possible and restart the browser after the update.
Do not click email links, chat links, or ad redirects from unknown sources.
Avoid using outdated browsers to access admin consoles, payment services, email, or other sensitive pages.
Keep Windows, antivirus software, and browser extensions updated.
Remove browser extensions that are unused or from unclear sources.

References

Summary

The key point about CVE-2026-2441 is not how complex the vulnerability details are, but that it has been reported as exploited in the wild. For personal users and enterprise endpoints, the most direct response is to open edge://settings/help, confirm that Edge has finished updating, and restart the browser.

Why ChatGPT Says 'This Chat Was Flagged for Possible Cybersecurity Risk' and What to Do

Wed, 06 May 2026 00:17:00 +0800

When using ChatGPT or similar large language models, you may occasionally see a notice: “This chat was flagged for possible cybersecurity risk.” This means the platform’s automated safety system has detected that the conversation may violate its usage policies.

Below is an analysis of what triggers this notice, what it actually affects, and how to respond.

Why a Chat May Be Flagged

Sensitive Input

The conversation may contain content that could be interpreted as harmful, such as:

Requests to generate malicious code or scripts.
Analysis or exploitation of network vulnerabilities.
Questions related to illegal activities.
Instructions for bypassing security restrictions.

False Positive

Even when the intent is legitimate code analysis or technical research, the system may still misread cybersecurity-related terminology as a potential attack attempt. AI moderation models tend to be sensitive to keywords, and the line between technical discussion and offensive behavior is not always precise.

Platform Review Mechanism

The system automatically scans conversation content for risk assessment. In newer versions, such as the April 2026 update, this kind of notice appears more often, suggesting that the platform may have introduced a stricter external review process.

What Happens After the Notice Appears

The current chat may be stopped: The platform may restrict or halt generation in the current conversation.
Risk records: Repeated risk-control triggers may be recorded, and accumulating too many of them could affect account status.
A trend toward higher sensitivity: Review mechanisms are becoming stricter, making technical discussions more likely to hit boundary cases.

How to Handle It

Start a New Chat

The most direct approach is to abandon the current conversation and click “New Chat” to start fresh. The previous context will no longer carry over, so the same moderation trigger usually will not repeat.

Adjust Your Prompt

Review what you entered earlier, remove terms that may be judged sensitive, and ask in a more neutral way. For example, change “how to bypass a certain restriction” to “what is the principle behind this restriction,” or change “how to write an attack script” to “what mechanisms do scripts of this type typically use.”

Do Not Try to Bypass It

Avoid using prompt injection or similar methods to force the AI to answer questions it has refused. This increases the risk of account penalties and often backfires.

Check the Nature of Your Activity

If you were not doing anything high-risk, such as analyzing phishing links or writing malware, the issue is most likely the AI misreading technical concepts. In that case, you can consider reporting it to the platform, though the short-term effect is usually limited.

Protect Privacy

Do not submit content containing sensitive personal information or trade secrets for AI analysis. Even if it does not trigger risk control, there is still a risk of data leakage.

Prevention Tips

Use neutral wording as much as possible when discussing technical topics.
Avoid concentrating a large number of sensitive topics in a single conversation.
Regularly clean up unnecessary chat history.
Avoid frequently testing moderation boundaries on important accounts.

Summary

“This chat was flagged for possible cybersecurity risk” is usually triggered by automated moderation and does not necessarily mean the account has violated rules. The priority is straightforward: start a new chat > adjust the wording > do not fight the system head-on. In daily use, paying attention to wording boundaries can prevent most triggers.

Why ChatGPT and Codex Ask for Phone Verification at Login

Wed, 06 May 2026 00:07:43 +0800

Recently, some users have run into a situation where their ChatGPT account has already been registered, but the system asks for phone verification again when logging into ChatGPT or Codex. This is especially confusing with Codex: the account was fine for signup, so why ask for a phone number when logging into the tool?

This is usually related to account risk controls, abuse of free quotas, network environment, and account security policies. Below is a summary of common causes and how to approach them.

Why phone verification is required

The most direct reason is tighter risk controls.

Once Codex opens up to users, its free quota attracts not only legitimate users but also mass registration and quota-farming. When registration bots create accounts in bulk and drain free quotas, platforms naturally tighten verification policies.

From the user’s side, the result looks like: an account that previously only needed email or third-party login is suddenly asked for a phone number when accessing ChatGPT or Codex.

This does not necessarily mean your account has a problem. It may simply be that the login environment looks risky. For example:

You are using a network exit shared by many users.
The current IP range has been heavily used for registrations or suspicious logins.
The account is brand new but immediately accesses a resource-intensive tool.
The device, region, or network changes frequently.
Free-tier usage patterns resemble those of bulk accounts.

If you recently experienced account anomalies, login restrictions, or false bans, your network environment may have been flagged along with others using the same exit. Shared nodes used by many people carry inherently higher risk.

Why Codex triggers it more often

Codex differs from normal chat—it is closer to a development tool, potentially involves heavier resource usage, and is more attractive for bulk accounts draining free quotas.

So it is not unusual for the same account to look fine on the regular ChatGPT page but hit phone verification in the Codex login flow. Think of it as different product entry points applying different risk judgments.

For normal users, this kind of verification is usually not targeting individuals—it is aimed at curbing mass registration and quota abuse. But if your network environment is not clean, you can get caught in the crossfire.

Approach 1: Upgrade to Plus

If you use ChatGPT or Codex long-term, the simplest fix is upgrading to ChatGPT Plus.

In practice, paid accounts are generally less likely to trigger quota-abuse risk controls than free accounts. A Plus account is also better suited for stable use of Codex, advanced ChatGPT models, and other high-frequency features.

That said, upgrading to Plus does not mean you will never see another verification prompt. If it still asks for a phone number after upgrading, the common cause is still the network environment.

At this point, check:

Whether you are on a shared network used by many people.
Whether your exit IP keeps changing.
Whether you have been using low-quality proxies or public nodes long-term.
Whether many OpenAI accounts are active on the same network.

If possible, switching to a more stable and cleaner network environment before logging in is usually more effective than repeated retries.

Approach 2: Check your network environment

Many login verification problems that look like account issues are fundamentally network issues.

If a particular exit IP is shared by many users, or has been used for bulk registration, suspicious logins, or automated requests, it is more likely to be flagged. When that happens, even a legitimate user may be asked for additional verification when logging into ChatGPT or Codex.

Check from these angles:

Switch to a more stable network environment.
Avoid public, cheap, high-user-count shared nodes.
Minimize frequent region switches over short periods.
Do not rapidly switch between multiple accounts in the same browser.
If using a proxy, prefer lines with more stable quality and less abuse history.

You can also use third-party network quality detection tools to check the risk profile of your current IP, but such results are only a reference and do not fully represent OpenAI’s internal assessment.

Approach 3: Complete the phone verification as required

If the system explicitly asks for phone verification, the safest approach is to complete it as requested.

It is advisable to use a phone number you can keep long-term. That way, if your account later needs security verification, recovery, or alerts, you can handle them.

Do not bind important accounts to numbers of unknown origin, shared numbers, or numbers you cannot keep. It may get you through the short term, but in the long run it creates risks for account recovery, security audits, and secondary verification.

If you are using a work account, team account, or a development account you rely on heavily, you should especially avoid temporary numbers you cannot control. Account security matters more than short-term convenience.

What to watch for when upgrading to Plus

If you plan to upgrade to Plus, confirm a few things first:

The account itself can log in normally.
The current network environment is stable and not frequently hopping regions.
The payment method is reliable—do not use third-party proxy payments of unknown origin.
After upgrading, keep the payment record and account email safe.
Do not share the account with multiple people.

Many account problems are not caused by Plus itself, but by the network, payment, and sharing habits around the upgrade. An account that is shared by many, logged into from different locations, and frequently environment-switched can trigger security verification even if it is paid.

If you are only trying it out occasionally, a free account works fine. But if you already use Codex as a daily development tool, Plus is better suited for long-term use.

Quota farming is not recommended

The free quota for tools like Codex is meant to let regular users try and experience the product. If large numbers of bulk accounts continuously drain that quota, the platform has no choice but to keep tightening risk controls.

The result is that normal users get affected too: more login friction, more verification steps, more false bans, and higher account usage costs.

For people genuinely using Codex for coding, modifying projects, and running engineering tasks, it is more worthwhile to clean up the account and network environment than to spend time dodging risk controls. In the long run, that is easier than constantly registering new accounts, switching nodes, and dealing with verification issues.

Summary

When ChatGPT or Codex asks for phone verification at login, it is usually tied to account risk controls, free-quota abuse, and network environment risk. It does not necessarily mean the account violated any rules, but it does indicate that the current login environment or account state triggered a higher verification level.

The order of action is straightforward:

First check the network environment; avoid shared high-risk exits.
If you are a long-term user, consider upgrading to Plus.
If the system requires phone verification, use a number you can control long-term.
Avoid bulk registration, account sharing, and frequent login-environment switching.

The core of stable AI tool usage is not about bypassing verification forever—it is about keeping the account, network, and usage patterns as normal as possible. That reduces login friction and lowers the chance of collateral damage later.

Use Tests and Behavior Descriptions to Keep AI Coding Under Control

Tue, 05 May 2026 14:35:38 +0800

When you use AI to write code, the common pattern is easy to recognize: the beginning feels fast, and the later stages get messy. A feature can be scaffolded quickly at first, but once the project grows and the number of changes increases, fixing one bug can easily create three more.

This is not entirely an AI problem. Many human developers write code this way too. AI simply writes faster, so the problems surface faster. To reduce this loss of control, the key is not to make AI “try harder”, but to give it clearer boundaries: define what counts as correct first, then ask it to implement.

TDD and BDD fit naturally into an AI coding workflow. TDD turns “is this correct?” into automated tests. BDD turns “is this the feature I actually want?” into behavior descriptions that humans can read. Used together, they reduce guessing, limit free interpretation, and make the result easier to review.

What TDD Solves

TDD stands for Test-Driven Development. Its basic sequence is:

Write the test first.
Run the test and confirm that it fails.
Write the feature code.
Keep adjusting the implementation until the test passes.

This is the opposite of how many people naturally work. If you are writing a sorting function, the intuitive approach is to write the function first, then try a few inputs and see whether the results look right. TDD asks you to write the expected behavior as tests first. For example, input [3, 1, 2] should return [1, 2, 3], an empty array should return an empty array, and an array with duplicate values should still be sorted correctly.

The point is that the correct result is defined before development begins. Later, no matter who changes the code, rerunning the tests tells you whether previously agreed behavior has been broken.

Why TDD Used to Be Hard to Keep Up

TDD sounds great, but it is not easy to practice consistently in real projects.

First, it feels counterintuitive. When facing an empty file, many people would rather write the feature first than write tests first. This is especially true when the requirement is still unclear, because test cases are hard to write when the behavior itself is fuzzy.

Second, requirements change quickly. A dozen carefully written tests today may need to be rewritten tomorrow after the requirement changes. In the short term, TDD can slow the development rhythm.

Third, tests have their own cost. Test code does not appear out of nowhere. In the past, developers had to write it, maintain it, and explain its value. In teams that only care about short-term delivery speed, this work is easy to squeeze out.

AI changes that cost structure. Turning requirements into test code is exactly the kind of work AI is good at. Asking AI to implement against tests is also far more reliable than asking it to freely interpret a vague paragraph.

How to Use TDD When AI Writes Code

When using AI to build a feature, change the prompt from “implement this feature for me” into this sequence:

Ask AI to list test cases from the requirement first.
Require each test case to include a plain-language explanation.
Review whether the test cases match the real requirement.
After confirming the tests, ask AI to implement the feature.
Ask AI to run the tests and keep fixing based on failures.

At this point, the main thing you review is no longer a large block of implementation code. Instead, you review whether the tests describe the requirement clearly. Test cases are usually closer to “what is the input, what should the output be, and how should edge cases behave”, which is much easier than reading implementation logic directly.

For example, you can ask AI like this:

1
2
3

Do not implement the feature yet.
Write test cases based on the requirement below. Add a plain-language comment to each test case explaining the business rule it covers.
After the tests are confirmed, implement the code according to the tests.

This workflow reduces two common problems: AI drifting away from the requirement while coding, and later changes breaking old behavior.

TDD Is Not Enough

TDD alone still leaves two gaps.

The first gap is that passing tests does not mean the product actually meets expectations. Tests only prove that the code satisfies the rules written into the tests. If the tests themselves fail to express the user need clearly, the code may still “correctly do the wrong thing”.

The second gap is that test code is still unfriendly to non-technical users. Even with plain-language comments, many people do not want to read through a pile of unit tests. The more product-oriented a requirement is, the harder it is to confirm from test code alone that “this is what I wanted”.

That is where BDD helps.

What BDD Solves

BDD stands for Behavior-Driven Development. It focuses less on how code is written internally and more on how the system should behave in a given scenario.

BDD often uses the Given / When / Then format:

Given: a specific starting state.
When: an action performed by the user or system.
Then: the expected result.

For example, a game character with a lifesteal effect can be described like this:

Given there is a vampire on the board with 1 remaining HP, 2 attack, and 5 max HP
And an adjacent enemy unit has 10 remaining HP
When the vampire attacks that enemy unit
Then the enemy unit has 8 remaining HP
And the vampire recovers to 3 HP

This is not code, but it is much more precise than “recover health when attacking an enemy”. It describes the initial state, the action, and the result. It also exposes rules that need clarification: if the enemy only has 1 HP left, should the vampire recover based on damage dealt or attack value? If the vampire is already at full health, what happens to excess healing?

The earlier these questions appear, the less AI has to guess later.

Why BDD Fits AI So Well

BDD also used to have a high adoption cost. It asks product, engineering, and testing teams to communicate with the same behavior descriptions. In reality, many teams do not have that collaboration habit.

In the AI era, the cost of BDD drops. You can start with a rough requirement such as:

`1`	`After the vampire attacks an enemy, it recovers health equal to the damage dealt.`

Then ask AI to generate Given / When / Then scenarios. A good AI will add edge cases and ask about unclear rules. Your job is to confirm those behavior descriptions, not read the implementation code directly.

Once the behavior descriptions are clear, ask AI to convert them into tests, and then implement the feature based on those tests. The path becomes much smoother.

A More Reliable AI Coding Workflow

In practice, you can chain BDD and TDD together:

Write the requirement in natural language.
Ask AI to convert it into BDD behavior scenarios.
Confirm whether the Given / When / Then scenarios match your expectation.
Ask AI to convert the behavior scenarios into automated tests.
Quickly review test coverage.
Ask AI to implement the feature.
Run the tests. If they fail, ask AI to fix the code based on the errors.
Finish with manual acceptance and code review.

The key is the order. Do not ask AI to write the full implementation at the beginning. First ask it to turn the requirement into reviewable behavior, then into executable tests. This leaves much less room for free interpretation.

You can use a prompt like this:

Handle this requirement using a BDD + TDD workflow.

Step 1: First organize the requirement into Given / When / Then behavior scenarios. Do not write code.
Step 2: List any unclear rules you find and ask me to confirm them.
Step 3: After the behavior scenarios are confirmed, convert them into test cases.
Step 4: After the tests are confirmed, implement the feature.
Step 5: Run the tests and fix failures until all tests pass.

This kind of prompt is not complicated, but it can noticeably change how AI works. It narrows the requirement first, then moves into implementation, instead of immediately producing code that looks complete but is hard to verify.

Where to Use It First

BDD + TDD is not necessary for every task. For one-off scripts, temporary data processing, or small style tweaks, the full workflow may be too heavy.

It is better suited to these cases:

Business rules are numerous and easy to misunderstand.
There are many edge cases, and the feature will continue to change.
Logic-heavy features such as games, billing, permissions, state machines, and form validation.
Multiple people need to confirm the requirement together.
The code will be maintained for a long time, not generated once and thrown away.
The project already shows signs of AI making things messier after each change.

If you only need AI to change the text on a button, you do not need the full workflow. But if you are building a character skill system, order state transitions, permission checks, or points rules, writing behavior scenarios and tests first is usually worth it.

What to Watch Out For

First, more tests are not always better. Tests should cover key rules and high-risk boundaries, not lock every implementation detail in place. Otherwise, even a small requirement change can turn the tests into a maintenance burden.

Second, BDD scenarios must be specific. Do not write unverifiable descriptions like “the system should work normally” or “the experience should be smooth”. Be clear about the state, the action, and the expected result.

Third, humans still need to review. AI can generate tests and behavior scenarios, but it does not know the product tradeoffs you actually want. Boundary rules in particular must be confirmed by a human.

Fourth, after tests pass, you still need to run the feature for real. Automated tests can catch logic problems, but interface experience, performance, interaction details, and user feel still need manual acceptance.

Summary

AI writes code quickly, but speed is not the same as stability. The more complex the requirement is, the less you should rely on a single “help me implement this” prompt. A better approach is to break the requirement into reviewable behavior, turn that behavior into executable tests, and then let AI implement against those tests.

TDD tells AI what counts as correct. BDD makes it easier for humans to confirm whether the feature is actually what they wanted. Together, they are not about adding ceremony. They are about reducing the space for AI to guess, turning “writes fast” into “changes safely”.

Hard Drive Prices Are Soaring: Do Not Expand Your NAS Yet, Try a $200 TerraMaster + HC620 Cold Data Setup

Mon, 04 May 2026 11:46:53 +0800

When hard drive prices rise sharply, a full NAS does not always need an immediate drive upgrade. If the main NAS is still working normally and only running out of capacity, it is often better to separate data by access frequency: keep frequently used hot data on the original NAS, and move rarely used cold data and backups to a separate cold-storage disk.

This article records a low-cost approach: use large HC620 drives for cold data, then use an inexpensive TerraMaster F2-220, F2-221, or F4 as the migration and mount node. It does not aim for high performance. It solves one practical problem: during a period when upgrading disks is not cost-effective, first free up space on the main NAS.

Idea

Sort data by access frequency first:

Hot data: photos, work files, recent downloads, frequently watched videos. Keep these on the main NAS.
Cold data: old media libraries, archived materials, large files that rarely change. Move these to HC620.
Backup data: data that only needs periodic writes and occasional reads. This can also be stored on HC620.

For HC620 usage scenarios, see the site article: Misunderstandings and Correct Usage of Western Digital HC620 SMR Drives. It is better suited to sequential writes, long-term storage, and random reads. It is not suitable for workloads with frequent deletes and repeated writes.

If the goal is simply to free up space on the main NAS, I do not recommend replacing the main NAS disks on a large scale while hard drive prices are high. Move rarely used data out first, and let the main NAS continue handling hot data. This is usually more cost-effective.

Why Use an Old TerraMaster

The problem with HC620 is not capacity, but convenience. It has requirements for the operating system, interface, and usage pattern, so putting it directly into a USB hard drive enclosure is not a good fit.

An old TerraMaster F2-220, F2-221, or some F4 models can be used as a low-cost cold-data node. The advantages are straightforward:

Cheap. A used F2-220 is often under 200 RMB.
Small footprint and acceptable power consumption.
The system can be installed on a USB drive, so it does not occupy a drive bay.
Two or more SATA bays are available, making it suitable for HC620 archive disks.

These old machines are not powerful, but they are enough for cold-data migration, CIFS mounting, and background copying. Although the F2-220 only has older SATA 3G ports, HC620 can still reach around 200MB/s in outer-track disk-to-disk copies in testing. For cold-data migration, this is not slow. The bottleneck is often the network, the source disk condition, or the number of files.

If the onboard gigabit network is not fast enough, you can also add a USB 2.5G network adapter. A cold-data node does not need complicated modification. As long as the system recognizes the adapter, and both the switch and main NAS support 2.5G, the network bottleneck can be raised noticeably.

Prepare Video Output

If the machine has no HDMI port, you need VGA for system installation. The F2-220 has an internal VGA header. You can use a motherboard internal 12-pin VGA adapter cable: one end connects to the internal header, and the other end exposes a standard VGA connector for a monitor.

For VGA adapter specifications and notes, see: Installing fnOS on TerraMaster F2-220: VGA Output. In short, search terms include “12Pin VGA adapter cable”, “motherboard 12-pin VGA cable”, and “2.0mm 12Pin to VGA”. Before buying, check pitch, direction, and pinout.

Install Ubuntu Server to a USB Drive

Install Ubuntu Server to a USB drive so all hard drive bays remain available for data disks.

The F2-220 is relatively weak, so installing directly on it can be slow. A more efficient method is to plug the USB drive into a faster computer, complete the Ubuntu Server installation there, then move the USB drive back to the TerraMaster. As long as the boot mode is compatible, it usually works directly.

After installation, check the network configuration carefully. Otherwise, the machine may boot but have no network connection, making SSH management impossible.

Configure Networking

After entering the system, check the network interface name first:

`1`	`lshw -c network`

The sample output shows the logical name:

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 07
       serial: 6c:bf:b5:00:63:ab
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.8.0-111-generic duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.8.205 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:17 ioport:e000(size=256) memory:d0604000-d0604fff memory:d0600000-d0603fff

Here the interface name is enp2s0. Then edit the netplan configuration:

`1`	`sudo more /etc/netplan/01-install-config.yaml`

If the file does not exist, create it with this content:

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true

Replace enp2s0 with the actual interface name on your machine. Save the file and apply it:

`1`	`sudo netplan apply`

After the network is restored, you can SSH into the TerraMaster and continue without keeping a monitor connected.

Format HC620 as btrfs

If the HC620 is new, or if all data on it has been confirmed unnecessary, format it as btrfs first. The following operations erase the target drive. Confirm the disk device before running them. Do not format the main NAS share or the system USB drive by mistake.

List current disks:

`1`	`lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS`

You can also check stable disk paths:

`1`	`ls -l /dev/disk/by-id/`

After confirming which device is the HC620, unmount any existing mount point:

1
2

sudo umount /dev/sda 2>/dev/null
sudo umount /dev/sda1 2>/dev/null

If you want to create btrfs directly on the whole disk:

`1`	`sudo mkfs.btrfs -f -O zoned -d single -m single -L HC620_01 /dev/sda`

Parameter notes:

-f: force file-system creation, avoiding old signatures blocking the format.
-O zoned: enable the zoned feature, suitable for drives like HC620 that need zone-aware sequential writes.
-d single -m single: use single-disk mode for both data and metadata.
-L HC620_01: set a label for easier identification.

If your system or kernel does not handle zoned btrfs well, continue with the earlier test notes: Is a New WD HC620 14T Drive for About 600 RMB Worth Buying?. Compatibility for this type of drive depends on kernel version, SATA controller, and file-system support. Do not import real data until the setup behaves normally.

After formatting, test with a temporary mount:

1
2
3

sudo mkdir -p /mnt/disk1
sudo mount /dev/sda /mnt/disk1
df -h

After confirming it mounts correctly, write /etc/fstab for automatic mounting. For long-term use, prefer /dev/disk/by-id/ instead of /dev/sda to avoid device-name changes after reboot.

Configure Mounts

This cold-data node usually needs to mount two types of paths:

The main NAS share, used to read data that needs to be migrated.
The local HC620 data disks, used to store cold data and backups.

Create mount directories first:

`1`	`sudo mkdir -p /mnt/xxxxx /mnt/disk1 /mnt/disk2`

If you need to mount CIFS/SMB shares, install the tools:

1
2

sudo apt update
sudo apt install cifs-utils

Then edit /etc/fstab and add lines like these:

1
2
3

//192.168.x.xxx/xxxxx   /mnt/xxxxx cifs auto,username=xxxxx,password=xxxxx,uid=997,gid=997,file_mode=0777,dir_mode=0777,nofail 0 0
/dev/sda  /mnt/disk1  auto  defaults,nofail  0  0
/dev/sdb  /mnt/disk2  auto  defaults,nofail  0  0

The first line mounts the main NAS share. The next two lines mount local disks.

In real use, prefer stable paths such as /dev/disk/by-id/ for data disks to avoid /dev/sda and /dev/sdb changing order after reboot. HC620 formatting and mounting notes are also covered in the earlier record: Is a New WD HC620 14T Drive for About 600 RMB Worth Buying?.

Test the mount after editing:

1
2

sudo mount -a
df -h

After confirming that both the main NAS share and local data disks appear, start migrating data.

Copy Files in the Background

For large data migrations, do not run plain cp directly in the SSH foreground. The preferred setup here is screen + mc: screen keeps the session alive after SSH disconnects, while mc provides a clearer two-pane file-management interface.

mc is well suited to manually organizing cold data. Open the main NAS mount on the left, open the HC620 data disk on the right, select files, and press F5 to copy. During copying, it shows both current-file progress and total progress, which is much easier to read than raw command-line output when moving many files.

The image above illustrates the copy-progress window. The Midnight Commander manual also notes that copy, move, and delete operations show a file-operation dialog in verbose mode, with current-file and total progress available.

Install the tools:

`1`	`sudo apt install screen mc rsync`

Start a background session:

`1`	`screen -S cold-data`

Run mc inside screen:

mc

The usual workflow is to open the source directory and target directory in the two panels, then operate with shortcuts:

Tab: switch between panels.
Insert: select multiple files or directories.
F5: copy to the other panel.
F6: move or rename.
F8: delete, use carefully.

If you need a more scriptable and repeatable sync task, use rsync instead:

`1`	`rsync -avh --progress /mnt/xxxxx/old-data/ /mnt/disk1/old-data/`

Even if SSH disconnects during copying, the screen session remains alive. Reconnect and run:

`1`	`screen -r cold-data`

You will return to the original copy task.

Usage Advice

This setup is for cold data and backups. Do not use HC620 as a high-frequency write disk. Suggested usage:

Keep hot data and daily services on the main NAS.
Store large long-term files, media libraries, and archive materials on HC620.
Migrate mainly by sequential writes; avoid frequent deletes and repeated small-file writes.
Keep at least two copies of important data. Do not keep the only copy on a single disk.
After migration, sample-check files and confirm that directory and file counts look normal.

If hard drive prices fall later, upgrading the main NAS array can still be considered. For now, using a low-cost node to relieve capacity pressure keeps both risk and spending more controllable.

Summary

When NAS space is full, buying new drives immediately is not the only answer. Treat the main NAS as the hot-data device, treat HC620 as cold-data and backup storage, and use a cheap TerraMaster F2-220, F2-221, or F4 as the mount and copy node. This is a low-cost and practical transitional setup.

The key is not performance, but division of responsibility: the main NAS keeps the daily experience smooth, while cold data is stored separately. This frees up space and avoids a large upgrade cost during a period of high hard drive prices.

How the NCP45521 Load Switch Works

Mon, 04 May 2026 06:49:33 +0800

NCP45521 is a controlled load switch from onsemi. In practice, it can be understood as a high-side electronic switch controlled by a logic signal. It is commonly used in power management: when a module needs to work, power is connected; when it is idle, power is fully disconnected to reduce standby consumption, control power sequencing, and reduce inrush current from large capacitive loads.

Compared with building a high-side switch from discrete MOSFETs, NCP45521 integrates the power MOSFET, gate driver, charge pump, soft start, output discharge, and protection logic into a small package. The external circuit is simpler, and the power-up waveform is easier to predict.

Internal Core: N-Channel MOSFET

NCP45521 integrates a low-resistance N-channel MOSFET. It works on the high side: current flows from VIN to VOUT, then into the downstream load.

The important point is that an N-channel MOSFET used as a high-side switch needs its gate voltage driven above the source voltage. A normal GPIO cannot do this directly. That is why the chip includes a charge pump and gate driver to turn the MOSFET on reliably.

After the switch is fully on, the load sees a voltage close to the input voltage. The voltage drop is mainly determined by RDS(on) and load current:

`1`	`Vdrop = Iload * RDS(on)`

For example, the larger the load current, or the higher the on-resistance, the more obvious the voltage drop and heat dissipation become. In real designs, check input voltage, continuous current, package thermal limits, and ambient temperature together instead of looking only at the headline maximum current.

Soft Start and Slew Rate Control

One of the most useful functions of a load switch is controlling the power-up speed.

If a power rail is connected directly to a module with large input capacitors, those capacitors look almost like a short circuit at the instant of connection. This can create a large inrush current, causing input voltage droop, system resets, or even damage to connectors, regulators, or other components.

NCP45521 solves this by gradually raising the internal MOSFET gate voltage, so VOUT rises with a controlled slope. The downstream capacitors are charged smoothly, and the startup current peak is reduced.

This behavior is usually described as:

Soft start: the output voltage is established gradually.
Slew rate control: the output voltage rise slope is controlled.
Inrush current limiting: the input supply is not pulled down by a large capacitive load.

In real circuits, this feature is especially valuable when the downstream input capacitance is large or the upstream power source has limited current capability.

EN Pin Control

NCP45521 uses the EN pin to control the switch state. Different orderable parts may use different enable polarities, including active-high and active-low versions, so the exact part number should be checked in the datasheet.

Using an active-high version as an example:

1
2

EN = High -> internal charge pump starts -> MOSFET gradually turns on -> VOUT rises
EN = Low  -> gate driver shuts down -> MOSFET turns off -> VOUT is disconnected

This pin is usually driven by an MCU, SoC, PMIC, or power-sequencing circuit. It does not carry load current; it only tells the load switch when to connect or disconnect the downstream power rail.

In laptops, NAS devices, routers, and development boards, EN is often used to control subsystems such as Wi-Fi modules, USB devices, sensors, auxiliary drive power, and display-related power rails.

Quick Output Discharge

Many loads retain voltage for a while after power is turned off because of output capacitance. If that residual voltage falls too slowly, downstream chips may not fully reset, or they may stay in an undefined partially powered state.

NCP45521 includes output-discharge-related circuitry. When the switch turns off, the chip can discharge the remaining charge on VOUT to ground through an internal path, bringing the output back to a low level faster.

This feature is commonly called:

Quick Output Discharge, or QOD.
Output discharge.
Bleed discharge.

Its value is making the downstream state deterministic, especially for digital circuits, communication modules, and hot-plug-like scenarios that need clear power-on and power-off boundaries.

Typical Operating Flow

The behavior of NCP45521 can be understood in five stages:

Standby: VIN is present, EN is not asserted, the internal MOSFET is off, and VOUT is unpowered.
Enable: EN becomes active, and the internal bias, charge pump, and driver circuits start.
Soft start: the MOSFET turns on gradually, VOUT rises with a controlled slope, and downstream capacitors are charged smoothly.
Steady on: VOUT is close to VIN, the load works normally, and voltage drop mainly depends on load current and RDS(on).
Turn-off: EN becomes inactive, the MOSFET turns off, and the output discharge path releases the remaining charge on VOUT.

So it is not merely a mechanical disconnection of the power line. It provides controlled and predictable power behavior during both turn-on and turn-off.

Why Not Use a Plain MOSFET

Of course, a load switch can be built with discrete MOSFETs. But to make it robust, you often need to handle these details:

Gate drive voltage for a high-side N-channel MOSFET.
Power-up inrush current.
Output voltage discharge.
Undervoltage, overcurrent, short-circuit, or thermal protection.
Reverse current and residual downstream voltage when turned off.
PCB area and external component count.

The point of an integrated load switch is to absorb these common problems, reducing external parts and making power sequencing more stable. During board repair and analysis, this kind of chip should be treated as a power-domain switch, not as a normal voltage regulator.

What to Check When Selecting One

When choosing NCP45521 or a similar load switch, pay attention to these parameters:

VIN range: whether it covers the actual input voltage.
Maximum continuous current: whether it supports the load peak and steady current.
RDS(on): affects voltage drop and heat.
Soft-start time or slew rate: whether it matches downstream capacitance.
Enable polarity: active-high or active-low.
Output discharge: whether the output needs to be pulled low quickly after shutdown.
Protection features: thermal, short-circuit, current-limit, and undervoltage protection.
Package and thermal performance: a small package does not mean it can run at the rated maximum current continuously.

When repairing a board, if the load switch is suspected, measure VIN, VOUT, and EN. If input power exists and enable is valid but output is missing, continue checking the chip itself, downstream short circuits, or protection-trigger conditions.

Common Load Switch Models

The following models and series are useful as search and selection references. Different suffixes may mean different packages, current ratings, enable polarities, and discharge options, so parts should not be substituted by series name alone.

Model or Series	Vendor	General Feature	Common Use
NCP45520 / NCP45521	onsemi	Low-resistance high-side load switch with soft start and output-discharge-related functions	Laptops, embedded devices, power-domain control
NCP45524 / NCP45525	onsemi	ecoSWITCH load-management series for controlled power switching	Module power switching, system sequencing
NCP45560	onsemi	Higher-current load switch for larger power paths	High-current subsystems, auxiliary hot-plug control
TPS22910A	Texas Instruments	Low-current, low-power load switch	Portable devices, sensor power
TPS22918	Texas Instruments	Low on-resistance, common in mobile and embedded power management	SoC peripherals, low-voltage rails
TPS22965 / TPS22966	Texas Instruments	Low on-resistance with controlled rise time	Processor peripherals, storage, wireless modules
TPS22975	Texas Instruments	Higher current capability and low on-resistance	Motherboard power domains, USB/peripheral power
AP22802 / AP22804	Diodes Incorporated	Protected power-switch series	USB power, peripheral port protection
AP2331	Diodes Incorporated	Single-channel current-limited load switch	USB ports, 5 V peripherals
MIC2005A / MIC2009A	Microchip	Power distribution switches with current-limit protection	USB, power distribution
RT9742	Richtek	Power switch / current-limit switch	USB and peripheral power
SY6280 / SY6288	Silergy	Common low-cost current-limited load-switch series	Consumer electronics, development boards, USB power
AOZ1360 / AOZ1361	Alpha & Omega	Power switch or protection-switch series	Power-path management, interface protection

These chips may all be called load switches, but their priorities differ. Some focus on low power, some on high current, some on current limiting and short-circuit protection, and some on startup waveform control. For replacement, compare pinout, package, maximum voltage, current rating, RDS(on), enable polarity, and output discharge behavior one by one.

Summary

NCP45521 is essentially a controlled load switch with an integrated high-side N-channel MOSFET. It uses an internal charge pump to drive the MOSFET, soft start to limit inrush current, the EN pin to control the power domain, and output discharge to make the off state clearer.

In board repair, it often appears at the power input of a subsystem. In hardware design, it is commonly used for power sequencing, standby power saving, and peripheral power control. The most direct way to judge whether it is working is to check input, enable, and output together: whether VIN is present, whether EN is valid, and whether VOUT rises as expected.

Hermes + Qwen3.6: A Low-Cost Local Agent Deployment

Mon, 04 May 2026 06:40:30 +0800

This article documents a local Agent deployment plan: run a Qwen3.6 GGUF model with llama.cpp inside WSL2, then connect Hermes Agent to the local OpenAI-compatible API. This gives you a long-running local AI assistant on your own computer, without paying by online service Token usage.

This setup is suitable for users who want to try local AI Agents while keeping data private and controllable over the long term. It can be used for daily Q&A, writing, coding assistance, document organization, and simple automation tasks. The larger the model, the higher the VRAM requirement. The original example uses Qwen3.6-27B, and 24GB VRAM is more stable. If your VRAM is smaller, choose a smaller model or a lower quantization.

Architecture

The overall chain is simple:

Install WSL2 and Ubuntu 24.04 on Windows.
Install CUDA Toolkit inside WSL2 and compile llama.cpp.
Download the Qwen3.6 GGUF model.
Start a local model service with llama-server.
Install Hermes Agent and configure it to http://localhost:8080/v1.
Optional: write a startup script so the model service starts automatically when WSL2 opens.

Hermes provides the Agent capability, while Qwen3.6 provides the local LLM capability. Together, they turn the computer into a private local AI assistant.

Install WSL2 and Ubuntu

Run in an administrator Windows PowerShell window:

1
2

wsl --install
wsl --set-default-version 2

After rebooting, install Ubuntu 24.04:

`1`	`wsl --install -d Ubuntu-24.04`

After installation, Ubuntu prompts you to set a username and password. Once inside Ubuntu, first check whether the NVIDIA GPU is visible in WSL2:

`1`	`nvidia-smi`

If the GPU cannot be detected, update the NVIDIA driver on Windows first. WSL2 inherits the Windows driver, but CUDA Toolkit still needs to be installed separately inside WSL2.

Install Python and Basic Tools

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

You also need build tools, Git, and CMake:

`1`	`sudo apt install -y cmake build-essential git`

Compile llama.cpp

Clone the repository:

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

If CUDA is already available in WSL2, compile directly:

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 is suitable for Ada GPUs, such as RTX 40 series cards. Adjust it according to your actual GPU architecture.

If compilation reports that CUDA Toolkit is missing, install CUDA Toolkit inside WSL2 first:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

Configure environment variables:

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

Then rebuild:

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Download the Qwen3.6 GGUF Model

The example uses Qwen3.6-27B-UD-Q4_K_XL.gguf from unsloth/Qwen3.6-27B-GGUF:

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

The file is about 17GB. If Hugging Face is slow, use a mirror such as ModelScope. Do not force a 27B model if your VRAM is insufficient; use a smaller model or lower quantization.

Start the Local Model Service

Start llama-server with your own model file name:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

After startup, open this in a Windows browser:

`1`	`http://localhost:8080`

For Hermes Agent or other OpenAI-compatible clients, the API endpoint is usually:

`1`	`http://localhost:8080/v1`

Thinking Mode Tradeoff

Qwen3.6 may enable Thinking mode by default. It is suitable for complex reasoning, complicated coding problems, and multi-step analysis, but it is slower.

To disable Thinking mode, stop the service and add --chat-template-kwargs:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

After disabling Thinking, simple Q&A, writing, code completion, and code explanation become faster. For complex algorithm design, difficult debugging, and architecture analysis, Thinking mode is still recommended.

Install Hermes Agent

Keep llama-server running, then open a new WSL2 terminal and install Hermes Agent:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

The installer handles dependencies such as Python, Node.js, ripgrep, and ffmpeg. When configuring the model endpoint, choose a custom endpoint:

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: auto-detect

For a local llama-server, the API Key can be any placeholder value. After configuration, you can connect Telegram, WeChat, QQ, Discord, and other chat tools, allowing Hermes Agent to call the local model and execute tasks from those entry points.

Auto-Start the Model Service

You can write a startup script so the model service starts automatically when a WSL2 terminal opens.

Create the script:

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

Write it into .bashrc:

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

Each time you open a WSL2 terminal, it will start llama-server if it is not already running. If it is running, it skips startup and avoids duplicate processes.

Notes

27B models require substantial VRAM; 24GB VRAM is more stable. Use a smaller model if VRAM is limited.
--ctx-size 65536 significantly increases VRAM and RAM pressure. If unstable, reduce it to 32768 or lower.
Both CUDA Toolkit in WSL2 and the Windows GPU driver must work properly. Either side can cause CUDA compilation or runtime failures.
Hermes Agent calls the local service through an OpenAI-compatible API. The key is that http://localhost:8080/v1 responds correctly.
If accessing from a phone or another device, handle Windows Firewall, LAN addresses, and security isolation. Do not expose the local model service directly to the public internet.

Original article: Hermes + Qwen3.6：本地最强 Agent 组合！零成本、无限 Token，太香了！
llama.cpp: ggerganov/llama.cpp
Hermes Agent: NousResearch/hermes-agent
Qwen3.6 GGUF example: unsloth/Qwen3.6-27B-GGUF

Installing fnOS on TerraMaster F2-220: F3 Backplane, NVMe, and BIOS Module Injection

Mon, 04 May 2026 06:09:40 +0800

This is a practical note on installing fnOS on a TerraMaster F2-220. The goal is to replace the original TOS and keep using the NAS after official support for the F2-220 has ended. The process also verifies that the F3 backplane can work on the F2-220, and solves the issue where the BIOS cannot boot from NVMe.

The original F3 backplane project was verified on the F2-221 with a J3355 platform. The F2-220 uses the J1800 platform, so compatibility was not guaranteed. A V1.1 version existed in a project fork with fewer components, lower cost, and less assembly difficulty, so that version was used for testing.

PCB Fabrication and Soldering

Backplane project: arnarg/f3_backplane. The board used here is the V1.1 version from a fork. Its core goal is to keep the original SATA drive bays while exposing an NVMe SSD position from the backplane connector.

Multiple PCBs were received after fabrication. One detail appeared during soldering: after soldering the M.2 connector, it became clear that the SATA connector was different from common SATA connectors.

A fully matching native SATA connector was not found on Taobao, so an existing connector was modified instead: the pins were pulled out, positions were swapped, and then the connector was soldered back to the board.

The key takeaway is that the F3 backplane approach can be tried on the F2-220, but SATA connector selection needs special attention. Do not order only by looking for a generic SATA connector.

VGA Output

The F2-220 has no exposed video output, but it has an internal 12-pin VGA header. You need an internal motherboard 12Pin VGA adapter cable. One end connects to the 12-pin header inside the machine, and the other end is usually a standard DB15 VGA female connector for an external monitor.

Useful search keywords include “12Pin VGA adapter cable”, “motherboard 12-pin VGA adapter cable”, and “2.0mm 12Pin to VGA”. Before buying, compare the connector direction, pitch, and pinout against a photo of the internal header. Do not order based only on the “12Pin” label.

This step is important for installation. Without video output, BIOS and installer troubleshooting becomes much harder.

Installing fnOS

Boot the fnOS installer through Ventoy. The installer can see the NVMe SSD, which means the backplane and NVMe hardware path are working.

However, after installation, removing the boot drive causes the machine to reboot into the BIOS screen instead of entering fnOS. The BIOS boot list does not contain the NVMe SSD. If fnOS is installed to a USB drive and booted from there, the system can still see the NVMe drive normally.

This indicates:

NVMe hardware detection is fine.
Linux can access the NVMe drive.
The failure point is the BIOS boot stage.
The F2-220 platform is old, and the stock BIOS likely lacks an NVMe boot module.

Backing Up the BIOS

At this point, fnOS can already boot from a USB drive. Since fnOS is Debian-based, flashrom can be used inside the system to back up and flash the BIOS.

Flashing BIOS is risky. Prepare a programmer if possible, so recovery is still possible after a failed flash.

Install flashrom:

1
2

sudo apt update
sudo apt install flashrom -y

Check whether the BIOS chip can be detected:

`1`	`sudo flashrom -p internal`

Detected chip information may look like this:

`1`	`Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.`

Back up the original BIOS. Replace the chip model in the command with the actual result from your machine:

`1`	`sudo flashrom -p internal -c "W25Q64.W" -r backup_factory.bin`

Injecting the NVMe Module

The backed-up BIOS is a .bin file. You can transfer it to a PC with WinSCP, then refer to the Bilibili tutorial 让老主板用上 Nvme 协议的固态 to inject the NVMe module into the BIOS file.

After processing, transfer the modified BIOS file back to fnOS.

Do not blindly reuse someone else’s BIOS file. Different machines, BIOS versions, and flash chips may differ. The safer approach is to back up your own original BIOS and modify that backup.

Flashing the New BIOS

The flash command is shown below. Replace the chip model, firmware path, and file name according to your actual setup:

`1`	`sudo flashrom -p internal -c "W25Q64.W" -w /vol1/NEW_NVME.bin`

When the output shows this line, verification has passed:

`1`	`Verifying flash... VERIFIED.`

After flashing, the BIOS boot list may show a PATA entry. On older BIOS setups with an injected NVMe module, the NVMe boot entry often appears as PATA. Seeing it means the BIOS can now recognize the NVMe boot path.

Result

Final result:

F3 Backplane V1.1 can detect NVMe on the TerraMaster F2-220.
The fnOS installer can see the NVMe SSD.
The stock BIOS cannot boot directly from NVMe.
After injecting the NVMe module into the BIOS, a PATA boot entry appears.
The machine can boot fnOS from NVMe after the BIOS modification.

Testing feedback also notes that this NVMe channel is only a little over 300MB/s. That is enough for a system drive. There is no need to use a high-end SSD; even a small Optane drive can be sufficient.

Notes

This is not a risk-free general tutorial. It is closer to a hardware and BIOS modification record. Before trying it, note the following:

F2-220 and F2-221 use different platforms, so F2-221 results should not be treated as identical to F2-220 results.
The F3 backplane requires PCB fabrication and soldering. The SATA connector may also require pin modification.
A suitable internal VGA adapter cable is needed for installation and troubleshooting.
BIOS flashing can brick the machine. Prepare a programmer and keep the original backup.
The chip model in the flashrom command must match the chip detected on your own machine.
Do not directly flash someone else’s modified BIOS. Inject the NVMe module into your own backup first.

The value of this note is that it adds real F2-220 test results: the F3 backplane idea is not limited to the F2-221, and the F2-220 can also use an NVMe system drive. The real blocker is not Linux detecting NVMe, but whether the BIOS supports NVMe booting.

fnNAS forum test thread: 铁威马F2-220折腾飞牛OS过程