Tech Sharing on TorchTree

Notion CEO's Jazz Mode: Five Deep Shifts in AI-Era Organizational Management

Tue, 25 Aug 2026 12:58:43 +0800

In a recent conversation with Sequoia partner Brian Halligan (former HubSpot CEO), Notion CEO Ivan Zhao introduced a new concept: Jazz Mode. He argues that after Manager Mode and Founder Mode, organizations in the AI era should operate like a jazz band: everyone has room to improvise, yet the whole still comes together in collaboration.

This article doesn’t intend to recap everything Ivan said. Instead, it tries to extract a few structural changes that are easy to overlook from his remarks, and what those changes mean for teams building products with AI.

From Building Bridges to Brewing Beer: Why AI Rewrites the Underlying Logic of Product Development

Ivan used a metaphor to distinguish traditional software development from AI product development: traditional software is like building a bridge — designers draw the blueprint and engineers build to it; AI products are more like brewing beer — you can only experiment, observe, and adjust, without precisely controlling the final result.

The value of this metaphor isn’t rhetorical; it exposes a structural problem that has been underestimated in AI product development: traditional software development is requirement-driven; AI product development is technology-driven.

In the traditional model, product managers define requirements, designers produce solutions, and engineers implement them. The whole process starts from customer needs, with technology as the means of execution. But AI products are different. The boundaries of model capability determine what a product can do, and those boundaries change every week. If you plan your product roadmap strictly according to customer requirements, three months later what you’ve built may already be obsolete.

Ivan said their internal development model has shifted from “customer-driven” to “technology-driven experimentation.” The traditional boundaries between PM, designer, and engineer have been thoroughly blurred — even product designers are among the team members who consume the most LLM tokens.

This isn’t just Notion’s practice. As LLM capabilities iterate quickly, more and more AI product teams face the same dilemma: you can’t fully plan your product at the start of the year, because three months later the model’s capabilities have already changed. An AI product roadmap is, in essence, a collection of assumptions that keep being overturned.

For teams building AI products, this means two things. First, you need to accept that “plans can’t keep up with change” isn’t a management problem but a consequence of the product form. Second, you need to let the people with the best judgment on your team (not just engineers) work directly with the model, because instinctive judgment about model capability is becoming a more valuable product asset than a requirements document.

Hierarchy Won’t Disappear, But Its Function Is Being Redefined

Ivan was explicit in the conversation that he doesn’t believe in hierarchical-free organizations. His reasoning is simple: hierarchy is human nature — even chimpanzee societies have natural hierarchies, and you can’t eliminate it by forcibly flattening the org.

But he also pointed out that language models are becoming the new infrastructure of organizations. Information transfer, state synchronization, and decision coordination — work that once required many middle managers — can now be partly handled by AI. Future organizations will be flatter, but hierarchy won’t disappear.

Hidden beneath this is a deeper change: the rationale for hierarchy is shifting from “information transfer” to “allocation of judgment.”

In traditional organizations, one core function of hierarchy is information filtering and passing. A CEO can’t know every detail, so you need VPs; VPs need Directors; Directors need Managers. Each layer compresses information and reports upward. But AI tools (including Notion’s own products) are making information transfer more efficient, even automated. When information transfer is no longer the bottleneck, hierarchy only retains two values: decision judgment and resource allocation.

This means the job of future middle managers will fundamentally change. They will no longer be transfer stations for information, but carriers of judgment in specific domains. The value of a middle manager will no longer depend on how many people they manage, but on how broadly they can make high-quality decisions.

For organizational designers, this is a very practical question: if your middle managers mostly do meetings, reporting, and passing information, their roles are being eroded by AI; if your middle managers are the judgment centers of a domain, their value is actually rising.

The Talent Formula Has Changed: Capability or Taste — Which Is Scarcer?

Ivan proposed a talent formula he currently endorses most: Talent = Capability × Taste × Agency.

In the past, Capability was the most important variable. An engineer’s technical skill determined their output. But in the AI era, capability is being rapidly commoditized. Tools like Claude Code, Cursor, and Copilot are making “writing code that runs” increasingly easy.

When capability becomes cheap, Taste and Agency become scarce resources. Taste is what you think is good; Agency is whether you proactively push things forward.

This isn’t empty philosophy. Notion has adjusted its hiring strategy along these lines: it no longer focuses mainly on work history, big-company background, or resume length, but on curiosity, optimism, energy, and proactivity. Their first-round interviews no longer review resumes; they simply ask candidates to “build something,” looking at the work before the background.

Even more noteworthy is their “barbell model” engineering organization: at one end, very young engineers responsible for fast trial-and-error and efficient execution; at the other, a tiny number of super-senior architects responsible for judgment, Taste, and architecture. One senior architect guides 2–3 junior engineers, and with the help of AI Agents, each junior engineer can produce as efficiently as managing a mini-team.

The underlying logic of this model is: AI amplifies individual execution, but not judgment. A tasteful senior engineer, plus AI tools and a few junior executors, can produce what a small team used to. But if the Taste is wrong, no amount of execution is doing anything but accelerating in the wrong direction.

For team managers, this means you need to reassess who in your team is the “Taste center,” and ensure those people’s judgment directly shapes product direction rather than being diluted by layers of reporting.

Founders Are an Organization’s Decalcifying Agent: Why Notion Took In 60 Founders

Notion has 50–60 former startup founders internally — an unusual number. Ivan said founders are an organization’s “decalcifying agent.”

His logic is clear: a 1,000-person company will naturally tend toward bureaucracy; that’s a physical law. But if a steady stream of founders keeps mixing in, they continuously launch new projects, challenge old processes, propose new ideas, and push organizational change — effectively injecting new vitality into the organization.

This observation reveals a problem often neglected in organizational theory: bureaucratization isn’t a management failure, but a natural result of organizational scale. Any sufficiently large organization will produce processes, norms, and hierarchy. These things ensure efficiency early on, but once they accumulate past a certain point, they become obstacles to innovation.

The value of founders is that they naturally distrust process. They’re used to “doing first, then talking,” used to breaking existing frames and rethinking problems. Scattered across a large organization, they act like so many “anti-entropy nodes,” constantly resisting the force that drives organizations toward rigidity.

But there’s a prerequisite: the organization must give these people enough autonomy. If founders are assimilated by existing processes after joining a large company, the “decalcifying agent” fails. Ivan said Notion’s approach is to keep these people highly autonomous, consistent with the spirit of Jazz Mode.

Enterprise Sales Is the Last Fortress AI Can’t Take

One detail in the conversation is easy to overlook: Ivan said they had previously made mistakes in the sales area — they tried to reinvent sales and failed. Later they found that many enterprise customers simply want to talk to a real person.

This observation forms an interesting contrast with the current narrative of many AI companies. Over the past two years, a lot of AI startups have tried to replace the sales process with AI, from automated outbound calling to intelligent customer service to AI SDRs. But Ivan’s experience suggests that, at least in the enterprise market, trust relationships between people remain the key to closing deals.

The logic behind this: enterprise procurement decisions are costly, and the consequences of error are severe. In such scenarios, customers need more than just information and efficiency; they need “someone who can be found when something goes wrong.” AI can handle information, but it’s hard for it to provide that kind of psychological security.

For AI entrepreneurs, this points to a pragmatic direction: AI’s best position in the enterprise market may not be replacing sales, but empowering it. Let salespeople use AI tools to prepare materials, analyze customers, and follow up leads more efficiently, but the final customer relationship is still maintained by humans.

Planning Cycles Are Shrinking Dramatically

Ivan said something very direct: financial planning can be done quarterly, but product planning may need to change weekly, because model capabilities change too fast.

That’s not an exaggeration. Over the past two years, the capability curve of LLMs has been nearly exponential. Tasks considered impossible when GPT-4 was released in early 2023 had been matched or surpassed by multiple models by the end of 2024. If your product planning is built on the assumption of “GPT-4-level capability,” that assumption needs updating every few months.

Ivan also stressed that a CEO must experience AI firsthand — not just watch videos, talks, or summaries. He used two phrases: Feel the AI, Feel the AGI. Only by using it yourself and building with it can you know which opportunities really exist.

The practical meaning of this advice: product decisions in the AI era increasingly rely on intuitive judgment of model capability, and that intuition can only come from hands-on use. You can’t gain an accurate sense of model capability by reading secondhand information, just as you can’t learn to swim by reading a swimming tutorial.

A Company Eventually Grows Into the Image of Its Founder

At the end of the conversation, Ivan touched on a view: many CEOs like to imitate others — Jobs, Musk, or Brian Armstrong — but a company is ultimately a projection of its founder. If you’re a craftsman, the company becomes a craftsman culture; if you’re a salesperson, it becomes a sales culture; if you’re a jazz musician, the company also eventually becomes a jazz band.

He was very candid about the quasi-religious/“cultish adoration” perception of the Notion community, even saying he “liked” it. He believes a company is, in a sense, a religion, projecting a worldview and value system onto the real world through commerce and products.

The deeper meaning of this view: organizational culture isn’t designed; it’s an amplification of the founder’s personality. You can draw a perfect org chart, but what ultimately determines organizational behavior is what the founder believes, values, and how they make decisions.

Jazz Mode suits Notion not just because it’s a good management concept, but because it matches Ivan’s own personality. He doesn’t like pure delegation, pure process, or pure management, so he needs an organization that allows improvisation. If a founder is a natural controller by nature, Jazz Mode will most likely fail in their company.

For entrepreneurs, this may be the question most worth thinking about: does the organizational model you’re trying to build match your own personality? If it doesn’t, even the best concept is nothing but a castle in the air.

Original link: Notion CEO on the New Paradigm for AI-Era Organizational Management: Jazz Mode

Morning Brew Founder's Content Machine: Never Run Out of Topics, No AI Slop

Tue, 04 Aug 2026 03:23:29 +0800

Alex Lieberman sold the majority stake in Morning Brew to Insider in 2020, when the media company born in a college dorm was valued at $75 million. He now runs 10x, an AI-transformation consultancy, while keeping up high-frequency content output on X and LinkedIn. In an interview with How I AI, the podcast under Lenny’s Newsletter, he revealed the system behind that output: a Claude-based “content machine” where AI participates in everything from ideation to drafting to review, and yet the output has “no AI slop.”

This breakdown is compiled from the full transcript of that interview, walks through the content machine’s operational stages, and finally distills what this system means for ordinary creators.

Why build a content machine

Lieberman says he faced two problems:

The first is time constraints. He has been creating continuously for a decade since founding Morning Brew in his dorm, and content has brought him many opportunities. But the time he can dedicate to creation each day is only about 25%. He wanted to know how to maximize the value of that 25% while guaranteeing he doesn’t produce AI slop.

The second is employee creation. He believes that in the future business world, as technology becomes increasingly commoditized, the real moat is “trusted distribution channels,” and turning your company’s employees into creators is a distribution resource many companies haven’t fully tapped. His goal is to make “employees becoming creators while holding a full-time job” as simple as possible.

His approach is to refactor the content production process to be AI-native.

Before getting into the details, it’s worth understanding Lieberman’s basic stance on AI content. The host mentioned a writer friend’s view that AI will raise the floor for mediocre writers but cap the ceiling for great ones. Lieberman agrees with that assessment but says it needs refinement. If AI only participates in drafting and editing, it might indeed cap the ceiling for top-tier writers’ output. But content creation is a multi-stage process; using AI for inspiration gathering, material organizing, and format conversion doesn’t mean abandoning quality. More important is comparing against the baseline—his team’s alternative before the content machine was simply not creating at all. Between having employees produce content around their expertise and having nobody produce any content, he’d always choose the former.

He also mentions a counterintuitive observation: the popularity of AI slop is actually creators “pointing at themselves and saying I’m not smart enough.” When a person feeds AI vague ideas, they naturally get vague writing back. The problem lies in the input stage, not in the AI itself. This view runs throughout the interview and explains why his system spends enormous effort on ideation and interviewing, not writing.

Step 1: Map the existing process first, then tear down constraints and rebuild

Lieberman emphasizes that the starting point of the whole transformation isn’t introducing AI, but drawing a process diagram. He breaks the entire content-creation process down from beginning to end: finding inspiration, judging whether it’s worth writing, drafting, editing, publishing, distributing. He says most people, before doing process mapping, have no idea how much waste is in their own process—AI is just the push that forces them to complete this step.

Host Claire Vo adds a key piece of advice: don’t design the process around current constraints; design it around the ideal state. Unconstrained, of course you’d want an always-on researcher digging up topics for you, and of course you’d split one piece of content into multi-platform micro-content. First map the ideal process, then decide which stages go to AI and which stay with humans.

Step 2: Oracle scans seven days of information and produces fifteen post ideas

The content machine’s first component is called Oracle. It connects to all of Lieberman’s information sources in Tenex, including Slack, Notion, meeting notes, Linear, Git, and Gmail, plus a custom list of internet information sources he configured himself. Oracle scans the information from the past seven days every day, scores potential “content spikes” (specific topics identified from the information stream that have potential to be written about) against a scoring rubric, and finally outputs roughly 15 candidates.

This design stems from a fear of the “blank page.” Lieberman thinks the biggest friction point in content creation is facing a blank page, and Oracle’s role is to fully automate that stage. Creators open the machine each day and face not a blank page, but fifteen topic candidates loaded with specific details.

The real-world example shown in the interview is vivid. Oracle grabbed several lines from internal sources: a conversation with a banking client, where the client said McKinsey’s advice would take six months to land while he rebuilt it in a week with Claude Code; his self-deprecating line on a sales call that “I might be the worst salesperson in the world”; and his pain after selling Morning Brew. Oracle flagged these concrete stories as high-potential content spikes. From external sources, it picked up Amazon’s $1 billion investment in FDE and the disagreement among experts over whether FDE is a cure-all.

The key point is that Oracle isn’t grabbing generic topics, but specific moments from someone’s lived experience. Lieberman says AI-generated slop usually isn’t because the AI writes badly, but because the person didn’t feed good enough material at the sourcing stage.

Step 3: Six interview personas—“say it out loud” instead of “write it down”

Once topics are selected, the content machine moves to the interview stage. Lieberman created six interviewer personas that take turns asking him questions. He responds to these questions out loud, using speech-to-text tools like Wispr Flow to shape the raw draft material.

The intent behind this design is to turn creation from “facing a blank document” into “answering questions.” What you say out loud is more conversational and more genuine than what you write, and closer to his actual voice. This stage determines the information density of the content and is, in Lieberman’s view, the watershed for whether the whole system produces slop. He repeats one judgment throughout the interview: whether AI-generated content has an “AI smell” depends mainly on how good the ideas are that a person shares in the interview stage. If the input is vague opinions, the AI naturally outputs vague text; if the input is specific moments from lived experience, the AI outputs details nobody else could fabricate.

Step 4: “Encode” personal style with Markdown files

Lieberman’s writing style is decomposed into two types of files.

One kind is a voice markdown file, recording his sentence preferences, word choices, and expressive traits. The other is a content lessons markdown file, recording the lessons distilled from each round of editing—like “don’t use clichés like ‘if X, then Y.’”

When drafting, the AI writes the first draft in his voice according to these two files. Each time he gives feedback on a final draft, the system runs a “lessons loop”: comparing the differences between the raw material and the final published version, extracting lessons that can be abstracted and reused, and, after his confirmation, appending them to the lessons file. This way the system increasingly matches his standards, effectively solidifying his personal aesthetics into a searchable asset.

Step 5: A writers’ committee scores the draft—below 9 and it gets rewritten

After the first draft is done, it moves to the review stage. Lieberman created six writer personas, including well-known writers like David Perell, Morgan Housel, and Shaan Puri, plus one persona specifically allergic to “AI smell.” The six reviewers each read and score the piece from 1 to 10. If the total score is below 9, it automatically enters a revision loop until it scores 10 before being released.

In a live demo, the draft was initially scored low by the reviewers and the system immediately entered the revision loop; Lieberman joked, “I guess it won’t get a 9.” The whole review process is visible and auditable—the author can see each reviewer’s score and comments. In essence, this mechanism uses AI to simulate an editorial committee, providing an outside perspective without a real human editing team.

Step 6: Reuse and distribute after publishing

Once content is finalized, the machine also handles distribution. Lieberman can specify what formats to break it into—for example, three short tweets plus two long LinkedIn posts—and the system auto-generates the multi-platform versions in his style.

He says one step is still missing from the process he runs daily: Oracle should also remind him which historical content is worth repackaging. That’s the feature he plans to add next.

The tech foundation: a catalog of Claude Skills

This content machine isn’t custom software; it’s built on Claude’s plugin ecosystem. Lieberman describes it as “a catalog of skills,” running in Claude Code or Cowork environments, and team members can pull updates from the company’s internal code repo. He deliberately made the update process simple enough that non-technical colleagues can sync to the latest version with one click.

This choice is worth noting. He didn’t develop a dedicated product for the content workflow; instead, he decomposed the process into a set of composable skill files hung onto a general-purpose AI programming tool. The benefit is extremely fast iteration—a lesson discovered today can become a shared skill update for all colleagues tomorrow.

The numbers: production time dropped from 20–30 hours to 3–4 hours

On the system’s effectiveness, the figures circulating outside the interview say per-post production time dropped from 20–30 hours to 3–4 hours, and building the system itself took over 50 hours. Lieberman didn’t directly give either number in the interview, but the live demo throughout it confirmed the process’s efficiency—picking a topic from that day and completing drafting, review, and revision within minutes.

It should be noted that efficiency gains don’t equal quality compromises. He repeatedly stresses that the premise of this system is his own decade of content-creation accumulation—running thousands of content-creation processes—before he could decompose the workflow finely enough. This also answers his stance on whether AI caps the creative ceiling: AI won’t turn mediocre people great, but it can free excellent creators’ time from repetitive labor to invest it where real judgment is needed.

Employee creation: using gamification to turn everyone into a content source

The content machine solves “how the founder creates efficiently himself,” but Lieberman also addresses, at the company level, “how to get employees willing to create.”

He believes employees are the most-underrated marketing channel for most companies. Claire Vo adds during the interview that she’s seen many CEOs worry that employees who stand out too much on social media will get poached, but what actually makes employees leave is their lack of opportunity to show off valuable work. Companies willing to encourage employees to build personal brands have a clear advantage in the talent war.

At his previous company StoryArb, he ran an event called Own the Internet: over six to eight weeks, everyone was encouraged to post on LinkedIn, with the only rule being that at least half the content had to be work-related, and the final winner got $5,000. That quarter, the event contributed 40% of the company’s inbound leads and brought a lot of recruiting-side exposure.

The version Tenex just launched is called Creator Cup: for a month, everyone posts on LinkedIn or X—10 points per post, 3 points for engaging with a colleague’s post, an extra 50 points for the best post each week chosen by the founders, plus weekly and monthly leaderboards. The company opened a Slack channel called Reply Guys where everyone reads and comments on each other’s posts. The whole design turns content creation into a team sport, using points and leaderboards to create engagement.

Lieberman says employee advocacy has existed for many years; he just thinks the internet and social media have lowered the barrier to an unprecedented low, while most companies are still stuck in the stage of worrying about risk. He also shares an observation from the interview: as technology becomes increasingly commoditized in the AI era, business moats are getting rarer, and “trusted distribution channels” are one of the few barriers that can compound over time. Turning your company into a media company and making employees into content sources is, in essence, building that moat.

Anthropic is a counterexample: several engineers related to Claude Code keep producing on social media, and readers trust the product more because they trust the individuals. These people have become an extension of the brand, and their personal output and the company’s product form a mutually reinforcing loop.

What ordinary creators can learn

The entire system can be abstracted into a four-step methodology that doesn’t depend on Morning Brew’s resources or Tenex’s engineering capabilities.

First, map the process before talking about AI. Break the creative process into stages, find the bottlenecks and waste; this is the starting point of any AI transformation. Lieberman says in the interview that process mapping alone exposes a huge amount of efficiency problems—AI is just the catalyst that pushes you to get it done.

Second, topics come from real experience. Oracle’s value isn’t “automatically generating topics” but fishing concrete stories out of the person’s own conversations, meetings, and emails. Without real raw material, no AI can write content with real information density.

Third, style can be encoded. A voice guide plus a lessons file is, in essence, sedimenting “I don’t think this writes well” into searchable rules, so AI understands you better the more you use it.

Fourth, externalize the review. The six-persona committee simulates “getting an expert to review your draft,” providing an objective feedback loop without an editing team.

At the end of the interview, Lieberman is asked “what do you do when AI produces slop.” His answer is pragmatic: either write it by hand, or spend time scolding it and confirm whether those lessons have already been written into the lessons file. He admits he sometimes treats AI poorly—“given that AI will eventually be my boss, I should really be nicer to it.”

Finally, it’s worth noting his take on engineers: the best engineers have both system-level understanding and the willingness to make their entire workflow agentic. This standard applies equally to content creators: understanding how the whole system works while being willing to delegate repetitive labor to AI is the most valuable combination of abilities in this transformation. The value of this content machine lies precisely in turning that combination of abilities into a replicable process.

Sources: This breakdown is based on the full transcript of the How I AI podcast interview with Lenny’s Newsletter, “How the founder of Morning Brew built a Claude content machine that never runs out of ideas” (Lenny’s Newsletter), and related reporting on Insider’s acquisition of Morning Brew (Axios, Business Insider).

Advanced Pi Agent Configuration: AGENTS.md, Model Switching, and Thinking Levels in Practice

Wed, 22 Jul 2026 12:14:08 +0800

In the article Pi Coding Agent in Practice: From Installation to Everyday Use, I covered Pi’s installation, first-time configuration, and its core extension packages. That content lets beginners get up and running quickly, but Pi’s real flexibility lives in its configuration files.

Pi’s core is just 418 lines of TypeScript, and by default it only gives the model four tools (read, write, edit, bash). All of its advanced behavior — which model to use, how large a context, how deep to think — is controlled through external configuration files. Understanding how these files relate to each other and how they’re prioritized is the key step in taking Pi from “usable” to “actually good.”

How many layers does Pi’s configuration have, and what does each one manage?

Pi’s configuration system uses a layered, additive design. Once you understand what each layer is responsible for and its order of precedence, you won’t run into “I changed it but nothing happened.”

Global configuration lives in ~/.pi/agent/, affecting all projects. Project configuration lives in a project’s .pi/settings.json, affecting only the current project. Nested objects in the project config are merged with the global config rather than replacing it entirely.

Beyond the two layers of settings.json, Pi also uses four specialized configuration files, each with a different purpose:

Config file	Location	Purpose	Load timing
AGENTS.md	Project root or ~/.pi/agent/	Project context and coding instructions, injected into the system prompt	Auto-loaded at startup
APPEND_SYSTEM.md	~/.pi/agent/	Global behavior rules, appended to the end of the system prompt	Loaded at startup
settings.json	Global or .pi/	Model selection, UI theme, compaction strategy, retries, and other runtime parameters	Loaded at startup
models.json	~/.pi/agent/	Custom models and Providers (Ollama, vLLM, etc.)	Reloaded each time you open /model
auth.json	~/.pi/agent/	API keys and OAuth credentials (permission 0600)	Read on demand

Below I’ll break down best practices for each configuration file in turn.

How to write an AGENTS.md that actually works

AGENTS.md is the primary entry point for Pi to understand a project’s context. When Pi starts, it looks in several locations and merges their contents into the system prompt: it loads ~/.pi/agent/AGENTS.md first (global instructions), then walks up through parent directories, and finally loads the AGENTS.md in the current directory.

In other words, the global AGENTS.md defines your typical tech stack and general conventions as a developer, while the project AGENTS.md defines that specific project’s constraints and workflow.

What to put in the global AGENTS.md

The global ~/.pi/agent/AGENTS.md is a good place to record the tech-stack preferences you use day to day. The global AGENTS.md that DeepakNess shares on his blog is a great reference example:

This content comes from DeepakNess’s article, Setting Up and Using the Pi Coding Agent. It doesn’t try to be overly specific — instead it gives broad tech-stack hints while asking Pi to defer to the project-level AGENTS.md first.

How to organize a project AGENTS.md

The project-level AGENTS.md needs to be more precise. Here’s a template tailored for a TypeScript project, based on the recommendations in the official Pi documentation:

If you manage multiple projects, it’s worth keeping a template for each project type. Copy it over each time you start a new project and adjust the tech-stack fields as needed.

Remember to reload after changes

Every time you modify AGENTS.md, you need to run /reload or restart Pi for the change to take effect. This operation isn’t triggered often, but it’s easy to forget. It’s best to test immediately after writing a new rule to confirm Pi’s behavior changed as expected.

What does APPEND_SYSTEM.md control?

~/.pi/agent/APPEND_SYSTEM.md is appended to the end of the system prompt, and it takes precedence over AGENTS.md. This means its instructions override what came before.

It’s a good fit for defining behavioral guidelines that apply across projects, especially constraints about how the agent works and how it interacts with the user. Drawing on official recommendations and community practice, a typical APPEND_SYSTEM.md looks like this:

These rules ensure Pi maintains a consistent way of working across projects, without having to restate everything at the start of every conversation.

settings.json: common options explained

settings.json has two layers: global (~/.pi/agent/settings.json) and project (.pi/settings.json). Nested objects in the project layer merge with the global layer. Drawing on the official Pi Settings documentation, here are the settings most worth knowing:

Models and thinking levels

defaultProvider and defaultModel control the model Pi uses by default at startup. defaultThinkingLevel sets the thinking depth, with options including off, minimal, low, medium, high, xhigh, and max.

enabledModels is a high-impact setting. It defines the list of models cycled through by Ctrl+P, and supports wildcards. If you leave it unset, Ctrl+P iterates over every available model for that provider, which hurts the experience significantly.

thinkingBudgets lets you customize the token budget for each thinking level. The numbers above follow the defaults given in the official Pi documentation. Whether to adjust them depends on your model and task: the higher the budget, the deeper the thinking, and the more tokens consumed.

Context compaction

Compaction is Pi’s core mechanism for handling long contexts. When the session approaches the context limit, Pi automatically summarizes older messages to free up space for subsequent conversation.

reserveTokens: the number of tokens reserved for the LLM’s response (default 16384). The smaller this value, the sooner compaction happens.
keepRecentTokens: the number of recent tokens kept without being summarized (default 20000). Kept messages stay intact, ensuring the most recent discussion isn’t lost.

If you regularly handle long sessions, you can raise keepRecentTokens. Note, though, that this reduces compaction efficiency and may hit the model’s context-window ceiling sooner.

Retry strategy

The retry configuration is split into two layers: agent-level retries (handled by Pi itself) and provider-level retries (handled by the API SDK). The official documentation recommends keeping retry.provider.maxRetries at 0, because provider-level retries can burn quota before you even see a rate-limit error.

baseDelayMs controls the initial delay of exponential backoff: 2s → 4s → 8s. For tasks that need to run stably over a long time (for example, batch data crawling), you can reasonably increase this value.

Project trust mode

When Pi first starts in a project, it asks whether to trust that project’s .pi/ directory. This mechanism exists to prevent malicious project plugins from auto-loading.

Available values include ask (ask every time, the default), always (auto-trust), and never (never trust). In CI or automation scenarios, you can use the -a / --approve flag to skip the prompt.

Adding custom models with models.json

If your model isn’t among Pi’s built-in 20-plus Providers, you can add it via ~/.pi/agent/models.json. This file supports Ollama, LM Studio, vLLM, OpenRouter, Cloudflare AI Gateway, and any OpenAI-compatible API endpoint.

Referencing the full configuration notes in the official Pi Models documentation, here are the three most common scenarios:

Scenario 1: a local model via Ollama

apiKey being set to "ollama" is just a placeholder. Ollama doesn’t validate the API key, but Pi needs an auth value to show the model in /model. The two switches under compat target Ollama’s characteristics: it doesn’t support the developer role or the reasoning_effort parameter.

The name field gives a human-readable label. Pi uses this value both in the model selector and when matching the --model mode.

Scenario 2: OpenRouter routing configuration

OpenRouter lets you set routing preferences among multiple API providers. The configuration below follows the OpenRouter example in the official Pi documentation:

The openRouterRouting object is passed through verbatim to the provider field of the OpenRouter API. order specifies provider priority, and data_collection: "deny" declines to use your data for training.

Scenario 3: proxying the Anthropic API

If you use a third-party proxy for the Anthropic Messages API, you can configure it like this:

In models.json, apiKey and headers support three value-resolution modes: a direct literal, $ENV_VAR environment-variable interpolation, or !command command execution. Bitdoze notes in the Pi Coding Agent Setup Guide that Pi supports Ollama, LM Studio, vLLM, and any OpenAI-compatible endpoint. This extensibility is a major advantage over comparable tools.

Managing API credentials with auth.json

~/.pi/agent/auth.json stores the API keys and OAuth tokens for all providers. Its permission is set to 0600, allowing only the current user to read and write it.

auth.json supports three ways of resolving keys:

Literal: use the API key string directly
Environment-variable interpolation: "$MY_KEY" or "${KEY_PREFIX}_${KEY_SUFFIX}"
Shell command: "!security find-generic-password -ws 'anthropic'"

The official documentation notes that auth.json takes precedence over environment variables. This means if you’ve set both a DEEPSEEK_API_KEY environment variable and a deepseek entry in auth.json, the latter overrides the former.

One practical tip is to use a shell command to read the credential from the system keychain, avoiding writing your API key in plaintext to any file:

Model-switching strategy: which model to use when

One of Pi’s core strengths is model-agnosticism. You can pick a different model for different tasks, and switching is instantaneous.

How to switch

Action	Shortcut / command	Notes
Open the model selector	Ctrl+L or /model	Quickly switch models
Cycle through models	Ctrl+P	Rotate through the enabledModels list
Adjust thinking level	Shift+Tab	Toggle thinking depth
Interrupt the current action	Escape	Cancel the running task
Send a steering message	Enter	Interrupt the agent’s current workflow and respond immediately
Send a follow-up message	Alt+Enter	Append a message after the agent finishes its work
Quit	Ctrl+C (press twice)	Exit Pi
Reference a file	@	Fuzzy-search files
Run a command	!	Send a command’s output to the model
Silent command	!!	Run a command without adding it to context

The shortcut table partly draws on the Pi Agent Chinese guide and DeepakNess’s setup article.

A recommended layered strategy

Experience from multiple community users converges on the same pattern: use models in layers, matching capability to task complexity. The following is drawn from DeepakNess and Bitdoze’s articles:

Task type	Recommended model	Thinking level	Reasoning
Quick edits, file operations, batch scripts	DeepSeek V4 Flash / MiniMax M2.7	low or off	Extremely cheap, plenty for fast tasks
Everyday coding, small-to-medium refactors	DeepSeek V4 Pro / Qwen 3.6 Plus	medium	Balances quality and cost
Deep analysis, architecture design, complex debugging	DeepSeek V4 Pro / Claude Sonnet 4	high or xhigh	Needs a deeper reasoning chain
Visual tasks (screenshot understanding, UI analysis)	Kimi K3 / Claude	depends on the model	Proxied via pi-vision-proxy when the main model has no vision

DeepakNess provides a concrete data point in his article: crawling 285,000 URLs with DeepSeek V4 Flash took about 1.5 hours with a total cost of $1. That illustrates the cost-effectiveness of low thinking level plus a cheap model on batch tasks.

enabledModels wildcards

To make Ctrl+P switching more efficient, it’s worth setting an enabledModels list in settings.json:

Wildcards match all qualifying models. If you only need two or three specific models, you can also write exact IDs:

How Thinking Level affects output quality

Pi’s thinking level is a layered parameter that controls how deeply the model reasons before answering. Based on the official Settings docs at pi.dev and the thinkingLevelMap explanation in models.md, different levels correspond to different behavioral characteristics:

Level	Use case	Token budget (default)
off	Simple Q&A, tasks that need no reasoning	no reasoning tokens
minimal	Very simple judgments, such as “yes/no” classification	1024
low	Light reasoning, e.g. formatting, simple conversions	4096
medium	Routine coding tasks	10240
high	Complex refactors, debugging	32768
xhigh	Deep analysis, architecture design	65536
max	Extremely complex multi-step reasoning	provider cap

The differences between levels aren’t linear. The biggest quality gain is from low to medium; from high to xhigh, the marginal returns diminish. In practice, 80% of everyday tasks get satisfactory results at the medium level.

For models that support thinkingLevelMap, you can finely control in models.json which provider-side parameter each level maps to. For example, a given model might only need the high and max levels, with the middle levels skipped:

This mechanism comes from the thinkingLevelMap explanation in the Pi Models documentation. When a model doesn’t support certain levels, Pi automatically jumps to the adjacent supported level.

Context management: compaction, session trees, and manual control

Long sessions are the norm for coding agents. Pi provides three layers of context-management mechanisms.

Automatic compaction

Compaction runs in the background. When the context approaches the model’s window limit, Pi automatically summarizes older messages. compaction.reserveTokens controls when compaction triggers: it fires when the remaining tokens drop below this value. compaction.keepRecentTokens ensures the most recent messages aren’t summarized.

If you want finer control, you can trigger /compact manually and Pi will immediately compact the current session.

Session-tree management

The /tree command displays the session history as a tree structure. Each branch represents a conversation path. Pi supports:

/resume: pick up a previous session and continue working
/new: start a new session
/fork: branch from the current session to begin a new line of conversation

This design lets you try different solution paths without losing context.

A complete configuration template

Combining all of the above, here’s a complete configuration you can put into daily use.

Global settings.json

Global APPEND_SYSTEM.md

Project .pi/settings.json (overriding the global compaction strategy)

This override makes short-session projects that need frequent compaction trigger it earlier, avoiding wasted context window.

Summary

Pi’s configuration system revolves around one core principle: layer on layer, precise control. Global configuration defines general behavior, project configuration overrides specific needs, AGENTS.md conveys project context, and APPEND_SYSTEM.md constrains the agent’s behavioral patterns.

Once you understand what each layer is responsible for and its priority, Pi’s “minimal core + external configuration” design philosophy stops being a “too few features” weakness and becomes a “you control everything” strength. When facing different tasks each day, you only need to switch models with Ctrl+P and adjust thinking depth with Shift+Tab to move quickly between different working modes.

If your configuration already covers the main files mentioned in this article, the next step is to focus on the extension system: use pi install to add packages such as pi-web-access (web search), pi-codex-goal (task tracking), and pi-vision-proxy (vision proxy), gradually building a Pi environment fully suited to your own workflow.

Sources:

Pi Coding Agent in Practice: A Complete Guide from Installation to Everyday Use

Sat, 13 Jun 2026 02:01:27 +0800

Pi is an open-source terminal coding agent built by Mario Zechner, the author of libGDX. Its core is just 418 lines of TypeScript, providing four tools by default — read, write, edit, and bash — with all advanced features supplied through extensions and packages. Previously I analyzed Pi’s design philosophy at the architecture level. This article focuses on real-world use: how to install it, configure it, pick extension packages, and weave Pi into your daily development workflow.

Positioning: Pi’s role in the toolchain

Pi isn’t meant to replace every coding tool. Taking DeepakNess’s actual usage as an example, three tools each have their own division of labor:

OpenAI Codex: handles complex tasks on the main project
Cursor: everyday coding on the main project
Pi: side projects, experimental tasks, and one-off scripts, usually paired with cheaper open-source models

The core logic behind this layered strategy: use strong models plus heavyweight tools for high-complexity tasks, and lightweight agents plus low-cost models for simple or exploratory tasks — keeping overall spending in check.

Installation and first-time configuration

Installing Pi only takes a single command:

Once installed, launch it by typing pi in the terminal and authenticate with the /login command. Pi supports two authentication methods:

Subscription login: supports Claude Pro/Max, ChatGPT Plus/Pro, GitHub Copilot, Google Gemini CLI, and more
API key: choose “Use an API key” and enter your provider’s secret (e.g., DeepSeek)

Use /model or Ctrl+L to open the model selector. The author defaults to deepseek-v4-pro with the xhigh thinking level for deep analysis, switching to deepseek-v4-flash for quick tasks.

Three core extension packages

Pi installs extension packages with pi install. The following three cover most practical scenarios:

pi-web-access

Gives Pi web search, content scraping, YouTube transcription, and GitHub repository exploration capabilities.

The configuration file lives at ~/.pi/web-search.json:

pi-codex-goal

Adds a goal-tracking mechanism for long-running tasks, well-suited to complex tasks that require multiple steps.

pi-vision-proxy

When the main model lacks vision capabilities, it proxies image-analysis requests to a vision-capable model (such as Kimi K2.6).

The configuration-file system

Pi’s configuration is divided into two layers:

AGENTS.md (project context): placed in the project root or ~/.pi/agent/AGENTS.md, its contents are injected into the system prompt. Good for defining a project’s tech stack, coding conventions, and so on.

APPEND_SYSTEM.md (global behavior rules): located at ~/.pi/agent/APPEND_SYSTEM.md, appended to the end of the system prompt and given higher priority than AGENTS.md. Good for defining cross-project behavioral conventions, such as:

Automatically use the vision proxy when the main model lacks vision
Prefer local files, and only search the web when necessary
Explain high-risk edits and commands
Write concisely and avoid AI-sounding language

Shortcuts and common commands

Pi’s interaction design focuses on terminal efficiency:

Action	Shortcut / command	Notes
Open the model selector	Ctrl+L or /model	Quickly switch models
Cycle through models	Ctrl+P	Rotate through configured models
Adjust thinking level	Shift+Tab	Toggle thinking depth
Interrupt the current action	Escape	Cancel the running task
Send a steering message	Enter	Interrupt the agent’s current workflow and respond immediately
Send a follow-up message	Alt+Enter	Append a message after the agent finishes its work
Quit	Ctrl+C (press twice)	Exit Pi

Common commands include /model, /settings, /resume, /new, /tree (session-branch management), /compact (manually compact context), and /session.

A real-world cost example

A typical use case: crawling 285,000 URLs with DeepSeek v4 Flash took about 1.5 hours for a total cost of $1. This illustrates Pi’s cost advantage when paired with open-source models.

Why choose Pi

Pi’s core strengths come down to:

Terminal-native: no UI lag, responsive
Model-agnostic: switch providers anytime via /model, with seamless context migration
Highly customizable: the extension and package mechanism lets users assemble features on demand
Session-tree management: the /tree command supports branching and navigating conversation history
Automatic context compaction: automatically summarizes when approaching the context limit

For terminal users, Pi’s value lies not in “having the most features” but in “having the highest controllability.” Every one of its behaviors is transparent, and every feature is explicitly installed. This design philosophy makes it the ideal choice for side projects and experimental tasks.

Sources:

The Kelly Criterion: Finding the Optimal Bet Size in an Uncertain World

Wed, 20 May 2026 08:03:37 +0800

What problem does the Kelly Criterion solve?

Most decision dilemmas come down to two questions: whether to do something, and how big to do it. The former is about direction; the latter is about sizing. The Kelly Criterion focuses on the latter.

In 1956, John L. Kelly Jr. of Bell Labs derived a mathematical framework while studying noise in information transmission. He discovered that if you treat signal transmission as analogous to gambling, there is an optimal stake size that maximizes the geometric growth rate of long-term wealth.1

The discovery was later introduced to the casino and Wall Street by Edward Thorp. In Beat the Dealer, published in 1962, Thorp showed that managing bet sizes in blackjack with the Kelly Criterion provides a mathematically stable edge. Since then, the Kelly Criterion has become a foundational tool in quantitative investing and money management.2

What does the formula look like

The standard form of the Kelly Criterion:

f* = (bp - q) / b

where:

f* — the fraction of total capital to bet each time
p — probability of winning
q — probability of losing (q = 1 - p)
b — the odds (net profit on a win relative to the amount wagered)

Here’s a concrete example: suppose you’re in a game where a coin toss decides the outcome. You judge the probability of heads at 55% (p = 0.55), and winning pays 2x return (b = 1, i.e., net gain of 1x). Plug into the formula:

f* = (1 × 0.55 - 0.45) / 1 = 0.10

This means you should stake 10% of your total capital each time. Betting more won’t make you grow faster—in fact, the added volatility lowers your long-term growth rate. Betting less wastes your edge.

If the probability of heads is only 45% (below 50%), the formula returns a negative value. The meaning is clear: no edge, don’t bet.

Why “optimal” rather than “maximum”

Here’s a counterintuitive key point. Suppose you have a 60% win rate and 1:1 odds. Intuition says “since I’m favored to win, I should bet a lot.” But the Kelly Criterion says to stake 20% each time.

What if you bet 40%? In the short run, you might earn more. But over the long run, because wins and losses alternate, over-concentration causes wild swings in your capital curve. A single large loss can wipe out many rounds of accumulated gains.

Mathematically, one can prove that in repeated games, the Kelly Criterion maximizes the long-term growth rate (the geometric growth rate) of capital.3

Let’s illustrate with a simplified model. Assume total capital of 10,000 yuan, stake fraction f each round, 60% win rate, 1:1 odds. After 100 rounds, the expected capital at different stake sizes compares as follows:

Stake size	Expected capital after 100 rounds (60% win rate)
10% (Half-Kelly)	~18,000 yuan
20% (Full Kelly)	~22,000 yuan
30%	~19,000 yuan
40%	~12,000 yuan
50%	~4,000 yuan

Note: beyond the Kelly fraction, capital doesn’t decline gradually—it deteriorates sharply. That’s another layer of the Kelly Criterion: it isn’t just the “earn the most” plan; it’s also a “don’t go broke” safety boundary.

Half-Kelly and conservative strategies in real investing

Theoretically the Kelly fraction is optimal, but almost nobody in real investing runs the full Kelly. There are three reasons:

First, probability estimates themselves contain error. You think your win rate is 60%, but the true win rate might be 55% or 52%. Small misjudgments of parameters get amplified under full Kelly.

Second, odds in the real world aren’t fixed. Stock market odds (i.e., expected returns) keep changing with market sentiment, macroeconomics, and industry cycles.

Third, psychological tolerance is limited. Even if mathematically optimal, a 40% drawdown is enough to push most people into panicked capitulation.

That’s why in practice most people adopt “Half-Kelly” or even lower fractions. Half-Kelly sacrifices roughly 25% of the long-term growth rate but cuts capital volatility by about 50%. This tradeoff of “a little return for a lot less volatility” is far more sustainable for most investors.4

What the Kelly Criterion teaches us about life

The core logic of the Kelly Criterion applies not only to casinos and stock markets—it offers a general decision framework.

Identify your edge. The Kelly Criterion assumes you already know p and b. In reality, the first step is to honestly assess: do I have an edge in this domain? How big is it? If the answer is “no” or “uncertain,” the formula recommends zero commitment. That in itself is a valuable life principle: concentrate resources where you have a cognitive edge.

Sizing depends on the size of the edge. The bigger the edge, the more you invest; the smaller the edge, the less. This logic applies to career choices (what are your win rate and potential returns in this track), startup decisions (how strong is your product’s differentiation against competitors), even everyday time allocation (is the marginal return on time spent on this skill declining).

Avoid “all-in” thinking. The Kelly Criterion never recommends going all-in, even with a 90% win rate. It’s a mathematical reminder about humility: the world is always uncertain, and over-concentration is the shortest path to ruin. In career planning, this means keeping your skill set diversified and your income sources spread out; in investing, it means always leaving room to maneuver.

Accept volatility and focus on the long run. The Kelly Criterion optimizes the long-term geometric growth rate, not single-period returns. This requires accepting short-term volatility as the price of admission rather than trying to win every time. Many people lose money investing precisely because they try to eliminate all volatility, and end up accumulating fees and emotional attrition through over-trading.

Common misconceptions

Myth one: The Kelly Criterion guarantees you always win. It doesn’t. The Kelly Criterion only matters when you have a genuine edge. If your win rate is below the break-even point, the formula tells you not to bet.

Myth two: As long as you compute the probabilities correctly, you can use the Kelly Criterion well. The accuracy of your probability estimates is the whole bottleneck. In reality, human probability estimates are subject to systematic biases, and overconfidence is the most common trap.

Myth three: The Kelly Criterion only applies to gambling and investing. Its underlying logic is resource-allocation optimization. Any scenario involving “how much resource should I commit to maximize long-term returns” can draw on this framework.

Summary in one sentence

The core capability the Kelly Criterion teaches us is this: in an uncertain world, translate your judgment of an edge precisely into the intensity of action—neither wasting opportunity through caution, nor destroying yourself through recklessness.

References:

Kelly criterion - Wikipedia
Edward O. Thorp - Wikipedia
Kelly criterion, Wikipedia, “Practical use of Kelly criterion” section
The Kelly Criterion - Investopedia

Every Generation Thinks They Can't Get Ahead—300 Years of Data Says They're All Wrong

Thu, 14 May 2026 12:56:55 +0800

HuXiu recently republished an article from the WeChat account 「不懂经」 introducing the work How to Get Rich in American History by American historian Joseph Moore. The original article’s core argument is clear and powerful: every generation complains that “it’s hardest to get ahead right now,” yet 300 years of data repeatedly prove they were all wrong each time.

That conclusion is striking enough, but the original interpretation stops at a “believe and opportunity will come” level—like a bowl of lukewarm chicken soup. If we push Moore’s framework further, we uncover several key insights the original didn’t fully develop, and they have far more concrete relevance to today than the four words “stay optimistic.”

The real cost of “can’t get ahead” isn’t poverty—it’s hijacked attention

Moore introduces the concept of the “Big Woe” complex: a vast industry—built from academics, media, podcasts, and short videos—whose core business is convincing you that “you can’t get ahead.” The original article’s explanation was “they’re wrong, so you shouldn’t believe them.”

But that explanation ignores a sharper question: why is the human brain so easily captured by pessimistic narratives?

The neuroscience answer is that the human brain is naturally two to three times more sensitive to negative than positive information. This is called the “negativity bias,” a legacy of evolution. In the wild, ignoring good news only means missing a meal; ignoring bad news could cost you your life. To keep you alive, the brain weights negative information far above positive.

This means the “woe industry” Moore describes works not because its content is especially persuasive, but because it surgically exploits the underlying architecture of the human nervous system. Every analysis of “class hardening,” every tweet about “K-shaped divergence,” every podcast about “the middle class sliding back” is injecting extra anxiety signals into a brain already oversensitive to negative information. The real question isn’t “whether the pessimistic narrative is true”—it’s “once your attention is hijacked, how much cognitive capacity is left for action?”

Pew Research Center data shows 60% of young Americans believe “the American Dream is no longer possible.” Moore would counter that the data shows they’re wrong. But being “wrong” at the data level doesn’t change one fact: when a person spends a large slice of cognitive bandwidth on anxiety, the resources they’d use to spot opportunities, weigh risks, and execute plans shrink. The cost of pessimism isn’t that it makes you “disbelieve in opportunity”—it leaves you with no energy to do the things that create opportunity.

This is exactly the point Moore touches on when citing Consumer Financial Protection Bureau research: income and “financial well-being” are only weakly correlated—the strongest predictors are “optimism about the future” and “saving habits.” The causal chain goes like this: pessimistic narrative → hijacked attention → reduced capacity for action → missed opportunities → confirming the “can’t get ahead” prophecy.

“The past was easier” is a cognitive illusion, but today’s anxiety has real anchors

Moore uses 300 years of data to establish a stable cognitive pattern: every generation yearns for a time when “the past was easier.” Virginians in 1676 thought things were better 15 years earlier; textile workers in 1870 thought the colonial era was better; workers in 1929 thought the Gilded Age was better.

This pattern holds true in today’s China. Social media is full of nostalgia for “the era around 2010”: housing prices hadn’t taken off yet, the internet still had its dividend, and getting a civil-service job wasn’t so ruthlessly competitive. But China’s per-capita GDP in 1980 was only about $200, and most families couldn’t afford a single color TV. The so-called “easier past” simply doesn’t hold up in material terms. However, Moore’s framework has a blind spot: it conflates “material standard of living” and “opportunity structure.” Material standards have indeed been rising steadily. An ordinary white-collar worker in 2026 enjoys far better material conditions than a rural “ten-thousand-yuan household” of the 1980s. But changes in opportunity structure are nonlinear. In certain historical windows, the density and variety of opportunities contract sharply. For example:

In 19th-century America, if you could buy a plot of land and start a farm, you had a chance to accumulate capital. Land was cheap; the barrier was physical labor.
In the mid-20th century, if you could enter a big corporation and secure a lifetime employment contract, you could steadily build middle-class wealth. The barrier was a diploma and loyalty.
From the late 20th to early 21st century, if you could get into the internet industry and receive stock options, you might achieve upward mobility within a decade. The barrier was technical skill and timing.

By 2026, these three channels have all narrowed to varying degrees. Land is no longer an ordinary person’s ticket in; lifetime employment has become flexible labor; the internet’s dividend is over, and AI is reshuffling the deck. Moore would say “every generation thinks the channel is closed, but they’re wrong”—and that’s statistically true. But “statistically, someone can make it” and “most people can make it” are two different things. Here’s a key data point the original article missed: the research Moore cites shows that between 1820 and 1910, at most 28% of residents in US cities achieved upward mobility. The original called “28% a striking number” because it was far higher than Europe in the same period. But read the sentence the other way: 72% did not achieve upward mobility.

Most people stay where they are; a minority get ahead. What Moore proves is that “can’t get ahead” is wrong as a collective judgment, but as an individual experience it’s real for most people. Acknowledging that is more constructive than simply denying it.

Slow time and fast time: the real lesson isn’t “wait”—it’s “posture of readiness”

Moore’s “Slow Time” and “Fast Time” framework is the most practically valuable concept in the book. The original interpreted it as: accumulate during slow time, and when fast time arrives you’ll be ready to catch it.

That interpretation is too simplistic. Moore tells two stories to illustrate the framework:

Hollywood star Kim Basinger bought a small Georgia town in the 1990s, hoping to build a film studio. Her direction was right (the region later became one of the fastest-growing film production centers in the world), but she mistook slow time for fast time and went bankrupt waiting.

Norman McGhee bought more than 100 foreclosed homes with borrowed money during the Great Depression, and after the economy recovered became one of the most important Black businessmen of his generation. He kept slow-time patience during fast time.

The difference between these two stories isn’t patience—it’s cognitive precision. Basinger knew the direction was right but didn’t know the time scale. McGhee knew the direction was right and also understood that economic cycles have their own rhythm. The distinction: one was betting that fast time would come, the other was making structural preparations for fast time. To translate the framework into today’s language: “slow time” is the everyday you’re living through right now. Housing prices drifting down, discussions of AI replacing jobs, workplace rat-race, consumption downgrading. These changes are so slow they feel like they’ll never end.

“Fast time” is the moment some variable suddenly breaks through its threshold. It could be an AI capability breakthrough that makes certain jobs vanish overnight, a policy shift that opens a new wealth channel, or the start of a technology cycle that pays disproportionate returns to those who got positioned early. What Moore is really saying: you can’t predict when fast time will arrive, but you can place yourself in a structural position that can catch it when it does. That position is more than simply “saving up enough money.” It includes: whether the skills you hold will command a premium in the next wave of change; whether your network connects you to the sources of new opportunity; whether your cognitive framework is flexible enough to recognize the signal that “the rules have changed.”

In other words, preparation in slow time isn’t passive waiting—it’s a deliberate “posture adjustment.”

“The rules keep changing”: every generation navigates with the previous generation’s map

Moore uses 300 years of data to trace how the rules for getting rich have changed: farms and canal stocks in the 19th century, railroads and steel in the early 20th, stocks and real estate in the mid-20th, corporate equity and the internet in the late 20th, and today compute capacity, attention coordinates, and algorithmic pricing power. The original summarized this insight as “most people operate with the previous generation’s map,” but didn’t ask a deeper question: why does every generation walk around with an old map? The answer lies in the “anchoring effect” from cognitive science. The human brain tends to use the most recent success as the template for the future. If someone profited from real-estate speculation in 2015, their brain encodes “buying property = making money” as a reliable rule. When the environment shifts (prices no longer rise broadly, liquidity tightens), their first reaction isn’t “the rules changed”—it’s “this is only temporary.”

That’s why Moore’s data is so persuasive: it isn’t saying something abstract like “opportunity always exists.” It’s saying “the rules switch far more frequently than human intuition expects.” Over 300 years, the rule for getting rich has undergone a fundamental transformation roughly every 30 to 50 years. And the psychological age of humans (how fast their cognitive framework updates) can’t keep up with that pace.

Placing this pattern in the 2026 Chinese context: the mainstream wealth path of the past 20 years was “college → big tech / civil service → buy a house → financial security.” That path was largely effective before 2020. But now, layoffs at big tech have become routine, the civil service is cutting salaries while expanding headcount, and housing prices are flat or drifting down. The old map is failing. But Moore’s data also tells us: the moment the old map fails is precisely the moment a new map becomes most valuable. At every rule switch, a small group—precisely because their cognitive framework is flexible enough—identifies and executes the new rules first. What they share isn’t good luck; it’s that they started exploring the new rules while the old ones were still working.

Marriage as a financial strategy: a badly underrated variable in the Chinese context

The original article mentioned that Moore sees marriage as a “badly underrated financial strategy,” but only gave a superficial treatment. In today’s Chinese context, this point deserves its own unpacking.

All the examples Moore cites point to the same mechanism: a dual-income household lives on one income and pours the other into asset accumulation. Flagler, Bell, Stanford, and Sam Walton all launched with capital from their spouse’s family. This was common knowledge in 19th-century America, but in today’s Chinese discourse, “marriage” is mostly discussed as a matter of emotion and consumption (bride price, weddings, adding a name to the property deed), and almost never as a synergy.

The core mechanism is this: a single-worker financial model is linear (time for money); a dual-worker model is, ideally, exponential (one income covers living costs, the other goes entirely into compounding assets). Moore makes a sharp remark in the book: “Having one person support the family is the real invention—and it’s a terrible one.”

This isn’t advocating “marrying for money.” Moore’s point is that marriage, as a long-term shared financial unit, yields compounding effects far beyond what most people recognize. One person’s spending impulses are random; two people’s spending decisions, after negotiation, tend to be more rational. One person’s investment perspective is singular; two people’s combined knowledge and judgment cover more ground. This isn’t psychology chicken soup—it’s portfolio theory applied to the household.

The real takeaway: belief is the infrastructure for action

Moore’s own transformation story is the most persuasive part of the book. Born into a Southern working-class family and a committed Marxist, he taught students each semester that “the American Dream is a myth.” After the 2008 financial crisis, he began personally testing the money-making methods he’d excavated from historical sources. Eventually, he became a millionaire.

The original read this transformation as “belief changes destiny,” but that’s only the surface of the story. A more accurate formulation: belief is the infrastructure for action.

When Moore believed “you can’t get ahead,” his behaviors were: studying history, analyzing inequality, criticizing capitalism in the classroom. These behaviors were cognitively self-consistent but financially inert. When he changed that underlying belief, his behaviors changed with it: he started buying property, running things by market logic, making decisions with business reasoning. The key isn’t “optimism” itself—it’s that optimism changes the search space of behavior. A pessimistic person chooses among known, low-risk options. An optimistic person searches a larger space of options, including those with higher risk and higher reward. Over the long run, a larger search space means a higher expected value.

This aligns with another study Moore cites: optimistic views of the future significantly predict long-term saving behavior. Saving isn’t the “result of optimism”—saving is “a manifestation that optimism has changed behavior patterns.” What actually changes is that the person begins making decisions on longer time horizons, directing resources toward the future instead of burning them in the present.

Closing thoughts

Moore uses 300 years of data to prove three things: every generation thinks it’s living through the hardest era, but the data says they’re wrong; the rules for getting rich keep changing, and most people navigate with an old map; fast time will always come—you can’t predict when, but you can position yourself to catch it.

The original interpretation stops there. But push one level deeper, and Moore’s real contribution isn’t the data or the framework—it’s a more basic observation: human judgments about their own situation systematically deviate from reality.

And that deviation almost always runs toward pessimism. That bias itself is the source of opportunity.

Because while most people are consuming cognitive resources in pessimism, those who keep their capacity for action face less competition.

Reference: 不懂经 - It’s easier to get ahead today than ever before

Malus.sh: How AI Clean-Room Clones Threaten the Open Source Sustainability Loop

Tue, 05 May 2026 07:16:47 +0800

What is Malus.sh

Malus.sh (pronounced like “malice”) is an AI-powered tool that claims to recreate functional equivalents of any open source software from scratch using “Clean Room” engineering methods, while stripping away all license obligations of the original project. Its most eye-catching slogan: “No attribution. No copyleft. No problems.”

What makes the project unique is that it is both a satirical work and a genuinely operating commercial product. Founder Mike Nolan works as a researcher on the political economy of open source at the United Nations. In an interview with 404 Media, he explicitly stated that if it were only satire, open source practitioners would dismiss it with “that can’t happen to me.” Making the tool actually usable forces the community to confront the structural cracks that already exist in the open source economic model.

Malus.sh is registered as an LLC, accepts payments via Stripe, and has real paying customers. Its “liberation service” is currently unavailable, but the industry discussion it ignited keeps spreading.

Technical mechanism: AI-accelerated clean-room engineering

Historical precedent of the traditional clean-room method

The legal foundation of clean-room engineering dates back to the 1982 IBM BIOS case. At the time, IBM monopolized the personal computer market, and competitors wanted compatibility without infringing copyright. The solution was:

Team A analyzes IBM’s original BIOS code and writes a functional specification
Firewall isolation: strict separation between Team A and Team B
Team B sees only the specification and reimplements the code from scratch
Legal outcome: functionally compatible but independently written code, ruled by the court to be non-infringing

This case was dramatized in the first season of the HBO series Halt and Catch Fire, becoming a key milestone in the history of software copyright law.

Malus’s AI version of the process

Malus fully automates the traditional clean-room method:

The concrete steps include:

Upload manifest: supports formats like package.json, requirements.txt, and Cargo.toml
Isolated analysis: four AI units separately read the README, analyze the API, study type definitions, and review documentation—“never seeing a single line of original source code”
Independent rebuild: behind an isolation firewall, a separate set of AIs reimplements the code from the specification
License liberation: the output code ships with the MalusCorp-0 License—zero attribution, zero copyleft, zero obligations

A leap in speed

AI’s biggest change to clean-room engineering is time compression. Malus claims:

Project	Traditional time	Malus time
IBM BIOS clone (1984)	4+ months	an entire engineering team
left-pad (11 lines of code; its 2016 deletion crashed builds worldwide)	hours of manual rewrite	10 seconds
SPACEWAR! (the first video game)	weeks	5 seconds

Developer Dan Blanchard used Anthropic’s Claude Code in early 2026 to do a similar “from scratch” MIT-licensed rewrite of the popular Python library chardet. His verdict: “What used to take a team months or even years to rewrite, AI can now do in days. This trend is irreversible.”

Business model and pricing

Malus.sh uses a usage-based pricing model:

Item	Details
Billing method	Per-KB, based on uncompressed package size
Per-package limit	10 MB
Per-run limit	50 packages
Payment methods	USD, EUR, BTC, stock options
Output license	MalusCorp-0 License
Legal protection	Claims indemnification via “an offshore subsidiary that doesn’t recognize software copyright”

The “customer testimonials” on the site are clearly satirical—e.g., “guilt doesn’t show up on quarterly reports.” But the pricing structure and payment functionality are real.

The founder’s core argument

Mike Nolan laid out Malus’s position systematically in his March 2026 blog post, “Thank You for Your Service.”

Three structural problems with open source

Cases where open source has already failed

Year	Event	Type
2016	left-pad deleted, thousands of builds crashed worldwide	Maintainer sabotage
2021	Log4Shell (CVE-2021-44228)	Critical CVE
2022	colors.js and faker.js injected with infinite loops	Maintainer protest
2022	node-ipc contained a file-deletion payload targeting Russian/Belarusian IPs	Geopolitical sabotage
2025	Shai Hulud 2.0 npm worm	Supply chain attack

On Log4Shell, Nolan wrote: “Engineers patched it over their Christmas holidays, while the people who actually maintain Log4j are mostly unpaid volunteers who received panicked emails from around the world. This isn’t the failure of any individual—it’s the natural consequence of building critical global infrastructure on code that nobody is formally responsible for maintaining.”

Enterprise compliance cost comparison

Expense item	Annual cost
SCA tools	$1.2M
OSPO team	$850K
Legal review	$700K
Incident response	$980K
CLA management	$270K
Total traditional open source compliance	$4M
Malus full liberation package	$50K/year

Nolan claims savings of 98.75%.

Response to “exploitation” accusations

Acknowledgment of the “tragedy of the commons”

Legal and ethical controversy

Arguments supporting clean-room validity

Copyright law protects expression, not ideas. The 1879 case Baker v. Selden established this principle. Phoenix Technologies successfully cloned the IBM BIOS using the clean-room method in 1984 and received court recognition. If AI-generated code differs completely from the original at the level of expression and is only functionally equivalent, then in theory it does not infringe copyright.

Core arguments questioning the authenticity of the clean room

Training data exposure: AI models have already been exposed to the original open source code during training. If the LLM’s weights contain patterns from the original code, can its output truly be considered “independent creation”?
Copyright ownership of AI output: The US Copyright Office has made clear that purely AI-generated works are not copyrightable. If Malus’s output has no human author, users can’t claim copyright protection for it either.
Inducement to infringe: marketing explicitly aimed at “circumventing copyright” may constitute inducement liability.

A highly-upvoted Slashdot comment noted: “Good luck getting a judge to agree that an AI performed a ‘clean-room’ implementation—when that very AI was trained on the code it’s ‘reinventing.’”

Another commenter added: “The Chinese Wall legal strategy requires Team A to produce the specification and Team B to produce the implementation. If these people can’t show the specification, they’re done. Arguing that a specification must exist somewhere in the abstract Platonic space of an LLM’s black-box network won’t convince a courtroom.”

Why this threatens the open source sustainability loop

The sustainability of the open source ecosystem relies on an implicit social contract:

Contributors publish code and receive reputation, collaboration opportunities, and indirect commercial value
Users comply with license obligations (attribution, copyleft, feeding improvements back)
Companies use open source to cut development costs while giving back to the ecosystem through compliance spending

The capability Malus.sh demonstrates breaks this loop on three levels:

First, the enforceability of license obligations is hollowed out. When anyone can obtain a functionally equivalent but legally independent version at near-zero cost, MIT’s attribution requirement, GPL’s copyleft constraints, and Apache’s notice-preservation clauses all lose their practical teeth.

Second, contribution incentives are eroded. If developers know their work can be copied by AI with obligations stripped away, why choose open source at all? The reward of reputation presupposes that attribution is respected—and Malus’s core selling point is precisely “zero attribution.”

Third, the motivation for corporate compliance spending disappears. Traditionally, companies invest in OSPOs, SCA tools, and legal review both as a compliance need and as an indirect way to support the open source ecosystem. When Malus cuts compliance costs from $4M to $50K, that “savings” doesn’t flow to open source projects—it simply disappears.

The “commons decay” scenario Nolan himself acknowledges in his blog describes exactly this gradual unraveling of the loop: not a sudden collapse, but a slow erosion of willingness to contribute, ultimately draining the open source commons dry.

An irreversible trend

Malus.sh itself may be an elaborately designed satire, but the capability it demonstrates is already being used seriously. Dan Blanchard’s rewrite of chardet with Claude Code shows that this technique needs no dedicated Malus platform—anyone with a mainstream AI coding tool can achieve a similar result.

Blanchard’s verdict reflects a broad consensus in the industry: “What used to take a team months or years to rewrite, AI can now do in days. I don’t think there’s any way to put the genie back in the bottle.”

The market impact of this trend is already visible. In early 2026, software stocks like Oracle were sold off over concerns that “AI can be used to rapidly replicate software functionality.”

References

Claude Cowork vs. Code Mode: The Key Differences

Wed, 29 Apr 2026 02:54:21 +0800

In early 2026, Anthropic introduced three parallel work modes to the Claude desktop client: Chat, Cowork, and Code. Chat continues the traditional conversational interaction, while Cowork and Code represent two different directions of Agentic capability expansion. Both share the same Claude model engine, yet differ fundamentally in interaction interface, toolchain, and optimization targets.

This article focuses on comparing Cowork and Code, systematically covering core positioning, capability boundaries, and real-world use cases.

1. Core positioning: the same engine, two different kits

Cowork and Code aren’t two independent products — they’re two packaging forms of the same intelligence engine aimed at different user groups.

Dimension	Cowork	Code
Design goal	General office automation for non-developers	Code engineering tool for developers
Interface form	GUI tab inside the Claude Desktop app	Terminal CLI / IDE plugin / Desktop Code tab
Underlying capabilities	Based on Computer Use (screenshots + mouse/keyboard control)	A full development toolchain based on MCP + Shell + Git
File access	Explicitly authorized folders, sandboxed access	Full project-level filesystem access
Code execution	Executes after showing a plan; visualization-oriented	Runs shell commands, tests, and builds directly
Git integration	None	Full lifecycle (branches, commits, PRs)

The relationship can be summarized as: same engine, different equipment. The model-level reasoning capabilities are identical (both use Opus or Sonnet); the differences lie in the tool set the model is allowed to call and how humans interact with it.

2. Cowork: the “desktop automation colleague” for non-technical users

Cowork launched in January 2026. Anthropic positions it as “Claude Code for the rest of your work” — extending the Agentic capabilities developers already enjoy to non-technical scenarios.

Core capabilities

Local file read/write: after the user authorizes specific folders, Cowork can directly read, create, and modify files without manual uploads and downloads
Cross-app desktop automation: built on Computer Use, it identifies UI elements via screenshots and controls mouse and keyboard, operating any desktop program — Excel, PowerPoint, browsers, and more
Browser automation: reads Gmail and backend web data, using the user’s already-logged-in sessions to complete web-level tasks
Subagent orchestration: breaks complex tasks into parallel workflows, automatically merging results from multiple subtasks
Scheduled tasks: supports the /schedule command to set up daily or weekly recurring automation flows
Professional document generation: directly outputs office formats such as PPTX, XLSX (including formulas), and DOCX

Typical use cases

File organization: “Sort the 200 screenshots on my desktop by date and generate an index table”
Data extraction: “Read 50 PDF invoices and extract supplier names, dates, and amounts into Excel”
Scheduled reports: “Every Monday at 9 AM, automatically summarize Salesforce sales data and generate a weekly report”
Presentations: “Generate a formatted PowerPoint deck based on the research materials”

Cowork’s design philosophy is lowering the barrier to entry: the user describes the goal in natural language, and the system executes autonomously after presenting an execution plan, with real-time progress visible in the GUI.

3. Code: the developer’s “terminal-level engineering assistant”

Code mode (and the earlier-released Claude Code CLI) targets software development, offering deep access to codebases and development toolchains.

Core capabilities

Codebase-level understanding: automatically maps project structure, dependency relationships, and cross-file references to build a complete code context
Multi-file refactoring: modifies code across files in a single session, updates import statements, adjusts test cases, and fixes build errors
Terminal command execution: runs shell scripts, test suites, build pipelines, and deployment commands directly
Full Git lifecycle: a complete loop from reading issues and writing code to running tests and submitting PRs
MCP tool connections: connects to external systems like GitHub, Slack, Jira, and databases via the Model Context Protocol
Background agents and /loop: supports long-running tasks such as reviewing PRs every 5 minutes or continuously monitoring deployment status (up to a week)
Plan mode: read-only exploration of the codebase without modifying any files, suitable for the understanding and analysis phase

Typical use cases

Feature development: “Add JWT authentication to the Express app, create middleware and routes, and write tests”
Code refactoring: “Refactor the service module across 8 files, run the tests, and submit a PR”
Bug hunting: “Track down the frontend rendering issue, open the browser debugger, and analyze the UI with screenshots”
Continuous monitoring: “Set up a background agent to continuously monitor new PRs in the repo and automatically perform code reviews”

Code’s design philosophy is precise control: developers interact with the model via terminal or IDE, can review every intermediate output, and make fine-grained corrections when necessary.

4. Underlying technical differences

Computer Use vs. MCP + Shell

Cowork’s core technology stack is Computer Use — Claude captures screen images, identifies UI elements, and then simulates mouse clicks and keyboard input to complete tasks. The advantage is generality: in theory, it can operate any application with a graphical interface. The cost is lower efficiency — every step requires screenshots, analysis, and simulated input, with limited tolerance for UI changes.

Code’s core technology stack is MCP (Model Context Protocol) + Shell commands. MCP gives the model a structured tool-calling interface (reading files, executing commands, querying databases), while Shell grants direct access to system-level tools. The advantage is precision and efficiency: the model can manipulate the filesystem directly, run compilers, and invoke test frameworks without the indirect simulation of a GUI layer.

Memory mechanisms

Cowork: persistent memory based on Projects, retaining task history and connector configurations across sessions
Code: project-level instructions based on CLAUDE.md files plus automatic memory; finer-grained memory, deeply tied to codebase structure

5. Choosing between them

The following decision table helps you quickly determine which mode to use:

Task characteristics	Recommended mode
Involves codebases, version control, testing, and builds	Code
Requires operating multiple office apps, organizing files, generating documents	Cowork
Repetitive office tasks that need scheduled execution	Cowork
Needs deep code understanding and cross-file refactoring	Code
Quick Q&A, brainstorming, mobile interaction	Chat

Common misconceptions

Cowork is not a GUI version of Code: the two have completely different interfaces and optimization directions; Cowork lacks Git support, terminal access, and IDE integration
Writing code in Cowork is inefficient: without codebase-level context and build toolchains, cross-file refactoring is limited
Configuring Code for non-developers is a poor fit: the terminal interface and development workflow impose unnecessary learning costs on operations, sales, HR, and similar roles

6. Summary

Cowork and Code represent Anthropic’s two productization paths for Agentic AI: Cowork centers on generality and ease of use, targeting daily office automation for knowledge workers; Code centers on precision and control, targeting engineering needs of software developers. The two aren’t in competition — they’re complementary. The same user may need both in different scenarios.

From a broader perspective, the three-layer structure of Chat, Cowork, and Code also reflects an evolution trend in AI products: from passive response (Chat) to proactive execution (Cowork/Code), from single conversation to tool integration and then to system-level automation. For users, understanding each mode’s boundaries and strengths is a prerequisite for using the Claude ecosystem effectively.

References

This article synthesizes information from the following public sources:

Pi Coding Agent: A Terminal AI Coding Agent Built on 418 Lines of Code

Wed, 29 Apr 2026 02:07:14 +0800

Pi (full name pi-coding-agent) is an open-source terminal AI coding agent (a CLI coding harness). It has accumulated more than 17,500 stars on GitHub, with peak npm weekly downloads of 1.3 million. It was developed by Mario Zechner (author of the well-known game framework libGDX, GitHub @badlogic), and recently ranked first on OpenRouter’s trending list.

Core philosophy: minimalism and extensibility

Pi was born out of Zechner’s dissatisfaction with existing coding agents. As he wrote on his blog: “Claude Code has turned into a spaceship — I don’t use 80% of its features. The system prompt and tools change with every release, breaking my workflow.”

Pi’s philosophy can be summed up as: “If I don’t need it, I don’t build it.”

Compared with similar tools, Pi chooses extreme minimalism on multiple dimensions:

Dimension	Mainstream tools like Claude Code	Pi
Core agent loop	Thousands of lines of code	418 lines of TypeScript
System prompt + tool definitions	Thousands of tokens	< 1,000 tokens
Default tools	A dozen or more	4 (read, write, edit, bash)
Built-in features	Big and comprehensive	Minimal, filled out with extensions

Zechner’s core assumption: all frontier models have been heavily trained with RL, so they already understand what a coding agent is. Therefore the harness doesn’t need to over-instruct the model — the lighter the better.

Four-layer architecture

Pi uses a strictly bottom-up layered design, with each layer having zero dependency on the layers above it:

pi-ai: cross-provider context migration

pi-ai is the low-level unified LLM API, supporting 15+ providers and 300+ models. It normalizes four protocols — OpenAI Completions, OpenAI Responses, Anthropic Messages, and Google Generative AI — into a unified event-stream format.

Its killer feature is cross-provider context migration: in a single session you can think with Claude first, then switch to GPT-4o to verify, with the context carried over seamlessly. Claude’s thinking traces are automatically converted into `` tags for OpenAI models to read.

pi-agent-core: the 418-line dual loop

This is Pi’s core, using a two-layer separation of AgentMessage (application layer) and LLM Message (model layer):

No maximum step limit: the loop keeps running until the agent itself declares completion
Runtime hot-swapping: setModel(), setTools(), setSystemPrompt() take effect at any time
Steering mechanism: users can send “steering messages” while the agent is executing tools; the agent responds as soon as it finishes the current tool, skipping the remaining queued tool calls
Three-tier event system: full streaming event subscription at the agent / turn / message / tool level

pi-coding-agent: the terminal application layer

Provides four operating modes:

Mode	Use case
Interactive	Full TUI interaction experience
Print (-p)	Generate a shell script and print it
JSON (–mode json)	Structured event stream, good for pipelining
RPC (–mode rpc)	JSON protocol over stdin/stdout, embeddable in other applications
SDK	Embed directly into Node.js applications

Extensibility: Pi’s real killer feature

Pi turns “features built into other tools” into “extensions you build or install yourself” — this is its most fundamental difference from tools like Claude Code.

Extensions: TypeScript modules with access to tools, commands, shortcuts, events, and the full TUI
Skills: on-demand capability packages (instructions + tools)
Prompt Templates: reusable Markdown prompts expanded quickly with /name
Pi Packages: extension packages distributed via npm or git

The official repo offers 50+ extension examples, including subagents, plan mode, permission gating, path protection, SSH execution, sandboxing, and MCP integration.

Context-engineering mechanisms

Pi provides multiple mechanisms for precise context control:

Mechanism	Use case
AGENTS.md	Project-level instructions, placed in ~/.pi/agent/ or the project directory
SYSTEM.md	Replace or append to the default system prompt
Compaction	Automatically summarizes near the context limit; customizable
Dynamic Context	Inject messages, filter history, RAG, and long-term memory via extensions

Community positioning and the Harness Effect

According to a six-harness comparison released by Pawel Jozefiak in April 2026, Pi’s positioning is that of a moldable, minimal harness.

The review proposed an important “Harness Effect”: the same model can differ by 5–40 percentage points across different harnesses. For example, Claude Opus scores 77% in Claude Code but reaches 93% in Cursor. Pi’s value is that it provides a highly tunable, fully transparent foundation, letting users optimize this effect for themselves.

Tool	Positioning	Characteristics
Claude Code	Agent Orchestrator	Strongest contextual coherence; suited to complex multi-file tasks and unattended overnight runs
Codex CLI	Coding Tool	Executes cleanly but lacks contextual coherence
Aider	Coding Tool	High editing precision, but doesn’t aim to be an autonomous agent
OpenCode	Middle ground	Built by the SST team; feature-complete
Pi	Moldable minimal harness	Lightweight, transparent, deeply customizable

What can you use it for

Everyday coding agent: a replacement for Claude Code / Codex CLI, handling code generation, refactoring, and debugging in the terminal
Custom workflows: build your own “plan mode”, “permission gating”, and “subagent orchestration” via extensions
Embedding in other applications: use Pi as an engine inside your own tools via the SDK or RPC mode (OpenClaw takes this approach)
Multi-model collaboration: switch between different models within a single task, leveraging each one’s strengths
Overnight autonomous runs: combine the steering and follow-up mechanisms for long-running autonomous tasks
Team standardization: share coding conventions and workflows across a team through AGENTS.md, Skills, and Pi Packages

Quick start

Pi’s install and launch flow is extremely simple.

Installation

Launch it after entering your project directory:

Adding a model (authentication)

Pi supports two authentication methods:

Method 1: subscription login

Run this inside Pi’s interactive interface:

Then choose a provider. Built-in support includes Claude Pro/Max, ChatGPT Plus/Pro (Codex), GitHub Copilot, and Google Gemini CLI.

Method 2: API key

Set the environment variable before launching:

You can also choose an API-key provider via /login, storing the key in ~/.pi/agent/auth.json.

Task conversations

After launching, just type what you need:

Four tools are provided by default: read (read files), write (write files), edit (edit files), and bash (run commands). Read-only tools like grep, find, and ls can be enabled via options.

Common operations:

Reference a file: type @ for fuzzy search, or specify directly on the command line: pi @README.md "Summarize this"
Run a command: !npm run lint (send output into the model’s context), !!command (run without sending into context)
Switch models: /model or Ctrl+L
Continue sessions: pi -c (most recent session), pi -r (browse history), /resume, /new, /tree (session management)
Non-interactive mode: pi -p "Summarize this codebase" (single-shot output)

Project instructions

Create an AGENTS.md in the project root, which Pi loads automatically at startup:

Run /reload after modifying it for changes to take effect.

Summary

Pi is not “yet another Claude Code replacement.” It is a radical minimalist experiment, proving that a well-designed lightweight harness can match or even surpass complex frameworks.

It’s best suited to developers dissatisfied with the “black-box behavior” of existing agents, and to advanced users who want full control over the system prompt, tools, and context flow. If all you want is an “out-of-the-box, feature-complete” experience, Claude Code may remain the first choice; but if you want to understand and control every line of behavior in your agent, Pi is one of the most transparent options available today.

Sources

Key Differences Between Q4 and UD-Q4 Quantized Models

Thu, 23 Apr 2026 05:32:47 +0800

In local deployment and inference optimization for large language models (LLMs), quantization is the key to reducing VRAM usage and improving runtime speed. Among the options, Q4 (4-bit quantization) has become the de facto “gold standard” in the industry thanks to its excellent balance between performance and precision.

Recently, with the rise of optimization frameworks like Unsloth, a new format called UD-Q4 (Unsloth Dynamic Q4) has entered developers’ view. This article takes a deep dive into the core differences between standard Q4 and UD-Q4, and examines the important position of 4-bit quantization in the model quantization landscape.

1. Core definitions and technical differences

Q4 (Standard Quantization)

Standard 4-bit quantization (such as Q4_K_M in the GGUF format, or the earlier Q4_0) typically uses a static quantization strategy.

Bit allocation: Every layer and every weight block uses a fixed number of bits (4-bit).
Technical characteristics: Relatively simple to implement, with excellent compatibility across inference backends.
Limitations: Treats all weights the same, with no way to give extra protection to the layers that matter most in the model (such as key attention weights).

UD-Q4 (Unsloth Dynamic Q4)

UD-Q4 stands for Unsloth Dynamic quantization. It departs from the “uniform allocation” approach and introduces finer-grained optimization.

Dynamic bit allocation: Dynamically adjusts the bit count per layer based on each weight’s influence on model output (typically calibrated with imatrix data). Core layers may get 6-bit, while less important layers drop to 3-bit.
Precision advantage: While maintaining an average of 4-bit (bpw ≈ 4.5), UD-Q4 uses this “rob Peter to pay Paul” strategy to significantly reduce quantization loss (perplexity), with precision that often approaches traditional 5-bit models.

Feature	Standard Q4 (Q4_K_M)	Unsloth UD-Q4
Quantization strategy	Static / fixed	Dynamic / importance-aware
Average precision	Industry baseline	Above baseline, approaching Q5
Compute overhead	Very low	Slightly higher (quantization stage only); inference identical
Best use case	General-purpose, high performance	Pursuing the ultimate precision-to-size balance

2. Q4’s benchmark status in quantization

In the history of LLMs, the arrival of 4-bit quantization (Q4) was a milestone. It dominates for one reason: a balance across three dimensions.

2.1 The “sweet spot” between precision and compression ratio

According to a large body of academic research (such as GPTQ and GGUF/llama.cpp test data), the precision-vs-bit-count curve typically shows an “inflection point” at 4-bit. Going above 4-bit (e.g., 5-bit, 8-bit) yields diminishing marginal precision gains, while going below 4-bit (e.g., 3-bit, 2-bit) causes precision to fall off a cliff.

2.2 Fits within VRAM budgets

4-bit quantization shrinks raw FP16 weights by roughly 4x (about 3.5–3.8x in practice once metadata is accounted for). This means:

7B/8B parameter models run smoothly on consumer GPUs with 6GB/8GB of VRAM.
70B parameter models can be deployed with 48GB of memory (e.g., dual A6000s or Mac unified memory).

2.3 Hardware acceleration support

Current GPUs and NPUs (such as Apple Silicon’s Neural Engine) have good native or instruction-set-level optimization for 4-bit computation. Compared with non-standard formats like 3.5-bit, Q4 has a natural advantage in data alignment and compute efficiency.

Conclusion

Q4 (Q4_K_M) is the current industry standard for local LLM inference, representing the broadest compatibility and reliable performance. UD-Q4 is the next step in the technique’s evolution: through importance-aware dynamic allocation, it squeezes out the model’s last drop of precision potential without changing the hardware bar.

For the average user, Q4_K_M remains the safe “close your eyes and pick it” choice; for developers who want smarter responses within a limited VRAM budget, UD-Q4 is clearly the best option available today.

References and further reading

Demystifying LLM Quantization Suffixes: What Q4_K_M, Q8_0, and Q6_K really mean - Medium
Quantization for Local LLMs: How It Works and Which Formats Fit Your Setup - Hardware Corner
Choosing a GGUF Model: K-Quants, I-Quants, and Legacy Formats - Kaitchup Substack
GGUF Quantization Explained — Q4_K_M vs Q5_K_M vs Q8: VRAM, Quality - Will It Run AI
Unsloth Model Explorer (for UD-Q4 variants) - Hugging Face

Guide to Buying China's Mainstream AI Coding Plans: A Hands-on Speed and Price Comparison of 9 Platforms

Thu, 16 Apr 2026 09:46:38 +0800

Since the second half of 2025, Chinese LLM vendors have been rolling out Coding Plan subscriptions aimed at developers, replacing the traditional per-token billing with a fixed monthly fee and significantly lowering the barrier to AI-assisted programming. However, the platforms differ widely in pricing, quotas, response speed, and model support—and some even have hidden clauses like different metering units and strict limits, leaving many developers struggling to choose.

This article combines a hands-on Xiaohongshu test note, an in-depth cross-review from Cnblogs (博客园), and each platform’s official documentation to sort through 9 Chinese Coding Plans from the two core dimensions of price and speed, hoping to inform your purchasing decision.

1. Coding Plan billing models and pitfalls to avoid

Before comparing specific plans, it’s necessary to clarify the different metering units these vendors use, as this is the easiest place to trip up:

API request count: Alibaba Cloud Bailian (百炼), Volcengine Ark (火山方舟), and Infinity (无问芯穹) use this. One user prompt can trigger 5–30 model calls in the backend, and each call counts as 1 API request (per Tencent Cloud’s official docs).
Prompt count: Zhipu GLM and MiniMax use this. 1 Prompt is roughly equivalent to 1,200–1,600 API requests.
Token metering: Kimi switched to this mode on January 28 of this year, billing by input/output tokens, and cache hit rate directly affects actual usable quota.

Because the metering units differ, comparing raw numbers is meaningless. For example, Bailian Lite’s “1,200 API requests every 5 hours” and Zhipu Lite’s “80 Prompts every 5 hours” may amount to similar real-world usage intensity.

2. Price and quota comparison

2.1 The big four platforms

According to the screenshots in the Xiaohongshu note and the Cnblogs compilation, the pricing strategies of Alibaba Cloud Bailian, Volcengine Ark, Tencent Cloud, and JD JoyCoder are highly convergent:

Platform	Lite Plan	Pro Plan	Core quota (Lite)	Supported models
Alibaba Cloud Bailian	¥40 (first month ¥7.9)	¥200	1,200/5h, 9,000/week, 18,000/month	Qwen3.5-Plus, Qwen3-Coder-Next, GLM-4.7, Kimi-K2.5
Volcengine Ark	¥40 (first month ¥8.91)	¥200	Same as Bailian	Doubao-Seed-Code, DeepSeek-V3.2, GLM-4.7, Kimi-K2.5
Tencent Cloud	¥40 (first month ¥7.9)	¥200	Same as Bailian	Hunyuan series, MiniMax-M2.5, Kimi-K2.5, GLM-5
JD JoyCoder	¥40	¥200	Same as Bailian	DeepSeek-V3.2, Kimi-K2.5, MiniMax-M2.7, GLM-5

2.2 Emerging AI vendors

Compared to the big four, emerging vendors’ pricing is more scattered:

Platform	Entry price	Core quota	Billing	Highlights
Infinity	¥19.9/month	1,000/5h, 6,000/week	API requests	Lowest monthly fee, multi-model aggregation
MiniMax	¥29 (first month ¥9.9)	40 Prompt/5h, no weekly cap	Prompt	Lowest entry price, no weekly limit
Kimi	¥49 (Andante)	Per token (3x for a limited time)	Token	Native multimodal, 256K long context
Zhipu GLM	¥49 (after the 2-month price increase)	80 Prompt/5h, 400/week	Prompt	Pure in-house models, 20+ tool integrations
StepFun	Not tested	—	—	No hands-on data yet

From a value-for-money standpoint:

Budget-conscious users: Infinity (¥19.9) and MiniMax (¥29) have lower entry barriers.
New users trying the waters: Alibaba Cloud Bailian’s first-month ¥7.9 is currently the lowest known trial price.

3. Hands-on speed tests: TTFT and TPS

The following speed data comes from a Xiaohongshu hands-on test note, tested under the conditions of “daytime @ 10K tokens,” measuring time to first token (TTFT) and TPS generation speed respectively. This data directly reflects the “responsiveness” of coding and code-generation efficiency.

3.1 Time to first token (TTFT)

Platform	Fastest model	TTFT	Slowest model	TTFT
Zhipu GLM	glm-5-turbo	1.43s	glm-5	7.82s
Tencent	hunyuan-2.0-thinking	2.51s	kimi-k2.5	12.38s
MiniMax	m2.1	2.44s	m2.5	5.54s
Alibaba	glm-4.7	2.76s	qwen3-coder-next	11.58s
Infinity	deepseek-v3.2-thinking	3.26s	kimi-k2.5	7.76s
Volcengine	doubao-seed-2.0-pro	3.29s	glm-4.7	21.52s
JD	deepseek-v3.2	~5s	kimi-k2.5	~19s
Kimi	kimi-for-coding	5.71s	—	—

Observations: Zhipu GLM’s glm-5-turbo is the fastest of all at 1.43s TTFT; the time-to-first-token for some models on Volcengine and JD is notably higher, hitting 21.52s and 19s respectively, possibly related to platform scheduling policies or model deployment methods.

3.2 TPS generation speed

Platform	Fastest model	TPS	Slowest model	TPS
Zhipu GLM	glm-4.5-air	103	glm-5	23
Volcengine	doubao-seed-2.0-pro	76	kimi-k2.5	23
Tencent	hunyuan-2.0-thinking	76	glm-5	30
Alibaba	qwen3-coder-next	67	glm-4.7	41
Infinity	minimax-m2.5	51	kimi-k2.5	25
MiniMax	m2.5	48	m2.1	45
JD	deepseek-v3.2	35	glm-5	25
Kimi	kimi-for-coding	35	—	—

Observations: Zhipu’s glm-4.5-air reaches 103 TPS, significantly ahead of other platforms; Volcengine and Tencent’s Hunyuan/Doubao models also hit 76 TPS. JD and Kimi are relatively slow at around 35 TPS.

In addition, MiniMax officially claims its M2.5 model can reach 100+ TPS, which differs from the 48 TPS measured on the MiniMax platform in the Xiaohongshu note, indicating that the same model may perform differently when deployed on different platforms.

4. Platform reviews and buying recommendations

Combining price, quota, and speed data, here are recommendations for different usage scenarios:

New users / those wanting to try it cheap

First choice: Alibaba Cloud Bailian Lite (first month ¥7.9). Rich model selection, backed by Alibaba Cloud infrastructure, with solid stability. Downsides: only the primary account is supported, and the config documentation isn’t beginner-friendly.

Budget-conscious, light use (monthly budget ≤ ¥30)

First choice: Infinity Lite (¥19.9/month). Quota close to Bailian’s at half the price, ideal for light developers who code 2–3 times a week.
Second choice: MiniMax Starter (¥29/month). No weekly cap; quota only refreshes every 5 hours, good for continuous use.

Daily development, moderate use (monthly budget ¥40–50)

First choice: Alibaba Cloud Bailian Lite (regular ¥40) or Volcengine Ark Lite (regular ¥40). Both have transparent quotas and many model choices.
Not recommended: Zhipu GLM (¥49 after the price increase, worse value) and Kimi (¥49, few tool integrations and quota heavily affected by cache).

Heavy development, full-stack, or multi-model switching

First choice: Alibaba Cloud Bailian Pro or Volcengine Ark Pro (¥200/month). Around 5x the quota of Lite, with free switching between multiple models. Volcengine also supports Auto smart scheduling.
If you prefer GLM’s in-house models, consider Zhipu GLM, but note its weekly limit and peak-time quota multipliers (3x during peak, 2x off-peak).

Pursuing ultimate response speed

If time-to-first-token and generation speed are your top priorities, Zhipu GLM’s glm-5-turbo (1.43s TTFT) and glm-4.5-air (103 TPS) perform best.

5. Summary

The Chinese Coding Plan market is iterating rapidly, with price wars and model wars running in parallel. When choosing, don’t fixate on surface prices; instead, focus on three core questions:

What is the metering unit? API requests, Prompt counts, or tokens? Different units can’t be compared directly.
How does the quota mechanism work? Refreshed every 5 hours, capped weekly, or capped monthly? This determines whether you can sustain high-intensity use.
Is the speed responsive? TTFT and TPS directly affect the coding experience, and the same model can perform wildly differently across platforms.

A final reminder: plan policies change frequently across vendors (e.g., Zhipu’s price increase, Kimi switching to token billing, Alibaba Cloud discontinuing its Lite tier), so be sure to confirm the latest details on each platform’s official website before subscribing.

Data sources

Why the Harder You Work, the Lower Your Income Ceiling?

Thu, 16 Apr 2026 03:01:41 +0800

Many working professionals go through a familiar phase: when you first start out, your skills and income rise almost in lockstep—every new technique you master, every certification you earn, pushes your salary higher. But a few years in, an invisible line quietly appears: your professional ability keeps improving, yet your income growth stalls.

This isn’t because you aren’t working hard enough. It’s because you’re applying the logic of “honing a craft” to a problem that requires “running a system” to solve.

The essence of the problem: skill and moneymaking are two different operating systems

We tend to assume that “doing things to perfection” will naturally bring “greater returns.” But the two goals actually depend on completely different ability dimensions.

Think of a chef. He could spend his entire life studying heat control, knife work, and seasoning to become one of the top culinary masters in the industry; but when he wants to open a profitable restaurant, he faces an entirely different set of problems: where do customers come from, how should the menu be designed, how do you pick a location and food-delivery platforms, and why would guests pay for his food instead of a cheaper alternative next door?

Great cooking only solves the “making” part; a profitable restaurant solves the “selling” part.

In the workplace, most “employees” spend their careers on the former—optimizing code, designing plans, writing reports, processing data. These tasks make us excellent “executors” but rarely train us to be “closed-loop designers.” Once income reaches a certain level, what decides whether you break through the ceiling is no longer “how beautifully you do the work,” but whether you can build a complete value-monetization system.

The recent social media discussion around this topic centers on exactly this: many people discover they’ve poured all their energy into “cooking a better dish” without ever lifting their head to look at the restaurant’s ledger.

Self-reflection: why are we “bad at making money”?

After realizing this problem, many people’s first reaction is self-blame: “Am I too comfortable with the status quo?” “Do I lack business acumen?”

But if you zoom out, you’ll find a deeper cause: the entire environmental system in which we grew up was never designed to raise “independent business operators.”

From foundational education to higher education, and then on to on-the-job training after joining a company, the core logic has always been to turn a person into a “qualified laborer”—mastering a skill that is available to be hired, replaceable, and priced. A company as an organization also doesn’t exist to maximize your personal wealth; it exists to embed you in an already-designed value chain through division of labor, so you can produce efficiently.

This isn’t a conspiracy theory; it’s an efficient mechanism for social collaboration. The problem is that this mechanism distributes returns linearly: you invest time, you earn a wage; stop investing and the returns stop. Real wealth accumulation, by contrast, usually depends on non-linear, compounding productive assets—such as controllable customer channels, reusable product assets, automated systems, or equity.

One sentence sums up the divide:

When you invest 100% of your energy in the former but never deliberately accumulate the latter, an income ceiling is almost inevitable.

Core insight: making money is a “tacit knowledge” that requires deliberate practice

Once you understand the structural causes, there’s another common trap to avoid: many people assume that since “making money” is a skill, it must be learnable systematically like programming or design, through tutorials and certificates.

But the opposite is true. Methodologies for making money do exist, yet a huge share of them falls under “tacit knowledge”—highly dependent on context, trial and error, networks, and timing, and very hard to standardize and export. You can finish ten business books and still not know how to find your first paying customer in the real market; you can memorize every marketing theory and still not know how to price and close a deal in a specific negotiation.

This is why so many people feel the frustration of “I’ve heard all the advice, but I still can’t make money.” It isn’t weak comprehension; it’s that the ability to make money comes primarily from hands-on experience, not from what you read in books.

A chef who studies a recipe book can’t open a restaurant; the real ability to run a business can only grow in the process of doing business.

A gradual path: how to shift from “executor” to “closed-loop designer”?

Once you realize this, the most critical mindset change is: don’t expect to solve the problem with a single dramatic leap (such as quitting your job to start a business right away). That is usually the highest-risk, lowest-success path.

A more realistic approach is to deliberately cultivate a “business perspective” within your existing job and life, and build up hands-on moneymaking experience gradually through small closed loops. Here are four incremental entry points:

1. Cultivate a “business perspective” while working a job

Even if you don’t plan to leave your current position, you can start reorienting yourself from “task executor” to “observer of the value chain.” Try answering these questions:

Where does the revenue for your product or project come from?
Who are the customers, and why do they choose you over competitors?
Where in the value chain do you sit? How replaceable are you?
If you had to independently replicate this business model, what would be missing?

This shift in perspective won’t earn you an extra cent right away, but it will gradually change the reference frame you use to make decisions—from “how do I do this well” to “how do I become irreplaceable in this system, or gain the ability to monetize independently.”

2. Try to “productize” your skills

For many professionals, their biggest asset is years of accumulated expertise and experience. But most are used to “selling services by the hour” and have never considered turning that into a scalable product.

Productizing doesn’t need to be grand at first. It can be an Excel template you use often, a structured industry-research framework, a 30-minute mini-course, or an automation script. The key is that this process forces you to think about pricing, user personas, delivery methods, and sales channels—and those are exactly the core components of the “craft of making money.”

3. Actively touch the real scenes of “acquisition” and “conversion”

Many technically-minded people instinctively reject sales, marketing, and negotiation as “not their proper job.” But the essence of business is exchange, and exchange requires someone to drive acquisition and conversion.

You don’t need to become a star salesperson overnight. You can start very small: help a friend promote a side project, run a social media account sharing your professional expertise, or actively join a business discussion with a client. Every real interaction gives you insight you can’t get in a classroom—what kind of customer is willing to pay for value? Where do their pain points really lie? What kind of expression moves them most?

4. Complete your first full closed loop through a side hustle or small transactions

However much you study theory, nothing beats personally running through the complete “acquire customer—quote—deliver—collect payment” flow once.

The scale of this loop can be tiny: take a few-hundred-yuan consulting gig, sell your first template, or help an acquaintance solve a specific problem. Its value isn’t in how much money you make, but in letting you experience firsthand: how a business closed loop operates, and where your blind spots still are.

Once you build this feel, your understanding of “making money” moves from abstract concept to operational experience.

Conclusion: skills set the floor; business ability sets the ceiling

The accumulation of skills will never betray you. It gives you a foothold in uncertain environments and forms the “floor” of your income. But if you want to break through the ceiling, you must accept a reality:

Change doesn’t need to happen all at once, and it doesn’t require you to instantly become a completely different person. It only asks that you start, one day, being willing to re-examine everything you do through the eyes of an “operator,” and then take the first small closed loop.

When you stop being only the chef buried in the kitchen and also begin thinking about how the restaurant can turn a profit, your ceiling has already quietly begun to rise.

The Programmer's Curse: Three Traps of Technical Thinking in Side Projects

Thu, 16 Apr 2026 02:15:34 +0800

Three typical traps

1. The building-in-a-vacuum trap: substituting engineering cycles for market validation

This is the most common path. Programmers are used to treating “writing code” as the default response to a problem: once requirements are clear, what follows is naturally designing the database, choosing a framework, and setting up CI/CD. But in side-project scenarios, the real risk is often not “can’t build it” but “nobody wants it.”

When all your energy goes into technical implementation, market validation gets postponed indefinitely. By the time the product launches, you discover the user pain point doesn’t exist, or exists but nobody’s willing to pay for it. Two months of engineering effort buys you nothing but a conclusion that validation failed — when a weekend landing page or community interviews could have told you the answer in advance.

When a technologist sees a product take off, their first reaction is often: “This feature isn’t complex, I can build a better one.” But commercial success rarely depends only on technical implementation. Channels, brand trust, community accumulation, timing windows, and operational capability — these factors are often far harder to replicate than code quality.

Cloning a more feature-complete version is not the same as replicating the other party’s business model. When sales fall short of expectations, attributing the cause to “the market doesn’t appreciate it” is essentially using technical superiority to mask a failure to understand business logic.

3. The analysis-paralysis trap: using technical decisions to escape business decisions

The irony of this path is that it looks “rational” on the surface while actually using low-risk technology selection discussions to avoid high-risk action decisions. Tech selection certainly matters, but for a project whose demand is unvalidated, the opportunity cost of “three months without writing a line of code” far outweighs the potential loss of “picking the wrong language.”

Many successful side projects had sloppy early code. They survived because the founders first focused on “finding people willing to pay,” not on “building a perfect tech stack.”

Why technical thinking is an asset at work but a liability in side projects

At your job, technical ability is clearly priced: systems must be stable, code maintainable, architecture extensible. The company pays for exactly these engineering qualities. So pursuing technical correctness is a rational strategy.

But the core variables in side projects and startups are market validation and cash flow. Whether users will sign up, whether they’ll pay, whether word-of-mouth spreads — the answers to these questions often become apparent before the code is finished. If you still treat “engineering perfection” as your top priority, you’ll unconsciously delay, avoid, or even replace the business actions that actually determine life or death.

In other words: the workplace rewards “doing things right”; side projects reward “doing the right things.” The scoring criteria differ, so reusing the same mental model produces systematic bias.

A perspective shift worth considering

Based on the analysis above, you can try reversing the order of execution in your side project:

Find people willing to pay first, then write code. Validate demand with pre-sales, landing pages, surveys, or community interviews. Only once you’ve confirmed someone wants to pay for a solution should you start development.
Understand the business loop first, then talk about technical replication. Before deciding to follow a direction, map out its customer acquisition channels, pricing strategy, and user lifecycle — not just its feature list.
Ship first, then iterate. Choose a tech stack you know best and can prototype fastest, make “launch” the first milestone, and defer “optimal performance” and “most elegant architecture” until you have real users.

Technical thinking itself isn’t wrong; what’s wrong is overusing it on the wrong battlefield. For programmers, the truly rare competitive edge may not be writing more elegant code, but knowing when to set the code aside.

Claude Rolls Out Identity Verification: Impact on Users in Unsupported Regions and How to Respond

Wed, 15 Apr 2026 15:22:53 +0800

Anthropic recently rolled out an identity verification mechanism on the Claude platform. Based on the official help center documentation and the list of supported countries and regions, this article summarizes the core points of the mechanism, with a focus on assessing the actual impact on users in unsupported regions (e.g., mainland China) and viable strategies.

1. Core points of the identity verification mechanism

1.1 Purpose

According to the official statement, identity verification aims to:

Prevent technical abuse
Enforce platform usage policies
Fulfill legal and security compliance obligations

When users access certain features, a verification prompt may appear — this is part of routine platform integrity checks.

1.2 Verification methods and required materials

The verification service is powered by Persona Identities. Users need to prepare:

A valid government-issued photo ID (passport, driver’s license/state ID, or national ID)
A device with a camera: a live selfie may be required
The verification process typically takes no more than five minutes

Document types that are NOT accepted include: photocopies/screenshots/scans, digital IDs (such as electronic driver’s licenses), student/employee/bank cards, and temporary paper IDs.

1.3 Data privacy statement

The official documentation highlights the following privacy protections:

Anthropic is the data controller of verification data; Persona only processes data as instructed
ID documents and selfies are not stored directly by Anthropic but kept on the Persona platform
Data is used only for identity confirmation and legal/security obligations, not for model training, and is not shared with third parties for marketing or advertising
Both transmission and storage are encrypted

1.4 Why accounts can still be banned after verification

The official documentation explicitly lists four situations that can lead to account suspension:

Repeated violations of usage policies
Creating an account from an unsupported location
Violating the Terms of Service
Use by individuals under 18

This point is especially critical for users in unsupported regions: even if identity verification passes, if the system determines the account originates from an unsupported region, there is still a risk of a ban.

2. Real impact on Chinese users

2.1 Mainland China is not on the official supported list

According to Anthropic’s Supported Countries and Regions page, mainland China does not appear in the supported list for Claude.ai or the commercial API. The list includes Taiwan, but not mainland China, Hong Kong, or Macau.

2.2 Core impact assessment

Impact dimension	Details
Ban risk shifts from implicit to explicit	Previously, the platform mainly relied on IP, payment methods, and login behavior for risk control; now identity verification is directly tied to regional policy. Even after passing verification with a genuine Chinese passport, users may still be banned for “originating from an unsupported region.”
Account acquisition threshold rises significantly	For users relying on shared accounts or SMS-activation platforms, completing a “physical ID + live selfie” verification process is nearly impossible.
Cross-border data concerns	Chinese users must submit ID documents and biometric data to Persona, a US third-party service provider, raising privacy and cross-border data compliance concerns.
Low success rate for appeals	If the ban reason is “originating from an unsupported region,” this is an explicit policy red line for Anthropic rather than a system error, so the likelihood of a successful appeal is low.

2.3 Behaviors more likely to trigger verification

Although the official trigger conditions are not fully disclosed, based on standard platform risk-control logic, the following behaviors are more likely to trigger identity verification:

High-frequency API calls or anomalous usage patterns
Upgrading to Claude Pro / purchasing large API credits
Frequently switching IP addresses or login devices
Accounts being reported or generating policy-violating content
Using unconventional payment methods such as virtual credit cards or gift cards

3. Response strategies

3.1 For existing accounts: reduce the chance of being triggered

If you still hold a usable account, the following measures can help extend its useful life:

Keep a low profile: try to avoid triggering high-risk-control features
Stabilize your network environment: minimize IP hopping and maintain consistent access patterns
Comply with usage policies: avoid generating prohibited content to reduce the chance of being reported

It should be clear that these measures can only lower the probability of being triggered; they cannot eliminate the structural risk of being in an “unsupported region.”

3.2 Long-term alternatives

Given the low compliance ceiling for personal accounts, it’s advisable to migrate to more stable, sustainable channels:

Option	Details
Enterprise cloud platforms	Access the Claude API through enterprise-grade platforms such as Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. These channels target enterprise users, are more compliant, and are not directly subject to the regional verification restrictions of personal accounts.
Official partners	Watch whether Anthropic provides services in mainland China through authorized partners.
Local alternative models	For daily work and development, migrate to models that operate compliantly in mainland China, such as DeepSeek, Qwen, ERNIE Bot, and Zhipu AI (GLM).

3.3 If you’ve already been banned

The official appeal form lets users submit a review request. However, if the ban reason is “originating from an unsupported region,” the chance of a successful appeal is very low. It’s better to prioritize backing up and migrating your data and session records.

3.4 Risks of creating a new account

Under the current policy, the long-term viability of a new mainland China user registering a personal Claude account and passing identity verification is highly uncertain. If there’s a genuine need, it’s recommended to apply through enterprise-grade cloud services or a physical office environment in a supported region in a compliant way, rather than relying on SMS-activation codes or virtual payment methods.

4. Summary

Claude’s identity verification mechanism elevates “regional restrictions” from a background risk-control rule to a front-facing compliance hurdle. This means:

Technical and payment-based workarounds (VPNs, virtual numbers, shared accounts) largely fail in the face of identity verification
Even after passing verification, “unsupported region” remains a red line that can directly trigger a ban
For long-term, stable business needs, migrating to enterprise cloud channels or local alternative models is the more sustainable strategy

This change also reflects the trend of leading AI platforms tightening compliance boundaries during global expansion. For users in unsupported regions, accepting this structural constraint and planning alternatives in advance is more rational than continuously investing in circumvention.

Success Is Not a Door but a Wall: Naval's Takedown of the Overnight-Success Myth

Wed, 15 Apr 2026 07:38:37 +0800

Introduction: the story selectively ignored

The success narrative the media loves to tell is always the same: a person, a product, a book—suddenly capturing everyone’s attention overnight. An app goes viral, a bestseller hits the top, a founder rings the bell. The headline always carries the same word—overnight success.

But Naval Ravikant, in this article published on Naval’s Archive, points out that this headline always leaves out the seven years that came before.

The tweet itself is only a few words, but the newsletter expands it into a full cognitive-recalibration essay. Here’s a breakdown and interpretation of its core argument.

1. “The Invisible Years”: the foundation beneath all visible success

The article introduces an easily overlooked concept: The Invisible Years.

Jeff Bezos sold books in a garage for years, J.K. Rowling’s manuscript was rejected twelve times, and Naval himself spent years building companies, writing, and thinking in public—these years, preceding any viral tweet, are what constitute the real foundation.

This line in the original text pinpoints the exact moment most people quit:

Interpretation: The value of this passage is that it redefines “giving up” as a time-perception bias—not a lack of ability, but a misjudgment of the feedback cycle. Struggle doesn’t go viral, process doesn’t trend; the only thing that gets shared is the outcome. This filtering mechanism of the information environment systematically inflates the illusion of “quick success.”

2. Why this myth is genuinely destructive

The article doesn’t stop at the cliché that “success takes hard work”; it goes further: believing in “overnight success” not only misleads you, it actively harms you.

If you believe success happens suddenly, then every day it doesn’t happen becomes evidence that “this isn’t going to happen.” You measure yourself against a timeline that doesn’t exist, comparing someone else’s chapter thirty to your chapter three.

Naval uses a set of very concrete, bodily words to describe the process:

Grind and sweat: the monotonous repetition day after day, with nothing romanticized about it
Toil and bleed: the real cost, the sacrifice, the effort that will never be known
Face the abyss: looking at everything you’ve built, genuinely unsure whether any of it will ever amount to anything

Interpretation: This is the sharpest insight. Many people can endure hardship, even sacrifice, but what they cannot endure is uncertainty itself. The abyss isn’t failure; it’s continuing in the complete absence of any cosmic feedback. This is a discipline that runs against human nature—the human brain is designed to rely on feedback to correct behavior, yet genuine long-termism demands that you hold course inside a feedback vacuum.

3. “Overnight success” isn’t entirely fiction—it’s just misdefined

The article concedes that the “overnight” part of overnight success does exist:

But that moment isn’t success itself. It’s the visibility of success. The real success happens in slow, unglamorous, unwatched rooms, accumulating day by day.

Interpretation: This is one of the clearest concretizations of the concept of “compounding.” Compound interest is a mathematical model in economics, but on a personal level it’s a psychological test—you have to keep investing before the curve breaks above the horizontal axis. The tipping point is a mathematical certainty, but before it arrives, it looks like a miracle that will never come.

4. Success is a lagging indicator

Strip away the poetic shell, and the article leaves you with a mathematical truth:

Everything you see today—money, reputation, influence—is the delayed result of decisions made years ago. The person you admire wasn’t successful the moment you noticed him; he succeeded on the day he chose to continue when “giving up made more sense.”

Interpretation: This fundamentally reframes the coordinate system of effort. If success is a lagging indicator, then your task isn’t to chase results, but to build the inputs. Day after day of inputs—no applause, no feedback, no dopamine reward. Naval has said elsewhere that life’s most important skill is the ability to delay gratification; this tweet is the lived experience of that idea.

5. The abyss is a filter

The article closes with a powerful metaphor:

The abyss filters out most people not because it selects for intelligence, talent, or capital, but because it selects for only one thing: the willingness to keep going when there is no rational reason to continue.

The phrase “overnight success” itself becomes a punchline—it’s the universe’s way of erasing all the evidence that came before. And those who have truly been through it will never say the word without a smile, because they remember every sleepless night that preceded it.

Interpretation: This “wall” metaphor is colder and more honest than any success-coaching chicken soup. A door implies a key, a shortcut, a moment of unlocking; a wall implies no technique, only pushing. When others on the other side of the wall call you “lucky,” it’s only because they haven’t seen the every single day you spent pushing against it.

Conclusion: to those living in the invisible years

The most valuable thing about this article isn’t telling us to “work hard,” but providing a normal narrative framework for “having not yet seen results.” In an era when social media only shows outcomes, realizing that “the stage without feedback is itself part of the process” is a rare cognitive immunity.

If you’re going through your own invisible years, Naval’s line can serve as an anchor:

Original source: The Myth You Were Sold About Success — Naval’s Archive

This article is a summary of and personal commentary on the Naval’s Archive newsletter piece; all quoted passages are attributed to their sources.

Nous Research Subscription Models: Prepaid vs Pay-as-you-go, Which Is Better Value?

Tue, 14 Apr 2026 03:57:09 +0800

Recently, Nous Research’s API service, Portal, has gradually drawn the attention of developers. This article systematically maps out its pricing system based on official documentation and public information, clarifies core concepts such as “credits,” “tokens,” and “rate limits,” and compares the use cases for the two consumption modes.

1. Core Concepts: The Exchange Relationship Between Credits and Tokens

In Nous Portal’s billing system, 1 Credit = $1 USD. This means:

The “$10.00 monthly credits” in a subscription plan is equivalent to $10 of API usage credit.
Model pricing (e.g., Hermes-4-70B at $0.13/1M input tokens) is priced directly in USD.
The actual amount of tokens a credit converts to depends on the unit price of the chosen model.

Conversion example (using Basic plan’s $10 credits):

Model	Input price/1M	Input tokens purchased with $10
DeepHermes 3 (Mistral 24B)	$0.02	500 million tokens
Hermes-4-70B	$0.13	~76.9 million tokens
Hermes-4-405B	$1.00	10 million tokens
Claude Opus 4.6	$5.00	2 million tokens

Source: Nous Portal Models page

As shown, when using high-performance models (such as Claude Opus 4.6), the amount of tokens your credits buy can differ by dozens of times.

2. The Two Consumption Modes Explained

According to the official API documentation, Nous Portal offers two independent consumption modes:

Mode A: Subscription (prepaid)

Plan	Monthly fee	Credits received	Rate Limits
Free	$0	Trial credits (small amount)	50 RPM, 100K TPM
Basic	$10	$10.00	400 RPM, 2M TPM
Plus	$20	$20.00	400 RPM, 4M TPM
Scale	$50	$50.00	600 RPM, 6M TPM
Max	$100	$100.00	800 RPM, 8M TPM

Source: Nous Portal API Docs

Analysis of characteristics:

A fixed monthly charge that grants equal-value credits.
Access to rate limits higher than the “default paid user” tier.
Credits may reset at the end of the month (confirm the exact policy on the billing page).

Mode B: Pay-as-you-go (direct top-up)

No subscription required; add API credits directly to your account (any amount).
Rate Limits: 200 RPM, 800,000 TPM (corresponding to the “Default paid users” level in the docs).
Use until depleted, top up at any time.
Credits may not expire (per the WorldSim Terms of Service: “Purchased credits will not expire unless the application(s) is retired”).

Source: WorldSim Terms of Service

3. Key Differences vs OpenRouter

Feature	Nous Portal	OpenRouter
Consumption mode	① Subscription prepaid ($10-100/month); ② Direct credit top-up (any amount)	Pure pay-as-you-go (no monthly barrier)
Rate Limits	Determined by subscription tier: Free(50) → Basic(400) → Max(800) RPM	Dynamically adjusted by usage
Credits mechanism	Prepaid credits, may reset monthly	Credits never expire
Anonymous payment	Not supported	Supports x402 protocol (Solana USDC)
Model coverage	400+ models, incl. OpenAI/Anthropic/open-source	200+ models, aggregates multiple providers

Source: Nous Portal API Docs, OpenRouter official site

Key difference: Nous Portal’s subscription model essentially trades “monthly fees for higher rate limits + equal-value credits”; OpenRouter is pure per-usage billing with no subscription barrier.

4. Billing Formula and Cost Estimation

API call cost formula:

Model price reference (from the official Models page):

Model	Input/1M	Output/1M
DeepHermes 3 Mistral 24B	$0.02	$0.10
Hermes-4-70B	$0.13	$0.40
Hermes-4-405B	$1.00	$3.00
GPT-5.4	$2.50	$15.00
Claude Opus 4.6	$5.00	$25.00

Source: Nous Portal Models page

Real example: if you use Hermes-4-70B to process one conversation (2K input tokens, 1K output tokens):

Cost = (2000/1M × $0.13) + (1000/1M × $0.40) = $0.00026 + $0.0004 = ~$0.00066
$10 in credits can support about 15,000 such conversations.

5. Selection Advice and Potential Caveats

Recommended options for different scenarios

User type	Recommended approach	Reason
Trial/light use	Free tier → top up a small amount of credits	No monthly commitment
Developer/moderate traffic	Basic Subscription ($10)	400 RPM is enough for daily use; $10 credits are roughly consumed
High-traffic production	Scale/Max Subscription	600-800 RPM avoids 429 throttling
Agent developers	Plus ($20)	Balance between rate limit and credit amount
Uncertain usage	Direct credit top-up	Avoid wasting subscription credits that reset monthly

Potential issues to note

Credit reset risk: subscription monthly credits may reset at the end of the month (confirm the exact policy by logging into the portal billing page).
Rate limit difference: the top-up mode offers only 200 RPM; high-concurrency scenarios can easily trigger throttling.
Huge model price gaps: Claude Opus 4.6 costs 38× more than Hermes-4-70B; choosing the wrong model can drain credits quickly.
Refund policy: per the Terms of Service, “All Fees are non-refundable.”

Source: Nous Portal Terms of Service

6. Summary

Nous Research Portal’s pricing system is designed to serve both “stable subscription users” and “flexible on-demand users”:

Subscription mode suits production environments that need a stable, high-concurrency rate limit.
Top-up mode suits scenarios with fluctuating usage where users want to avoid being bound by a monthly fee.

Developers should choose the most suitable billing method based on their token consumption, concurrency needs, and cost budget. For users who are uncertain, it’s recommended to first try the Free tier or a small top-up, then decide whether to upgrade the subscription based on actual usage.

This article is compiled from Nous Research’s official documentation and public materials; specific policies are subject to the latest official announcements.

The Complete Guide to Hermes Agent Discord Setup and Session Isolation

Mon, 13 Apr 2026 10:12:01 +0800

Hermes Agent, as a fully-featured AI assistant platform, supports connecting to servers as a Discord Bot. Based on hands-on deployment experience, this article systematically walks through the whole flow from bot creation to session-isolation configuration, and answers the typical problems you may hit during deployment.

1. Discord Bot creation and basic configuration

1. Create a Discord Application

Go to the Discord Developer Portal, click New Application, fill in the app name, and you’ll enter the management interface. On the General Information page, note down the Application ID; you’ll need it later to generate the invite link.

2. Configure the Bot and key permissions

Open the Bot tab on the left. Here you need to complete three key settings:

Bot identity settings

Public Bot: keep it ON so you can use Discord’s standard invite link
You can upload the bot’s avatar and banner on this page

Getting the Token

Click Reset Token to generate the Bot Token
This Token is shown only once, so save it carefully; you’ll write it into Hermes’ .env file later

Privileged Gateway Intents (key step)

At the bottom of the page, find the Privileged Gateway Intents section. You must enable both of the following:

Intent	Purpose	Required?
Server Members Intent	Access member list, resolve usernames	Yes
Message Content Intent	Read message text content	Yes

Note: Message Content Intent is a prerequisite for the bot to respond properly. If it isn’t enabled, the bot can come online and receive events but can’t read the message text—it appears “online but unresponsive.”

3. Generate the invite link and authorize

Method 1: Installation tab (recommended)

On the left, go to Installation → enable Guild Install
For Install Link, select Discord Provided Link
Under Scopes, check bot and applications.commands
Under Permissions, select: View Channels, Send Messages, Read Message History, Embed Links, Attach Files

Method 2: Build the URL manually

Replace YOUR_APP_ID with the Application ID, then visit the link and pick a server to authorize.

2. Hermes environment configuration

Add the following to the ~/.hermes/.env file:

To get your User ID: Discord Settings → Advanced → enable Developer Mode, then right-click your own username and select Copy User ID.

Start the Gateway:

Optional environment variables:

Variable	Default	Description
DISCORD_REQUIRE_MENTION	true	Whether the bot only responds when @-mentioned in a channel
DISCORD_AUTO_THREAD	true	Automatically create a Thread on @mention (recommended to keep on)
DISCORD_FREE_RESPONSE_CHANNELS	-	Channel IDs where the bot responds without an @mention
DISCORD_IGNORED_CHANNELS	-	Blacklist of channels the bot completely ignores

3. How session isolation works

Hermes distinguishes sessions with a session_key. The default behavior in the Discord scenario is as follows:

1. DM — naturally isolated

Every DM conversation has its own independent session_key, no @mention needed, and all messages automatically fall into the same session.

2. Server channels — isolated per user by default

A global setting in config.yaml controls this behavior:

When the value is true:

Alice @-mentions the bot in #research; the bot maintains a separate session for her
Bob @-mentions the bot in the same channel; the bot maintains a completely different session for him
The two share no context, token usage, or runtime state

If set to false, the whole channel shares a single session.

3. Threads — the core isolation mechanism

Discord Threads are the key mechanism Hermes uses to isolate sessions:

Threads are isolated from the parent channel

A Thread’s session_key includes the thread_id, so conversations inside a Thread are completely isolated from the parent channel

Shared by default within a Thread

thread_sessions_per_user defaults to false, so all users in the same Thread share one session (good for collaborative scenarios)
If you want per-user isolation within a Thread too, set thread_sessions_per_user: true

Auto-created Threads (strongly recommended)

DISCORD_AUTO_THREAD defaults to true. Its mechanism:

Result:

Each @mention = one new Thread = one brand-new isolated session
Subsequent replies inside the Thread don’t need another @mention
Different tasks naturally live in different sessions, completely avoiding context contamination

4. Troubleshooting: no response to @mention in a channel

If DM works fine but channel @mention gets no response, check in this order:

1. Check Message Content Intent (the most common cause)

Go to Discord Developer Portal → your Application → Bot → Privileged Gateway Intents, confirm Message Content Intent is enabled, then click Save Changes.

2. Check the bot’s channel permissions

In Discord, right-click the channel → Edit Channel → Permissions, and confirm the bot role has:

View Channels
Read Message History
Send Messages

3. Check the environment configuration

4. The ultimate fix: re-authorize

If you’ve confirmed all the above settings are correct but it still won’t respond, try:

Kick the bot from the server
Re-authorize with a new invite link (make sure the permission integer includes the required permissions)
Restart the hermes gateway

Real-world deployment experience shows that re-authorizing often fixes the problem—likely because Discord’s side permission cache hasn’t refreshed.

5. Recommended configuration

For maximum isolation, here’s the recommended configuration:

~/.hermes/.env:

~/.hermes/config.yaml:

The interaction experience under this configuration:

In #general, @Bot “help me write a Python script” → the bot automatically creates Thread A, and the task runs in an isolated environment
@Bot again “analyze this document” → the bot creates Thread B, another brand-new session
A colleague also @-mentions the bot in #general → gets their own Thread C, no interference

6. Session management commands

The following commands are available in any conversation:

Command	Effect
/reset	Reset the current session and start a fresh empty session
/title task-name	Name the current session for easier reference later
/sethome	Set the current channel as Home Channel, used to receive scheduled task output

Summary

Isolation level	Default behavior	Control method
DM vs channel	Fully isolated	Natural
Different users, same channel	Isolated per user	group_sessions_per_user: true
Different Threads	Fully isolated	Natural (thread_id is part of the session key)
Same Thread, different users	Shared session	Enable isolation with thread_sessions_per_user: true
Same user, same channel, different tasks	Shared session	Rely on DISCORD_AUTO_THREAD=true to auto-open a Thread

Keeping DISCORD_AUTO_THREAD=true (the default) is the simplest and most effective way to prevent contamination: every @mention lands in a fresh Thread session, fundamentally preventing multiple tasks in the same channel from interfering with one another.

The 2026 Qiangji Plan Launches: Changes Parents Should Watch and How to Adjust Training Strategies

Sat, 11 Apr 2026 08:13:40 +0800

The 2026 “Qiangji Plan” (Strong Foundation Plan) admissions work has officially begun, with online applications opening across the board in April. Based on official information released by Xinhua News on WeChat, this article reviews the policy highlights, the changes to admission rules, and the dynamic adjustments to how parents nurture their children’s education — from a parent’s perspective.

1. Key 2026 timeline

According to the schedule compiled by Xinhua News:

April: enrollment brochures published, online applications open
June: students sit the unified gaokao (college entrance exam)
After the gaokao, before July 4: provinces provide gaokao scores; universities determine the shortlisted candidates and organize assessments
Before July 5: universities convert weighted composite scores and admit the best candidates on merit

Note that the Qiangji Plan allows applying to only one school, and if admitted, you no longer participate in the later admission rounds’ preference filling; if not admitted, it doesn’t affect normal-round admission.

2. Policy positioning: not a “ticket to a prestigious school,” but a channel for national reserve talent

Since the Ministry of Education launched the Qiangji Plan in 2020, its guiding philosophy has always been clear: to serve national strategy, select young students who have ambition, interest, and talent, and channel reserve talent into the nation’s major strategic fields.

According to the direct statements in the Xinhua article:

This means that when parents help their children evaluate whether to apply, the core question shouldn’t be “can this give my child an extra chance at a prestigious school” but rather “is my child willing to commit long-term to a foundational discipline.” In principle, students cannot transfer majors after admission, so this is a highly binding academic contract.

3. Two major changes in the 2026 admissions

1. Expanded majors, with new strategic shortage programs

While continuing to strengthen foundational disciplines such as mathematics, physics, chemistry, biology, and humanities/literature/history/philosophy, 2026 adds a batch of hard engineering directions urgently needed by the nation. According to the Xinhua report:

Shandong University adds “Cryptography Science and Technology”
Xi’an Jiaotong University adds “Energy Storage Science and Engineering”
Beihang University adds “Aircraft Airworthiness Technology”
Tianjin University adds “Naval Architecture and Ocean Engineering”

These majors all fall under promising fields of national shortage, reflecting that universities’ cross-disciplinary layouts, supported by foundational disciplines, are accelerating.

2. Competition-based exceptional admission channels tighten; gaokao single-subject weight rises

The Xinhua article states this clearly:

In concrete terms:

Beijing Normal University, South China University of Technology, Lanzhou University, and others have explicitly canceled the exceptional admission channel based on competition wins into campus assessment
Xi’an Jiaotong University, Tongji University, and others retain exceptional admission eligibility only for Olympiad gold medalists or first-prize winners
More and more universities are adopting “exceptional admission” or “weighted scoring” based on a single gaokao subject, selecting students with outstanding subject potential

The aim is to “de-utilitarianize competition,” correcting the deviation of some students going all-in on competition prizes purely for admission, and returning to an assessment of students’ genuine subject strengths and long-term research interest.

4. The list of 39 pilot universities

Currently, 39 universities nationwide run Qiangji Plan pilot admissions:

Peking University, Renmin University of China, Tsinghua University, Beihang University, Beijing Institute of Technology, China Agricultural University, Beijing Normal University, Minzu University of China, Nankai University, Tianjin University, Dalian University of Technology, Northeastern University, Jilin University, Harbin Institute of Technology, Fudan University, Tongji University, Shanghai Jiao Tong University, East China Normal University, Nanjing University, Southeast University, Zhejiang University, University of Science and Technology of China, Xiamen University, Shandong University, Ocean University of China, Wuhan University, Huazhong University of Science and Technology, Hunan University, Central South University, Sun Yat-sen University, South China University of Technology, Sichuan University, Chongqing University, University of Electronic Science and Technology of China, Xi’an Jiaotong University, Northwestern Polytechnical University, Northwest A&F University, Lanzhou University, and National University of Defense Technology.

5. Strategy adjustments from a parent’s perspective

Based on these policy changes, parents can consider several dynamic adjustments in how they plan their children’s education:

1. Shift from “universal tutoring” to “discovering strengths”

As exceptional admission channels tighten and the weight of single gaokao subjects rises, the logic of educational resource allocation is shifting from “undifferentiated all-subject excellence” toward “strengthening a single peak subject.” Parents should observe earlier whether their children show sustained self-driven exploration in fields such as math, physics, chemistry, biology, history, philosophy, or paleography — rather than deciding about competition investment based solely on exam rankings.

2. Interest cultivation needs to start as early as middle school or even elementary school

The selection mechanism increasingly emphasizes “genuine subject strengths and long-term research interest,” which means parents can’t wait until high school, or even senior year, to decide whether their child is suited to the Qiangji Plan. The seeds of foundational-discipline interest often sprout much earlier: curiosity about math puzzles in elementary school, fascination with physics experiments in middle school, or a special sensitivity to history or ancient scripts — all are important signals.

Dynamics of cultivation emphasis:

From “cramming for exams” to “problem-driven learning”: early on, expose children to real foundational-discipline problems through popular-science reading, lab open days, and project-based learning, rather than falling prematurely into a pattern of memorized problem types.
Lengthen the observation window: give children enough time and space to try different subject directions in middle school, then focus in high school. Interests formed this way better withstand the pressure of senior year and are better able to pass universities’ in-depth assessments of research potential.

3. The cost-effectiveness of competition investment needs re-evaluation

“De-utilitarianizing competition” means the value of competitions should return to their essence: testing discipline talent, deepening thinking, and confirming research interest. If a child doesn’t have top-level talent in a subject, over-investing time in competitions may crowd out gaokao review, creating opportunity cost. Parents need to evaluate more rationally whether competition investment matches the return.

4. Watch subject-selection and physical-condition restrictions early

Many Qiangji majors require physics + chemistry as mandatory choices, and some programs have explicit physical-condition requirements (for example, South China University of Technology’s chemistry and biotechnology programs do not admit colorblind examinees). Parents should clarify the admission threshold for their target major during the middle-school or high-school subject-selection phase, to avoid discovering only during senior-year applications that they don’t qualify.

5. Build an “interest–ability–contract” three-in-one decision framework

The admission and training mechanisms of the Qiangji Plan mean it isn’t suited to be a “try-it-and-see preference.” Parents can help their children establish the following judgment framework:

Interest: without the pressure of admission, would the child still take the initiative to read monographs in the discipline or follow relevant frontiers?
Ability: is the gaokao score (especially the single-subject score in the target discipline) competitive?
Contract: is the child willing to accept the long-term constraint of “in principle, no major transfer after enrollment”?

Only when all three reach a certain level is the Qiangji Plan an option worth serious consideration.

6. Conclusion

The 2026 adjustments to the Qiangji Plan send a clear signal: the selection mechanism is further squeezing out speculating, strengthening the examination of genuine subject strengths and long-term research aspiration. For parents, this means understanding their children’s subject interests and capability structure earlier and more deeply, and avoiding equating the Qiangji Plan with a “fast track to a prestigious school.” Against the backdrop of expanded national strategic shortage majors and increasingly mature undergraduate-to-graduate articulation pathways, for children who truly love foundational disciplines, the Qiangji Plan remains an academic path worth pursuing in depth.

API Keys Don't Belong in Your Shell Config Files

Tue, 07 Apr 2026 03:11:16 +0800

API keys should not live in your shell config files. It’s a habit many developers have, chosen for convenience, but the risk has been underestimated for a long time.

A recent operational mistake brought this home for me: a command couldn’t find its target file, so the fallback ran env, dumping the entire terminal environment variables out. A dozen API keys went straight into an AI conversation’s context, and I had to rotate all of them.

The incident was small, but it revealed a structural problem: keeping keys in shell config files means they are always exposed to every child process and every tool’s view.

Why shell config files aren’t a good place for API keys

Different shells have different config files, but they all face the same problem:

zsh: ~/.zshrc, ~/.zprofile
bash: ~/.bashrc, ~/.bash_profile, ~/.profile
fish: ~/.config/fish/config.fish

Writing export API_KEY=xxx in these files has these consequences:

Every terminal session loads them automatically at startup, so any child process can read them
Commands like env and printenv can reveal the plaintext at any time
AI tools, log collectors, and debug output may accidentally capture them
If the config file gets synced to a dotfiles repo, they become public directly

The root problem is: the key’s lifetime is far longer than the time it’s actually used.

Better approaches

Option one: project-level `.env` + precise injection

The lightest improvement. Each project only holds the keys it uses, extracted precisely via a script without polluting the global environment.

run.sh example:

Pros: simple, no dependencies, works on every operating system.

Cons: the key still sits on disk in plaintext.

Option two: macOS Keychain

System-level encrypted storage. The key is stored encrypted in the Keychain and only decrypted into memory at the moment it’s read; cat, grep, and env can’t see it.

Storing:

Reading in a script:

Experience: When you log into your Mac, the system Keychain unlocks automatically, so scripts can read values directly for the whole session without asking for a password. The first time you access an item, the system shows a single authorization dialog; click “Always Allow” and it never appears again.

This is the most direct replacement for storing keys in shell config files, and it has almost no impact on your workflow. It’s macOS-only; Linux and Windows have their own equivalents (secret-tool, Windows Credential Manager).

Option three: Bitwarden CLI (self-hosted)

If you have a Bitwarden instance (including a self-hosted Vaultwarden), you can use the official CLI, bw, to pull keys dynamically within scripts.

Configuring the self-hosted address:

Logging in and getting a session:

The session stays valid within the current terminal session and expires when you close the terminal, so it isn’t persistently exposed.

Reading a specific entry in a script:

bw get password looks up an entry by name and returns its password field. You can also use bw get notes to fetch the notes field, which is handy for keys with complex stored formats.

Best fit: scenarios where multiple devices share the same set of keys, or where you need cross-platform support (macOS/Linux/Windows are all supported). Keys are centralized in Bitwarden, so switching devices only requires logging in again rather than manually migrating .env files.

Migration suggestions

If your shell config files currently hold lots of export KEY=xxx:

Organize by project; give each project its own .env with only the keys that project uses
Migrate high-value credentials (database passwords, payment-related) to Keychain or Bitwarden
Remove all the export KEY= lines from your shell config files
Make sure .env files are added to .gitignore

You don’t have to do everything at once. Migrate the most sensitive ones first, and move the rest as you touch each project.

Summary

Approach	Plaintext on disk	Cross-platform	Cross-device	Dependency
Shell config files	✓ (dangerous)	✓	Manual sync needed	None
Project `.env`	✓	✓	Manual sync needed	None
macOS Keychain	✗	✗	✗	Built into the system
Bitwarden CLI	✗	✓	✓	bw CLI

There’s no perfect solution, but any of these is better than shell config files. The most pragmatic starting point is: clear the keys from your config files and switch to project-level .env, then gradually move high-value credentials to Keychain or Bitwarden.

Connecting Kimi Code to OpenClaw: Key Configuration Cheat Sheet

Sun, 05 Apr 2026 07:01:31 +0800

Kimi Code is the Coding Plan subscription from Moonshot AI that provides an API based on the Anthropic protocol. If you’ve already subscribed to Kimi Code, here’s how to connect it to OpenClaw.

Core information

Endpoint: https://api.kimi.com/coding/
Protocol: Anthropic Messages API (not OpenAI-compatible)
Model name: kimi-for-coding
Context window: 256K tokens
Max output: 64K tokens
Multimodal: Supported (based on K2.5, can handle visual inputs like images)
API Key: Generate it in the Coding Plan page of the Kimi Code console; usage is also tracked on the same page

Example OpenClaw configuration

Add the following provider to your OpenClaw configuration file:

Configuration notes:

Set the API Key as the environment variable KIMI_CODE_API_KEY, using the key generated on the Coding Plan page
api must be anthropic-messages; going through the OpenAI-compatible path returns 403 or 404 errors
cost is set to 0 because the Coding Plan is a subscription, not per-token billing
input includes text and image, indicating multimodal input support

Gotchas

Some OpenClaw versions may have compatibility issues with tool calls; if your call chain breaks, watch for version updates
Kimi Code officially permits use in Claude Code and Roo Code; connecting it to OpenClaw is a “non-officially-supported product” and carries a risk of being flagged as abuse—evaluate this yourself

Suitable use cases

This fits users who already have a Kimi Code subscription and want to reuse their quota within OpenClaw. If you don’t have a Kimi Code subscription yet, you’ll first need to sign up for a membership plan at kimi.com.

Update note: the provider name changed from kimi-code to kimi-plan to avoid colliding with a built-in OpenClaw name.