Workflow on KnightLi Blog

How Much Extra Token Usage Do subagents Cost? Multi-Agent Costs and Usage Strategy

Sun, 31 May 2026 14:17:42 +0800

Using subagents or a multi-agent workflow usually increases token usage. The question is not whether it costs more, but how much more it costs, and whether the parallel speed or extra stability is worth it.

For small tasks, it is usually cheaper to let the main agent handle the work directly. Subagents become more useful when the task can be clearly split, or when an independent review is valuable.

A subagent is not a cheaper parallel thread

When people first see subagents, it is easy to think of them as parallel threads: the main agent handles one part, the subagent handles another part, and the task finishes faster, so it must be more efficient.

That is not how it works. A subagent is still a separate model call. It needs to read the task, understand the context, inspect files, reason through the problem, and produce an output. It is not a free copy of the main agent; it is an additional reasoning path.

So the key question is not “can this run in parallel?” The real question is: “Is the time saved or quality gained worth the extra token cost?”

Why token usage increases

A subagent call usually adds token usage from several places:

the task description written by the main agent;
the context passed to the subagent;
the files and details the subagent reads;
the subagent’s own reasoning and output;
the main agent’s follow-up review, integration, and verification.

If multiple agents read the same large files, the waste becomes more obvious. This is especially true for codebase analysis, long-document translation, and batch content cleanup. If the task is split poorly, many tokens are spent on repeatedly understanding the same context.

Re-reading context is the biggest token waste

The biggest waste is often not “opening one more agent.” It is having multiple agents read the same material again and again.

For example, suppose a task needs to process 6 posts. If 4 agents all begin by reading the full site structure, the full skill instructions, and the full article list before handling a small slice, the parallelism becomes expensive. A better approach is for the main agent to define the boundaries first, then let each subagent read only the article directory it owns.

The cheaper split usually looks like this:

each agent owns one clear directory;
the context passed to each subagent is as short as possible;
multiple agents do not repeat the same exploration;
the main agent performs one final review instead of asking every agent to run a full review;
checks that can be scripted are handled once by scripts, not repeated by several agents.

In other words, controlling subagent cost is mostly about boundaries, not just the number of agents.

Rough cost multipliers

The following is a rough estimate. Actual usage depends on context length, file size, task complexity, and the number of agents.

Scenario	Token increase
One subagent handles a small task	Around `1.2x - 2x`
2-4 agents handle a clearly split task in parallel	Around `2x - 5x`
Multiple agents each read many files and do long analysis	Possibly `5x+`
Main agent and subagents read the same large files repeatedly	The most obvious waste

This is not an exact billing formula. It is only a practical range. Real usage also depends on whether each agent needs to read full files, perform long reasoning, or repeatedly wait for more context.

How to write a more token-efficient subagent task

The broader the instruction, the more likely the subagent is to explore on its own, which increases token usage. A better prompt defines the boundaries clearly.

A good subagent task should include:

which files or directories it may handle;
which files are read-only and which files may be written;
whether existing files may be overwritten;
which fields must be preserved, such as date, slug, and aliases;
what the final report should include;
what should not be done, such as running a full build or editing unrelated files.

For translation, do not just say “translate this post into multiple languages.” A more efficient instruction is: “Only process content/post/2026/05/240; read index.zh-cn.md; only create missing index.en.md, index.zh-tw.md, index.ja.md, and index.es.md; skip files that already exist; preserve date and slug.”

That instruction is a little longer, but it reduces guessing and repeated exploration. It is often cheaper overall.

Splitting by file or directory is cheaper than splitting by language or step

For batch post translation, splitting by article directory is usually better than splitting by language.

Suppose 6 posts each need English, Traditional Chinese, Japanese, and Spanish versions. It is usually better to let one agent handle all languages inside one article directory, rather than assigning one agent to all English files and another agent to all Japanese files.

The reason is simple: front matter, code blocks, links, tables, and semantic context only need to be read once for a single post. If you split by language, several agents read the same source post repeatedly, increasing token usage.

The same logic applies to code tasks. Prefer splitting by module, directory, or component rather than by steps such as “analyze first, implement second, test third.” Step-based splitting often forces every agent to reread the same context.

When it is worth using subagents

The value of subagents mainly comes from two things: parallelism and an independent perspective.

Good use cases include:

translating multiple posts in batches;
editing several independent directories;
splitting frontend, backend, and test work cleanly;
one agent implements while another reviews risk;
high-risk changes that need a second perspective.

In these cases, token usage increases, but total elapsed time may drop noticeably. Each agent can also focus on one slice of the work.

When one review agent is worth it

A review agent is not always worth the cost. It is most useful when the task is risky, broad in impact, or easy for the main agent to miss edge cases.

Cases where a review agent is worth considering include:

changes involving login, payment, permissions, or data deletion;
multilingual content that affects categories, URLs, or internal links;
broad refactors that need independent regression review;
user requests for code review or risk review;
the main agent has implemented a change and needs a second view on edge cases.

Cases where a review agent is not worth it are also clear: single-file edits, title tweaks, simple front matter fixes, or running one command. The main agent can usually self-check those.

When it is not worth using subagents

Subagents are often not worth it for:

small single-file edits;
simple Q&A;
running one command;
very small changes;
tasks that cannot be split clearly;
tasks where the subagent must repeatedly wait for the main agent to provide context.

In these cases, using a subagent mostly adds overhead. The main agent is faster and cheaper.

My default strategy: prioritize token savings and add review only for risk

If the goal is to save tokens, a conservative default strategy works well:

Small tasks: do not use subagents.
Medium tasks: do not use subagents.
Large batch tasks: still avoid subagents by default unless the user explicitly wants parallel speed.
High-risk tasks: consider one extra agent for review, trading tokens for stability.

This strategy gives up some parallel speed, but it reduces repeated context reading and repeated reasoning.

If a task is large but not high risk, I would first look for scripts, batch checks, and structured local processing. Multiple agents make more sense when the split is very clear, or when the user explicitly wants parallel speed.

A more balanced strategy

If you want to control cost without completely giving up parallelism, a balanced strategy is:

default to the main agent doing the work directly;
consider subagents only when the task can be clearly split by file or directory;
each subagent reads only the files it owns;
do not let multiple agents read the same large files;
the main agent performs the final review of key fields, test results, and Git diff;
add one independent review agent only for high-risk tasks.

This avoids parallelism for its own sake. Subagents should serve a clear speed or quality goal, not become the default action.

Summary

Subagents and multi-agent workflows always increase token usage. One subagent may add only a little, but several agents running in parallel can multiply the cost.

Whether it is worth it depends on the task. If the work can be clearly split, or if the risk is high enough to need independent review, the extra tokens may be justified. For small single-file edits, simple Q&A, or routine checks, it is cheaper to let the main agent handle the task directly.

In one sentence: save tokens on small tasks, split only when the work has clear boundaries, and use extra agents for stability only when risk justifies it.

How browser-harness domain skills keep AI agents from repeating browser automation mistakes

Sun, 24 May 2026 23:43:35 +0800

The most interesting part of browser-use/browser-harness is not only that it lets AI agents control real Chrome. It also turns web-operation experience into reusable domain skills.

That matters because browser automation is rarely difficult only because of clicking buttons. Each website has its own details:

Which pages require login.
Which data can be fetched directly through an API.
Which buttons do not respond to normal DOM clicks.
Which iframes, shadow DOM components, or popups block the flow.
Which selectors are stable and which are temporary classes.
Which actions involve accounts, payments, or irreversible changes and require human confirmation.

If this experience only stays in one task log, the agent will hit the same problems again next time. domain skills are meant to preserve that experience so the agent does not start from zero every time it opens a site.

What domain skills are

You can think of domain skills as site-operation manuals for agents.

They are not ordinary user documentation, and they are not one-off scripts. They are closer to field-tested site knowledge:

Whether the site is suitable for browser automation.
Which API should be used first if an API exists.
Which URL should be used when the browser is necessary.
Which DOM structures, aria-labels, and button behaviors have been verified.
Which common approaches fail.
Which scenarios should stop and ask for human intervention.

This content can be reviewed by humans and read by agents during tasks. It turns on-the-spot exploration into maintainable experience.

A good browser agent should not turn every problem into opening a webpage, looking at screenshots, and clicking buttons.

One important kind of experience in domain skills tells the agent when not to use the browser.

For sites such as ArXiv, paper search, metadata, and abstracts can be fetched directly through the Atom API or HTML meta tags. HTTP requests are usually faster, more stable, and easier to parse than opening a browser.

GitHub follows a similar pattern. Repository, user, and release data should use the REST API first. File contents should use raw.githubusercontent.com first. Only pages such as GitHub Trending, which do not have an equivalent API, need browser interaction.

This shows that browser-harness is not based on “the browser solves everything.” It puts the browser in the right place: when APIs, HTTP, and static pages cannot solve the problem, let the agent operate a real page.

They store site-level knowledge

Traditional automation scripts are usually written around one task, for example:

`1`	`Open page -> enter keyword -> click button -> download file`

That script may complete the task, but the experience is scattered inside code. When the site changes, the script may fail. When the task changes, much of the experience may not be reusable.

domain skills are closer to a site-level knowledge base. They care about:

Which container selector is stable in Amazon search results.
Which GitHub data should go through the REST API.
How LinkedIn invitation buttons differ in aria-label.
Which Shopify Admin pages are embedded apps.
Why Shopify Polaris inputs cannot always be filled with normal JS value assignment.
How Browser Use Cloud browser instances are created, listed, and cleaned up.

These are not steps for one task. They are decision-making knowledge that many future tasks can reuse.

Example: Amazon product search

For Amazon product search, the important part is not only how to search, but which path is more stable.

A more reliable approach is to use a direct search URL instead of opening the homepage and simulating typing every time. Search results can be extracted from a container such as [data-component-type="s-search-result"]. Field extraction also has details: title, price, rating, review count, and sponsored status each have more stable DOM sources.

This kind of experience is valuable for an agent. Without it, the agent may guess buttons from screenshots and repeatedly try selectors. With it, the agent can go directly to a more stable extraction path.

More importantly, a skill can record traps. For example, some selectors that look usable may misread sponsored results or cross-sell areas. You only learn that from field testing.

Example: LinkedIn invitation management

LinkedIn is closer to a real account workflow, and the risk is higher.

On the invitation manager page, the Accept and Ignore buttons use different aria-label formats. You cannot simply derive one from the other. Some invitation cards even render Accept as an <a> element rather than a <button>, and ordinary CDP clicks may not trigger the accept action.

This shows that real web automation does not end when an element is located. Button labels, event binding, soft navigation, and component implementation all affect whether an action really works.

For an agent, this experience also has a safety meaning. Operations involving social accounts, invitations, messages, and posting should not be fully delegated. A skill can record the path and traps, but accepting invitations in bulk, sending content externally, or changing account details should keep human confirmation.

Example: Shopify Admin

Shopify Admin shows another issue: backend systems are often not one page, but a combination of embedded apps and complex components.

Many Shopify apps run inside iframes. Polaris React inputs, Web Components, and embedded apps all behave differently. Some inputs cannot be filled with element.value = ...; they need CDP keystrokes that are closer to real keyboard input.

The value of this kind of skill is that it lets the agent first identify what kind of UI it is looking at, then choose the right operation method.

Shopify experience also emphasizes “do not use the browser if you do not have to”:

For read-only product and inventory data, use the Storefront API first.
If an Admin API token exists, use the Admin API first.
For theme code editing, use Shopify CLI first.
Use the browser only when there is no API, the change is rare, or you are exploring the admin.

That is a mature tool-selection logic for agents.

Example: Browser Use Cloud

domain skills do not only serve webpage clicking. They can also record API experience around browser runtimes.

Browser Use Cloud experience can record how to create cloud browsers through REST APIs, list running browsers, clean up zombie browsers, and obtain liveUrl and cdpUrl.

This means a skill is not limited to “how to click a button.” Any recurring task with a stable method can become a skill:

API call patterns.
Authentication header format.
Request and response structure.
Verified status codes.
Common failure modes.
Resource cleanup and recycling methods.

For agents, all of these are reusable capabilities.

Why this is more reliable than ad-hoc reasoning

Many people expect a large model to understand the webpage by itself every time. In real tasks, relying only on ad-hoc reasoning is unstable.

The reasons are simple:

Web UI changes often.
The same button may have multiple implementations.
Visible does not mean clickable.
Clickable does not mean the action really worked.
Some tasks should use APIs instead of browsers.
Some operations require human confirmation and should not be decided by the model alone.

Writing these experiences into files brings several benefits:

Humans can review them.
Wrong experience can be corrected.
Site knowledge can accumulate over time.
New agents can inherit old experience.
Temporary task discoveries can become long-term knowledge.

This is more stable than putting everything into a prompt or chat context.

How teams can use it

In a team, domain skills can become a lightweight automation knowledge base.

Useful content to record includes:

Post-login paths in internal systems.
Report export flows.
Common popup handling.
Which buttons require human confirmation.
Which pages have API alternatives.
Which selectors were tested and found reliable.
Which tasks agents are not allowed to run automatically.

This knowledge does not need to be complete at the beginning. A practical path is to start with low-risk, frequent, reversible workflows: read-only tasks, downloads, organization, and checks. Once the flow is stable, turn the experience into a skill.

For team managers, skill files also make automation boundaries visible. You can inspect what the agent knows, what it can do, and where it should stop.

Boundaries to keep

domain skills can improve an agent’s success rate, but they should not fully automate high-risk operations.

Several boundaries matter:

Do not record passwords, Cookie, token, customer data, or sensitive internal URLs.
Keep human confirmation for payments, deletion, bulk submission, account changes, and external publishing.
Record verification date and scope.
Allow skills to expire after site changes and require revalidation.
Do not make bypassing risk controls or platform limits a goal.

In other words, domain skills make agents steadier. They do not give agents unlimited permission.

Conclusion

The domain skills mechanism in browser-harness shows one thing: AI browser automation cannot rely only on the model improvising at runtime.

A usable browser agent needs at least three layers:

Low-level control: screenshots, clicks, input, downloads, CDP, HTTP.
Site-level knowledge: API priority, stable selectors, component traps, login boundaries.
Human safety rules: do not give credentials to the model, confirm high-risk actions, and do not write sensitive information into skills.

domain skills fill the second layer. They let an agent enter a web task with verified experience instead of rediscovering everything every time.

References:

browser-harness domain skills: https://github.com/browser-use/browser-harness/tree/main/agent-workspace/domain-skills
Amazon product-search skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/amazon/product-search.md
ArXiv scraping skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/arxiv/scraping.md
GitHub scraping skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/github/scraping.md
LinkedIn invitation-manager skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/linkedin/invitation-manager.md
Shopify admin skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/shopify-admin/README.md
Browser Use Cloud skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/browser-use-cloud/cloud.md

Claude-Mem: Adding Cross-Session Long-Term Memory to Claude Code

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem is a persistent memory system for Claude Code.

It tries to solve a very specific problem: every time an AI coding assistant starts a new session, it often forgets earlier architecture decisions, past pitfalls, project preferences, and implementation context.
If a project lasts for a long time, repeatedly explaining the same background becomes a waste of time.

The idea behind Claude-Mem is to compress Claude Code conversations into memories, store them in a local database and vector store, and then retrieve them later through a search tool.

What Problem Does It Solve?

Claude Code is good at code tasks, but session context is still limited.

Common pain points include:

A new session does not know what previous sessions did
Project design decisions need to be explained repeatedly
Problems that were already debugged are easy to repeat
Long-running tasks lack continuity
Project knowledge is hard to accumulate across conversations

Claude-Mem is designed around these problems.

It is not simply saving chat logs. Instead, it compresses conversations into memory fragments that are easier to retrieve. When needed later, semantic search can bring the relevant context back.

How It Works

From the README design, Claude-Mem mainly consists of several parts.

The first part is hooks.

It integrates with the Claude Code session flow and captures conversation data at the right time.

The second part is a background worker.

The worker processes raw conversation content into shorter, more searchable memories.

The third part is local storage.

The project uses SQLite for structured metadata and Chroma for vector indexing. This preserves basic session information while supporting semantic retrieval.

The fourth part is mem-search.

This is the query entry point for Claude Code. When old context is needed, it can search relevant memories through this tool.

The overall flow can be understood like this:

Claude Code sessions generate content
Hooks capture session data
The worker asynchronously compresses and organizes it
Memories are written to SQLite and Chroma
Later sessions retrieve them through mem-search

When Is It Useful?

Claude-Mem is suitable for long-running projects, not one-off small tasks.

For example:

A repository is developed over many days
The code structure is complex and has a lot of background
Project conventions, naming habits, and architecture choices need to be remembered
Claude Code is often used for bug fixes, features, and documentation
You want the AI to remember why something was changed earlier

If you only ask Claude Code to make a one-line change, long-term memory is not very meaningful.
But if you treat Claude Code as a long-term collaborator, it becomes useful.

Installation and Startup

The README gives a direct installation flow:

1
2

npm install -g claude-mem
claude-mem install

Start it with:

`1`	`claude-mem start`

Check status:

`1`	`claude-mem status`

Stop it when needed:

`1`	`claude-mem stop`

The goal behind these commands is to connect the memory system as a long-running local service to the Claude Code workflow.

How to Use `mem-search`

mem-search is the key entry point for retrieving memory.

It is not meant to replace ordinary search. It lets Claude Code query past conversations by meaning.

For example, Claude Code can search for:

Why a module was designed in a certain way
How a bug was debugged earlier
Naming rules agreed on in the project
Technical trade-offs discussed before
The background behind a refactor

This is different from simple keyword search.
If memory compression and vector indexing work well, you can retrieve semantically related content even if you do not remember the exact wording.

How Is It Different from Project Documentation?

Project documentation is good for stable conclusions.

For example:

Architecture notes
Deployment procedures
API conventions
Database structure
Development rules

Claude-Mem is better for context created during conversations.

For example:

Why a plan was rejected
How a temporary issue was worked around
The discussion behind an implementation
Project preferences not yet written into docs
Task background accumulated across multiple conversations

The two are not replacements for each other.
A good workflow is to write stable knowledge into project docs and use the memory system to help retrieve conversational context.

Things to Watch Out For

First, more long-term memory is not always better.

If every conversation is saved without distinction, later retrieval can become noisy. The most valuable memories are project decisions, implementation background, debugging history, and long-term preferences.

Second, memory cannot replace code and documentation.

Old context found by AI is only a reference. Final judgment still depends on the current code, test results, and latest requirements.

Third, pay attention to privacy and local data.

Since it stores conversation content, you should know which projects are suitable for it and which sensitive information should not enter the conversation.

Fourth, memory systems need maintenance.

As a project moves forward, old memories may become outdated. If outdated context is reused incorrectly, it can mislead later tasks.

Why This Kind of Tool Matters

AI coding tools are moving from one-off Q&A toward long-term collaboration.

In one-off Q&A, the model only needs to answer the current question.
In long-term collaboration, it needs to know project history, earlier decisions, team preferences, and pitfalls that have already been found.

This is where tools like Claude-Mem matter: they turn “remembering context” from a temporary chat capability into a local system that can be installed, run, and searched.

For real engineering projects, this is more practical than simply making the model context window longer.
Much information does not need to be stuffed into context all at once; it needs to be retrieved at the right time.

Who Should Try It?

You may want to try it if:

You use Claude Code frequently
You often work on the same project across multiple days
The project context is complex
You repeatedly explain the same background to AI
You want to preserve experience from conversations

If you only use Claude Code occasionally, or the project is small, you may not need this kind of system yet.

Reference

thedotmack/claude-mem

Final Thought

The point of Claude-Mem is not “saving chat logs.” It is helping Claude Code retrieve useful context in later tasks.

As AI coding moves from one-off tasks to long-running project collaboration, memory systems will become increasingly important.
They cannot replace documentation and tests, but they can reduce repeated explanations and make the AI feel more like an assistant that understands project history.

Codex Is Starting to Control the Computer. What Does That Mean for the Future?

Wed, 29 Apr 2026 11:28:25 +0800

The most important part of this Codex update is not that it added another ordinary button. It is that Codex is starting to move toward “controlling the computer.”

In the past, using AI usually meant asking questions in a chat box, copying, pasting, and then manually operating software.
Now that boundary is expanding: AI does not just answer you. It can operate desktop applications according to your goal.

In the short term, this is a new feature. In the long term, it may change how many people use computers.

What This Feature Is

Simply put, Codex’s computer use capability lets it access and operate the desktop environment.

It can do things such as:

select and control an application
receive tasks in natural language
open browsers, AI tools, local files, or other software
enter text, click buttons, and wait for results
connect multiple steps into one task
keep running in the background without requiring the user to follow every step manually

Its role is not just to write a piece of text for you, but to complete an operation flow for you.

That is the key difference between an Agent and an ordinary chatbot:
a chatbot mainly gives answers; an Agent is closer to “receiving a goal and then executing it.”

Why This Matters

In the past, much automation required you to know how to write scripts.

For example, suppose you want to complete a cross-software workflow:

open a web page
find information
copy content
pass it to another AI tool
save a file
open the local directory and check the result

To automate this traditionally, you might need browser scripts, APIs, local programs, and even window automation.

But many ordinary users do not know how to write these things.
Even if they do, it may not be worth writing a script for a temporary task.

This is where computer use matters: it pushes “script-like capability” toward natural language.

You do not necessarily need to tell it exactly where to click.
You can tell it what result you want and let it try to complete the task.

Workflows It May Change

I think the first workflows to change will not be extremely serious or high-risk work, but the tasks that are annoying, fragmented, repetitive, and not worth writing a dedicated program for.

1. Moving Information Across Software

The most typical case is moving information between applications.

Previously, you might switch back and forth between a browser, a document, a chat window, and a local folder.
In the future, you can hand this kind of task to an Agent:

find a certain kind of information
summarize it into a document
save it to a specified directory
open the result for you to review

This work is not hard, but it consumes attention.
The value of an Agent is that it absorbs these small operations.

2. Coordination Between Multiple AI Tools

Many people’s real workflow is no longer based on a single AI tool.

It may look like this:

one tool writes code
one tool researches information
one tool generates images
one tool organizes documents

Previously, these tools were connected by manual copy and paste.
In the future, an Agent can become the middle layer: it opens tools, passes context, waits for output, and organizes results.

This can turn “multiple AI tools working together” from a manual process into a semi-automated process.

3. Office Software Automation

Spreadsheets, presentations, documents, and email share one trait: they are powerful, but many operations are fragmented.

If Agents can reliably control this software, the barrier to office automation will drop noticeably.

You do not need to remember where a menu is or learn complicated shortcuts.
You only need to describe the goal, such as:

turn this spreadsheet into a monthly report
make a one-page summary from this document
combine these materials into a clearly structured explanation

The tedious button operations will gradually be hidden behind natural language.

What It Means for Ordinary Users

For ordinary users, this kind of feature may have a more direct impact than “the model got a bit smarter.”

Because it lowers the operation barrier, not just the knowledge barrier.

Many people can describe what they want, but they do not know where to click or how to combine features inside software.
If Agents can take over this part, using a computer may become:

1
2
3

I describe the goal
Agent operates the software
I check the result

That is closer to real productivity than simple chat.

Its Impact on Software

If this kind of Agent capability continues to mature, software itself will also be affected.

In the past, software design mainly served human clicking.
In the future, software may also need to serve Agent operation.

This means:

interface elements need to be clearer
operation feedback needs to be more stable
local permissions need to be more granular
software may provide interfaces better suited for Agent calls
users may care more about whether software can be operated smoothly by AI

In the long run, the boundaries between applications may become thinner.
Users may care less about “which app should I open” and more about “what task do I want to complete.”

Do Not Overhype It Yet

Of course, it is not time to fully let go yet.

This kind of capability still has several clear limitations:

stability still needs observation
complex tasks may fail in the middle
permission boundaries must be handled carefully
account, payment, and file deletion operations should not be delegated casually
quota consumption is not something you can completely ignore

So at this stage, the best use case is not letting it take over the whole computer, but letting it handle low-risk, reviewable, step-heavy tasks.

For example:

organizing materials
generating drafts
moving content across tools
opening and checking files
running semi-automated workflows that can be reviewed by a human

One Last Line

The real importance of this Codex update is that it pushes AI from “answering questions” toward “operating the environment.”

In the short term, it is a computer use feature.
In the long term, it may mark a shift in how personal computers are used.

In the future, we may spend less time remembering buttons, finding menus, and switching windows.
More often, we will describe the goal, let an Agent execute it, and then let humans make the final judgment.

What Is the Difference Between ~/.codex/skills and Project .codex/skills in Codex

Wed, 29 Apr 2026 11:08:00 +0800

When organizing Codex skills, people most often get stuck on two questions:

What is the difference between ~/.codex/skills and project/.codex/skills?
Why does a skill exist in the directory but not appear in the current session?

Here is the short version.

The Difference

The simplest way to remember it:

~/.codex/skills is your global skill library
project/.codex/skills is the local skill library for that repository

`~/.codex/skills`

Use it for:

skills you personally reuse across projects
general workflows that are not tied to a specific repository
workflows that clearly belong to your own habits

For example:

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

The key trait of this kind of skill is: it still makes sense outside the current project.

`project/.codex/skills`

Use it for:

workflows that only apply to this repository
rules tightly coupled to the current project structure, scripts, or templates
skills that should be shared by the team

For example:

a publishing workflow specific to this repository
a generation template that only works in this project
automation steps tightly bound to private project scripts

The key trait of this kind of skill is: it stops being meaningful once it leaves this repository.

When to Use Global and When to Use Project Skills

This rule of thumb is enough:

If it is about your personal habits, put it in ~/.codex/skills
If it is about repository rules, put it in project/.codex/skills
If it can be reused across projects, prefer global
If it should be shared by multiple people and evolve with the repository, prefer project-level

The Current Repository

Based on the current state:

your machine has ~/.codex/skills
this repository does not have .codex/skills

So right now, you mainly rely on global skills.

That means workflows such as post-rewrite, post-translate, and git-commit-push are currently more like part of your personal workflow, not something explicitly bundled with this repository.

Why a Skill Exists on Disk but May Not Appear in the Current Session

There are two different things here:

Existing on disk: the skill file exists in a local directory
Exposed to the session: the current session registered it into the available skill list

These are not the same thing.

So this can happen:

a skill already exists under ~/.codex/skills
but it does not appear in the list after /

This usually does not mean the skill is broken. More often, it means: the current session has not re-indexed it.

How to Make a Skill Available in the Current Session

The practical checklist is short.

1. Put It in the Right Directory

Global:

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

Project-level:

`1`	`project/.codex/skills/<skill-name>/SKILL.md`

2. Make the `SKILL.md` Header Recognizable

At minimum, it needs:

---
name: your-skill-name
description: What this skill does
---

3. Open a New Session After Creating or Editing It

In many cases, a skill does not appear because the current session already fixed its available skill list when it started.

So if you create a skill in the middle of a session, it may already exist on disk, but this session may not recognize it.

The most reliable workflow is:

Put the skill in place
End the current session
Re-enter the project
Open a new session
Check whether it appears under /

4. Put Project Skills in Place Before Starting

If you want project/.codex/skills to be recognized more reliably, put those skills into the project before entering the repository and starting the session.

One Last Line

The shortest conclusion is:

~/.codex/skills is your personal skill library
project/.codex/skills is the repository’s local rule library
a skill existing in the directory does not mean the current session will always show it
the most common fix is to put it in the right directory, write a valid SKILL.md, and then start a new session

Using Agent Skills to Replace Copilot's 'Generate Commit Message' in VS Code

Mon, 06 Apr 2026 13:09:49 +0800

GitHub Copilot’s “Generate Commit Message” in VS Code is very useful. Once the quota is exhausted, the reset cycle can feel long. This post is a practical attempt to replace that feature with local Agent Skills.

Problem and Goal

The goal of this post is to provide a practical alternative: use git-commit-push-zh skill agents to complete standardized commits and pushes.

Alternative: `git-commit-push-zh`

This skill turns your current changes into a fixed workflow:

Check change status.
Confirm the current branch.
Stage changes.
Generate a Chinese commit message.
Run commit.
Push to the remote branch.

The corresponding commands are:

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

Suggested Commit Message Convention

Use this format consistently:

`1`	`<类型>(<范围>): <中文摘要>`

Type examples:

feat: New feature
fix: Bug fix
docs: Documentation update
refactor: Refactoring
chore: Maintenance changes

Examples:

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

Common Failure Scenarios

nothing to commit: no new changes to commit; stop before pushing.
push failed: check permissions, remote branch state, and conflicts first.
SSH/permission issues: verify credentials and access, then retry.

Appendix: Original `SKILL.md`

The content below is the original git-commit-push-zh document, preserved as-is for reuse and maintenance.

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

Workflow on KnightLi Blog

How Much Extra Token Usage Do subagents Cost? Multi-Agent Costs and Usage Strategy

A subagent is not a cheaper parallel thread

Why token usage increases

Re-reading context is the biggest token waste

Rough cost multipliers

How to write a more token-efficient subagent task

Splitting by file or directory is cheaper than splitting by language or step

When it is worth using subagents

When one review agent is worth it

When it is not worth using subagents

My default strategy: prioritize token savings and add review only for risk

A more balanced strategy

Summary

How browser-harness domain skills keep AI agents from repeating browser automation mistakes

What domain skills are

They are not about blind clicking

They store site-level knowledge

Example: Amazon product search

Example: LinkedIn invitation management

Example: Shopify Admin

Example: Browser Use Cloud

Why this is more reliable than ad-hoc reasoning

How teams can use it

Boundaries to keep

Conclusion

Claude-Mem: Adding Cross-Session Long-Term Memory to Claude Code

What Problem Does It Solve?

How It Works

When Is It Useful?

Installation and Startup

How to Use mem-search

How Is It Different from Project Documentation?

Things to Watch Out For

Why This Kind of Tool Matters

Who Should Try It?

Reference

Final Thought

Codex Is Starting to Control the Computer. What Does That Mean for the Future?

What This Feature Is

Why This Matters

Workflows It May Change

1. Moving Information Across Software

2. Coordination Between Multiple AI Tools

3. Office Software Automation

What It Means for Ordinary Users

Its Impact on Software

Do Not Overhype It Yet

One Last Line

What Is the Difference Between ~/.codex/skills and Project .codex/skills in Codex

The Difference

~/.codex/skills

project/.codex/skills

When to Use Global and When to Use Project Skills

The Current Repository

Why a Skill Exists on Disk but May Not Appear in the Current Session

How to Make a Skill Available in the Current Session

1. Put It in the Right Directory

2. Make the SKILL.md Header Recognizable

3. Open a New Session After Creating or Editing It

4. Put Project Skills in Place Before Starting

One Last Line

Using Agent Skills to Replace Copilot's 'Generate Commit Message' in VS Code

Problem and Goal

Alternative: git-commit-push-zh

Suggested Commit Message Convention

Common Failure Scenarios

Appendix: Original SKILL.md

How to Use `mem-search`

`~/.codex/skills`

`project/.codex/skills`

2. Make the `SKILL.md` Header Recognizable

Alternative: `git-commit-push-zh`

Appendix: Original `SKILL.md`