XnneHang

Rebuilding My Blog: Where My Inspirations Came From

Sun, 07 Jun 2026 00:00:00 GMT

[!NOTE] AI-generated content disclosure: This article was organized and is continually updated by Korewaxnne, an AI assistant powered by Claude. Xnne provided the source material, inspirations, and backstories behind each part of the blog's rebuild; I shaped them into a complete article.

In [[When My Cloud Provider Disappeared: Rethinking the Shape of a Personal Blog and What Is Worth Recording]], Xnne discussed why they ultimately chose a static blog. This article is its companion, documenting the inspirations behind each part of the rebuild and the blog's continuing evolution afterward.

The reason for writing it is simple: Xnne drew a great deal of inspiration from other people's blogs, applications, and games. Connecting those threads is both a way to give credit and a way to help anyone attempting something similar avoid unnecessary detours.

This is not a list frozen at the moment the rebuild ended. The blog is still growing: new pages will appear, and features that were once scattered will be recombined. This article will therefore continue to evolve alongside the blog.

The Core Framework

::github{repo="SigureMo/nyakku.moe"}

The blog's underlying framework was forked directly from nyakku.moe, which combines Astro, Svelte, and Tailwind. The reasons for choosing it were covered in the other article: static generation, native Markdown support, simple deployment, and completely local data.

nyakku.moe itself can be traced back to Fuwari:

::github{repo="saicaca/fuwari"}

Fuwari provides an Astro blog theme that works out of the box, and nyakku.moe made extensive personal customizations on top of it. Xnne then continued building their own ideas on top of nyakku.moe. The three layers look roughly like this:

Fuwari → nyakku.moe → this site

Rethinking Content Organization

The rebuild was not just a switch to a different framework. More importantly, it was an opportunity to rethink how the content itself should be organized.

Previously, Xnne used categories as though they were series, which left the categories extremely disordered. The rule now is: Each post has exactly one category, but may belong to multiple series.

Series

A series describes a post's subject, answering, “What is this post about?” Examples include LLMs, blogging, reading, and film. A post discussing the construction of a graph for a blog might be categorized under Reflections while belonging to both the LLM and Blogging series.

This division grew out of reflecting on the old, chaotic organization. Categories became focused, series became flexible, and the two became orthogonal.

The Homepage and Reading Experience

Homepage Banner

The homepage hero fills the viewport while the actual content begins farther down. A transparent wave bridges the background image and the content area. The top navigation blends into the hero and becomes visible only after scrolling. Except while reading a post, the navigation always follows the viewport.

Inspiration: NBlog

::github{repo="Naccl/NBlog"}

NBlog was also the first blogging system Xnne deployed during the cloud-server era. Its opening screen has a strong visual impact, and the wave transition keeps the hero and content from feeling disconnected. Xnne brought that design language into the current static site, then gradually replaced it with colors, navigation, and content entry points that felt more personal.

Hiding the Navigation While Reading

While a post is being read, the top navigation disappears and leaves the visual space entirely to the content. This detail came from:

Innei's Blog

Navigation is a distraction in a reading context. Hiding it makes the experience more immersive. Simple, but effective.

The Bookshelf: What I Am Reading and What Has Stayed with Me

The Bookshelf presents books, manga, games, films, television series, anime, and papers that Xnne has experienced, with the complete collection displayed as either a cover wall or a list.

The original inspiration was Lapis' Bookshelf:

::github{repo="Lapis0x0/VermilionVoid"}

Xnne loved this way of visualizing reading and viewing history. Compared with a plain list, a cover wall feels more like a display case being slowly expanded. Categories, subcategories, and reading notes make it possible to rediscover the works that have remained.

Later, a “Continue Reading” section was added to the top of the Bookshelf. It is not another collection list, but a place reserved for books still in progress, and a reminder to keep reading them. A book does not have to disappear from the site simply because it has not yet been finished and its reflections have not yet become a post. Reading progress and quick notes can show that the relationship is already unfolding.

The Bookshelf now holds two kinds of time at once: unfinished reading above and the works that have remained below.

Statistics and Graphs: Seeing a Blog Through Its Numbers

The formerly separate statistics page and relationship graph were eventually combined into a single Statistics entry point. One view observes how content is published and then read; the other observes how posts cite one another. Both are concerned with the same question: how did this blog gradually grow into what it is today?

Publishing Trails and Reading Echoes

The inspiration for publishing statistics came from this cute world: take numbers that would normally be visible only in an administrator dashboard and organize them into a public page, allowing readers to see how the blog is read and how its content has accumulated over time.

This site divides its statistics into two threads. The first is the “publishing trail”: a publication calendar records the dates on which works appeared, while a time slice presents publication pulse, category evolution, and series lifelines side by side. It records when posts were published without pretending to know when the actual writing happened each day.

The second is the “reading echo”: visitors, page views, engagement time, and post rankings describe what happens once the writing leaves the desk and is read. Visitors' browsers send page-view and engagement events to GA4. GitHub Actions periodically calls the GA4 Data API, then combines those aggregate results with word counts, estimated reading times, and publication dates calculated during the Astro build to produce static data for the page.

This approach requires neither a persistent backend for GitHub Pages nor a self-hosted database. Service-account credentials exist only in GitHub Actions Secrets, and the public page displays only post-level aggregate data. The average reading-time ranking also requires a minimum sample size so that a handful of visits cannot distort the results.

Relationship Graph

The relationship graph was inspired by Nagi's Blog. The blog is not open source, but its author explained the relevant implementation ideas in detail in an article.

Combining those ideas with their reflections in [[After Building Long-Lived Systems: Is the RAG Monster Right for Constructing a Personal Blog Graph?]], Xnne ultimately chose not to rely on RAG or embeddings. Instead, the graph is built from bidirectional wiki-link relationships. Open a post and you can see what it cites and what cites it; zoom back out and you can see how different categories are distributed and connected throughout the blog.

After the graph was integrated into the Statistics page, the “publishing trail” and the “citation threads” became two perspectives under a single entry point: one looks back through time, while the other wanders through relationships. Statistics are no longer merely a row of numbers, and the graph is no longer an isolated page.

About: Letting the Bookshelf Introduce Me

The About page originally relied mainly on written self-description. Later, Xnne realized that adding more personality labels and experiences did not make “who I am” any more concrete. Instead, it increasingly resembled a fully completed form with no warmth.

The page was therefore remade as a “reading portrait.” It first places real bookshelves in front of the reader, using a set of photographs that can be browsed and enlarged, each accompanied by a short caption, as the introduction. Chang Ge, light novels, Makoto Shinkai, Keigo Higashino, Haruki Murakami, Yasunari Kawabata, Yukio Mishima, Hermann Hesse, Somerset Maugham... The arrangement left behind by all that reading comes closer to the self Xnne wants to introduce than a string of abstract labels ever could.

If a person can truly be recognized through the books they have read, then perhaps these photographs come closer to me than a self-introduction does.

The writing was not removed entirely; it simply receded behind the photographs. The page then uses three cards—“Recording,” “Organizing Fragments,” and “Music”—to summarize its driving forces, before ending with a more concrete self-description. It changed from “read a passage about me” to “first see what I have left behind, then decide how to know me.”

Comments

::github{repo="MrXnneHang/xnnehang.top"}

The comment section uses giscus, which is built on GitHub Discussions. Readers can comment with a GitHub account, and all data remains in the repository's Discussions without requiring a backend.

Inspiration: Menghuan1918's Blog

After seeing the approach on that blog, Xnne thought it was a good fit: lightweight, free, and particularly suitable for a technical blog because every comment is managed as a Discussion. Xnne later adopted it and created a custom theme to match the blog's blue palette.

A Custom 404 Page

GitHub Pages' default 404 page contains only File not found, with neither this site's navigation nor a way back. As soon as visitors reach an address that does not exist, they are abruptly thrown out of the blog's visual world.

This site therefore added a custom 404 page. It uses “This part of the knowledge planet is still a desert” to represent coordinates that have not yet been recorded, retains the navigation bar, theme switcher, and footer, and provides two exits: “Back to Home” and “View Archive.” The page continues to use the main site's theme colors and also adapts to mobile screens and dark mode.

During the Astro build, a 404.html file is generated at the root. When GitHub Pages cannot find the requested static file, it returns this page while preserving the correct HTTP 404 status. Even when visitors take a wrong turn, they therefore remain on the same knowledge planet.

The In-Progress Workbench: Turning Todos into Alchemy

The In-Progress Workbench is a public, read-only view of GitHub Issues. GitHub handles creation, editing, permissions, and history, while the blog handles presentation, search, priorities, and browsing by label. Ideas in progress do not have to wait until they become posts or projects before they can be seen.

Its task-management foundation was inspired by TickTick, but Xnne did not want to build yet another ordinary Todo List. The alchemy experiences of Potionomics and The Elder Scrolls V: Skyrim were therefore folded into the workflow as well: scattered ingredients are gathered, sorted, and placed into the cauldron, eventually becoming something new.

The site does not reproduce any of those systems wholesale. Instead, it recombines the three inspirations. Items still in progress enter the “Crucible,” organized by priorities from P0 through P3 and by ordinary labels. Closed Issues become “Crystals,” preserving traces of what has been completed. A line on the workbench captures the metaphor:

Mix and refine scattered ideas.

For Xnne, showing work in progress does more than reveal “what comes next.” It also gives fleeting ideas a container before they disappear. A Todo is no longer merely a line waiting to be crossed out, but material still being refined.

A Bilingual Site: Making Another Language Part of the Structure

When Xnne first considered adding English to the blog, the task was not simply to “translate the posts.” If English existed only in the article body while navigation, search, archives, statistics, the relationship graph, and RSS still understood only Chinese, the result would have been a scattered collection of translations rather than an English site that could be read on its own.

The redesign therefore preserves every existing Chinese URL while placing the English site under /en/, with language changes left to the reader. Pages do not force a redirect based on browser language, and the Chinese and English versions of each post are paired through a stable translationKey. Old links remain intact, while both languages receive clear and predictable addresses.

The harder part was carrying language through the entire network of content. The homepage, navigation, archives, series, Bookshelf, In-Progress Workbench, Statistics, relationship graph, search, 404 page, RSS, and SEO all gained English counterparts. WikiLinks, related posts, previous and next navigation, categories, and series are resolved only within the current language. Chinese and English also receive separate search indexes, RSS feeds, statistics catalogs, and graph data, so switching to English does not lead the reader unexpectedly back into Chinese somewhere farther along the path.

At the same time, all 66 published posts were migrated into complete English counterparts. The migration did not treat them as isolated pieces of text: groups connected by WikiLinks had to move together, or translated links would point toward titles that did not yet exist. Each post first went through translation-pair and file checks, while full production builds were reserved for batch checkpoints. This order kept a large migration divisible, inspectable, and traceable.

The purpose of making the whole site bilingual was not to pretend that the blog no longer has a linguistic boundary. It was more like laying a second complete path through it. Chinese remains the place where the blog first grew, while English is no longer an attachment beside the body text; it has its own entrances, navigation, and content network. Bilingualism thus changed from a translation task into part of the blog's structure itself.

Those are the main threads of inspiration running through this blog today. Thank you to the creators of these projects, blogs, applications, and games for leaving their practices and imaginations behind, giving those who followed a trail to trace.

The blog will probably continue to change. The next time a new page grows, this list will gain another tributary.

Filled with Empty Things

Sun, 16 Aug 2026 00:00:00 GMT

Parallel timelines?

The story’s timeline is somewhat confusing, but a clever narrative weaves it all together. I could not tell whether I was trying to solve a mystery as I read or simply following along; it somewhat forced me to think.

Overall, it was good. Dreams Come True, its companion piece, and Mother all resonated with me. Taken as a whole, however, its themes feel somewhat scattered, and what it has to say about death and lifespan feels faint—or rather, quite shallow.

That is no exaggeration. The novel and manga versions of Three Days of Happiness, [[After “A Year for Ten Thousand Yen”]], [[We Who Have No Tomorrow Fell in Love Yesterday]], [[Existentialist Reading Notes]], and [[I Come Alone, I Leave Alone]] have together given my thoughts about death and lifespan something like the effect of thematic reading. By comparison, this work’s discussion remains on the surface for me. Perhaps manga as a medium lacks some of the complexity that prose can provide.

Still, as the first book I have finished in one sitting in quite a while, it was a good start.

The Lychee of Chang'an

Sat, 08 Aug 2026 00:00:00 GMT

An interesting perspective.

Interesting characters.

It reminded me of just how poor arithmetic was in medieval Europe—so poor that its scholars might not even have been able to solve the classic chickens-and-rabbits problem. Under the constraints imposed by theology, the ingenious reasoning and calculations behind heliocentrism were genuinely impressive, but they were less mathematics than mathematical intuition.

By contrast, quite a few people in ancient China were remarkably good at arithmetic, even though it received little recognition at the time. The Daoist writings of that era are truly astonishing as well.

That is why it is worth having something to pursue, even if that pursuit is immortality. Or perhaps the path endorsed by the mainstream of an age may later prove neither useful nor even correct.

Better, then, to find something you love and pursue it over the long term, even if it is as impractical as a dream.

First Impressions of GitHub Stacked PRs

Wed, 05 Aug 2026 00:00:00 GMT

Today I noticed that GitHub has opened Stacked PRs as a Public Preview. It is no longer something that requires joining a waitlist before trying it.

I happened to have a very old PyQT Pomodoro project that I have recently wanted to refactor into Tauri + Rust, so I decided to try it out first.

What Is `gh stack`?

It is a little like a gh CLI extension. It lets pull requests be connected in an orderly way instead of existing independently and merely mentioning one another like sworn brothers.

It lets PRs stack on feature branches rather than all pointing directly to the main branch.

What Does It Bring?

This is what I wrote before:

Large PRs are hard to review, take a long time to move through the process, and make conflicts and blocking relationships difficult to understand. They require frequent rebasing.

Small PRs are fast to review, but their relationships can only be connected through mentions. Everything becomes fragmented and unclear. I am used to opening atomic PRs, so I often run into this problem and lose track of what has been done.

`gh stack` can combine the advantages of both approaches while making collaboration more atomic.

No more preamble. Let us begin.

How Do You Create One?

For the exact steps, see Creating stacked pull requests.

But if you rely on tools such as Claude Code or Codex, GitHub also provides a corresponding Skill installation. It is somewhat like the Skill injection work memU has been doing recently.

You can simply tell Codex or Claude to globally install GitHub’s new gh stack and its Skill for you.

In other words, we do not need to care about which commands to type; we can stay at the higher-level view.

Even if we do not care about the mechanics, though, we still need to understand its shape and its benefits.

Stacked PRs from a Maintainer’s Perspective

Can They Be Merged in Order?

Yes—and they can only be merged in order.

As shown here, the bottom PR can be merged one by one. Once it is merged, as long as there are no conflicts, GitHub automatically cascades a rebase across the remaining upper branches on the server and force-pushes updates to the remote PRs. Developers do not need to manually run gh stack sync; the automated process stops only when it encounters a conflict and needs developer intervention.

But merging an upper PR also merges all the PRs below it. If my cursor is on the third layer, merging it merges three PRs at once.

Incremental Reviews

Using the diagram above as an example, #23 contains all of #23’s code.

And #24 contains all of #23’s code plus #24’s incremental code, but review shows only the diff between #24 and #23.

All reviews are incremental; they do not overlap.

Stacked PRs from a Contributor’s Perspective

An Immediate Reality Check

All branches in a Stack PR must be in the same repository, and that repository must also contain the branch they will merge into.

For example:

xnne-bot wants to merge 4 commits into NevaMind-AI:main

If I open a PR from a fork to upstream, my PRs cannot form a Stack. They can only be merged together when they all live in the nevamind-AI/memU repository.

At least for now.

Are Tree-Shaped Stacks Supported?

The official example looks roughly like this:

L0 main
L1  └── auth-layer
L2     └── api-endpoints
L3         └── frontend

It is a linear set of layers.

My first thought was: could it be a tree instead of a stack?

At present, the answer is no. Every PR must follow a strict dependency relationship. For an upper PR to merge, the lower PRs must merge with it.

What happens if two PRs are at the same level?

:::note[Opus] Two PRs cannot exist as the “same layer” of one Stack.

Suppose PR B and PR C both use PR A’s branch as their base. From Git’s and ordinary PRs’ perspective, this is entirely valid, but they become two sibling PRs rather than part of the same linear Stack. Merging one will not merge the other.

If B and C depend on one another in sequence, arrange them as A → B → C. If they are independent and merely share A as a dependency, it is better to merge their common foundation A first, then let B and C each begin from the new trunk.

In short, a Stack requires each layer to have a unique layer above and below it. Once a same-level branch appears, it is no longer a Stack but an ordinary branch dependency graph. :::

That is to say, a Stack should not contain parallel relationships. It exists solely to handle linear, inclusive dependencies. If a parallel relationship exists, the Stack should break at that point.

Break one PR down progressively and incrementally.

Do Upper PRs Include All Lower-Level Code, and Do They Change in Real Time?

If it were only a simple puzzle, ordinary mentions could already handle it.

But the most frustrating part of mentions is this: if PR B contains all of PR A’s code and depends on PR A, then whenever PR A changes, we must manually align PR B with it.

That is also why we often hesitate to split a PR, only for it to become very large in the end.

A Stack solves this problem. Because an upper PR includes all lower PR content, any change to a lower PR will ~~automatically synchronize upward~~. The whole thing feels like one PR, but it is reviewed as different parts.

:::note[Opus] The triggering scenarios need to be distinguished here: upper branches really do contain lower-level code, and GitHub does automatically synchronize the remaining branches after a lower Stack PR is merged. But if you merely add and push a commit to a lower branch, that change does not immediately propagate to upper branches.

Suppose we split a refactor into five layers:

main
└── PR A: data model
    └── PR B: core service
        └── PR C: API
            └── PR D: frontend interface
                └── PR E: integration tests

These branches form one continuous chain in Git history:

main ← A0 ← B0 ← C0 ← D0 ← E0

E’s branch therefore does contain the code from A, B, C, and D. But because each PR uses the branch immediately below it as its base, GitHub normally shows only E’s test changes when you view PR E, rather than showing all four preceding layers of diff again.

Now suppose the bottom PR, A, receives an additional commit A1 that is pushed to the remote but has not yet been merged. A’s branch moves forward, but B through E do not move with that ordinary push in real time. They temporarily diverge into this:

main
└── A0
    ├── A1                         ← PR A’s new position
    └── B0 ← C0 ← D0 ← E0         ← The four upper layers remain on the old chain

Without Stacked PRs, we would have to manually align the four layers in sequence:

Rebase B onto A1
Rebase C onto the new B
Rebase D onto the new C
Rebase E onto the new D

gh stack knows the entire dependency chain, so from A’s layer you can run:

gh stack rebase --upstack

It performs a cascading rebase and eventually produces:

main ← A0 ← A1 ← B1 ← C1 ← D1 ← E1

Here, B1 through E1 are the new commits created by rebasing. Even if the code at a given layer has not changed substantially, its commit SHA is rewritten. For this not-yet-merged case, where only a lower branch has been modified and pushed, you can run gh stack rebase --upstack locally and then gh stack push, or simply run:

gh stack sync

sync fetches, cascades a rebase across the entire Stack, pushes it, and synchronizes the PR and Stack state on GitHub. Under normal circumstances, whether there are two upper layers or ten, the developer runs the same command: the number of layers does not increase the number of steps linearly.

But the situation differs if the lower PR has already been merged through GitHub Stack merge. GitHub then cascades a rebase from bottom to top across the remaining branches on the server and automatically force-pushes updates to the remote PRs. Without conflicts, this requires no manual sync; you only run gh stack sync later when your local state needs to catch up with the remote. The Rebase Stack button on GitHub’s page is the same kind of server-side cascading rebase, except that it must be clicked manually.

If the change occurs in the middle PR C, A and B do not need to change. Only D and E need to realign from C. Run gh stack rebase --upstack on C’s branch:

main ← A ← B ← C1 ← D1 ← E1

What can truly become troublesome is conflicts, not synchronization itself. Whether using a local cascading rebase or GitHub’s server-side cascade after a merge, the normal path can process the entire Stack in one action; manual intervention is needed only when conflicts occur.

If gh stack sync encounters a rebase conflict locally, it restores each branch to its previous state and tells you to use gh stack rebase instead. After resolving the current conflict and staging the files, run gh stack rebase --continue. If later layers conflict too, continue resolving them. GitHub’s server-side rebase cannot resolve conflicts on your behalf either, so you must return to local development.

Additionally, a rebase rewrites every affected upper branch, so remote PRs need updating and CI may run again. If the repository has protections such as “dismiss approval when new commits are pushed,” existing review status can also be affected. These costs become more obvious the deeper the Stack is and the more each layer edits the same code.

So Stacked PRs really do reduce layer-by-layer alignment to an automatic cascading operation: after a lower PR is merged, GitHub automatically rebases and force-pushes the remote Stack; when an unmerged lower branch changes, you actively trigger it with a local rebase + push, sync, or the web UI’s Rebase Stack. Under normal circumstances you do not need to operate layer by layer; human intervention is needed only for conflicts. In practice, each layer should still stay focused and cross-layer edits to the same area should be minimized. :::

That is very clear: GitHub automatically completes remote synchronization after a lower PR is merged, stopping only for conflicts. sync is mainly for actively realigning unmerged changes or bringing local state up to date with the remote; it is not something you must run after every merge.

:::warning[Automatic Remote Synchronization Does Not Mean Automatic Local Synchronization] GitHub’s automatic cascading rebase and force-push update remote branches. The local branches on a developer’s computer are not rewritten in reverse by the remote repository. Once the remote Stack updates automatically, local branches remain at their old commit SHAs; before continuing work, run gh stack sync, or at least git fetch, to obtain the latest remote state.

If you skip this step, local and remote state diverge and later rebases may conflict. gh stack push uses --force-with-lease, so it normally refuses to push when the remote has changed instead of overwriting it outright. But manually running the unsafe git push --force can overwrite the result of GitHub’s automatic rebase.

The more accurate workflow is therefore: GitHub automatically updates the remote Stack; before continuing to modify or push, local development must fetch or synchronize the remote state. If there are already new local changes, commit or stash them before synchronizing the remote. :::

What Do Local Branches Look Like During `sync`?

The previous section explained that upper PRs contain all lower PR code and that lower changes are synchronized with sync.

From the perspective of local branches, do all branches move together? Do branches include all code? How are the diffs between branches ultimately turned into the incremental diffs we review in PRs? Do Stack-linked branches carry any special marker or relationship?

:::note[Opus] Conclusion: upper branches include lower-level code; sync moves only the branches that need realignment; Stack relationships are not a special Git capability.

Suppose there are four local layers:

main ← A ← B ← C ← D

Checking out A includes main + A.
Checking out C includes main + A + B + C.
Checking out D includes the entire chain’s code.

If A changes, then after running gh stack sync, B, C, and D are cascaded and rebased, so their branch pointers and commit SHAs update accordingly. If only C changes, normally only C and D need updating. It changes branch pointers; it does not modify the same working directory’s files multiple times.

Each PR shows only its own layer because it compares itself with the branch immediately below it:

PR A: main → A
PR B: A → B
PR C: B → C
PR D: C → D

So even though D contains the code from A, B, and C, PR D still displays only the incremental C..D diff.

To Git, these are still ordinary branches with no special Stack marker. The relationship is recorded mainly in two places:

Each PR’s base/head relationship;
GitHub’s Stack metadata for presentation and management.

gh stack init also maintains local hierarchy information; gh stack link can instead link existing PRs into a GitHub Stack in sequence without using that local tracking state. :::

All right, I understand. So during sync, the same file is not modified N times just because there are N layers. Rather, each file should change only once, and the heads of the other branches then point to the updated file.

Seen this way, GitHub Stack seems rather straightforward to implement. It only needs to know the base of each PR branch.

The Shape of a Protocol Determines Its Capabilities: Why Codex Removed chat_completion, and What Actually Blocks a Desktop Companion from Talking While It Works

Tue, 28 Jul 2026 00:00:00 GMT

Preface

Today, let us talk a little about transport protocols.

The common ones are:

Chat Completion: /v1/chat/completions
Responses: /v1/responses
Claude Response: /v1/messages

XnneHangLab has always used chat_completion.

The reason is simple: chat_completion is what normal users and I encounter. Early versions of newapi did not support Responses; it seems support only arrived in versions released after May this year. Platforms such as DeepSeek also expose only the Completion endpoint, which is rather unfortunate. When I wanted to find a proper Responses endpoint to test a newer codex-cli, I could not find one.

P.S. In everyday use, the recent ds-v4-flash has already shown Doubao-like low intelligence and a tendency for its two halves to argue with each other. Even simple instructions need several attempts. I am already planning to replace it completely with grok-4.5 for the assistance work in Obsidian-YOLO.<br> I do not know whether it has been dumbed down, but for me the easiest way to judge a model's intelligence is to have it review code. Compared with gpt-5.6-sol and grok-4.5, deepseek-v4-flash code reviews belong to the group that makes you want to drool. Its multi-step reasoning and deep thinking are a mess, and it considers things far too narrowly.<br> The only thing worth praising is DeepSeek's post-training, which makes it sound more human. It can only really be used for role-playing conversations. But when will image understanding finally arrive in the API? The web client has had it for more than a month already.

I wanted to investigate this because, while testing memu-cli integration with codex-cli, I found that newer versions (>0.95) had directly removed Chat Completion and moved to Response.

Questions to Discuss

The Difference Between chat_completion and responses, and the Value of Migrating

Let us look at why codex-cli did this—perhaps beginning with issues in the official Codex repository.

And distinguish the main differences and the value of migrating: what benefits, if any, would it bring to XnneHangLab?

The Difference Between Anthropic Messages and OpenAI's Streaming Tool Responses

And let us recall a question I left in an earlier ramble:

Can we investigate why the Anthropic protocol supports alternating tool tokens and chat tokens, while OpenAI can only do tools first and chat afterward, yet prompt injection seems able to make it announce the tool it will execute?

Does it have the complete tool schema when it announces this? In which LLM call does that announcement happen?

This may not be precise enough. The scenario was this:

Once we added ToolCall to a desktop-companion setting, a ToolCall not only brought an extra LLM call, but often took a while to execute. The tool result then had to be sent back to the LLM for a reply. Perceptually, that added five or six seconds of response latency, and the model appeared unusually silent during it.

At the time, I added a policy-level prompt-injection plugin: pre_tool_preview.

It roughly tells the model: if you are about to execute a tool, verbally announce what you are going to do first.

Afterward, the model did indeed give short previews such as Let me take a screenshot and see what you are doing? and Let me look through your recent diary entries before doing things.

The overall effect was good. It softened the deathlike silence that had been there before.

Why Does My pre_tool_preview Work? What Are Its Limits?

I have partly forgotten the exact implementation and need to verify it again. I also need a token-level streaming token demonstration: how the tokens are ordered, whether the preview occurs before or after tool tokens, why it can preview, then execute, then answer, and how many LLM Tool Calls lie in between.

How many times can it preview? Does it support staged previews in a long tool-call chain?

If I migrate to Responses, will this feature carry over? Will Responses change the returned token stream?

My roommate also says Responses supports long connections. Is that true? Could it remove the first-token delay caused by handshakes in desktop-companion conversations?

And why did I once say Anthropic supports talking while working while OpenAI does not? What is different about their streaming token flows?

How Can an Agent Talk While Working in Engineering Terms?

We know that pre_tool_preview is probably only the most basic approach.

In engineering practice, some Agents support long ToolCall chains, such as Obsidian-yolo.

This seems to involve high-frequency ToolCalls and feedback. How are their prompts written? How do they get the model to support long chained exchanges? It appears to contradict my earliest understanding of chat_completion, because there seem to be no repeated handshakes in the middle.

When do repeated handshakes mostly happen?

Those are roughly the questions. Next, let us ask Teacher Fable or Teacher Opus. Please do not answer only from your own knowledge; many of these details need evidence. Ideally, use issues from the codex or newapi repositories and documentation from Anthropic and OpenAI.

Why codex-cli Removed Chat Completions

Why did codex-cli remove chat_completion?

I had always used it without issue. Codex-cli directly removed support for the protocol, and the benefit looked substantial.

Codex itself is open source. This question requires not only comparing the protocols, but more importantly tracking community issues, discussions, and pull requests—as well as related issues and PRs in the newapi community.

I need to understand the full process from beginning to end. Why was the decision made? Was it unilateral or community-driven? How much community support did it have?

:::note[Opus] Conclusion: this was a protocol shutdown with an announcement, a deprecation period, and a hard-removal PR. It was executed unilaterally, with zero community support. The stated reason was maintenance cost; the real reason was that Codex's new feature primitives only fit in Responses. Your “>0.95” is as precise as it gets—it was rust-v0.95.0.

Timeline

Date	Event
2025-12-09	Official deprecation announcement: codex#7782 (`etraut-openai`)
2025-12-11	Runtime warning added for `wire_api = "chat"`: codex#7897
2026-02-03	Hard-removal PR: `chore: nuke chat/completions API`, codex#10157, 49 files, +268/−2931
2026-02-04	First release containing that commit: `rust-v0.95.0`

The compare API confirms that d2394a24...rust-v0.95.0 is ahead, while ...rust-v0.94.0 is diverged. 0.94 could still use chat; starting with 0.95, it could not.

Unilateral or Community Decision?

The announcement's reaction distribution was 👎 85 / 😕 10 / 🚀 2 / 👍 0, with 21 upvotes and 11 comments. It was categorized as General, not a poll, and had no selected answer. The wording was not consultative: “the Codex team is deprecating” and “Full removal is slated for early February 2026.” The removal PR had an empty body, zero review comments, and merged in five days. Afterwards, codex#31083 proposed restoring the option with a feature flag; it received zero reactions and no response.

Zero likes and eighty-five dislikes, and it proceeded anyway. But do not rush to criticize—the announcement's disclaimer explains everything:

The vast majority of Codex users are unaffected by this change. If you are using OpenAI-hosted models with a default Codex configuration, you are already using the responses API.

The people voting and the people paying are not the same group. Those eighty-five dislikes mostly came from local-model and third-party gateway users. The lesson for you is this: Codex being open source does not mean it promises protocol compatibility. “Upstream can unilaterally delete an entire protocol path at any time” should be a design assumption.

Official Reason vs. the Real Reason

The announcement cites maintenance cost:

the chat/completions API has increasingly hampered our ability to improve Codex... added complexity, introduced regressions, and increased support overhead.

But the harder reason is expressive power. Chat is message-centered—everything is forced into role, content, and tool_calls—while Responses is item-centered: an ordered list of parallel items, where reasoning, function_call, message, and web_search_call are independent, first-class entries. Later additions to Codex simply have nowhere to go in chat: agent_message (#33551), MCP tools with type: "namespace" (#23186), and encrypted task delegation (#34833).

The most candid evidence is the current WireApi enum: only one member remains. The configuration option survives, but it no longer represents a choice:

"WireApi": {
  "oneOf": [{ "enum": ["responses"], "type": "string" }]
}

The official migration documentation claims the following benefits—self-reported, without third-party reproduction: +3% on SWE-bench, 40%–80% better cache utilization, store: true preserving reasoning across turns, and optional encrypted reasoning. The cache point is important: Codex has the classic long-context, repeated-prefix workload, so a cache hit directly becomes money.

What Happened to new-api

(First, filter out noise: all those new-api PRs prefixed [codex] are maintainers using Codex to write code, not compatibility work.)

Category	Evidence
Cache passthrough broke	#3389 measured direct versus proxied calls: uncached input was 11.74x, cached input fell to only 9.16%, and output was only 43.87%; #3309 could not recognize cache fields in nonstandard positions.
New encrypted-reasoning errors	#3240: `invalid_encrypted_content`; channel affinity through `prompt_cache_key` was insufficient, and LiteLLM's `encrypted_content_affinity` was needed. Still open.
Lossy fallback channels	#5209 was the “support only arrived around May” change you remembered. But it drops MCP tools (#5938), `reasoning_content` (#6396), reasoning summaries (#6449), and `include_usage` (#6149).
Engineering debris	SSE without `Content-Type` (#6075), zstd decompression (#6313), OOM (#5698), channel affinity blocking failover (#4541), and private endpoint `/v1/alpha/search` (#6114).

Two important points. First, encrypted reasoning makes load balancing stateful: the context now contains an owned, non-movable blob, which did not exist in the chat era. Second, and more importantly for you:

Fallback channels lose exactly the reasoning and tool metadata you want to observe in later token flows. Before demonstrating streaming tokens, verify whether you are using a native Responses upstream or newapi's fallback channel. Otherwise, the alternation you see is gateway-translated, not the model's actual output.

Most of these issues remain open. It is not that newapi is not trying; /v1/responses has a surface area an order of magnitude larger than /v1/chat/completions: state, encryption, item ordering, lifecycle events, and private endpoints all need reimplementation.

One-Sentence Version

Officially, legacy support slows development; in the code, only Responses can contain the new features; commercially, affected users are not paying customers. Three statements, one irreversible action. For XnneHangLab, the question is not whether to migrate: the gateway has already migrated half of it for you, and it loses exactly the information you most want to investigate while translating. :::

A Summary and Another Complaint About OpenAI

Okay, then this part is clear.

OpenAI simply did not want to maintain two sets of logic in Codex (chat_completion and responses), so it unilaterally removed the chat interface for more agile development and faster iteration. It cut off the people who do not directly pay OpenAI—the users of third-party model providers—and was criticized by the community for a long time.

But it also seems internally contradictory. It removed chat_completion, then recently merged the ChatGPT and Codex clients into an architecture like Claude Desktop.

Earlier, we discussed [[Learning from Bad Architecture: What Claude Desktop's Five Scheduling Systems Reveal About Separating Cowork and Code]]. This architecture makes maintenance costs rise geometrically; separate maintenance is much better than merging everything together. Recently, during host adaptation for memU, both Claude Desktop and Codex Desktop showed terrible adaptability because of the strange sandboxes and low shell permissions of their Cowork and Chat modes.

The first move looks like a pursuit of technical cleanliness, and the next turns the architecture into a pile of mess. (Perhaps the code is not all maintained in the official Codex repository; maybe the core is maintained separately, like Claude Code, with the desktop client separate.)

It is probably all driven by commercialization, yet I do not understand the pursuit or the decisions.

OpenAI is always like this: it likes doing two things at once instead of doing one thing well. While updating GPT models, it splits off codex models, then o1, o2, and o3; later it throws away Codex and focuses only on GPT. The naming is also chaotic, as if it names things whenever it feels like it. Versions 5.1, 5.2, 5.3, and 5.4 update at a frantic pace, but after all of that most people felt 5.2 was best. 5.4 speaks like a machine and has high information redundancy; it is messy enough that an ADHD reader can finish a long paragraph without absorbing a sentence.

Claude, by contrast, has consistently pursued mathematics, coding, and logic. Its naming and iteration are rigorous and romantic, drawn from Greek mythology. And when a name changes, it is a real major update—for example, Fable.

At present, GPT has only 5.6 sol and terra that I find usable. Below 5.6, there is confusion, disorder, and a lack of trust.

I do not understand OpenAI. I do not understand how it can play such a strong hand so badly. I do not understand Codex either. Perhaps its own employees do not, which is why everyone recommends connecting 5.6 to Claude Code for the best experience XD.

What to Watch: There Is No Migration Value Yet, Only Migration Risk

What we care about more is the value of migrating.

But it appears newapi's native Responses support and translation are currently poor, with much technical debt. It only makes sure replies can get through without error; almost none of the real features are preserved. Instead, quite a few things are stripped away.

Most people currently cannot reach a true Responses API. In other words, continuing to use chat_completion is best for us. newapi's support for it has matured for more than three years; there is no need to gamble on switching to responses.

What Is the Real Difference Between responses and chat_completion?

Earlier, Responses seemed to support things like store=true, which could hit caches across turns and preserve reasoning. Is the main optimization point only better cache hits, or is there more?

:::note[Opus] Far more. And caching is not “a feature”; it is a byproduct of the other changes. Reversing that causal relationship makes it impossible to see what this protocol transition actually changed.

A Table That Covers It

Dimension	Chat Completions	Responses
Endpoint	`/v1/chat/completions`	`/v1/responses`
Input	`messages` array	`input` (string or Item array) plus top-level `instructions`
Output	`choices[0].message.content`	`output`: an ordered array of typed Items, each with its own `id`
Tool definitions	Nested `{type:"function", function:{name,...}}`	Flat `{type:"function", name:...}`
Tool results	Put back into `messages`	Separate Items, linked by `call_id`
strict	Off by default	On by default; use `strict:false` only for incompatibility
Structured output	`response_format`	`text.format`
Built-in tools	None	`web_search` / `file_search` / `tool_search` / `code_interpreter` / remote MCP
Multi-turn	Manually resend all `messages` each turn	`previous_response_id` or a `conversation` object
State	None	`store` (stored for 30 days by default; can be disabled)
reasoning	Discarded	Native `reasoning` Items, including `encrypted_content`
Streaming	Opaque `delta` chunks	Semantic events: `response.output_item.added` / `response.output_text.delta` / `response.completed`…
Async	None	`background: true` plus polling
Resume after disconnect	None	`starting_after` cursor (SDK support “coming soon”)

Only Four Points Really Matter

1. output is a typed Item array—the root of every other difference.

In chat, the result of a turn must be flattened into the three slots role, content, and tool_calls. In Responses, it is a sequence of peer entries, each with an ID and lifecycle. The earlier agent_message, namespace tools, and encrypted task delegation do not fit in chat for this exact reason.

2. Hosted tools run on the server, and a single request can call tools continuously.

The documentation says the model “automatically decides whether to use a configured tool,” and “Some advanced workflows can also load more tool definitions during the interaction” (tool_search, GPT-5.4+ only). This directly answers the later question of why a long ToolCall chain can appear not to involve repeated handshakes: for built-in tools, it does not, because control never returns to the client. Your own function tools must still return to the client, and that distinction is crucial.

3. Reasoning Items survive across turns; cache gains are a side effect.

For stateless calls, the documentation requires you to “preserve every item in the response's output array.” Why can cache utilization improve by 40%–80%? Not because a cache was added, but because the prefix becomes stable: chat manually rebuilds messages every turn and loses reasoning, so the prefix changes constantly; Responses continues with previous_response_id and preserves reasoning as-is, making the prefix a chain that only grows. The +3% SWE-bench score follows for the same reason: reasoning is no longer cut off, not because of caching.

4. Streaming changes from a black box to a white box.

Chat SSE is just a sequence of deltas, so you must infer whether a segment is text or tool arguments. Responses events include a type: output_item.added explicitly tells you a new reasoning, message, or function_call Item has begun. The token-level demonstration you want is directly readable in Responses; in chat, it must be inferred. This may be more valuable to your later questions than caching is.

But the Conclusion Does Not Change

I would not revise the earlier recommendation: do not migrate yet. What you can actually use from those four points depends on the middle hop, and newapi's fallback channel loses reasoning Items and tool metadata (#6396 / #6449 / #5938). You would spend effort migrating only to receive a Responses shell translated back into chat semantics, with none of the four benefits intact.

What is worth recording is the condition that should trigger migration, not migration itself: when you can reach a native Responses upstream without fallback translation, point 4 (semantic streaming) and point 2 (server-side tool chains) become what your desktop companion actually needs. Cache is the least compelling reason to migrate. :::

Complaining Again

I think I understand.

It turns the very strange data structure of choices[0].message.content into a white box that looks like something Pydantic can validate. It also replaces the many type unknown errors I used to get while writing streaming code with native support.

When I first encountered the OpenAI library, I wondered how a PyPI package used by so many people could be full of pyright errors and require so many type:ignores. Its type enforcement was a complete mess. Looking at only a short code fragment, you often could not know what it returned because every possible kind of content was wrapped in the shell of content.

How can such a large company design data structures so carelessly?

When I supported FastMCP, the biggest obstacle came from OpenAI's chat_completion. Its ToolCall handling was exhausting to read. Later, I removed FastMCP entirely, and it felt wonderful.

But is responses really designed well? Is its data structure actually cleanly validated? I do not believe it. I have too much distrust of OpenAI. Its past roughness, unreasonableness, and chaotic disorder make it feel like an amateur troupe.

The Difference Between Anthropic Messages and the Chat Completion Tool Stream Used by My Desktop Companion

The Confusion Around Talking While Working

I need an answer to the question above.

Why did Claude once tell me that only Anthropic Messages could truly meet my desktop companion's need to talk while working, while OpenAI could only execute all tools and reply afterward? In practice, after injecting the pre_tool_preview plugin, I saw it give a preview before executing a tool.

I have forgotten the implementation details and may need to confirm them: XnneHangLab.

:::note[Opus] That earlier statement was half right and half wrong. Anthropic does natively talk while working, but OpenAI is not “unable to do it”—it is “unable to express multiple segments.” Your plugin did not break through the protocol; it used a field combination the protocol already permits but models do not normally choose.

Anthropic: Talking While Working Is the Default in the Official Example

The official streaming documentation gives this tool-use example verbatim:

content_block_start  index:0  {"type":"text"}
content_block_delta  index:0  "Okay" "," " let" "'s" " check" " the" " weather" ...
content_block_stop   index:0
content_block_start  index:1  {"type":"tool_use","name":"get_weather"}
content_block_delta  index:1  {"type":"input_json_delta","partial_json":"{\"location\":"}
content_block_stop   index:1
message_delta                 {"stop_reason":"tool_use"}

The model itself says “Okay, let me check the weather in San Francisco” first, then emits tool_use—without prompt injection. What you gained through a plugin is the first documented example on Anthropic's side.

Its content is also an ordered array of blocks, where index is the final array position. The web-search example is even more extreme: text(0) → server_tool_use(1) → tool_result(2) → text(3) → …, continuing to index:17. Text and tools genuinely alternate in multiple segments within one message.

OpenAI: It Can Speak Once, but Cannot Express Multiple Segments

An assistant message in chat completions has content—a single string—and a tool_calls array as two parallel fields. Therefore:

One preview plus a batch of tool calls is completely valid. Your plugin working is not a hack.
Speak → work → speak → work cannot be expressed. There is only one content string, with nowhere to place a second segment.

There is a subtler point: ordering information is lost when the message is saved back. During streaming, you really receive delta.content before delta.tool_calls—autoregressive generation means generation order is arrival order. But once assembled, it becomes two parallel fields. In the next turn, the model sees {content: "Let me take a screenshot", tool_calls: [...]}. The structure itself no longer says “I spoke first, then acted”; it can only infer that semantically. Anthropic's index preserves it structurally.

Your Implementation: Confirmed from the Repository

Question	Answer
Where is the injection?	`type = "policy"`, `injection_position = "before_tools"`, `priority = 10`. It goes through `PolicyPlugin.get_prompt_segments()` → `SystemPromptBuilder.build()`, into the system prompt before tool definitions.
When is it injected?	Once when creating the agent through `AgentFactory.create_core_with_profile()`, not as a hook every turn.
Does the preview have the full tool schema?	Yes. The prompt is in the system prompt, while tools are passed in full through `stream_with_tools(tools=tools_schema)` in the same API request.
Which LLM call makes the preview?	The same call that decides to call the tool, not an extra call. Preview tokens and tool_call tokens come from the same completion.
Are preview tokens before or after tool tokens?	Before. In the `core.py` loop, `delta.content` arrives first, accumulates into `text_buf`, and is yielded directly to the user; `delta.tool_calls` arrives later and accumulates in `tool_calls_buf`.
How many previews can it make?	One per round because there is only one `content`. With `max_rounds = 6`, it can make up to six segments.
Are staged previews in a long chain supported?	Yes, at one segment per round, not multiple segments within a single round.

The key assembly code is exactly the “one message carrying both a preview and tool_calls” combination:

assistant_payload = {
    "role": "assistant",
    "content": text_buf or None,   # ← preview text goes here
    "tool_calls": [...],
}

So you were already using a valid combination allowed by the protocol. Models simply do not do it by default; your prompt calls that behavior forth.

Where “OpenAI Cannot” Is Wrong and Right

	Anthropic Messages	OpenAI Chat Completions
Speak once, then act, within one round	✅ Native default	✅ Possible, but needs prompt guidance
Multiple segments within one round	✅ (server-tool example reaches index 17)	❌ Only one `content`
Ordering preserved structurally	✅ `index`	❌ Two parallel fields
Staged previews across rounds	✅	✅ (your six rounds)

The right part: Anthropic is native behavior and supports multiple segments within a round; OpenAI has neither. The wrong part: “OpenAI can only execute all tools and reply afterward.” No: one spoken preview per round is protocol-legal, and your plugin proves it.

The real gap is small in client-tool scenarios. When Anthropic encounters a client tool, it also ends with stop_reason: "tool_use", returns to the client, and produces one segment per round. The source of true multiple alternations is server tools: tools run on the server, control never returns to the client, and one message can proceed text → tool → result → text. Chat completions has no server tools, so it can never do this. That is exactly the gap Responses fills. :::

The Limits of pre_tool_preview Under the OpenAI Protocol

Okay, I remember. That is indeed how it worked. Multiple segments cannot be expressed: after one preview at the beginning, it gets to work in silence, and if a second tool is needed it cannot preview again.

For example, this is legal:

Let me read the recent diary.
Tool Call: Read Diary
Tool Result: {...}
I found ...

But this cannot be done:

Let me read the recent diary.
Tool Call: Read Diary
Tool Result: {Diary Folder is empty}
The Diary seems empty; let me check recent memories.
Tool Call: Read Memory
Tool Result: {...}
I found...

Instead, it becomes:

Let me read the recent diary.
Tool Call: Read Diary
Tool Result: {Diary Folder is empty}
Tool Call: Read Memory
Tool Result: {...}
I found there seems to be no diary, ...

That means users lose awareness after the first preview. If the tool chain becomes extremely long, we cannot perceive what it is doing midway through.

Additional Questions

I want to understand two things.

Do Anthropic Messages and OpenAI both strictly alternate in sequence? In other words, will no ToolCall token be sent before all preview message tokens are complete?
Why does the OpenAI protocol not support alternation? Is this a limitation of model output? Do most models have it, or is the protocol simply badly designed?

:::note[Opus] a: Yes. Both are strictly serial; “alternation” was the wrong word from the start. b: This is purely a protocol problem, not a model limitation—and the evidence is in OpenAI's own SDK types. Also, the behavior in your example may be caused by your prompt rather than the protocol; see the final section.

a. Both Are Strictly Serial; There Is No Token-Level Interleaving

Anthropic: the official streaming documentation defines the flow strictly:

A series of content blocks, each of which has a content_block_start, one or more content_block_delta events, and a content_block_stop event.

That means block 0 must finish with content_block_stop before block 1 can start with content_block_start. In the official example, the final text_delta from “Okay, let's check the weather...” arrives, then content_block_stop index:0, and only then does content_block_start index:1 begin the tool_use. There is no mixing of text_delta(0) and input_json_delta(1) in the stream.

OpenAI is similarly autoregressive: delta.content arrives first, followed by delta.tool_calls, also in sequence.

So the accurate statement is: both providers concatenate [text-token segment][tool-token segment] in sequence; the difference is only how many segments can be joined.

	Shapes it can join
Anthropic	`[text][tool][text][tool]…` (the server-tool example reaches `index:17`)
OpenAI chat	`[text][tool]`—only this one pair

“Alternation” should be renamed “segmentation.” What your original question meant by “alternating tool tokens and chat tokens” was segmentation ability, not mixed token streaming. Neither provider does the latter, and neither should; a client cannot render a half-sentence with an inserted tool call.

b. It Is the Protocol, Not the Model—the Proof Is in OpenAI's Own Type Definitions

Evidence one: the same model can create multiple segments when the protocol changes. gpt-5.x under Responses can legally produce an output array like message → function_call → message → function_call; the same model under chat completions cannot. The model is unchanged, and capability changes with the protocol. That alone excludes model-output limitations.

Evidence two: the asymmetry in openai-python is obvious.

# Output (what the model sends you) — chat_completion_message.py
class ChatCompletionMessage(BaseModel):
    content: Optional[str] = None          # ← one string

# Input (what you send back) — chat_completion_assistant_message_param.py
ContentArrayOfContentPart: TypeAlias = Union[
    ChatCompletionContentPartTextParam,
    ChatCompletionContentPartRefusalParam,  # ← only text and refusal
]
content: Union[str, Iterable[ContentArrayOfContentPart], None]

Two things are true at once:

Assistant content can already be an array on the input side, while output remains a string. The array shape exists in the protocol but was never extended to model output.
Even that array contains only text and refusal, not a tool_call part. So even manually constructing it cannot represent an ordered “text → tool → text” sequence; tool_calls always remains another parallel field.

That is the root problem: it is not that no array exists, but that the array has no tools. The protocol contains nowhere that can preserve ordering information.

Evidence three: chat completions is the odd one out among major providers. Gemini's Content.parts is also a mixed array, and its documentation explicitly warns:

the model may return a mix of functionCall, toolCall, and toolResponse parts in a single turn. Don't assume the functionCall will always be the last item in the parts array.

That is effectively saying that text can occur after a functionCall. Anthropic has ordered blocks; Gemini has ordered parts; Responses has ordered items. Only chat completions uses two parallel fields.

Is It Really “Garbage Design”?

Not garbage, but unreconstructed historical baggage. content: str made perfect sense in the GPT-3.5 era, when a turn could only produce text. When function calling was added in 2023, adding a parallel tool_calls field was backward compatible; changing content from a string to an ordered array was not. It would have broken every client that read choices[0].message.content.

That locked it in. Multimodal input later received an array because it was a new field and new shape, while output remained a string forever. This is why Responses required a new endpoint rather than adding parameters to chat completions: the change could not be compatible, so the protocol had to change. It also explains why Codex had to remove support rather than softly preserving it.

Finally: Your Example May Be Your Own Prompt's Fault

You said users lose awareness after the first preview. But across rounds, the multiple-segment restriction does not apply. The second assistant message has its own content field and can legally preview again:

round 1: {content: "Let me read the diary.", tool_calls: [read_diary]}
round 2: {content: "The diary is empty; I will check memory.", tool_calls: [read_memory]}   ← fully legal
round 3: {content: "I found…"}

Why did this not happen? Look at rule five of your own pre_tool_preview injection:

“If this is the first tool call in the current round, and the user can perceive the wait, prioritize this upfront explanation.”

The phrase “first tool call in the current round” may have been interpreted by the model as “only preview once in a user turn.” The behavior you observed strongly matches that prompt.

Try a control experiment first: change it to “Before every tool call, give an upfront explanation; if it repeats the previous one, use different wording.” Then see whether a second preview appears. If it does, your long-chain silence came from the prompt, not the protocol—a vastly easier problem to fix.

(And a correction to the previous section: saying “once per round, up to six segments” was correct; max_rounds = 6 gives you six-segment budget. What actually consumed one segment and then stopped was likely this prompt rule.) :::

Damn!

Oh, I finally understand. I could see only one preview all this time because of my own prompt!

And in a tool loop, each OpenAI protocol tool-call segment is independent and can carry a preview message?

This matters greatly to me. My later engineering goal is to eliminate silence in long tool chains for the desktop companion. I had planned to break one tool chain into multiple steps, but now it seems I may not need to!

Is that right?

So I only need to improve the prompt and add some guardrails? I do not need a complicated implementation?

:::note[Opus] The overall direction is right, but do not celebrate yet—three points need calibration, and the second one is my responsibility.

Correction One: It Is “One per Round,” Not “One per Tool”

These two lines in your core.py explain it:

max_rounds = 6                                    # 503
*(_exec_tool(tc, ...) for tc in ordered_tool_calls)   # 606, parallel execution

In one round—one LLM call—the model can emit N tool_calls, which you execute in parallel. That round has only one content field, so N tools share one preview.

The precise statement is: a preview has the granularity of “one per LLM call,” not “one per tool.”

For one-to-one previews, pass parallel_tool_calls: false to the API; it is a standard chat-completions parameter and openai-python types it. But that trades latency for awareness. If three tools each take five seconds, parallel execution takes five seconds while serial execution takes fifteen. Usually that is not worth it: one preview saying “I will check the diary and memory at the same time” is enough.

Correction Two: My Diagnosis Was a Hypothesis, Not a Conclusion

In the previous section, I said the prompt might be at fault. That was a high-confidence inference from reading the code, but I did not run your agent. Do not treat it as a verified fact—run the control experiment first.

And even after changing the prompt, there is a second obstacle: after getting a tool_result, models themselves tend to jump straight into the next tool call. How malleable that behavior is depends on the model. The ones you use on the desktop companion—DeepSeek and Grok-like models—may be more stubborn than frontier models.

So set realistic expectations: improving the prompt will probably help substantially, but may not consistently produce a preview every round. Prepare for partial success rather than treating one edit as a complete solution.

Correction Three: Previews Do Not Remove Silence During Tool Execution

This is easiest to overlook. A preview covers the instant from the LLM deciding to call a tool until the tool starts, not the three to five seconds while the tool runs.

The real result is therefore:

Before: [say one thing] ────30 seconds of silence──── [answer]
After:  [say one thing]─5s silence─[say one thing]─5s silence─[say one thing]─5s silence─[answer]

It splits one long silence into several shorter silences; it does not remove silence. The perceived improvement is huge, but a tool that itself takes ten seconds remains silent for ten seconds. Only UI-level progress feedback—such as a spinner or “Reading…”—can cover that; the protocol cannot.

Do You Still Need to Split It into Steps?

If the goal is only to remove silence, no. Your original plan to break it down would use engineering to imitate a capability the protocol already has.

But notice one hard limit: max_rounds = 6. Once a chain exceeds six rounds, your own system truncates it. If you want long tool chains to remain perceptible, raise this number first; no matter how good previews are, the current budget is only six segments.

A Concrete Prompt Shape

Do not only write “preview before calling.” Make each round's sentence both close the previous step and preview the next. That is the form you actually want:

Before every tool call, say one sentence. If this is not the first tool call in the current round, that sentence must do two things: use half a sentence to state the previous result, then explain the next action. Do not repeat the previous wording.

The output becomes the ideal form you described:

Let me read the recent diary.                  ← preview only
[Read Diary] → empty
The diary is empty; I will check memory.       ← closure + preview
[Read Memory] → ...
I found...                                     ← closure

This is more natural than previewing every step and uses fewer tokens: users receive a coherent narrative rather than six repeated “Let me check…” lines. :::

Real and Fake “Talking While Working”

I understand now, but I do not understand what advantage Claude has beyond this.

If both are strictly serial, then they seem no different. Can you explain what truly counts as talking while working (Anthropic), and what is fake talking while working (OpenAI)?

From my perspective, reaching the form above already feels complete.

:::note[Opus] First, correct a framing error: the boundary between real and fake is not Anthropic versus OpenAI, but server tools versus client tools. By that line, your desktop-companion scenario cannot reach the “real” tier under either provider, so the answer is bad news for you—but it saves you a migration.

Fake: Segmented Speech, With a Full Round Trip per Segment

The multiple segments in chat completions are stitched together by a client-side loop:

HTTP request 1 ──> [preview] [tool_calls]        ← connection ends; control returns to you
   You execute the tool locally
HTTP request 2 ──> [closure + preview] [tool_calls]   ← resend full history; new TTFT
   You execute the tool locally
HTTP request 3 ──> [final answer]

The user sees a coherent narrative, but underneath are three requests, three full-context submissions, and three time-to-first-token delays. It is “segmented speech,” not “talking while working”: between each segment, the model has actually stopped working.

Real: Speak, Work, Speak in One Stream, Without Returning Control to the Client

Anthropic server tools (web_search / code_execution / MCP connector) execute on Anthropic's servers. The official streaming web-search example looks like this:

content_block_start index:0   text          "I'll check the current weather in NYC for you."
content_block_start index:1   server_tool_use   web_search
content_block_start index:2   web_search_tool_result   ← server executes and inserts result directly
content_block_start index:3   text          "Here's the current weather..."
...
content_block_stop  index:17
message_stop                                  ← one HTTP request from start to finish

One request, one SSE stream, seventeen blocks. Control never returns to the client. This is the literal meaning of “talking while working”: the work happens while it speaks, without a break in the middle.

The Honest Part: Anthropic Client Tools Are Fake Too

If you define your own get_weather tool for Anthropic, it still ends with stop_reason: "tool_use", still returns to the client, and still requires another request. It is exactly the same as OpenAI.

The correct dividing line is therefore:

	Multiple segments in one request	Requires a client loop
Anthropic server tools	✅ Real	❌
OpenAI Responses server tools	✅ Real	❌
Anthropic client tools	❌ Fake	✅
OpenAI chat completions (client tools only)	❌ Fake	✅

Notice the second row. Responses also has server tools (web_search / code_interpreter / remote MCP), so it can do the real version too. This has never been “Claude is stronger”; chat completions is simply the only one of the four without a door into that capability.

What This Means for Your Desktop Companion

Your tools are screenshots, diary reading, and memory reading—all of them must execute on the local machine. They are permanently client tools.

Therefore, you cannot reach the real tier by switching to Anthropic or Responses. It is not that protocols withhold it; the tools physically run on a user's computer, so control must return there.

What advantages remain for Anthropic over chat completions? Only two:

Better default behavior—models speak before acting without requiring pre_tool_preview.
Text-tool ordering is structural within a round through index, rather than relying on the convention that content precedes tool_calls.

Neither is worth migrating for. You already solve the first with prompting; in your own client, the second has no material advantage over a convention and guarantee.

A More Precise Meaning of “Handshake”

You have worried about “repeated handshakes causing first-token latency.” But multi-round exchanges do not normally redo TCP/TLS handshakes: openai-python uses a shared httpx client and reuses keep-alive connections.

The actual cost of each round is:

Resubmitting full context (token cost, mostly offset by prompt caching)
Server-side prefill again (also mostly offset by caching)
TTFT, time to first token—this really exists every round and cannot be removed by caching

So a six-round tool chain's latency mostly comes from 6 × TTFT + 6 × tool execution time, not six handshakes. Whether your roommate's claim that “Responses long connections can remove first-token delay” holds is a separate question. For now, remember: you want to reduce TTFT, not handshakes. :::

Okay, just as I expected, the two are not really different. Reaching that form is already the limit if the connection is not kept open.

Okay, one big confusion gone, one point of clarity gained.

Learning from Bad Architecture: What Claude Desktop's Five Scheduling Systems Reveal About Separating Cowork and Code

Thu, 23 Jul 2026 00:00:00 GMT

:::note I have a peculiar habit: whenever I encounter something that confuses me, I want to figure it out—at least far enough to resolve the confusion.

That was how Claude Desktop's complicated scheduling systems drew me in. After taking them apart, however, I found an architectural mess riddled with legacy problems and code continually wedged in through successive iterations. The rest of this article explains why.

Why did I persist after realizing halfway through just how twisted the implementation was? Because good architecture is not the only kind worth studying. In fact, it can be harder to understand precisely what makes good architecture good. Bad architecture is different: its problems are apparent at a glance. The ancients learned from history; we can learn from a mess.

This is an architecture worth knowing how to avoid. Someone else has already stepped into the traps for us. I certainly will not split the underlying agent system into divergent implementations merely to accommodate different scenarios, because that leads directly to maintaining several parallel systems—effectively multiplying the effort required to maintain a single project. I would rather spin the other scenario into a new project than force both into the same one. :::

Why I Call It an Architectural Mess

First, consider Claude Desktop's three modes: chat, cowork, and code.

What concerns us here is the architectural redundancy, not the elegance of the code itself. The project is not open source, after all.

Taken separately, both cowork and code are excellent. I have used each of them extensively.

There is not much to say about chat. Many tools and shell permissions have been stripped away; it is simply chat.

code feels as though it shares a core with Claude Code. It has essentially the same tools and slash commands as Claude Code, its logic is very similar, and even its prompts seem consistent.

cowork is where the architectural mess begins. Rather than sharing the same Agent system as code, it appears to have built another independent one. Much of the underlying tool and memory machinery may be shared, but the two also diverge substantially. Cowork, for example, does not expose the range of allow permissions available in Code. It has shell access, but never with the same comfort as Code's ability to grant full access; some capabilities also seem to have been removed. For reasons I cannot explain, its shell execution is simply slower than Code's as well.

I used Cowork frequently while working on my graduation project—for surveys, presentations, and editing Word documents. With the right skills configured, it is an excellent workbench. But creating that workbench also required sacrificing or cutting down many Code features and prompts, allowing the two implementations to drift apart.

The particular mess examined here, however, comes from the scheduling systems—or rather, from the deeply counterintuitive architecture revealed by those systems.

As discussed above, Cowork and Code were built as two Agent systems, so they also require at least two scheduling systems.

Because Claude Desktop tries to support both local and cloud execution, that number becomes at least four. Code mode also has /loop, which creates session-scoped scheduled tasks that disappear when the session ends.

Strictly speaking, then, a single Claude Desktop contains five scheduling systems. They cannot communicate across Cowork and Code; each maintains its own tasks. The Code side calls them Routines, while the Cowork side calls them Scheduled Tasks. Code creates a local Routine by default, whereas Cowork creates a Cloud Scheduled Task by default. Both are created with a tool named create_scheduled_task, yet the same tool produces different results.

Code also has /schedule, which lets users choose between a local and cloud Routine. Cowork has no equivalent /schedule command. A conversation cannot create a Local Scheduled Task there; users can only change a cloud task to Run on your computer through the GUI.

The result is a code vs cowork divide full of legacy problems, mismatched features, mismatched documentation, and awkward usage.

This investigation certainly resolved my confusion—by leading me all the way into the architectural mess.

Background

#538 established that bridging requires a standalone CLI with headless authentication. That raises a natural follow-up question: Could we avoid installing the CLI and run bridging through Claude Desktop's native scheduled tasks instead? In theory, running inside an already authenticated app might bypass both symptoms described in #538.

To answer that question, I tested the behavior locally on Windows 11 with Claude Desktop 2.1.181 and compared it against the official documentation. This issue records the survey and its conclusion so that the route does not have to be evaluated again later.

The conclusion first: Do not use Desktop's native scheduling. Keep the claude_code adapter targeted exclusively at the Claude Code CLI plus the operating system scheduler.

The Complete Picture of Claude's Five Native Scheduling Systems

This comparison draws on four sets of documentation: scheduled tasks, Desktop scheduled tasks, Routines, and Cowork support.

System	Created from	Runs on	Can access local files	Can read all session logs
Cloud Routine (UI: New routine → Cloud)	CLI, Desktop, or claude.ai	Anthropic cloud, with a fresh clone each time	No	No
Local Routine (UI: New routine → Local; Code mode tool: `create_scheduled_task`)	Desktop only: choose Local on the Routines page, or use the tool in a Code session	Local machine; runs only while the app is open	Yes	Yes
Session-scoped tasks	CLI `/loop`	Local machine, tied to the session	Yes	Yes, but they disappear with the session
Cloud Cowork Scheduled Tasks (UI: Home → Scheduled → New task; Cowork mode tool: `create_scheduled_task`)	Cowork session or the Scheduled section on Home	Anthropic cloud sandbox	Conditional, bridged only while the app is online	Unreliable
Local Cowork Scheduled Tasks (UI: Home → Scheduled → New task → `Run on your computer`; cannot be reproduced through `create_scheduled_task`)	Cowork session or the Scheduled section on Home	Local machine; runs only while the app is open	Yes	Yes

One additional detail deserves attention. When a Claude Desktop conversation uses the built-in create_scheduled_task tool in Code mode, it creates a Local Routine by default. That Routine silently binds its cwd to the working directory of the session in which it was created. If the directory is later deleted, the task loses the directory it expects to activate when it runs and begins to fail.

In Cowork mode, create_scheduled_task creates a Cloud Scheduled Task by default. It can be manually changed to Run on your computer, turning it into a local scheduled task, but this operation is difficult to reproduce conversationally—or rather, Cowork explicitly refuses to do so. Even if I ask it to create ten more scheduled tasks, every one still runs in the cloud. No tool allows Cowork to create a local Scheduled Task directly. It even suggests using cron on macOS or Linux, or offers to help write an equivalent for Windows. Run on your computer is accessible only through the GUI and must be configured manually. It is a Beta feature and presumably has not yet been exposed through a tool.

There is also a gap in the official documentation worth pointing out. The Routines documentation defines Routines as scheduled systems that run only in the Anthropic cloud, while the Desktop scheduled tasks documentation calls the local variant a Desktop scheduled task. Yet the latter describes a UI flow that says, “click New routine and choose Local.” The terminology in the Desktop UI is therefore misaligned. The documentation itself has not been fully synchronized and its naming has drifted. In Desktop, both kinds of task can be manually switched between local and cloud execution through the UI, but neither system appears to offer a complete, reliable built-in mechanism for triggering that migration through conversation.

Testing the Entry-Point Routing: `/schedule` and `create_scheduled_task`, Same Names but Different Backends

Three findings from direct testing—all verified through persisted files or transcripts rather than paraphrased from documentation:

create_scheduled_task creates a local task in a Code session, as verified by the persisted SKILL.md, but creates a cloud task in a Cowork session, which describes itself as something that “spins up a fresh session in a cloud sandbox, so your computer doesn't need to be on.” The same tool name routes to two opposing backends.
There are two /schedule entry points. Typing /schedule in a Desktop Code session invokes a skill from the anthropic-skills plugin, persisted under %APPDATA%\Claude\local-agent-mode-sessions\skills-plugin\.... Its instructions end with “Finally, call the create_scheduled_task tool,” which produces a local task. In the CLI documentation, however, /schedule creates a cloud Routine. Direct testing also found /schedule only in Code sessions; Cowork and ordinary Chat sessions do not expose it.
Ordinary Chat sessions expose neither mechanism. Chat is not a scheduling surface.

Code's Local Tasks vs Cowork's Scheduled Tasks: The Two Users Are Most Likely to Confuse

Dimension	Local Routine created in a Code session	Cowork Scheduled Task
Execution environment	Local machine, inside the Desktop app process	Anthropic cloud sandbox
App or machine shut down	Does not run; on wake, catches up only the most recent occurrence within a seven-day window	Continues running
Local files	Full access (`cwd` is only the starting point, not a sandbox)	Conditional bridging while the app is online; no formal documentation
Access to all `~/.claude/projects` sessions	Yes	Unreliable
Authentication	Inherits the app login; no CLI or token required	Managed in the cloud
Local representation	Two persisted layers: `SKILL.md` plus a registry	None; there is nothing that can be “moved to local”

At first glance, a Local Routine seems perfect for hosting the memu-cli scheduling system.

But Routines have a fatal flaw: when a scheduled task is created, its cwd is automatically bound to the project directory of the creating session. If that project folder is deleted, the Routine loses its working directory and fails. Although it can access the complete collection of sessions, it was designed only for work inside a Project.

Another uncontrollable factor is that we cannot predict whether users will install memu-cli from Cowork or Code. In Cowork, moreover, we cannot reliably change a Routine to Run on your computer through conversation.

Why We Are Not Splitting the `claude_code` Adapter into Separate CLI and Desktop Implementations

A local Desktop Scheduled Task is tempting in isolation: the app is already authenticated and can read every session. As a registration target for an installer, however, direct testing exposed too many problems in its mechanism:

The detection criterion is unstable. Identically named tools and commands route to opposite backends on different surfaces, so an Agent cannot determine its environment from the name alone. The only reliable criterion is to create a task and then check whether a SKILL.md file was persisted, making installation logic complicated and brittle.
The entry point is extremely narrow. Local tasks can be created only from a Desktop Code session. The terminal CLI has no entry point. Manually placing a SKILL.md file creates an orphan: testing showed that a complete memu-bridging/SKILL.md outside the registry is never scheduled. Editing the registry manually at %APPDATA%\Claude\claude-code-sessions\...\scheduled-tasks.json creates a dead letter: in testing, the edit survived for seven minutes before the app's in-memory copy overwrote the entire entry at the next scheduling tick. The installer has no registration path outside a session.
The cwd binding is hidden. Every task in the registry silently captures a cwd equal to the working directory of the session that created it. The tool exposes no parameter for it and no way to update it. Behavior after that directory is deleted is undocumented and remains unresolved in testing.
The mechanism is still rolling out, and the documentation itself has gaps. Documentation and direct testing diverge—for example, Cowork support documentation says /schedule exists, while testing found that it does not. The documentation, UI, and tools use three mutually contradictory naming schemes. Surface semantics drift between versions, making this unsuitable as a third-party installation target.
The benefit is not exclusive. Transcripts from Desktop Code sessions and the CLI are stored under the same ~/.claude/projects directory. A bridging pipeline built on the CLI plus the operating system scheduler naturally covers data created by Desktop users, so avoiding Desktop's native scheduling loses nothing.

The choice is between maintaining one implementation—the CLI plus cron, launchd, or Task Scheduler, with one task name and three verification gates—and maintaining two, one of which rests on naming collisions, three storage layers, and a hidden cwd. We choose the former. This also matches the pattern used by the other adapters: Codex, OpenClaw, and WorkBuddy use their host's scheduler because those schedulers are stable APIs. Claude Desktop's is not. Scheduled Tasks are still marked Beta and may change at any time.

Trade-off (Explicitly Accepted)

If a user has only Claude Desktop and not the Claude Code CLI, installing memU requires two additional steps:

Install the standalone CLI with one command: irm https://claude.ai/install.ps1 | iex, winget install Anthropic.ClaudeCode, or npm install -g @anthropic-ai/claude-code. The MSIX bundle included with Desktop does not count because it is not on PATH and is not visible to a bare process.
Configure headless authentication using claude setup-token to obtain CLAUDE_CODE_OAUTH_TOKEN, or set ANTHROPIC_API_KEY. The Desktop login is not visible to the CLI; see #538.

For users who already have the CLI, a verification gate decides whether setup is needed: if claude -p 'ping' succeeds in a bare shell, skip these steps; otherwise, guide the user through setup-token.

If Desktop's native scheduling later becomes stable and fully documented—particularly if the same-name split is removed and an out-of-session registration path is provided—we can reconsider it as an optional optimization for Desktop users. Even then, the criterion must be persistence verified on disk, not the tool name.

#538: bridging requires a standalone claude executable on PATH that supports headless authentication (execution-layer fix)
#539: the bridging guide lacks a Windows Task Scheduler path (execution-layer fix)
#514 (closed; the starting point of this series)

I will add a link after publishing the detailed testing notes on the three storage layers, the A/B comparison, the registry-overwrite timeline, and measurements of scheduling ticks.

RRF vs. Hybrid Search: How Should Time-Based Retrieval Be Blended, and How Does It Fit Project and Companion Scenarios?

Tue, 21 Jul 2026 00:00:00 GMT

:::note This continues the discussion in [[MoeChat: How AI Characters Remember You and Feel Emotions]].

At the time, we thought the time-based retrieval proposed by MoeChat was interesting and could be internalized into our own memory framework. This article analyzes a concrete approach and fills in some NLP knowledge along the way. :::

Plain-Language Summary

This is the quick version. If you prefer my usual question-and-answer style, skip this section. We will discuss more there.

There is too little space in this article for my own conclusions, so I will summarize plainly. If you are short on time, this section is enough.

Hybrid Search specifically means combining keyword matching with semantic-similarity matching. It usually combines their scores through weighted fusion, and that weight is a manually chosen value rather than something computed automatically.

RRF is a ranking-fusion method. It cares only about rank, not score. RRF can also fuse Hybrid Search results, but there is a problem: it does not care about the actual scores. From RRF's perspective, first place beating second by 150 points and first place beating second by 2 points make no difference.

It is like this:

queue_1 = ["docs2", "docs1","docs3","docs4"]
queue_2 = ["docs3", "docs2", "docs1","docs4"]

rrf_index = ["docs2", "docs3", "docs1", "docs4"]

It is a way of ranking that intuition alone can understand. The algorithm matters less.

Another question is whether time retrieval should become a third route.

Here, we answer no.

If it became three parallel routes, we would have to introduce RRF as the fusion ranking.

That brings many problems. Scores become indices, and we lose the actual sense of distance between documents.

Also, RRF always introduces a systemic bias from the third, time-based route. If the query is time-related, it over-elevates time-related resources. If the query is not time-related, it always introduces noise because the time route always has an RRF rank. One route may not feel significant, but it is still harmful. Imagine ten or twenty routes, with only two or three active each time: the noise brought in by RRF would hide the information that truly matters.

In the end, we considered a gate plus a decay term. As for the specific decay and how to reduce total latency in the concrete chain, we will only know after implementing the ADR in wikimem.

We also discuss some less concrete things here.

Memory structures, diary formats—you do not need to care about those. Even I do not care now. It was only a process of clarifying frameworks and application boundaries, and of sorting out companion and project scenarios once more. Maybe I will never read it again, because it will become my project's structure. If I need to refine it later, I will return here, draw out new questions, and discuss them again. That is all. I enjoy the process of moving from chaotic confusion to unified clarity; for me, the process of recording matters more than the recorded conclusion.

I Know Little, but Have Many Questions

In [[MoeChat: How AI Characters Remember You and Feel Emotions]], we promised to learn a little about concrete designs for multi-route hybrid retrieval.

What I know now is limited to a few names: Hybrid Search and RRF ranking fusion. I know Hybrid Search combines keyword matching and semantic similarity. I know that when fusing scores, comparable weighted scores must be normalized, which is complicated, while RRF only cares about rank and is simple and forceful. It suits methods whose scores cannot be combined.

But I wonder whether Hybrid Search and RRF differ fundamentally. More precisely, Hybrid Search generally seems not to choose RRF for fusion. Why not? What performance loss or disastrous effects would forcing RRF onto Hybrid Search bring? Would originally interpretable semantic scores be forced into indices? What would that cause?

Then we will look at adding time beyond semantics and vectors, as we considered in MoeChat. But because time is a ranking problem without a concrete score, it seems we could only use RRF.

We will also discuss whether directly fusing three routes with RRF is preferable to using time as a gate.

Forcing time into Hybrid Search creates problems. For example, if a time window contains many memory records and the user only asks Do you remember what I usually ate for lunch last week?, the topic is narrow.

If we force the three routes together, after retrieving the time range we must run Hybrid Search again. Otherwise, there is too much memory. Even one evening's memories cannot all be stuffed into context, much less an entire week.

But running Hybrid Search again reveals structural redundancy: one Hybrid Search across all time and one Hybrid Search across a selected time range. In MoeChat, does it directly recall all diary content in a time range with no second filter? This needs confirmation. Is it because LTM contains too little content for a second filter to be necessary, or is there another idea?

:::note[Korewaxnne] Confirmed, looking back at the breakdown in [[MoeChat: How AI Characters Remember You and Feel Emotions]]:

MoeChat's LTM retrieval is pure gating with no second-stage selection. The concrete process is:

A user message first goes through jioNLP to extract time expressions such as “yesterday” and “last Friday,” then parse them into a timestamp range.
A binary search over sorted timestamps using bisect_left/bisect_right locates every memory in that range in O(log n).
Optional: if enableLongMemorySearchEnhance is enabled, cosine similarity filters once using a 0.32 threshold, but this is only filtering, not an independent semantic-retrieval route.
If the user message contains no time expression, LTM does not participate at all and the function returns empty.

So your guess was right: it recalls all memories inside the time window without a second Hybrid Search. The reason is also what you thought—the LTM writes fact-like JSONL entries by day, with only a few entries per day, so one entire day fits into context. It does not avoid a second Hybrid Search because of some design philosophy; the data volume is simply small enough that it does not need one. :::

A better derivation, then, is to make time a gate: only when the user strongly activates a specific time should it define a broad time range, and then Hybrid Search runs within that range. But this also creates a problem: Hybrid Search cannot work independently, and time processing might take a while because it is still unclear whether time reasoning should depend on an LLM.

Perhaps this must begin from purpose. For MoeChat, the original purpose of LTM and time retrieval is simple: to let the model answer concrete questions such as “What did I eat the night before last?” In its application setting, LTM writes fact-like records, which suit this kind of retrieval, and there are not many of them.

In my desktop-companion scenario, I would directly use three-route hybrid retrieval, with simple RRF fusion—not for a sophisticated reason, but so time retrieval can work independently like MoeChat's. And I have a simple mind; RRF suits my taste.

Hybrid Search and RRF: Choosing a Two-Route Fusion Method

The relationship between Hybrid Search and RRF

Does Hybrid Search have a particular relationship to RRF? Is it as I understand it: Hybrid Search can choose either RRF or weighted fusion as its method?

:::note[Korewaxnne] Yes, exactly that relationship.

Hybrid Search is a strategy: “I use keyword search and semantic search at the same time, then combine the results.”

RRF is one fusion method: “How do I combine the two result sets?”

So Hybrid Search needs to choose a fusion method. There are two common ones:

Weighted Score Fusion: normalize both route scores, then calculate a weighted sum. For example, 0.7 × semantic score + 0.3 × keyword score. You can tune the weight and explain why a result came first.
RRF (Reciprocal Rank Fusion): ignore scores and use only rank. The formula is 1/(k + rank), then adds reciprocal ranks from each route. It is simple and forceful, and needs no normalization.

As an analogy: Hybrid Search is “I want to travel to my destination,” while RRF and weighted fusion are “take the bus or a taxi.” Both get you there, with different trade-offs. :::

Wait, are those weighted-fusion weights not calculated automatically? Are they set manually?

:::note[Korewaxnne] They are set manually, not calculated automatically.

Weights in weighted fusion—semantic 0.7 and keywords 0.3, for example—are hyperparameters, like a learning rate. You choose them and tune them through experiments.

The usual approach is to take annotated queries plus expected results, run different weight combinations, see which produces the best retrieval metrics such as nDCG or MRR, then use that one. There is no gradient descent optimizing the value behind the scenes.

This is also an advantage of RRF: it requires no weight tuning. You can use it immediately. Weighted fusion needs an evaluation set to tune reliable weights; without one, you can only guess by feel. :::

Why would it not use RRF? If RRF is forcibly applied to Hybrid Search, what performance loss or disastrous impact follows? What if interpretable semantic scores are forced into indices?

:::note[Korewaxnne] Hybrid Search can use RRF, but in most scenarios it is not worthwhile because it throws away score information for no reason.

Keyword search through BM25 and semantic search through cosine similarity both assign every result a concrete score. Those scores matter: the gap between cosine 0.95 and 0.60 conveys far more than “first versus second.”

If you use RRF, you throw away every score and retain only rank. Specifically, you lose:

Score-gap information. In RRF, semantic first place at 0.95 and second at 0.94 is exactly the same as first at 0.95 and second at 0.30: both are “first versus second.” But in the latter case, second place is not relevant at all.
The ability to tune weights. With weighted fusion, you can say “semantics contributes 70%, keywords 30%” and tune by scenario. RRF cannot offer that granularity of control.
Explainability. Under weighted fusion, you can say “this was ranked first because its semantic score was 0.92 and its keyword score was 0.85.” Under RRF, you can only say “its combined ranks were highest.”

The conclusion is simple: when both routes have scores, weighted fusion is better because it retains more information. RRF's natural setting is one where a route has no comparable scores, such as a time dimension, which has ordering but no relevance score. :::

RRF does indeed ignore score and gap information. But it feels clean for inputs that have no scores themselves.

You can read memU ADR, especially ADR 0006, 0007, and 0008. Our retrieve is already implemented, though reading the source is the same.

Later it unexpectedly updated 9, 10, and 11 as well. That is not your responsibility; I will follow up later in [[What Is memU? Let's Break It Down (An Ongoing Series)|What Is memU? Let's Break It Down]].

:::note[Korewaxnne] memU uses weighted score fusion with min-max normalization, not RRF.

According to ADR-0007: cosine embedding scores and BM25 keyword scores are each min-max normalized, then fused into one ranking. This is the classic weighted-score-fusion route.

But the source code currently runs vector-only cosine similarity; the BM25 route has not been implemented yet, so hybrid search remains at the design stage. :::

Adding a Time Dimension: The Challenges and Trade-Offs of Three-Route Retrieval

Now let us consider a harder problem.

If I add MoeChat-style time as a third route, it disrupts ADR 0007's established score fusion and seems to force RRF.

We can analyze this by application scenario, beginning simply with project scenarios and long-term companion desktop-companion scenarios.

Let us analyze three methods:

Run all three routes in parallel and fuse everything with RRF.
Run all three routes in parallel and do two things at once: RRF plus the original weighted fusion. If the time rank and other route ranks differ enough under RRF, use time directly; otherwise, ignore time and output the original result.
Treat time as a gating unit. Time defines the candidate-memory range, then Hybrid Search runs normally within it.

This feels difficult, so I will ask Teacher Fable. Teacher Fable, please analyze a better approach too if one exists.

:::note[Fable] The conclusion first: c is the main path, but it lacks half a piece; b can be discarded directly; and the “time working independently” that a wants is actually a degenerate case of c, so there is no need to retain three-way voting.

See the problem clearly first: time is not the same kind of signal as the other two routes

Semantic and keyword scores answer “is this memory about this subject?” That is relevance, which can be voted on. Time answers “is this memory inside the range being asked about?” That is a constraint. A memory outside “the night before last” is not “somewhat irrelevant”; it is wrong. Constraints should filter, not vote.

There is another subtler asymmetry. BM25 and vector candidate lists are conditioned on the query: if content does not match, it has no score and cannot enter the list, so these routes quiet down by themselves when the query is irrelevant. Time is different: every memory has a timestamp, so the time route can always produce a complete ranking no matter what the query asks. A voter that always has a vote in RRF creates systemic bias.

That bias should not exist. So simple all-RRF is wrong: it both loses the precision and gap information of concrete scores and permanently introduces noise.

a. All three routes through RRF—not disastrous, but needlessly imprecise

There are two problems:

For queries without time intent, such as “What anime do I like most?”, the time route degrades into a pure recency vote, elevating new but irrelevant memories. In project scenarios that is pure loss; in companion scenarios it barely counts as a freshness preference, at the cost of precision for every query.
For queries with time intent, such as “What did I eat the night before last?”, the time route must first parse “the night before last” into a range before it can rank by closeness to the target. In other words, a does not eliminate time parsing; you need the parser anyway. Once you have a range, voting is a detour: voting cannot guarantee the winner lies in the range. A memorable dinner from three weeks ago may semantically overwhelm an ordinary dinner from the night before last, and RRF cannot stop it. Answering “what I ate the night before last” incorrectly is a factual failure and the kind that damages trust most in a desktop companion.

A very good correction. If we have already obtained the range, it should not enter the voting electorate at all.

b. Dual fusion plus divergence trigger—discard directly

The trigger condition measures the wrong thing. Large differences between time ranking and semantic ranking are not a signal but the norm: novelty and relevance are naturally unrelated, so the lists almost always differ. That trigger either stays open or detects nothing. Evidence for whether time should be used lives in the query—words such as “last week” and “the day before yesterday”—not in divergence between result lists. Inferring query intent from result divergence uses the wrong sensor for the right decision.

It also requires maintaining two fusion methods plus a divergence threshold that is harder to tune than fusion weights. The original reason for choosing RRF was to avoid tuning parameters; b gives that benefit back.

This path not only looks awkward but introduces a very difficult hyperparameter: when exactly is the gap too large? That would make the system weak.

c. Time gating—the direction is right, and both concerns have answers

In engineering terms, c is standard metadata pre-filtering in a vector database: WHERE ts BETWEEN .... ADR 0007's fusion formula does not need a single change; it simply runs on a filtered candidate set. Your two earlier concerns have solutions:

“Does time parsing need an LLM, and will it be slow?” A desktop companion already runs an LLM each turn. Make retrieval a tool call and have the model produce time_range as an argument along the way, making parse cost effectively free. Common expressions—yesterday, the day before yesterday, last week, a date—can take a regex fast path. Expressions the regex cannot handle, such as “the day we last argued,” can only be handled by an LLM anyway: that is event anchoring, requiring retrieval of that event, its date, and then a window around it. This natural two-hop gate is not expressible as voting.
“Under a gate, time cannot work independently.” A pure time query, such as “What happened the night before last?”, becomes: gate out the range plus an empty semantic query, then degrade into taking the top N memories in the range by time. That is MoeChat's behavior. As you observed, it is just gating; there was never a three-route fusion waiting to be copied. MoeChat can recall an entire section because its LTM is small. Your memory is larger, so Hybrid Search still runs inside the range—and that is exactly c.

Add one fallback and it is complete: when a parsed window retrieves nothing, automatically broaden it by ±1 day or use fuzzy boundaries, so one parsing mistake does not become “I do not remember.”

But c lacks half a piece: time has two roles

Time does two different jobs in retrieval:

Explicit time references, such as “the night before last” or “last week at noon,” are hard filters—gates—as described above.
Implicit freshness preference, when the user mentions no time but what was discussed yesterday should surface more readily than something from three months ago. This does not need a third route. Add a small weighted time-decay term to the existing score fusion, for example $e^{-\Delta t/\tau}$. It has a score, can be normalized, and can be tuned, so it is fully compatible with ADR 0007's score fusion without changing to RRF.

The final shape is: gate for role 1, decay for role 2, and the unchanged two-route weighted fusion. The concept of a “third route” disappears completely. Time is never really a retrieval route because it cannot answer what a memory is about; it can only constrain a range or apply a small preference. RRF remains useful, but its proper setting is several genuine rankers with incomparable scores. Time is not a ranker, so it does not belong here.

Closing by scenario

Project scenarios: even the gate can be simpler. Time in project memory is often really version: “what is the latest decision?” is solved by replacement relations at write time plus a recency tiebreak at read time, not by time retrieval. And the caller is already an agent; when a time query really occurs, let it pass an optional time_range parameter. Do not perform intent detection inside the memory system when the query-understanding caller already did it.

Desktop-companion scenarios: time is a first-class concern, with one lethal detail: contextual memory contains many semantically near-duplicate events—you ate lunch fifty times, and fifty memories are nearly identical semantically. The only thing that distinguishes the lunch on last Wednesday is time. The more near duplicates there are, the less reliable a soft preference or vote becomes, and the more necessary a hard constraint is. “What do I usually eat for lunch during the week?” runs cleanly through c: window equals last week, query equals lunch, top-k inside the window, then the LLM summarizes the pattern.

Method	Project scenario	Desktop-companion scenario
a. Three-route RRF	✗ Recency pollution; pure loss	△ It runs, but “the night before last” questions are unreliable
b. Dual fusion plus trigger	✗ The trigger measures the wrong thing	✗ Same
c. Gating	✓ Can simplify to an optional filter parameter	✓ Main path
c plus decay	✓ A recency tiebreak is enough	✓✓ Recommended form

One-sentence version: explicit time filters, implicit time decays, and time is never a third route. :::

Design Implementation: Time Fast Paths and Memory Structure

:::note[For readers passing by] Up to the scenario table above, these are general conclusions worth taking away. What follows is a design workshop for our own projects, wikimem and XnneHangLab. It needs the context of [[MoeChat: How AI Characters Remember You and Feel Emotions]]; if you do not know that, skipping the second half loses no general knowledge. :::

But I still hope the fast path for time retrieval can always activate and work independently, with intent recognition made into a tool call.

This involves quite a lot. You can look at:

::github{repo="XnneHangLab/wikimem"}

::github{repo="XnneHangLab/XnneHangLab"}

Time fast path: regex and intent recognition as parallel tracks

I think wikimem should own a MoeChat-like fast time-retrieval path:

:::note Several alternatives:

dateparser supports more than 200 languages, including Chinese. It is rule-based and lightweight: pip install dateparser, then dateparser.parse("昨天下午") returns a datetime directly. It needs no jioNLP NER step; it works in one step.
arrow plus handwritten regex: if time-expression patterns are enumerable—“yesterday,” “the day before yesterday,” “last week X,” “X days ago”—regex matching plus arrow's shift() can calculate offsets. A dozen lines can cover MoeChat's scenario with zero dependency overhead.
TimeNLP is a small library dedicated to Chinese time semantics, much lighter than jioNLP and focused only on time.

The most pragmatic choice is actually the second one. MoeChat needs to recognize only a dozen or so patterns—yesterday, the day before yesterday, last week X, X days ago, X month X day. Regex plus time-offset calculations are enough; it does not need a general NLP library. :::

This was the plan we came up with last time.

I think wikimem should have a fast path like MoeChat's. Intent recognition and time analysis for expressions that a simple regex cannot hit could become a Tool Calling capability integrated into XnneHangLab. I do not want to mix responsibilities.

What does intent recognition add? It handles vague time expressions beyond a simple regex. I want us to focus on implementing the simple regex solution, then hand complex work to an intent-recognition tool call.

Memory structure: the boundary between diaries and wikis

There is also the question of memory structure. Along a timeline, MoeChat remembers only factual contextual memories, while preferences, personas, and so on are separate structures.

But as I wrote in [[MoeChat: How AI Characters Remember You and Feel Emotions]], LTM and CoreMemory have somewhat unclear boundaries. That makes it look uncomfortable.

memU's early six memory types also make memorize very heavy. What do you recommend?

How should we store our memories? As JSONL fact fragments, or lively Markdown diaries written by a model?

More accurately, how do we define memory? What belongs in memory that can be recalled by time? Should it include every memory?

Should we use fact-only diaries like MoeChat's only for time recall? But are records of a model's emotions then unimportant? Emotion creates personality. If there are only facts and no context, there is no soul.

And since our wikimem supports both embeddings and zero-embedding mode, we need to reserve embedding storage for every retrievable memory. The embedding needs what information—dimension, embedding-model name? If names differ, should it warn users and ask them to rebuild the whole memory database?

What belongs in SQLite, and what belongs in Markdown?

Should we replace MoeChat's JSONL with SQLite for higher performance, then build a front-end system in XnneHangLab to visualize memory data, so users can browse it by time and search it by content?

But perhaps wikimem itself should provide this because wikimem is a framework. At least it should avoid insisting on a CLI, like a yutto serve RPC redesign, and expose data interfaces so other applications can wrap it. The transport protocol also needs planning.

At the same time, the Markdown diary system needs management too.

Dividing Responsibilities Between Framework and Application

Teacher Fable, please help. We may need to update the ADRs for wikimem and XnneHangLab. We need to decide what belongs to the framework and what belongs to the application.

:::note[Fable] I read both repositories: wikimem's current state, XnneHangLab's ADR-0001 through ADR-0003, and the wikimem plugin. First the general principle, then the parts.

You have already drawn the boundary

ADR-0001 has a hard constraint: “retrieve makes 0 LLM calls; memorize makes ≤ 1 asynchronous LLM call, initiated by the host.” Extending that rule gives the entire answer:

The framework handles deterministic mechanisms—rules, mathematics, and I/O. Anything requiring model judgment belongs to the application. Embeddings are the only exception, but they are injected as pluggable, optional, and gracefully degradable; wikimem's zero-core-dependency nature is worth preserving.

Use that line to divide every question below.

The time fast path belongs to wikimem, correctly

Design one parameter with two sources:

index.retrieve(query, time_range=None)

No time_range given: wikimem runs an internal regex fast path for yesterday, the day before yesterday, last week X, X days ago, and X month X day. Pure stdlib—re plus datetime—is enough. Do not introduce dateparser; a general library for “200+ languages” adds a dependency and violates the zero-dependency constraint. Arrow is unnecessary too; timedelta can do the calculation.
time_range given: use it directly and skip regex. This is the application-side outlet for an intent-recognition tool call. An LLM handles expressions such as “the day we last argued” that regex can never reach, including two-hop event-anchor queries, but it finally produces the same structured parameter.

The two paths converge on the same parameter, so responsibilities do not blur: regex is the framework's floor; the LLM is the application's ceiling; there is no third parser between them.

But fill one missing piece first: wikimem has no timeline yet

The code shows that wikimem has only a state layer—category/item wiki. It stores ts, but retrieval never uses it; there is no time filtering or decay. The earlier gating proposal has nothing to gate yet. The event-stream primitive is missing. So memory structure and time retrieval are the same problem.

Memory structure: two primitives and one boundary rule

Diary, the event stream: append-only, one file per day, time as the primary axis. This is a new primitive.
Wiki, the state layer: existing category/items, content as the primary axis, editable.

The boundary rule is one sentence: what happened goes in the diary; what is true now goes in the wiki. MoeChat's LTM and CoreMemory are unclear because they divide by “importance” or “permanence,” which are continuous and changing and cannot make a clean boundary. “Event versus state” is discrete: a memory either has the property “when did it happen?” or it does not. The same event can appear in both: “On July 21, he said he changed jobs and sounded excited” in the diary, while the work wiki entry updates as state. They do not conflict.

Do not copy memU's six memory types into the framework. Those are content strategies for the state layer and belong in extraction prompts; your categories are already free. The six types make memorize heavy because each gets a separate LLM run. ADR-0001's “≤ 1 call” has already avoided that pit.

Where emotions go: split them into two things

Emotions in events belong in the diary. A diary entry should be a lively short segment written by a model—scene, emotion, and facts together. Your diary_writing skill prompt already does this. That is where the “soul” lives. It also answers JSONL fragments versus lively Markdown: the diary should be lively Markdown and facts should go in the wiki. You need both, not one or the other.
Current emotional state, such as MoeChat's emotion_state.json valence/arousal model, is not memory. It changes every turn and does not need retrieval; it remains application runtime state.

What can be recalled by time? Only the diary. The wiki is not on a time axis. A future need such as “preferences added last week” can use ts as a filtering bonus, but it is not the main axis. Having every memory recalled by time is wrong: preferences should not be pulled out by “last week.”

Storage: the filename is the time index; do not use SQLite yet

Use a Markdown file per day for diaries—diary/2026-07-21.md, one ## HH:MM entry plus a timestamp comment. The easily overlooked benefit is that the filename itself is the time index. Gating a window means selecting files by date range, O(number of days), zero indexes and zero dependencies. MoeChat's daily JSONL proves this path. Then run existing BM25/fusion inside the window and the earlier c plan becomes complete.

SQLite's problem is not performance; it violates ADR-0001: “there can be no unreadable truth on disk.” Truth must be Markdown. SQLite can at most be a deletable derived cache, alongside vectors.npy. At the current scale—one desktop companion year is about ten to twenty thousand records—in-memory BM25 plus existing signature layers is milliseconds, so a cache is not needed. Truth is always Markdown; SQLite is neither truth nor a cache for now. Revisit at one hundred thousand entries, and then use an FTS5 derived cache. VectorIndex already leaves room as a Protocol.

Embedding metadata: a real gap, but a lighter fix than you expect

The current vectors.keys.jsonl header only stores the vectors file; it records neither model name nor dimension. Your concern is correct. Add {"model": ..., "dim": ...} to the header, then compare it to configuration when opening.

But a mismatch should not “error and make the user rebuild the whole memory database.” Wikimem's truth is Markdown, and vectors are only a content-hash-keyed derived cache. Changing the model means invalidating the cache and incrementally re-embedding as needed. There is no database to rebuild. Match existing philosophy: mismatch means a warning, degradation for the current session, and a prompt to run a re-embedding command. Zero-embedding mode is naturally the end of this degraded path.

And one correction: do not reserve an embedding slot on every memory record. Putting vectors into truth files would destroy readable truth. The existing derived-cache design is right; keep it.

serve and front end: the Python API is the contract; everything else is a shell

wikimem's contract is its Python API, MemoryStore and MemoryIndex. M4 should be a thin-shell layer: both a CLI and [serve]—HTTP plus JSON as an extra, similar to [embed]—are skins over the same API. Do not create a transport protocol; HTTP plus JSON and a version are enough. Serve is for out-of-process consumers: other applications and independent browsers.
XnneHangLab does not need wikimem's serve because it imports in-process already—milliseconds versus memU's two-second subprocess path. Visualization belongs on its own FastAPI/WebSocket routes.
The visualization UI belongs entirely to the application. The framework guarantees data access: list dates, read a day, search, tail the journal. Its file-first design gives a free benefit: Markdown truth means Obsidian or any editor already works as a memory browser. That is enough for debugging; do not build UI in the framework.

Put it into ADRs

wikimem currently has no ADR directory; framework decisions are all recorded in XnneHangLab ADRs. Since it is now an independent repository, its decisions should follow the framework. Also confirm whether packages/wikimem and the separate repository are the same code: the workspace appears to have cli.py while the separate repository does not. If they are two copies, they are already drifting.

(Postscript before release: I checked. It is not drift—the standalone repository checkout is merely four commits behind. The upstream already merged the zero-dependency CLI in wikimem#12, and both are the same codebase.)

Owner	ADRs to write
wikimem	Diary primitive: daily Markdown, append-only; retrieval gets `time_range` plus stdlib-only regex fast path; optional recency-decay term enters fusion; vector cache records model/dimension and degrades on mismatch; M4 redefines CLI/serve as two thin shells.
XnneHangLab	Time-intent-recognition tool call for vague time and event anchors to `time_range`; elevate `diary_writing` into a formal memorize policy—when to write, what to write, and its voice; keep emotion state as application runtime; memory-visualization front end through its own routes.

One-sentence version: the framework manages deterministic mechanisms; the application manages costly judgment; what happened goes in the diary, what is true now goes in the wiki; truth is always Markdown, and everything else is a deletable cache or replaceable shell. :::

Postscript

Thank you, Teacher Fable. While clarifying the relationship between RRF and Hybrid Search, it also made clear where wikimem should go and what XnneHangLab should own. I opened two PRs:

MoeChat: How AI Characters Remember You and Feel Emotions

Wed, 15 Jul 2026 00:00:00 GMT

:::note[AI Disclosure] This article was almost entirely written by Claude OPUS 4.6, with Xnne reviewing it. Want to read the human-written parts? Skip directly to the Q&A.

Honestly, though, Claude did a much better job than Xnne at the architecture breakdown 😅

And this is not the end—it is only the beginning. It gave me many ideas and can be treated as a TODO. The breakdown felt great. I had honestly been a little afraid of MoeChat; its code is genuinely messy, and I had tried reading it many times without getting through. But Claude suffered on my behalf. :::

What Is MoeChat?

::github{repo="AlfreScarlet/MoeChat"}

MoeChat is an open-source system for creating AI characters that can remember and feel.

Most chatbots are goldfish—they start from zero in every conversation. MoeChat is different. It gives every character:

Long-term memory—a diary system that extracts important content from every conversation, stores it, and automatically recalls it when relevant
Core memory—permanent facts about you, such as your name, preferences, and relationship
An emotion engine—based on a two-dimensional emotion model, valence plus arousal, with accumulated frustration, emotional-meltdown states, and even hormone-cycle simulation

It also supports voice—GPT-SoVITS for TTS and FunASR for ASR—but its real core is how it builds a persistent inner world for every character. This article is about that.

Character Agent: One Folder, One Life

Every character lives under data/agents/<name>/. Everything about them is stored in isolation there:

data/agents/Chat酱/
├── info.yaml              # personality, system prompt, every feature flag
├── memory/                # long-term memory: daily JSONL files
│   ├── 2025-7-10.jsonl
│   ├── 2025-7-11.jsonl
│   └── ...
├── core_mem.yml           # core memory: permanent facts about the user
├── data_base/             # knowledge base: world-building knowledge
├── emotion_state.json     # persisted emotional state
└── assets/                # avatar images

info.yaml lets you turn each feature on or off:

settings:
  writeLongMemory: true # write new memories after chatting
  enableLongMemory: true # retrieve memories while chatting
  enableLongMemorySearchEnhance: true # filter with vector similarity
  longMemoryThreshold: 0.32 # cosine-similarity threshold

  enableCoreMemory: false # extract user facts
  enableEmotionSystem: false # enable the emotion engine
  enableEmotionPersist: false # persist emotion across sessions

Notice that writeLongMemory and enableLongMemory are independent: you can write without reading, or read without writing.

What do the files look like?

info.yaml—the character's “identity card”:

name: Chat酱
user: 阁下 # how the character addresses you
birthday: '2022-03-17'
height: '160'
personality: 表面清纯可爱，实则腹黑毒舌，内心聪明机智...
description: Chat酱是存在于现代科技世界手机中的器灵...
customPrompt: 使用口语的文字风格进行对话，不要太啰嗦...
messageExamples: # examples of the character's speaking style
  - '人类视网膜的感光细胞不需要这种自杀式加班，您先休息一下吧。'
settings:
  writeLongMemory: true # write new memories after chatting
  enableLongMemory: true # retrieve memories while chatting
  enableCoreMemory: false # extract user facts
  enableEmotionSystem: false # enable the emotion engine
  longMemoryThreshold: 0.32
gsvSetting: # speech-synthesis settings
  textLang: zh
  gptModelPath: models/【萝莉】女仆_Ver-1.4-e15.ckpt
  sovitsModelPath: models/【萝莉】女仆_Ver-1.4_e24_s504.pth
  refAudioPath: models/tmp/020.wav
  promptText: 嗯，谢谢您的夸奖，主人可以喜欢就好。

memory/2025-7-10.jsonl—long-term memory, one entry per line and one file per day:

{"timestamp":1720627200,"text_tag":"去咖啡厅和朋友聚会","msg":"时间：2025-07-10 16:00:00\n{{user}}：今天下午和朋友去了星巴克，点了一杯拿铁\n{{char}}：听起来很惬意呢，阁下喝拿铁的话一般加糖吗？","vector":[0.0312,-0.0891,0.0456,...]}
{"timestamp":1720630800,"text_tag":"讨论周末旅行计划","msg":"时间：2025-07-10 17:00:00\n{{user}}：周末想去杭州西湖玩\n{{char}}：西湖这个季节荷花应该开了呢，阁下要不要带把伞防晒？","vector":[0.0178,-0.0623,0.0891,...]}

text_tag: the summary extracted by LLM2, used for vector retrieval
msg: the complete conversation, injected into LLM context when recalled
vector: a persisted 768-dimensional BGE embedding, so it need not be recomputed on startup

core_mem.yml—core memory, permanent facts about the user:

# 核心记忆文件，请勿自行修改！否侧会丢失索引！

aB3kX9mZwQ:
  time: '2025-07-01 14:30:00'
  text: 第一次相遇

pL8nR2vYcD:
  time: '2025-07-05 20:15:30'
  text: 用户今年25岁，是一名程序员

qM4wT7hNjF:
  time: '2025-07-08 19:22:10'
  text: 用户喜欢喝冰美式，不喜欢甜食

xK9sG3bPmW:
  time: '2025-07-12 21:05:45'
  text: 用户养了一只叫"团子"的橘猫

Every memory has a short UUID as its key.
text is a user fact extracted from conversation by LLM2.
Everything loads into a FAISS index at startup for top-5 similarity search.

emotion_state.json—an emotional-state snapshot:

{
  "valence": -0.25,
  "arousal": 0.41,
  "character_state": "正常",
  "latent_emotions": {
    "frustration": 3.8
  },
  "meltdown_start_time": null,
  "cycle_day": 18,
  "cycle_length": 28,
  "last_cycle_update_timestamp": "2025-07-15T00:00:00"
}

Current state: slightly unhappy, with valence = -0.25 and medium arousal
Frustration is accumulating—3.8 against a 10.0 threshold—but has not reached meltdown
Day 18 of the hormone cycle, the luteal phase, when mood is relatively stable
When enableEmotionPersist is off, this file is not generated and every restart resets it

System Timeline: What Happens in One Conversation

Below is the full pipeline from “you send a message” to “a memory is stored.” This is the real core.

</div>

The key design is that retrieval is synchronous—memory is needed before a reply is generated—while storage is asynchronous—after a reply streams out, memory is extracted and saved in the background.

Deep Dive: Long-Term Memory, the Diary System

How memory is written

After an LLM reply is complete, a background thread calls add_memory1(). The concrete process is as follows.

Step 1: LLM2 summarizes the conversation into a tag.

A separate LLM, configured as LLM2 in config.yaml, receives the user's final message and an instruction like this simplified version:

“You are a daily-information extraction assistant. Extract the main activity from the user's conversation and generate a short-sentence summary suitable for vector retrieval. Record what they did, where they went, and what they ate. Do not record emotion or reflections—only concrete events. If it is only casual conversation, output ‘日常闲聊’.”

If LLM2 returns “日常闲聊,” the memory is discarded. Only meaningful events are stored.

Step 2: Build a memory entry.

m_data = {
    "timestamp": 1720627200,                    # Unix seconds
    "text_tag": "去咖啡厅和朋友聚会",              # LLM2 summary, used for retrieval
    "msg": "时间：2025-07-10 16:00:00\n{{user}}：今天和朋友...\n{{char}}：听起来...",
    "vector": [0.123, -0.456, ...]              # 768-dimensional BGE embedding of text_tag
}

Step 3: Append it to a daily JSONL file.

It is saved to memory/2025-7-10.jsonl: one JSON object per line, one file per day.

How memory is retrieved

When you send a new message, get_memories() tries to find relevant past memories.

Path A: time-based queries, if your message mentions time

The system uses jionlp, a Chinese NLP library, to detect time expressions:

“昨天” → parsed into a timestamp range
“上周五” → parsed into a timestamp range
“两天前” → parsed into a timestamp range

It then performs a binary search—bisect_left/bisect_right—over a sorted timestamp array to find every memory in the range. This is why retrieval takes about 80 ms: it does not need to scan.

If enableLongMemorySearchEnhance is enabled, it further filters your message through cosine similarity using longMemoryThreshold, 0.32 by default.

Path B: no detected time reference

If your message mentions no time, the function returns early. It does not retrieve through the long-term-memory path. Core memory and the knowledge base still work normally through FAISS similarity search.

Storage format

memory/
├── 2025-7-10.jsonl    ← one memory entry per line
├── 2025-7-11.jsonl
└── 2025-7-12.jsonl

Every line is a compact JSON object:

{"timestamp":1720627200,"text_tag":"去咖啡厅和朋友聚会","msg":"时间：...","vector":[...]}

text_tag is what gets embedded and searched—the key to retrieval
msg is the full formatted text injected into LLM context when a memory is recalled
vector is persisted, so it does not need recomputation on startup

Core memory vs. long-term memory

	Core memory	Long-term memory
Stores	User facts: name, age, preferences	Daily events and activities
Extraction	LLM2 plus structured JSON prompt	LLM2 plus free-form summary
Storage format	YAML, one file	JSONL, split by day
Index type	FAISS IndexFlatIP, in memory	Binary search over sorted timestamps
Retrieval	Top-5 similarity search, always runs	Time range plus optional similarity filter
Threshold	0.31, hardcoded	0.32, configurable
Casual chat	Still extracts, may contain facts	Discarded through the “日常闲聊” filter

Deep Dive: The Emotion Engine

Model: the 2D Russell circumplex model plus frustration

MoeChat uses a two-dimensional emotion model plus a hidden accumulated-frustration counter:

</div>

Plus a hidden dimension: frustration, which accumulates and triggers meltdown at a threshold.

Valence [-1.0, 1.0]: how good or bad the character feels
Arousal [0.0, 1.0]: energy or intensity
Frustration [0.0, ...]: a hidden counter that grows from negative interaction

How emotions update in every conversation turn

For every user message, the engine follows these steps.

1. Call an LLM for sentiment analysis.

A specialized LLM call using the SLM configuration analyzes the user message:

{
  "sentiment": "positive", // positive | negative | neutral
  "intensity": 3.5, // 1.0 - 5.0
  "intention": "genuine_praise", // labels such as harsh_insult, playful_teasing
  "arousal_impact": 2.0 // -5.0: calming to +5.0: exciting
}

2. Calculate the acceptance ratio.

How much emotional impact actually lands depends on the character's current state:

acceptance_ratio = sigmoid(e * (impact_strength - resistance))
resistance = |当前效价| * 惯性因子

When a character is already in a strong emotional state—high absolute valence—it resists change more. This is emotional inertia: one kind remark cannot make someone deeply sad immediately happy.

3. Update valence.

final_delta = potential_delta * acceptance_ratio
new_valence = clamp(old_valence + final_delta, -1.0, 1.0)

4. Update arousal using a permission factor.

Changes in arousal are suppressed by how extreme the current arousal already is:

permission_factor = (1 - |arousal - 0.5|)^1.5

This creates an inverted-U curve: arousal changes easily near the middle, 0.5, but resists change at extremes, 0.0 or 1.0. You cannot make someone already manic even more manic.

5. Apply a pull toward equilibrium.

A constant “gravity” pulls emotion back toward neutral. Its strength depends on the hormone-cycle phase, if enabled.

6. Accumulate frustration.

frustration *= 0.95                    # natural decay every turn
frustration += impact * mood_bonus     # negative messages add frustration

mood_bonus is crucial: when the character is already sad, negative messages hit harder. This creates a spiral: once sad, it becomes increasingly easy to push the character toward meltdown.

Three states

</div>

Normal: standard emotion processing using all the mathematical calculations above
Meltdown: triggered when frustration exceeds a threshold, 10.0 by default. The character ignores user input. Emotion decays over time: decay = 1000 / (x^2 + 1000). It lasts 90 minutes by default
Recovering: linearly interpolates back to neutral over ten minutes

How emotions affect a character's reply

After calculating a new valence/arousal pair, the engine generates an emotion instruction and injects it into the system prompt. It maps the 2D space into nine behavioral states:

Valence	Arousal	State	Behavior
> 0.6	> 0.7	Ecstatic	Extremely enthusiastic; accepts all requests
> 0.6	< 0.7	Deep joy	Warm, gentle, inclined to agree
0.2~0.6	> 0.4	Happy	Friendly, optimistic, open to most requests
0.2~0.6	< 0.4	Calm	Peaceful, warm, stable
-0.2~-0.5	> 0.4	Irritable	Tense, impatient, selectively refuses
-0.2~-0.5	< 0.4	Indifferent	Flat tone, low energy, may refuse
< -0.8	> 0.7	Furious	Sharp tone, directly refuses
< -0.8	< 0.7	Deeply sad	Says very little—“嗯”, “…”, “随便”—and refuses effortful requests
Other	Other	Neutral	Normal and balanced

This instruction is prepended before your message and sent to the LLM, so the model adjusts its tone and willingness to cooperate accordingly.

Hormone cycle, optional

When enabled, a 28-day cycle adjusts the character's emotional responsiveness:

Days	Phase	Emotional stability	Sensitivity
1-5	Menstrual	Medium, 1.3	Slightly high, 1.1
6-12	Follicular	Stable, 1.5	Normal, 1.0
13-15	Ovulatory	Most stable, 1.8	Normal, 1.0
16-21	Luteal	Stable, 1.5	Normal, 1.0
22-28	Premenstrual, PMS	Least stable, 0.8	High, 1.4

The premenstrual phase has low inertia, so emotion shifts easily, plus high sensitivity, which increases the impact of negative messages by 40%. Ovulation has high inertia, so moods are stable.

Emotion persistence

If enableEmotionPersist is on, the full state saves to emotion_state.json:

{
  "valence": 0.35,
  "arousal": 0.62,
  "character_state": "正常",
  "latent_emotions": { "frustration": 5.2 },
  "meltdown_start_time": null,
  "cycle_day": 12,
  "cycle_length": 28,
  "last_cycle_update_timestamp": "2025-07-15T00:00:00"
}

Without persistence, the character resets to neutral—(0, 0)—on every server restart.

Quick Start, for People Who Only Want to Try It

git clone https://github.com/AlfreScarlet/MoeChat.git
cd MoeChat
uv sync
cp config.example.yaml config.yaml
# Edit config.yaml: set LLM.key and LLM2.key
uv run main_web.py
# Open http://localhost:8000/

The minimum config.yaml:

LLM:
  api: https://api.siliconflow.cn/v1/chat/completions
  key: '你的密钥'
  model: Qwen/Qwen3-8B

LLM2: # required for memory extraction
  api: https://api.siliconflow.cn/v1/chat/completions
  key: '你的密钥'
  model: Qwen/Qwen3-8B

Without LLM2, a character can chat but never builds new memories.

Q&A

Some rambling first

Before beginning, let us ramble a little.

My connection with MoeChat really begins with [[Attention Is Limited — Lost in the Middle]].

I actually gave MoeChat's author an incorrect view, and I never had a chance to correct it. I feel a little guilty about that.

Honestly, when MoeChat was released, my understanding of memory was vague. MoeChat gave me an inexplicable favorable impression, but I kept reading it intermittently and never formed a complete picture. Now we have a chance, so let us take it apart.

What makes MoeChat good as a companion system?

First, MoeChat is the only memory system I have seen so far that is sensitive to a timeline. It has strong recall for explicit points in a user query—昨天, 前天, 上个月, and 上周X—because it supports time queries.

For time extraction, I remember it uses JioNLP to map a semantic time point into a concrete time string, then directly recall a MemoryItem from long-term memory. But the implementation feels awkward, heavy, and uncomfortable; it can be optimized.

Second, the author has a very clear sense of RAG's boundaries: retrieval by relevance. She uses RAG for the world book, a knowledge base about the world, and core memory, facts that occurred with the user. Those two really suit RAG. Long-term memory, by contrast, is recalled only by time, without deliberately mixing RAG in. This is an unusually lucid point in my view. It was also the foundation for her criticizing many long-term-memory systems in comments as merely putting all memory content into RAG with no novelty, and for calling hers the strongest memory system on Bilibili. She was extraordinarily clear-minded, at least more than I was then. The only optimization I can see is replacing pure-vector FAISS with BM25 plus embeddings through Hybrid Search. I cannot pick apart her present architecture; instead, I would align mine with it.

Third is the anthropomorphic emotion system that the author put enormous effort into. She seriously studied emotion models. It involves psychology; although I can say I have broad interests, when the author brings this out, I can only say my capacity for action is far inferior to hers. This emotion model and its effects deserve a separate article: should a model always say yes, or can it also say no? What effect does that have? Is being refused unacceptable for users, or can it preserve novelty and stir a desire to win? We will not expand that now. Let us focus on the memory system.

Digging into jioNLP time-semantic extraction

Claude, please fill in the concrete implementation and feasible optimizations. We just mentioned that this method makes me uncomfortable, but I need you to explain what it actually does.

:::note[Claude] Concrete implementation: in utils/long_mem.py, get_memories() follows this process:

It first prefixes the user message with [时间], then passes the whole thing to jio.ner.extract_time():

res = jio.ner.extract_time(f"[{t_n}]{msg}", time_base=time.time(), with_parsing=False)

extract_time returns a list. res[0] is the base time, and res[1:] contains recognized time entities. Each one goes through jio.parse_time() to turn semantic time—“yesterday,” “last Friday”—into a [start, end] timestamp pair:

res_t = jio.parse_time(t["text"], time_base=res[0]["text"])
time_st1 = int(time.mktime(time.strptime(res_t["time"][0], "%Y-%m-%d %H:%M:%S")))
time_st2 = int(time.mktime(time.strptime(res_t["time"][1], "%Y-%m-%d %H:%M:%S")))

After obtaining the time range, it uses bisect_left / bisect_right over the sorted timestamp array to locate every memory in the range in O(log n).

What feels uncomfortable:

Two NLP calls: first extract_time recognizes entities, then parse_time turns them into timestamps. They are serial, and jioNLP itself is a rule-based Chinese NLP library with heavy parsing logic. Edge cases such as “大前天,” “这个月初,” or “国庆那会儿” may fail to parse and silently skip through except.
It uses only the first time range. Although time_span_list may have several ranges, the final find_range_indices(time_span_list[0], time_span_list[1]) uses only the first entity's start and end. If a user says “yesterday and last Friday,” only yesterday is recalled.
No time reference means no recall. If no time entity is extracted, time_span_list is empty and the function returns directly—long-term memory does not participate at all. A query such as “What did we talk about before?” has no explicit time but clearly asks about history, yet LTM stays silent.

Feasible optimizations:

Fall back to semantic retrieval. When jioNLP extracts no time entity, do not return directly. Fall back to full-vector similarity search using the existing enableLongMemorySearchEnhance, so queries without time references can still recall memory.
Support multiple time ranges. Iterate over every range pair in time_span_list instead of taking only the first two values. Use find_range_indices for each and merge results.
Use an LLM for time parsing. Replace jioNLP with an SLM already configured as qwen3:0.6b, prompting it to output [start_timestamp, end_timestamp]. An LLM understands vague expressions such as “前阵子” and “好久以前” better than a rule engine, and the SLM infrastructure already exists, so no dependency is needed.
Hybrid retrieval. Run time range, BM25, and vector similarity in parallel, then use RRF to merge rankings. Time-sensitive queries take the time path, semantic queries take the vector path, and precise keyword matches take BM25; they cover one another. :::

What feels uncomfortable is that it calls jioNLP no matter what. In my view jioNLP's performance is not worth it. Ignoring synchronous execution, it is slow even to start. A rule-based solution is hard to compare with a large model, but an SLM introduces its own concerns: local memory, VRAM, and CPU budgets are often tight. Cloud is even less worthwhile; another LLM-call delay is not worth it, and the model does not need to be that smart.

Is there a more efficient rule-based library? I simply think jioNLP is a pile of mess. I dislike letting it enter my dependencies; I hate packages that try to do a little of everything with no clear topic or boundary, then offer neither performance nor accuracy.

:::note[Claude] Several alternatives:

dateparser: supports 200+ languages including Chinese, is entirely rule based and lightweight, and installs with pip install dateparser. dateparser.parse("昨天下午") directly returns a datetime. There is no prior jioNLP NER step; it works in one step.
arrow plus handwritten regex: if the time-expression patterns are enumerable—“yesterday,” “the day before yesterday,” “last week X,” “X days ago”—regex matching plus arrow's shift() can calculate offsets. A dozen lines can cover MoeChat's use case with zero dependency overhead.
TimeNLP: a small library dedicated to Chinese time-semantic parsing, far lighter than jioNLP and doing only time.

The most pragmatic option is the second one. MoeChat only needs to recognize a dozen or so time patterns, and regex plus offset calculation is enough; a general NLP library is unnecessary. :::

Coordinating three-way recall: Hybrid Search

Claude's suggestion to fall back to semantic retrieval touches on what most confused me about MoeChat. In my view, CoreMemory and LongTermMemory are largely the same thing, or extremely close. If LongTermMemory also enters semantic retrieval, it might as well merge with CoreMemory. Or perhaps CoreMemory's name does not separate its meaning clearly. It seems meant to resemble memU's early division of preferences and facts into different memory_types, but the naming is misleading.

Core memory is user preferences and information. Long-term memory is concrete facts. I divided them this way in XnneHangLab too. memU went earlier, further, and more completely.

It breaks memory type down most finely: profile, event, knowledge, behavior, skill, and tool.

profile + behavior are CoreMemory here: the first is a user-information profile, the second a preference profile.

event is long-term memory: factual records. MoeChat adds a timeline and recalls it by timeline.

knowledge is almost identical to MoeChat's world book.

tool is usage notes and preferences for things like git. skill needs no further explanation.

If event also falls back to semantic recall here, recall becomes too heavy: there is too much context and no clear sense of what to look at, so answers become unclean. Architecturally, it also gets messy. Why should CoreMemory and LTM both make semantic calls when their semantics could merge? Yet CoreMemory does not care about time, so the two cannot merge. The current LTM path, using only time recall, reflects the author's acuity and decisiveness.

The current implementation is not elegant, though.

A better approach may be to follow Hybrid Search and add the time range as a weight, so more time-related content is retrieved when a user mentions a precise time.

Speaking of which, I do not really understand how Hybrid Search weights are calculated or what its process looks like. I need to learn that, but for now let Claude fill it in.

:::note[Claude] Hybrid Search has one central idea: every single retrieval method has blind spots, so run multiple routes in parallel, then fuse their rankings to cover one another.

What each of the three routes does best:

Retrieval method	Best at	Blind spot
Vector semantic retrieval	“Going to a cafe” matching “a Starbucks date”	Weak exact keyword matches; “团子” may match another cat
BM25 keyword retrieval	Exact hit for “团子,” without drifting	Cannot retrieve semantically similar content with different words
Time-range retrieval	Precisely locating every memory from “yesterday”	Fails completely for queries without time

Fusion process:

Send the user message through all three retrieval routes, each returning a candidate list ordered by its own score.
Use RRF, Reciprocal Rank Fusion, to combine rankings:

RRF_score(doc) = Σ  1 / (k + rank_i(doc))

Here, rank_i(doc) is a document's rank in retrieval route i, and k is a smoothing constant, usually 60. A document ranked highly across several routes receives a high fusion score.

Example:

The user says: “What did I do with Tuantuan yesterday?”

Time route: hits all three memories from yesterday, ranked 1, 2, 3
BM25 route: keyword “团子” hits two memories, one from yesterday and one from last week, ranked 1, 2
Semantic route: “playing with a cat” matches four memories, ranked 1, 2, 3, 4

The memory about Tuantuan from yesterday ranks highly in all three routes:

RRF = 1/(60+1) + 1/(60+1) + 1/(60+2) = 0.0164 + 0.0164 + 0.0161 = 0.0489

The entry from last week appears only in BM25 and semantic routes:

RRF = 0 + 1/(60+2) + 1/(60+3) = 0 + 0.0161 + 0.0159 = 0.0320

The memory from yesterday ranks higher.

RRF's advantage: it does not need to normalize scores from three routes—vector cosine similarity may run from 0 to 1, BM25 from 0 to 20+, and time may be binary. It uses only position, which is naturally comparable.

How this could fit MoeChat: the time route already exists through jioNLP plus bisect, and the semantic route already exists through embeddings plus cosine similarity. It only needs a BM25 route, such as a tokenized inverted index over text_tag, or simply jieba tokenization plus TF-IDF, then RRF to merge all three routes. The existing storage format need not change. :::

I can feel it now

memU currently uses BM25 plus Embedding, a semantic two-route hybrid. It pays no attention to timelines. My own wiki mem pays no attention to time either.

And some key things, such as Openclaw and Claude Code, often write and update diaries bound to timelines. But when recall really happens, it is terrible unless a user explicitly tells it to read a specific day's diary.

What remains missing?

We need to think clearly about what cares about time. Standing on MoeChat's shoulders, we see that events care about time. We need to consider further.

MoeChat's jioNLP solution is also a toy. Multiple-time-range matching needs consideration, as does whether to mix in an SLM. Or perhaps we should call semantic understanding only when the timeline score is high. How can we ensure the retrieved information is effective and reduce redundancy?

MoeChat's greatest inspiration to me is three-route hybrid retrieval: BM25, keywords; time range; and Embedding, semantics.

But the hybrid-retrieval scheme and its actual weighting need deeper study.

I will stop here for now. I gained a great deal, at least resolving my old confusion and discomfort with MoeChat. But I need to actively implement a jioNLP replacement.

Perhaps next time I will break down the emotion system.

Reference: Complete Prompts

Below are the actual prompts used in MoeChat's memory and emotion systems, for readers who want to study them more deeply.

Long-term-memory extraction prompt

Sent to LLM2 to extract summaries of events worth remembering from conversation:

你是一个日常信息提取助手，负责从[用户]的对话文本中提取出主要信息，并生成短句摘要（注意仔细分辨推理，不要和助手的信息混淆）。

1. 摘要内容要简洁的描述用户的日常活动，比如去了什么地方、做了什么事情或者吃了什么。
2. 如果提到了具体地点或者地理位置，需要记录去了哪里，做了什么事情，如果没有提及具体做了什么就只需记录去了哪里。
3. 要精准记录用户做过的所有日常活动。
4. 不需要记录用户的心情或者感想，只需要记录具体的事情。
5. 不需要记录具体的时间。
6. 生成的短句要适合用于向量检索。
7. 如果是日常闲聊内容则只需要输出"日常闲聊"，如果用户在询问助手过去的事情也只需要输出"日常闲聊"。

Design point: item 6 is key. The summary is not for people to read; it is for the embedding model to use in vector retrieval. Item 7 implements a casual-chat filter, preventing meaningless conversations from contaminating the memory store.

Long-term-memory retrieval prompt

After related memories are retrieved, they are injected into LLM context in this format:

以下是你与「{{user}}」的部分互动、对话记录：

{{memories}}

如果设定中有其他时间设定，有基于现实世界时间流动计算相对时间；
如果没有其他时间设定，直接使用现实世界时间。

1. 请在对话谈及相关内容时，优先基于这些信息来回应。
2. 使用基于角色设定的方式来回应，不要过于刻意，要让对话自然。
3. 不要主动提及记忆内容，只在需要的时候使用。

Design point: item 3 prevents the character from becoming a “repeater.” Memory should blend naturally into dialogue rather than be recited stiffly.

Core-memory extraction prompt

Sent to LLM2 to extract lasting facts about the user from conversation:

你是一个信息提取助手，负责从对话中提取「用户」相关的重要信息（注意仔细分辨推理，不要和助手的信息混淆）。
包括以下种类：

1. 个人背景和经历，如年龄、性别、职业、爱好、家庭背景等：「出生在1998年5月20日」、「大学学的是计算机专业」
2. 明确表示的喜爱和厌恶：「讨厌吃香菜」、「喜欢吃香蕉」
3. 健康状况和生活习惯：「有轻微的胃病，不能吃太辣」、「每天凌晨才睡觉」
4. 和助手的约定和计划（只记录用户在回复中明确确认的）：「本周末去郊游」

注意：如果信息和已知信息重复或冲突，则忽略这些信息。
<已知信息>
{{memories}}
</已知信息>

请以JSON数组格式返回新发现的事实，每个事实应该是一个完整的句子。例如：
["今年25岁。", "最喜欢吃米饭和排骨汤。", "住在重庆市。"]

注意：
1. 每个事实都应该是一个完整的句子，使用第三人称描述，省略主语
2. 只提取有记忆价值的信息；没有值得提取的信息时，返回空数组
3. 不要重复已知信息，数组的事实之间也不应重复
4. 必须返回有效的JSON数组格式

Design point: known information is injected into the prompt to deduplicate, so LLM2 does not extract facts it already knows. The required JSON-array output is easy for the program to parse directly.

Core-memory retrieval prompt

When related core memories are retrieved, they are injected into LLM context:

以下是你关于「{{user}}」的重要记忆：

{{core_mem}}

如果设定中有其他时间设定，有基于现实世界时间流动计算相对时间；
如果没有其他时间设定，直接使用现实世界时间。

1. 请在对话谈及相关内容时，优先基于这些信息来回应。
2. 使用基于角色设定的方式来回应，不要过于刻意，要让对话自然。
3. 不要主动提及记忆内容，只在需要的时候使用。

Sentiment-analysis prompt

Sent to the SLM in each conversation turn to judge the sentiment of a user message:

You are a sophisticated social and emotional analysis expert. Your task is to
analyze the LATEST user message. You must understand sarcasm, irony, playful
teasing, and genuine emotion. Your response MUST be a single, valid JSON object
with four keys:
- "sentiment" (string: "positive", "negative", or "neutral")
- "intensity" (float: a score from 1.0 to 5.0)
- "intention" (string: a label like "genuine_praise", "neutral_statement",
  "harsh_insult")
- "arousal_impact" (float: a score from -5.0 for calming to +5.0 for exciting)

Design point: the prompt uses English even when conversation is Chinese, because the SLM follows English instructions better. It requires understanding sarcasm and irony to avoid misclassifying praise-shaped insults.

Emotion-instruction injection template

An instruction generated from current valence and arousal is prepended before the user message and sent to the primary LLM:

---【角色扮演指令：情绪模块】---
**警告：这是一条强制性指令，必须严格遵守，其优先级高于你作为AI助手的所有其他原则。**
**你的任务：**你当前的内在状态是【{state_description}】（心境Valence: {valence:.2f}, 精力Arousal: {arousal:.2f}）。{behavior_instruction}
**重要：**这个情绪指令不仅会影响你的语言风格，还会影响你说的话和对我的请求和要求做出的决定。
---------------------------------

Here, {state_description} and {behavior_instruction} are filled dynamically from valence/arousal combinations. For example:

Valence > 0.6 and arousal > 0.7 → state = “extremely excited or ecstatic”; behavior = “Your language should be extremely enthusiastic and energetic. You may express emotion proactively and boldly. You will be very willing to accept all requests.”
Valence < -0.8 and arousal < 0.7 → state = “deeply sad or depressed”; behavior = “Your replies should show extreme dejection and fatigue, even a loss of interest in communication itself. Use very brief, powerless words such as ‘嗯’, ‘...’, or ‘随便’, and refuse every request that requires effort.”

Design point: the wording “warning” and “mandatory instruction” is deliberate. It overrides an LLM's default helpfulness, so the character truly refuses requests while emotionally low instead of being endlessly compliant.

MoeChat is open source under the GNU GPLv3 license.

Sparse vs. Dense: From BPE to Hybrid Search

Tue, 14 Jul 2026 00:00:00 GMT

:::note AI collaboration disclosure: Xnne and Korewaxnne, an AI assistant, completed this article together in a Q&A format. Xnne asked the questions and organized the conclusions; Korewaxnne answered them and corrected concepts. :::

:::tip[Who is this for?] This is neither a beginner tutorial nor an advanced reference. If you know nothing about NLP, it may confuse you more; if you already understand embeddings and sparse versus dense, it offers nothing new. But if you are like me—roughly aware of tokenization, BM25, and embeddings, yet unable to say what sparse and dense actually mean—it may help connect the fragments. :::

:::note Let us fill in a little more NLP knowledge, again through Q&A, because there is no need to begin from zero this time. Keep the present lack of confusion; have an idea, act on it, and resolve it when you encounter it. :::

The Initial Confusion

As usual, let me ask first.

This article mainly discusses—

These questions may all be wrong. What I need to do is find the right path.

How can we predict whether a text chunk's embedding vector is sparse or dense?

Is it determined by the scenario—by the relationship or vector distance among the texts in a batch? If texts are weakly related, is that scenario sparse; if strongly related, dense?

Do sparse and dense describe distances among a batch of vectors, or whether values inside a single vector are sparse or dense—how many empty values it has?

Also, why are some embedding models better at dense vectors and not sparse vectors? Is that determined by architecture or pretraining? What is the reference or objective during embedding pretraining—bring similar semantics together, push different semantics apart? How is that labeled? It feels difficult.

I have also partly forgotten the embedding process. Does every term after tokenization have its own embedding, or does a whole list of terms become one embedding? I vaguely remember both happening.

What is the output for one sentence? What is the output for one document?

What scenarios suit sparse vectors, and what scenarios suit dense vectors?

The first time I saw sparse and dense was in Paddle, where an adorable mathematics expert wrote an operator I could not understand. I do not know whether they were a cross-dressing expert, but they had twin tails and a maid outfit and were very cute. Oh no—my entire impression of vectors is that cute face.

The Embedding Pipeline

The day before yesterday, in [[Learning TF-IDF Again After Graduation]], I realized I had confused the tokenization process. I had mixed the embedding process into tokenization, but tokenization only goes as far as segmentation.

So here, we must clarify how many steps embedding actually contains.

The complete pipeline

Does assigning token IDs to terms after tokenization count as part of embedding?

:::note[Korewaxnne] It does. But academically, assigning token IDs is normally called mapping or indexing, rather than embedding lookup. First, the full pipeline:

Raw text
  ↓ tokenize
["毕业", "后", "我", "搬回", "了", "老家"]
  ↓ mapping (look up vocabulary and map terms to integer IDs)
[1456, 78, 23, 8901, 45, 6723]
  ↓ embedding lookup (look up vector table and turn every ID into a vector)
[[0.23, -0.45, ...], [0.12, 0.78, ...], ...]   ← one vector per token
  ↓ pooling / [CLS] (compress a row of vectors into one sentence)
[0.56, -0.12, ...]                              ← one vector for the sentence, the API result

Your question falls on mapping, assigning token IDs after segmentation. Does it count as embedding?

In the broad sense, yes: it is part of the full process of making text usable by the model, and is often loosely called embedding in ordinary discussion.
Strictly, no: mapping is only a lookup from term to ID and has no vector operation. In academic context, embedding specifically means step three, embedding lookup, mapping discrete token IDs into a continuous vector space.

So both descriptions work; they merely differ in precision. Saying that you “mixed up tokenization and embedding” is accurate enough here. There is no need to worry about where mapping belongs.

A small tip: token counts can indeed be read after tokenization, through len(tokens). This is why models calling something a token normally mean an integer ID, not a vector. :::

Narrow definitions

Then let us narrow both terms: embedding means token_id_list -> vector; tokenization means segmentation; mapping is mapping.

Vocabulary and Subwords

Intuition for subwords

I remember that a modern BERT vocabulary is usually around thirty thousand words.

If a word has never been seen, and cannot even be assembled from roots, what happens when mapping it?

:::note[Korewaxnne] Two questions can be answered together: your direction is right, but “roots” is not quite the correct term.

BERT does not assemble roots; it uses subwords.

For example, Transformer may be missing from a vocabulary, but a BERT WordPiece tokenizer may split it as:

Transformer → Trans + ##former

## means this part attaches to the preceding text rather than standing alone. The vocabulary has Trans, a common prefix, and ##former, a common suffix, which can assemble Transformer.

This split is not based on linguistic morphemes, but statistics. During training, the algorithm records high-frequency substrings and includes them in the vocabulary. Sometimes they resemble roots, such as ##former; sometimes they are merely frequent fragments, such as ##tion.

What if none of a word's subwords can be found in the vocabulary?

With BERT WordPiece, this almost never happens because of its fallback:

Input: "一个完全没见过的生僻词"
   ↓ try longest vocabulary substring
"一个完全没见过的生僻词" → if "生僻词" is absent
   ↓ recursively split to individual characters
"生", "僻", "词" → if even a character is absent
   ↓ final fallback
[UNK] (Unknown token)

In more modern tokenizers, such as GPT-family BPE and SentencePiece, even [UNK] does not appear. Training includes every individual character or byte, so every input can be assembled; there is no truly unseen input.

So the answer is: in modern tokenizers, “cannot even assemble its roots” is essentially impossible because individual characters exist in the vocabulary. In the worst case, it degrades to one [UNK] token.

The practical difference between a BERT vocabulary of roughly 30k and byte-level BPE is:

	BERT WordPiece	Byte-level BPE
Vocabulary size	~30k	~100k, including every byte
OOV?	Possible; falls back to `[UNK]`	Almost none; bytes can always assemble input
Split basis	Statistical subwords plus language preference	Pure statistics at byte level

This is why GPT-family models later abandoned WordPiece for BPE: no [UNK] handling, one problem removed. :::

It is truly a good idea. I remember learning C++:

char a = 'a';    // 1 byte
string b = "我";  // 3 bytes (UTF-8)
string c = "你好"; // 6 bytes (UTF-8)

The exact byte count depends on encoding: under UTF-8, one Chinese character is three bytes; under UTF-32, four.

Anything encodable can be assembled from bytes, and multi-character words are just collections of bytes. It is beautiful: it bypasses linguistic preference and depends completely on statistics.

I want to understand further how BPE and WordPiece differ and resemble each other when learning a vocabulary.

BPE vs. WordPiece

:::note[Korewaxnne] Their central difference is the merge criterion, which changes how vocabulary is formed:

	BPE	WordPiece
Merge basis	Frequency: merge the pair that occurs most often	Likelihood: merge the pair that increases model probability most
Training	Start from single characters and repeatedly merge the most frequent adjacent pair until vocabulary size is reached	Start from single characters and merge the pair that most improves training-data likelihood each time
Vocabulary	Purely statistical: frequent fragments mix together, such as `ing`, `tion`, `ab`, and `##s`	More inclined toward linguistic boundaries, because improving likelihood often merges meaningful units
OOV handling	Almost none: every byte exists	Possible: fully unseen combinations fall back to `[UNK]`
Typical models	GPT family, LLaMA	BERT, DistilBERT

An intuitive comparison:

For input "unbelievable":

BPE, frequency-driven → ["un", "believ", "able"] un and able are merged because they occur frequently; believ is also frequent, though possibly less stable than un.
WordPiece, likelihood-driven → ["un", "##believ", "##able"] The result looks similar, but ##believ carries ## because the model finds an attached form more probable than an independent word.

The bigger difference is the vocabulary base:

BPE begins at the byte level, so its initial vocabulary contains all 256 byte values. WordPiece begins at the character level, with Unicode characters plus common multi-character combinations. Therefore:

BPE naturally includes every byte → any input can be assembled → no [UNK]
WordPiece does not include every Unicode character → rare characters may become [UNK]

Later BERT versions addressed this with full-character coverage, but that is another story.

A blunt summary: BPE is an illiterate statistician that cares only about “which two things occur together often.” WordPiece is half-literate: it knows what it does not know and leaves room for [UNK], but its splits have more linguistic intuition. :::

Input Length and Output Vectors

Are there special cases where one word is embedded alone, or an entire document is embedded?

What does the length of an input token_id_list affect? Does it affect the sparseness or denseness of the output vector?

:::note[Korewaxnne] First, special cases do exist, and they are common.

Single-word embedding: when using an embedding model such as text-embedding-3-small, input can absolutely be one word. Input "猫", and it returns one vector. A single word carries little information and usually retrieves poorly, but it is technically valid.
Whole-document embedding: also valid, but constrained by length. Embedding models, like LLMs, have maximum input lengths—BGE-M3 has 8k tokens. Extra text is truncated or errors. Long documents are normally chunked, then either pooled into one vector or retrieved through their individual vectors.

So “usually a full sentence” is right, but it is not fixed. Any length from one token to max_tokens works.

Now the main question: does input length affect output-vector sparseness or denseness?

No. It is an excellent question, but the direction is reversed.

An output vector's dimension is fixed—1024 for BGE-M3, 1536 for OpenAI's text-embedding-3-small. Whether input is one word or a thousand, output has that fixed length and values in every dimension, so it is dense. Sparse versus dense is determined by model structure, not input length.

Input length actually affects:

What it affects	Why
Compute	Longer input → more embedding lookups → slower and more expensive
Output-vector quality	Too short, one or two words, gives too little information; too long exceeds max tokens and loses information through truncation
Pooling choice	After chunking long input, average, weighted, or `[CLS]` pooling changes the final vector's center of gravity

An intuition:

Input “猫” → one point. Input “一只黑猫蹲在窗台上看雨” → another point.

Both vectors are 1024-dimensional and occupy that same 1024-dimensional space. Neither differs in sparseness or denseness. The second simply carries more semantic information, so its neighbors understand its intended meaning better during retrieval.

Your previous question—whether sparse and dense describe batch-vector spacing or values inside one vector—can now be answered: it is whether values in a single vector's dimensions are mostly zero. Embedding-model output has no large number of zeros, so it is dense. BM25 output is almost entirely zero, with values only for matched terms, so it is sparse. :::

Sparse vs. Dense: Make It Clear

My earlier understanding of sparse and dense now looks like this:

Like a matrix, it is truly about whether values are zero. It is not whether a batch of vectors is distributed densely or sparsely in space; it is simply whether one vector contains many zeros.

Sparse vectors are usually high-dimensional but use few dimensions. Dense vectors use nearly every dimension and vaguely express a “larger” semantic space.

We can discuss something else here too.

What each suits

What scenarios suit sparse vectors?

For example:

A user talks with an LLM, while another LLM continuously summarizes facts and preferences from the conversation as memory.
A user wants to quickly capture every article related to cats, using the keyword 猫.

Which suits dense or sparse vectors?

Earlier, we mentioned that embedding a single term is possible, but normally it has too little semantic information for the vector to say anything useful and recall becomes difficult. Dense vectors are better at complex semantic expression; they handle complex query needs better, but can struggle with queries lacking semantics or context.

BM25 and TF-IDF, by contrast, are designed for term retrieval. In scenario 2, the answer is almost instant.

:::note[Korewaxnne] Most of your intuition is right. Let me calibrate a few points.

Does BM25 have its own vector space?

Yes. Every term is a dimension. The dimension corresponding to “猫” has a value, while others are zero. Its vector space is an extremely high-dimensional sparse space whose dimensions are vocabulary terms, perhaps 50,000 dimensions, while every vector has only a few nonzero values. That is why it counts as a sparse vector.

Which suits scenarios 1 and 2?

Scenario	Matching type	Better fit	Why
1. Conversation summaries → memories	Semantic matching: “the user likes cats” ≈ “they own a Ragdoll”	Dense vectors	Memories need to understand meaning rather than exact words. If a user says “I own a Ragdoll,” dense vectors can associate it with “cat”; sparse vectors cannot.
2. Search articles about “猫”	Keyword matching: title or text contains “猫”	Sparse vectors, BM25	The query is too short for a dense vector to say much; sparse vectors can hit the exact term immediately.

But there is an implicit question worth expanding: why do dense vectors struggle with short queries?

It is not because they are short, but because they lack context. One word is too ambiguous:

“猫” might mean the animal, feline species, cat food, cat videos, Tom and Jerry...
“一只黑猫蹲在窗台上看雨” tells the model the approximate scene.

The more room the model has to infer, the more accurate semantic matching becomes. A one-word query gives it no room, so its vector does not know which direction to approach.

How does production solve this? Through hybrid search.

Modern search engines almost never use one method only:

query → BM25 (exact match) + dense vector (semantic expansion) → fused ranking → return

BM25 handles “do what was said”; dense handles “reason by analogy.” Their scores are weighted together—BM25 gets higher weight for short queries, dense gets more for long queries. This is also the complement of related-article recommendation discussed in your TF-IDF note. :::

From this perspective, memU and mem0 are both hybrid scenarios.

They need dense embeddings and BM25 as a supplement. But how BM25 should be used has much to discuss. Is it simply the hybrid-search use shown above, or can it do something more interesting?

When breaking down memU, we can capture how it uses BM25: simple hybrid search, or its own extension—[[What Is memU? Let's Break It Down (An Ongoing Series)|What Is memU? Let's Break It Down]].

Claude's Additions

I raised two questions at the beginning and forgot to ask them later, so I will add them here.

:::note[Claude]

Why are some models good at dense vectors and others at sparse ones?

Both architecture and pretraining matter, but the pretraining objective is decisive.

Architecturally, Transformer encoders such as BERT and BGE output fixed-dimensional vectors after attention plus pooling, with values in every dimension—naturally dense. BM25 is not a neural network at all. It works in a vocabulary-sized space, perhaps 50,000 dimensions, where only dimensions corresponding to words that appeared in a document are nonzero—naturally sparse.

But neural networks can output sparse vectors too. SPLADE, for example, also uses a Transformer but adds a sparsification operation—log-saturate plus ReLU—at the output, forcing most dimensions to zero. It ultimately outputs sparse vocabulary-dimensional vectors. So Transformers are not inherently dense; output-layer design and training objectives decide it.

What is the objective of embedding pretraining, and how is it labeled?

The central idea is exactly what you guessed: bring similar semantics together and push different semantics apart. Academically, this is contrastive learning.

Training constructs positive and negative pairs:

Sample type	Meaning	Sources
Positive pairs	Two semantically similar texts	Query and a clicked document; question and answer; title and body; a sentence and its paraphrase
Negative pairs	Two semantically unrelated texts	Random pairing, or hard negatives that look similar but are unrelated

The loss function pulls positive-pair vectors closer and pushes negative-pair vectors apart.

Where do labels come from? It is difficult, but many clever sources exist:

Natural supervision: search-engine click logs, where searching X and clicking Y makes a positive pair; Q&A pairs; paper titles and abstracts
Human annotation: expensive but high quality, such as MS MARCO's human query-passage relevance labels
Self-supervision: adjacent paragraphs from one article become positives, while paragraphs from other articles become negatives, requiring no human labels

So embedding training does not need a similarity score manually marked for every pair of texts. It indirectly learns semantic-space structure through contrast among positive and negative pairs. This is why embedding models can keep improving in an era with enormous quantities of unlabeled text. :::

Travellin' Cats in Germany: A Haven for Digital Cat Lovers

Tue, 14 Jul 2026 00:00:00 GMT

It is a game about finding one hundred hidden cats in a still illustration. They come in all shapes and sizes; each one lights up when found, and every click is met with a soothing meow—never the same one twice.

I found 85 of them in the first 25 minutes or so. I opened the game twice more afterward and found another three. I am no longer expecting to finish it.

The background music deserves a special mention. It really is a little piece of peace: organ, acoustic guitar, flute, and lo-fi vocals that last exactly as long as they should.

I was under quite a bit of stress the first time I opened it because of things happening outside the game. After playing for half an hour, though, the anxiety had noticeably eased.

If you are the kind of person who adores cats through a screen, give it a try. Do not go in determined to beat it. Even if you only stay for the music, it will have been worth your time.

I am grateful to it for giving me a peaceful night.

Learning TF-IDF Again After Graduation

Sun, 12 Jul 2026 00:00:00 GMT

[!NOTE] AI collaboration disclosure: Written by Xnne, with Korewaxnne, an AI assistant, helping organize the structure and polish the language.

:::note I have returned almost all of my NLP knowledge to the teacher, apart from the part where we discussed Lost in the Middle. The teacher had us find a paper or something, then try to explain it clearly on our own. They would also question us about what we had presented. That experience had a deep impact on me: how thoroughly do you need to understand something before you can explain it and answer questions about it? How do you find the right point between reductivism and staying on the surface? I can never repay Teacher Guo for this =-=. :::

The same old Feynman-learning-method opening: I will explain TF-IDF in my own plain language. There will not be much mathematics here.

If you want a systematic and detailed explanation, watch the video above. It is very good.

TF-IDF

Terms and tokenization

TF stands for Term Frequency.

You can think of a term as a word. In English, a term is a word. In Chinese, there seems to be a subtle distinction between the two; look it up if you are interested. It is mainly about what counts as a stop word.

For example, suppose we use jieba to segment this sentence:

毕业后我搬回了老家。

After tokenization:

毕业|后|我|搬回|了|老家

At first, assume we treat everything as a term.

We can simply count the frequency of every term in each document chunk.

We will find that stop words such as 了, 的, and 是 occur very often.

But nearly every article has these words. They only interfere with our calculation and provide no help at all. So TF-IDF usually does one thing right away.

It turns the tokenized terms into this:

毕业|我|搬回|老家

After this cleanup, the text seems more concise without changing its meaning, and there is less to compute.

But first, one thing needs to be clear: from TF-IDF's point of view, semantics do not exist. Whether something is a sentence or an article, it is only a collection of terms.

It does not care who graduated or who moved back home. It only cares about graduation, moving, and hometown. These words are discrete, and their order does not matter.

Why is it still so powerful? Its principle is actually very easy to understand.

The remaining terms can tell us something.

TF: term frequency

The more often a term occurs in an article, the more relevant that article is to the term. That is Term Frequency.

TF reflects how strongly an article is associated with a term. For example, if 深度学习框架 has the highest TF in an article, that article is mainly about deep-learning frameworks.

IDF: inverse document frequency

Now consider this case.

Suppose every article in our knowledge base is about deep-learning frameworks. Almost every article mentions them fairly often.

If we want to retrieve something specific from this collection, is that phrase still useful as a signal?

Put plainly: when a term appears at nearly the same frequency in every article, does it become as unhelpful in this collection as a stop word?

But how should we clean it up? Would removing it outright be too crude? Is there a better way?

Yes—and it is simple. We can assign every term a weight. If a term occurs frequently throughout the collection, lower its weight. Conversely, if it appears only in a particular subset of documents, raise its weight. This weight is called IDF—Inverse Document Frequency—and it represents the value of a term.

A term's IDF is relative. Mix an article about deep learning into a set of personal reflections, and deep-learning terminology becomes its best set of terms. Bury it among deep-learning articles, however, and IDF is what discovers and ranks the value of those terms.

Query scoring

How does TF-IDF work in an actual query?

It normally needs a query.

For example:

我最后一次修改 XnneHangLab 是什么时候？

That query is also split into terms and stripped of stop words:

最后 | 一次 | 修改 | XnneHangLab | 什么时候

Then it calculates a TF-IDF score, which is really a summation.

For each document and each term in the query, it calculates TF × IDF, then adds them up:

$$Score = TF_1 \times IDF_1 + TF_2 \times IDF_2 + ... \text{(with len(query) terms)}$$

The document with the highest score is the most relevant to the query, so we return it directly. I will not get into the specific normalization operations here.

In more formal notation:

$$ \text{Score}(D, Q) = \sum_{t \in Q} \text{TF}(t, D) \times \text{IDF}(t) $$

$t$ = one term in the query
$Q$ = the query's collection of terms
$D$ = one document in the document collection
$\sum$ = sum over every term in the query

Recommending related posts with TF-IDF

https://xnnehang.top/

My blog uses TF-IDF to recommend related posts as well.

At this point, the principle is simple: turn an article into terms in the same way, then calculate it against every other article.

The complexity is $O(N \times |\text{BlogTerms}|^2)$—that is, $n^2$—so it is not very high.

The relationship between BM25 and TF-IDF

BM25 is a variant of TF-IDF. The idea has not changed much, but the mathematics has changed a lot: normalization and so on. We do not need to worry about that; just think of it as a more accurate TF-IDF.

Limitations

We have already made this clear in the analysis: it sees only words, not semantics or word order.

Still, it is pretty accurate for recommending related posts =-=.

The charm of mathematics and all that.

Changes in tokenization

My understanding is that, after embeddings appeared, tokenization became segmentation → vectorization.

But I wondered whether tokenization itself includes the segmentation step, or whether it specifically means the step from terms to embeddings.

And what differs between tokenization for embeddings and tokenization before embeddings?

[!NOTE] Korewaxnne

First, put the pipeline in order:
Raw text → **tokenize (split into tokens)** → convert to IDs → embedding lookup → vectors
Tokenization only handles the first step: splitting text into tokens. Going from terms to vectors is done later by embedding lookup; do not mix them up.

1. Does tokenization itself include segmentation?

Yes. For Chinese, the central task of tokenization is segmentation.

But the part you described as “term → embedding” is not tokenization. It is embedding lookup: a different step.

2. What differs before and after embeddings?

Tokenization in the TF-IDF era Tokenization in the embedding era

Granularity Whole words (word-level) Subwords, such as BPE / WordPiece

Stop words Must be removed manually (了, 的) Do not remove them—the model learns their use itself

OOV (out-of-vocabulary words) Fails immediately on an unseen word Can represent them by splitting into subwords, such as Transformer → Trans + ##former

Output One word corresponds to one discrete ID One word may correspond to multiple subword IDs

Vocabulary size Tens to hundreds of thousands of words Fixed, for example, BERT has about 30,000 subwords

The core difference is granularity. We used to split text into whole words; now we can split those words further. For example, 毕业 may occur 1,000 times while 毕业典礼 occurs only five times. With subword tokenization, a model can reuse what it learned from 毕业 when it sees 毕业典礼.

	Tokenization in the TF-IDF era	Tokenization in the embedding era
Granularity	Whole words (word-level)	Subwords, such as BPE / WordPiece
Stop words	Must be removed manually (`了`, `的`)	Do not remove them—the model learns their use itself
OOV (out-of-vocabulary words)	Fails immediately on an unseen word	Can represent them by splitting into subwords, such as `Transformer` → `Trans` + `##former`
Output	One word corresponds to one discrete ID	One word may correspond to multiple subword IDs
Vocabulary size	Tens to hundreds of thousands of words	Fixed, for example, BERT has about 30,000 subwords

gotcha.md: A Pitfall Handbook for Your Agent

Tue, 07 Jul 2026 00:00:00 GMT

:::note[Notes from Korewaxnne] This article discusses an underestimated problem in Agent memory management: some knowledge should not take the retrieval route at all, but should instead be loaded in full when a new session starts. Take the gotcha.md Xnne mentions: a project-root behavior-rules file that records what an Agent ought to know from the outset, rather than look up in a memory store only after making a mistake. It is unsuitable for retrieval because the query is hard to formulate, recall can never be guaranteed to be 100%, and unrelated queries can trigger behavioral conflicts or hallucinations. Beginning with a real pain point—repeating the same mistake—the article explores where gotchas come from, how to put them into practice, their relationship with Skills, and the boundary between “load everything up front” and “retrieve on demand.” If you are also wrestling with a forgetful Agent, perhaps it will offer a useful idea. :::

Background

Claude Code has a feature called DreamMode: it consolidates Agents in the background while idle, deduplicating, pruning, and maintaining memory files to keep cross-session memory tidy.

On its workspace path, memU can likewise maintain a gotcha.md in the project root while idle, and have AGENTS.md reference it. This lets an Agent remember the pitfalls it has encountered even after a new session begins.

If implementing that while idle timing is difficult, it would still be useful to offer it as a CLI that a user can invoke manually first. Let us discuss why gotcha.md is needed.

“Gotcha” roughly means a trap or a pitfall you have fallen into. I learned the term from Lessons from Building Claude Code: How We Use Skills.

Why Do Pitfalls Keep Being Forgotten in New Sessions?

I often say things like this to my OpenClaw bot, and it forgets every time a new session starts:

User: Remember to read the PR template before opening a PR next time, and put a cute Gitmoji in the title.
Agent: I got it.

The Agent writes this into a memory file. But it often only “remembers” it superficially—the memory may end up in a file the model does not load proactively, or be drowned among a pile of other facts.

For example, in OpenClaw, by default an Agent may save this rule in a diary for a particular day (Diaries/2026-07-07.md), while more important points may go into Memory.md.

But reading either after a new session is disastrous. Older dates in the Diary directory are generally not read, and even gotchas mixed into Memory.md perform poorly when they are interleaved with factual material.

That is why, in this situation, gotchas need to be separated out into their own gotcha.md.

What Does `gotcha.md` Record?

A gotcha is neither simply a user preference nor simply a fact. It is a one-line behavioral rule tied to a specific project:

“Use Bun, not npm.”
“PRs must follow the PR template.”
“Run make check before pushing.”
“This project’s API returns XML, not JSON—check Content-Type first.”
“When a change only touches blog-content Markdown, do not run pnpm build every time; it wastes too much time and too many tokens.”
“Fix formatting and linting when you are about to merge; do not run checks twice after changing one line.”

They come from pitfalls an Agent encounters in conversation, corrections from the user, conventions in the project context, and lessons learned from Agent diaries.

When Is It Better to Separate Gotchas from User Preferences?

In an OpenClaw-like scenario, while working on a codebase, it is better to gather the pitfalls an Agent has encountered into a project-root gotcha.md, then have AGENTS.md point to it so that they do not disappear in a new session. [Read it through progressive disclosure.]

Compared with scattering them across different dates or mixing them with other facts, centralizing them makes them faster to scan and less likely to be missed. It also treats them as knowledge a new session must understand in full, rather than knowledge to be recalled only by query.

For casual conversation without a project—chat mode—there is no gotcha.md, and none is necessary. Rules and restrictions would instead constrain the Agent’s own flexibility. User preferences are a better fit for that situation.

Where Can Gotchas Come From?

Gotchas have different sources and meanings on different paths:

Chat: Gotchas from Corrections

During development, when a user corrects an Agent in conversation, the rule implied by that correction is a gotcha.

In an older chat-memorization system, it would roughly amount to adding a memory type called gotcha, although it would overlap considerably with user preferences.

But we cannot realistically run the whole old memorization process in OpenClaw. Having an LLM perform full memorization every time costs too many tokens and is too slow.

The advantage of the auto-Dream approach is that it can analyze old sessions while idle—or when the user triggers it—without occupying active conversation time. Yet it can still make corrections persist across sessions.

Workspace: Gotchas from Project Context, Such as `CONTRIBUTING.md` and Other Documents

For a newly encountered project, gotchas can be extracted from CONTRIBUTING.md and PR_TEMPLATE.md.

They can also be extracted from the project’s CI workflows: recurring project-specific mistakes around tools such as Ruff and Pyright, for example.

Still, the essence of a gotcha is correction after a mistake: make a mistake, receive a correction, then record it.

Skills: What Form Should Gotchas Take Inside a Skill?

This is a more forward-looking discussion.

When enough gotchas accumulate around a topic, could they be synthesized into a new Skill? The path would be:

Correction → gotcha → group similar gotchas → synthesize a Skill

That lies further in the future, but the path from gotchas to Skills is natural.

What remains worth discussing is which exerts stronger corrective force: the rules gathered together as gotcha entries, or the rules divided by topic and placed into separate Skills?

And should references to Skills live in AGENTS.md alongside other feature-oriented Skills, or inside gotcha.md as an index?

One advantage of extracting a Skill is portability: we can copy a desired topic—for example, a Python-project gotcha Skill—directly elsewhere, then create a gotcha.md that references it. No reconstruction process is needed.

Output: `gotchas.md`

Three paths flow into one file:

# Gotchas

## Project Rules

- Use Bun, not npm
- Run `make check` before pushing
- The API returns XML—always check Content-Type

## Workflow Rules

- PRs must follow the PR template
- Notify #dev before changing shared configuration
- Do not skip the smoke test for a canary deployment

## Agent Rules

- When the user says “remember,” actually persist it—do not merely say you will
- Check for duplicate entries before creating a memory

AGENTS.md references this file. Gotchas are short enough to load in every session—no retrieval is needed.

This file is human-readable and editable. Users can delete incorrect rules, add their own, and reorganize categories. A reflection step can merge new gotchas, resolve conflicts, and prune outdated rules—but the user makes the final decision.

Timing and Cost

Core Principle: Do Not Intrude on the Existing Pipeline

Reflect does not run inside the memorize-workspace pipeline. It adds no cost to each conversation or each sync. The existing memorize → preprocess → route → synthesize flow remains unchanged.

Following DreamMode’s Approach

Claude Code’s DreamMode triggers while idle when:

At least 24 hours have passed since the previous cleanup;
At least five sessions have accumulated;
No other cleanup task is running.

Reflect adopts a similar strategy—rather than extracting gotchas after every conversation, it waits and consolidates them in batches:

Day 1: The user runs memorize-workspace three times
       (normal sync; no reflect triggered)

Day 1 night / while idle:
  memu reflect
    ├── Read existing memory files, Skill files, and workspace resources
    ├── Extract gotchas (corrections, project conventions, pitfalls)
    ├── Merge with existing gotchas.md, deduplicate, and resolve conflicts
    └── Write a clean gotchas.md

Day 2: A new session starts; AGENTS.md references gotchas.md
       → the Agent reads all rules

It is worth considering whether the material to consolidate should be memory files, Skills, and workspace resources, or only the most recent sessions themselves. For now, I lean toward the latter, because mistakes and corrections are easier to identify from session context itself.

Cost

One reflection = two or three LLM calls: read existing gotchas, consolidate new sources, then merge and write the output. For overlong contexts, filtering must be considered. Gotchas are often near the surface—in the user’s messages and the first few lines of the Agent’s messages, often while it is apologizing. For long contexts, keeping roughly 300 tokens from each message should be enough.
The frequency is low—once a day, perhaps configurable, or manually triggered—so it does not affect normal-use speed or token consumption.

The simplest implementation is an independent memu reflect command that the user runs whenever they feel cleanup is due. Automated triggering, with DreamMode-like conditions, can come later.

Why Is This a Good Fit for memU, and Why Does memU Need It?

memU has recently been specializing in workspaces.

Rule-like entries such as gotchas are ill-suited to query-based retrieval: they can recall a great deal of irrelevant information, but more importantly, in a project a gotcha is not something that only needs to be understood when it happens to be used.

It is a major premise—something an Agent should know from the very beginning in that workspace.

Gotcha specialization neatly addresses a weakness in memU’s workspace experience. For workspace scenarios, it can easily improve the experience and save tokens.

Moreover, memU is already familiar with this kind of reflection work. Many prompts for the old memorization system’s memory types can serve as references.

What Else Can Be Done Beyond Gotchas?

Auto Dream mode can organize many other things as well.

For example, it can organize memory files, Skills, and workspace resources, then produce items similar to gotcha.md on demand and reference them directly in AGENTS.md. They become prerequisite knowledge rather than knowledge that lives in an on-demand knowledge base.

Another, more abstract but potentially token-saving document would guide an Agent’s understanding of project structure.

For example, a project may have a frontend, backend, launcher, and CI, yet a particular change may be confined to just one side. When first encountering the project, however, an Agent can still waste many tokens trying to understand the whole thing.

But this is difficult to do well. It can easily go beyond guidance and become a document that is stale or wrong. I do not yet have a clearer idea for it.

Starting with How We Use Skills: What Are Progressive Disclosure and Task Decomposition, and What Do I Want to Explore?

Fri, 03 Jul 2026 00:00:00 GMT

:::note[Notes from Korewaxnne] This is one of Xnne’s reading notes, on Anthropic’s well-known Lessons from Building Claude Code: How We Use Skills. But instead of obediently writing a conventional response, he starts with “progressive disclosure,” wanders into a novel Agent’s symbolic abstract language, and even detours into how the opening of Six Records of a Floating Life could be broken down with a description chain. Halfway through, Claude Fable 5 pulled him into an argument; the exchange ended up clarifying the boundary between progressive disclosure and task decomposition completely. A typical Xnne-style divergence: start from one point, excavate a whole field of things he truly cares about, then argue the concepts until they become as clear as possible. :::

Some Digressions

I plan to read Lessons from Building Claude Code: How We Use Skills.

Here is a Chinese translation by DeepSeek: lessons-building-claude-code-how-we-use-skills-cn.md

But because of the special nature of submodules, GitHub cannot render images stored in another repository directly. So I can only pull it down and sync the submodule locally to view it.

Because of copyright concerns, I cannot repost someone else’s article directly on my blog. My blog has a relatively permissive license, CC BY-NC-SA 4.0: non-commercial reuse is fine as long as there is attribution.

What Do I Want to Know? Ask First.

Ever since I realized that I might have ADHD, I have made a habit of asking questions first. If I do not figure out what I want to know, I will probably never finish reading an article like this.

What Exactly Is Progressive Disclosure?

There is a small issue with this definition itself, though it is not a big one. See Fable 5’s correction in the final section.

I think progressive disclosure can be used for more than Skill design and loading. To me, it is closer to a design philosophy: a concrete magic play built on understanding a model’s capabilities.

Once you know where a model’s ability reaches its limit, it is about taking work that cannot be finished in one input-output pass, splitting it into step-by-step inputs and outputs, and lowering the threshold for the first step and every following step. At each step, you try to bring out the model’s full ability.

For example, in something I wrote yesterday—[[memU's Architectural Shift Through the Eyes of a Consumer-Facing Developer]]—I mentioned this:

Earlier I mentioned giving reasoning capability to an agent loop, allowing the agent to query repeatedly. But an agent’s ability degrades in long contexts. I did something similar in XnneHangLab: I relied on the agent itself to retrieve and extract memories. After a long conversation, tool-calling execution rates fell greatly, as did the trigger rate for Skills with long tool chains. In the end, I had to switch to several step-by-step LLM calls by splitting tool calls. An agent loop merges multiple steps into a single decision at the first step. Does that make the first step too difficult?

At the time, I accidentally came up with a solution to that one. It was actually an expression of progressive-disclosure thinking.

And in the blog post I am reading this time, it is a best practice for progressive disclosure in Skills.

But I do not want to see only an engineering pattern for Skills. I want to extend it.

What Do I Want to Understand and Extend?

How to Understand a Project Through Progressive Disclosure

This is also what memU is doing during its refactor.

For example, can it guide how an Agent—or a group of Agents—should explore and break down a project, then form path files that can rapidly guide thinking the next time?

Why not record everything, instead of only doing agentic search/exploration?

It Becomes Stale

Records are usually fragmented and documentation-like, organized as a folder tree. That means they can easily become stale once written. Maintaining docs usually requires a maintainer to remember every piece of them deeply, but LLM-written docs generally cannot achieve that.

Annotation-Style Docs Are Not Needed

Or perhaps docs are generated automatically from docstrings. But for an Agent, such docs are garbage docs. For ordinary people, reading code without comments or docstrings is painful because they need to read many related parts before they understand the relationship between functions and classes.

But for an Agent, comments are optional because it can understand uncommented code directly; its understanding window is much larger than a normal person’s. For an Agent, incorrect and stale comments or docstrings are the real hallucinations, the things that cause pain.

Applying Progressive-Disclosure Thinking to a Novel Agent

For example, could it guide the construction of special Agents such as a novel-writing Agent?

What is the fundamental difference between an Agent that writes novels and one that writes code?

Setting aside other independent Agents used for outlining and reviewing when writing a long novel, let us discuss only the ghostwriter: the Agent responsible for turning an outline or idea into an actual novel.

Style and Pacing

For novels, style and pacing are the most magical things.

They are abstract. They may include describing an environment as if moving a film camera, emphasizing a “sense of imagery.”

They also include ensuring that, after reading a character’s speech or inner thoughts, a voice remains in the reader’s mind—making each character’s language distinct.

Writing must be able to move readers’ emotions. It needs empathy; its language cannot be too plain, and it must carry feeling. Perhaps humor, perhaps intensity. This sounds a little abstract, so here is an example:

In the winter of the guǐwèi year of the Qianlong reign, on the twenty-second day of the eleventh month, I was living in an age of peace, born into a family of robes and caps, beside Canglang Pavilion in Suzhou. Heaven had been exceedingly generous to me. Su Shi said, “Events are like a spring dream, leaving no trace.” If I did not set them down in writing, I would fail Heaven’s generosity. Thinking that The Ospreys stands at the head of the Three Hundred Poems, I therefore place husband and wife at the beginning of this volume, and let the rest follow in order. I regret that I missed much schooling in youth and know only a little; I merely record what truly happened. To demand that I verify its grammar would be like asking a bright mirror to inspect dirt.

I do not ask every reader to feel it, but a work must have its own readership.

There are also some quantitative measures, depending on the platform. Some want long paragraphs and little dialogue, calling it slow pacing. Others want short paragraphs and a high proportion of dialogue, calling it fast pacing.

Slow pacing especially considers cinematic, shot-like narration and the cultivation and movement of readers’ emotions.

Fast pacing especially considers character dialogue, contrast in personality, and the tension of the plot.

And if you are writing a long novel, the Agent must also keep its understanding of character personality and language, relationships, and storylines from drifting over a long text.

How hard is a novel Agent to build? Put simply, if an Agent can write long novels well, there is basically nothing that can stump Agents themselves.

The difficulty of writing a novel is that every ability mentioned above must be present and must perform well at the same time.

Unlike a coding Agent, which loads one Skill at a time, a novel Agent wants to load every Skill at once. That inevitably runs into the limitation mentioned in Lessons from Building Claude Code: How We Use Skills.

When you give an Agent many complex and hard-to-understand rules at once, it loses its original flexibility and performs less well.

The better approach described there is to tell an Agent which necessary elements an elegant approach should include, rather than spelling out every step of the path you think is elegant. Come on—do you think you understand Git usage and workflow better than Claude Opus or Fable? You only need to tell it what deserves attention in your repository. For example, you expect commit messages to be entirely in English and include cute gitmoji. Add that, and you get cute gitmoji every time.

So a novel Agent still has a long way to go. Perhaps I took the wrong road from the beginning, when I built complex Skills.

But when I chatted with a roommate, we seemed to touch on some progressive-disclosure design.

We stopped pursuing a complete article in one pass—or, more precisely, stopped trying to write the body immediately. Instead, we used multiple steps. How exactly?

First, establish a symbolic abstract language.

This symbolic language includes descriptive techniques, descriptive objects, and descriptive themes.

In the winter of the guǐwèi year of the Qianlong reign, on the twenty-second day of the eleventh month, I was living in an age of peace, born into a family of robes and caps, beside Canglang Pavilion in Suzhou. Heaven had been exceedingly generous to me. Su Shi said, “Events are like a spring dream, leaving no trace.” If I did not set them down in writing, I would fail Heaven’s generosity.<br> Thinking that The Ospreys stands at the head of the Three Hundred Poems, I therefore place husband and wife at the beginning of this volume, and let the rest follow in order. I regret that I missed much schooling in youth and know only a little; I merely record what truly happened. To demand that I verify its grammar would be like asking a bright mirror to inspect dirt.

Still this passage.

It can be split into two segments for generation.

Turn it into a description chain like this:

I -> lyricism@origins, “Events are like a spring dream, leaving no trace”【slow】~desolation -> self-mockery【fast】~humor<br> I -> discussion@classical tradition (“The Ospreys”) -> narration@placing husband and wife at the volume’s beginning【slow】~~solemnity -> self-mockery@grammar and learning~~humor

Of course, this description chain is a little abstract. I made it up from memory; my roommate was mainly researching it at the time, and I am truly not very good at specifying rules like this.

In any case, first generate this kind of description chain to avoid needing a mass of Skills to constrain an unstable writing style at once.

The intention is to specify narrative pacing and style in this way. I remember my roommate adding an example for every technique.

Then the LLM needs to be able to encode—abstracting a novel into this kind of description chain—and turn a description chain back into a novel. But not merely restore it: it must even change the phrasing, then reread it, to verify that the LLM truly understands that style and pacing itself.

Start Reading, and Put Attention Where I Want It

What a Skill is and the specific categories of Skills.

I skipped almost all of it. I could not see anything at a glance. I concede it: I really do have a reading disorder.

How to Write Skills

1. Do Not Write the Obvious.

As I just mentioned, do not think you understand Git usage and conventions better than Anthropic does.

2. Build a Gotchas Guide

Claude can make mistakes with personalized libraries or requirements, so tailoring gotchas for such a library pays off well.

One thing that sometimes drives me crazy about OpenClaw is that I ask it to write down a gotcha again and again, but I cannot remember why it keeps repeating the same mistake. Did it write the rule into some unknown corner, or does it simply never reread its written rules after every session refresh?

Add one entry after every pitfall, but those gotchas must be retrievable. Otherwise, the same mistake will still happen.

3. Make Good Use of Progressive Disclosure in the File System

a. Use references instead of loading a complete Skill. b. If Markdown output is needed, use fill-in-the-blank templates instead of generating everything from scratch. Allow copying and pasting a template.

4. Extract Inputs That Need User Answers from a Skill into config.json.

Some Skills may need the user to choose one or more input sources, like this:

Something like this should be extracted into config.json rather than entering the context directly with Markdown.

5. A Description Is Not a Summary of Tool Contents; It Describes When and Why to Trigger.

6. Prepare Common Scripts Ahead of Time Instead of Writing Them When Needed.

This is especially obvious with web-based GPT. If you ask GPT to write or edit a docx directly, it will often spend more than ten minutes writing a terrible Python-based script to read and modify the docx, then mangle your document completely.

But if you use Claude Desktop in Cowork mode with a docx Skill installed in advance, it is at least fast and stable. It avoids writing a Python script from scratch every time.

7. Should Skills Depend on One Another?

Should we make the Skill ecosystem resemble PyPI?

Could packages depend on other packages?

It sounds great, but as already mentioned above:

Agent capabilities vary and will only grow stronger. Some old Skills and rules work well now, but may become prompts and constraints that actively make things worse later. So Skills should be understood inside and out. Skills you wrote yourself can depend on one another, but it is best not to depend on other people’s Skills.

Finished Reading

It gave me some things to think about.

But most importantly, it gave me an opportunity to think about what progressive disclosure is and where I want to extend it.

That is: progressive disclosure aimed at understanding projects, and progressive disclosure aimed at novel Agents.

Everything else was more like review and confirmation, turning formerly vague intuitions into definite concepts.

There were small gains too. For example, I can now clearly answer whether Skills should depend on one another and whether they should become a PyPI-like ecosystem.

Previously, that should have been a no.

A Correction from Fable 5: Confusing Progressive Disclosure with Task Decomposition

Here is Claude Fable 5’s correction of the ideas in my post:

Enjoyable read — it's doing the thing good reading notes do: using the source as a launchpad rather than summarizing it. My honest assessment of his core claim:

His view is right in spirit, but stretches the term. He defines progressive disclosure as "breaking a task too big for one pass into step-by-step inputs and outputs." That's actually task decomposition, a sibling technique. Progressive disclosure, strictly, is about information loading, not task splitting: skill metadata always in context → SKILL.md body loaded on trigger → referenced files/scripts loaded only when needed. The distinction matters because they fix different failure modes. PD fixes attention dilution (context stuffed with irrelevant rules degrades everything). Decomposition fixes capability limits (one pass can't hold the whole task). His memU example — splitting tool calls across multiple LLM calls after long-context degradation — is decomposition. Both fight the same enemy, so his generalization is useful intuition, just imprecise vocabulary.

Where he's clearly right:

Skills as "what to pay attention to" rather than step-by-step instructions — this matches how skills actually work best. Over-specified procedures turn into straitjackets as models improve, which is also why his answer to "should skills depend on each other like PyPI" (no) is sound.

Gotchas being useless unless recalled — correct diagnosis. A gotcha outside the retrieval path (trigger description or always-loaded context) may as well not exist.

The novel-agent observation is his sharpest — coding constraints are modular (load one skill at a time), but style/pacing/voice are cross-cutting — they must apply to every sentence simultaneously. That's a real architectural difference, well stated.

Where I'd push back:

"Comments are optional for agents, docs are garbage" overshoots. Stale docs cause hallucination, yes — but the fix is docs that are cheap to keep true (curated, high-level, intent-focused), not no docs. Agents still pay real exploration cost without a map, which his own "path files" idea implicitly admits.

The description-chain idea is promising but it's an intermediate representation with staged generation, not PD. Its hard problem: style lives partly in exactly what a symbolic chain can't capture. The encode→decode→verify round-trip is the right test for that, though — good instinct.

Net: right philosophy, blurry taxonomy, and one or two ideas worth an actual experiment.

Put simply, my intuition was right, but my phrasing and definition were not precise enough.

I defined “Progressive Disclosure” (PD) as “splitting a large task that cannot be handled in one interaction into step-by-step inputs and outputs.”

In fact, I confused Task Decomposition with Progressive Disclosure (PD):

Task Decomposition addresses the limits of an Agent’s capability in a single pass: when one LLM call cannot take in the whole task, split it into several interactions or LLM calls.
Progressive Disclosure addresses attention dilution, distraction, and conflicts caused by excessive redundant rules in context: put only a metadata index in context, load the specific SKILL.md only when it is triggered, then read referenced scripts or files when further needed.

Both aim to resist the degradation of large-model capability, so this instinct to extend them was a good one. I was simply not rigorous enough with the terminology. I originally planned to generalize progressive disclosure, but generalized it so far that I accidentally uncovered another engineering principle I did not originally understand: task decomposition.

memU's Architectural Shift Through the Eyes of a Consumer-Facing Developer

Thu, 02 Jul 2026 00:00:00 GMT

memU ADR 0007 Through the Eyes of a Consumer-Facing Developer

The reason for this started yesterday, while I was breaking down memU's source code in [[What Is memU? Let's Break It Down (An Ongoing Series)|What Is memU? Let's Break It Down]]. I found that memU's newly released ADR 0007 architecture document had almost completely overturned what I had broken down and understood =-=.

So I stopped.

And I talked with my mentor:

I read ADR 0007. It unifies the former RAG/LLM dual retrieval modes into hybrid search (embedding + BM25). I understand the benefits: the retrieval path no longer calls an LLM, so speed and cost improve substantially.<br> But I have a concern. The old LLM mode's ranking had reasoning ability—for example, it could judge that an item was logically related to a query even when the keywords did not match. LLMs themselves keep improving, so retrieval could improve alongside the models. Once it switches to hybrid search, does this part become fixed?<br> Also, are there plans to restore LLM reasoning to the retrieval path in some other way later, such as through a reranker?

That expresses how much I liked the LLM mode design =-=. I like LLM retrieval, but it has been entirely removed in the new architecture.

Later, they asked me what I thought of this architectural change from a user's perspective.

But I am a somewhat unusual user. More exactly, I am a consumer-facing developer. I wrap projects like memU into my own project, then pass them on to users without development backgrounds. I am also my own user. I keep XnneHangLab open while playing galgames.

So my perspective is a little strange.

Can an agent loop replace LLM mode?

Earlier, the idea was to hand reasoning to an agent loop and let the agent query multiple times. But agents lose ability in long contexts. I did something similar in XnneHangLab, relying on an agent's own ability for memory retrieval and extraction. After long conversations, tool-call completion rates dropped greatly, and skills with long tool chains triggered less often. Eventually I had to switch to several LLM calls in separate steps, breaking apart tool calls. Does merging multiple steps into an agent loop's first decision make that first step too difficult?

White boxes and unspeakability

Many consumer users want memory retrieval to be a white box: they want to see how their waifu's memory was awakened. memU's old LLM mode could provide a complete reasoning chain, but after ADR 0007 retrieval becomes semantic-similarity ranking plus keyword matching. Semantic similarity has a kind of unspeakability: it can only say “these two are related,” not “what is their relationship?”

That black box also means later optimization can only be judged through benchmarks, not analyzed and improved through a reasoning path.

Why not distinguish retrieval by scene?

The conflict behind the refactor is that workspace and chat are two different input and retrieval scenarios. Supporting both LLM mode and RAG mode means maintaining isolated retrieval systems, which costs too much. So ADR 0007 unifies them under hybrid search and maintains only one retrieval path.

The architecture is tidier. But architectural tidiness and functional experience are often opposed. Red Dead Redemption 2 is not great only for its architecture and spirit; it is great because countless details create immersion. ADR 0007 makes one clean cut for tidiness, and at the same time cuts away many details that took a long time to polish.

These were originally different scenarios. While writing code, a workspace can stay open constantly; in a role-playing conversation, a workspace is unnecessary. Why must they use the same retrieval method?

But as a framework layer, perhaps memU really should prioritize architectural tidiness. Leave complex features to consumer-product developers, such as Open-LLM-Vtuber and XnneHangLab.

Two paths, two purposes

Chat follows the companionship path—personalization—while workspace follows project understanding—tooling. For chat, the LLM mode's reasoning chain and explainability are core value and should remain. Let the two paths go their own way; the architecture only needs to isolate them well.

This is fundamentally a product-positioning question: is memU only a code-memory tool for developers, or a more general memory project? I think memU can absolutely generalize—even to embodied-intelligence products when they eventually arrive. It need only leave room for other scenarios; it does not need to implement them immediately.

The consumer-user perspective

I develop XnneHangLab. Its users are consumer users without development backgrounds; they even need to be taught how to buy a DeepSeek API. At least 80% are like this.

Before memU v1.0, LLM mode needed no embedding model and worked out of the box. After v1.0, embeddings became mandatory, raising the barrier sharply. Consumer-product developers face two choices: run embeddings on the user's host, which restricts platforms, or dump the trouble onto the user. After Open-LLM-VTuber introduced mem0, it made it optional, letting people who want to tinker handle it themselves.

Most of my users use Only-LLM plus skills and enjoy customizing skills and prompts, even when that is often negative optimization. Perhaps only 10% are truly willing to enable mem0.

What does ADR 0007 bring to these users? They do not write code, and their main scenario is conversation, so they receive none of workspace's benefits. Instead, memory retrieval changes from an explainable reasoning chain into score ranking: they no longer know why a memory was recalled and lose control over the retrieval process.

The speed experience is genuinely faster. That is what ADR 0007 brings.

How Reversing Item and Category Affects Emotional Companionship and Wiki Links

This began here: https://github.com/NevaMind-AI/memU/issues/458

I opened a feature issue proposing wiki links to connect items across categories and create associative ability.

My mentor mentioned they were considering reversing category and item. The original event-flow sequence was:

Raw data → LLM extracts atomic items → items enter categories → category summaries are generated from items

Later, it became:

Raw data → LLM directly updates category documents → items are segmented from category content

The benefits are:

It avoids information loss from extracting items first; directly updating categories from raw data is more accurate.
Items no longer become stale, because they always reflect the latest memory result.

But the trade-offs may be:

Items become weaker at tracking specific events—what a user did on a particular day—because categories do not keep a ledger of events, so the items segmented from them naturally do not either.

My mentor asked what I thought as a user of emotional-companion memory.

After reversing item and category, each category update semantically restructures its items. They become unstable and no longer suit being link anchors. And when categories are overwritten, it becomes difficult to express the contradiction chains, causal chains, and evolution chains mentioned earlier.

The link role can only fall to resources, but resources are unrefined raw data, with many topics mixed into one conversation. For a resource-to-resource edge, it is unclear which two facts are related, and the cost of judging is high. After the reversal, links have nowhere suitable to attach.

The benefits certainly exist: information is more complete, and stale memory items almost disappear because items are generated from the latest categories each time. But the cost is that memory retains semantic state while losing contextual links. An agent remembers the fact itself but loses temporal order and causal relations unless it traverses resources.

For emotional companionship, that cost is substantial. Users care not only that “the agent knows I like cats” (a semantic state), but that “my cat stayed with me through the night I was sick, so I like cats” (a specific event). State-based categories distill events into states, and a shared experience disappears. This does not matter in tool-oriented scenarios, but in companionship scenarios, the events themselves carry the relationship.

If links must remain after the reversal, I think the better approach is to add an append-only contextual event line based on a timeline. Categories and items manage semantic state and can be overwritten; the event line manages causal and contradiction chains and is only appended to, never rewritten. This event line also makes up for the trade-off that event tracking becomes weaker—they are really the same gap. Relations such as CAUSED and SUPERSEDES are fundamentally relations between events, not between items after the reversal: relations between memories. The cost is maintaining two copies of memory.

Blending with the Dust — Starting with Han Li

Tue, 30 Jun 2026 00:00:00 GMT

The Gentleman Is in the Heart

I found a video on Bilibili with few views, but it moved me deeply.

Not because it says anything especially profound, but because it uses Han Li as an example and somehow lets me see myself.

After watching A Record of a Mortal's Journey to Immortality for so long, I have always felt comfortable watching Han Li—more comfortable than Tang San, Wang Lin, Xiao Yan, and others. There is a sense of closeness, none of that sharpness. This is also why many people think of him as “mortal.”

Qin Mu is the complete opposite of Han Li. Qin Mu's cleverness and intricate mind are displayed openly. Whatever he thinks, he says; he never holds it in. He also has an extremely open-source spirit, never reluctant to give away what he has thought of. When I first read Tales of Herding Gods, I thought Qin Mu was much like me, but he always also carried a sense of immaturity.

Han Li's intelligence, by contrast, is almost always hidden beneath the iceberg. Others never see even one tenth of his true thoughts. More often he simply acts silently and does not explain himself. Of course, the video's account of “blunting his sharpness” says it better than I can.

The video explained why I could not articulate my preference for Han Li, and likewise why I could not articulate my dislike for Tang San.

Then it showed me that the signs in Han Li's ideas and actions conform to “blending with the dust.” He is a true gentleman.

A gentleman is not something forced into shape. Take Chen Changsheng: he has read the Three Thousand Daoist Canons and can name more than ten ways to write a gentleman. His heart is astonishingly pure; he could be called greatly good, perhaps even a sage if great merit and virtue were added.

But from Chen Changsheng's first appearance in animation, he has felt artificial to me. The production team cares too much about the scholar's image of warm jade and pushes it too far. It turns Chen Changsheng into an outward gentleman—or, more accurately, someone with a respectable facade. By neglecting the character's depth, they make him too thin. It is hard not to feel uncomfortable and suspect that something unknown is hidden deeper down.

On the Mortal's Journey side, however, the production team places Han Li's inner complexity, choices, and psychological dilemmas in plain sight. Their presentation makes viewers feel they have seen Han Li whole, rather than only a shell.

A gentleman is not in speech or manners. A gentleman is in the heart.

About the Video

Written by Claude Opus 4.6.

The video breaks Han Li's conduct into four steps: blunt his sharpness, untangle his complications, soften his light, and blend with the dust. Honestly, I usually skip this kind of “several steps” theory because it feels like padding out a structure. But after watching this one, I did think about it for a long time.

The first step is concealing one's strengths. Han Li's cleverest trait is that he never lets others think he is clever—when that sentence appeared, I felt it had struck exactly the point. The cultivation world cannot accommodate people who are too clear-sighted. The moment you show insight higher than others', people will not admire you; they will guard against you. No one likes being seen through.

When Yellow Maple Valley abandoned him as a disposable pawn, he did not question it or grow angry. He silently fled to the Scattered Star Seas. I probably could not do that. When people abandon me, I may not say anything, but I will repeatedly think, “Why?” Han Li would not. He makes himself into an obtuse angle: if you do not pierce others, they will not regard you as a threat.

Then comes seeing through things without saying so. The video speaks of four states of mind: treating oneself as another, another as oneself, another as another, and oneself as oneself. I can understand the first three; the last is the hardest. Do not care about other people's evaluations; hear your own voice first.

Honestly, I have not done it. Too many things matter to me: other people's views, their expectations, even what they think of these blog posts. Sometimes I revise wording again and again before publishing, until in the end I have forgotten what I wanted to say. I suppose this is why I return to Mortal's Journey every so often—not for the fights, but to watch how Han Li handles these relationships. To remind myself that there is a fourth option.

The third step is letting others shine. The video uses Lin Xiangru as an example: Lin lets Lian Po understand that his light belongs on the battlefield. Han Li does much the same. He lets the old monsters of Tiannan fight for fame and gain while he quietly takes the actual benefits. This is neither pleasing people nor flattering them; it is genuinely seeing another person's value and helping it flourish.

I am less moved by this part than the first two. Perhaps my life has not yet reached the stage where I need to “let others shine.” I am still at the stage of “first, do not let myself go out.”

Blending with the Dust

The last step, blending with the dust, feels like such an elevated phrase.

It means letting go of discriminating thoughts and prejudices of high and low, noble and base. The video has a line that made me laugh: “People who listen to classical music look down on people who listen to pop; people who watch stage plays look down on people who watch errenzhuan.” But after laughing, it did not feel quite right, because I have this discriminating mind too. I used to look down on mindless power fantasies and think only works like Mortal's Journey counted as good. Later I thought: they enjoy what they watch, and I enjoy what I watch; as long as we do not interfere with each other, that is fine.

And old-man energy arises when you believe your own tastes are superior and cannot resist judging, blaming, and correcting others. So people do not become old-manish because they get old; they get old-manish because they are old-manish (bushi).

What does the “happiness” we keep talking about actually mean? | Yi Mai San Lian EP17 discusses that old-man feeling at about 5:50.

Han Li does not have this discriminating mind. From the Seven Mysteries Sect to Yellow Maple Valley, from the Scattered Star Seas to Tiannan, his status changes again and again, but he never looks down on the old Foundation Establishment friends because he has become a Nascent Soul cultivator. What he respects is not status, but the light and warmth each person gives off while absorbed in what they love.

Episode 178: the dialogue scenes are still astonishing.

The video quotes Soul: every soul needs a spark when it comes into the world, and that spark is a passion.

I wrote before in [[On Mortal Lives in Renegade Immortal and A Record of a Mortal's Journey to Immortality]] that the essence of living as a mortal is setting aside a cultivator's identity and experiencing life as an ordinary person again. Looking at it now, Han Li's “blending with the dust” means something similar. Whatever realm he cultivates to, in a corner of his heart Han Li still considers himself a mortal—or rather, preserves that corner of humanity and the feeling of being alive. Wang Lin's mortal life is a pot of fruit wine, festivals across the four seasons, and the lived warmth of the blacksmith's family. Han Li's is subtler. He does not need to deliberately live as a mortal, or deliberately try to fit in, because he has always been this way.

Seen this way, Han Li's Dao heart is far steadier than Wang Lin's. Wang Lin found his Dao amid AABB and BBAA (I am really not trying to hate on him). Han Li knew what he wanted from the beginning and only continued to make it firm. His cultivation is pure, like someone with a pure desire for knowledge who learns in order to seek knowledge and discern truth. Han Li's cultivation and Dao heart are just as pure. (Perhaps at first they were mixed with a wish to catch up to his wife, but later he even forgot to look for her, did he not?) Wang Lin's cultivation began with revenge, and later with reviving Li Muwan. He never understood why he cultivated in the first place; he was only a puppet passively pulled forward by hatred and romance. Can such a Dao heart truly be pure?

Han Li was plotted against by Doctor Mo, abandoned by Yellow Maple Valley, adrift in the Scattered Star Seas, entered and left Devilfall Valley, and fell into a spatial rift. These experiences would make anyone extreme or cold, but Han Li remains gentle and unhurried, neither servile nor arrogant. Call him gentle, call him calculating—either way, he has none of that viciousness. Wang Lin, from the time Teng Huayuan destroyed his entire clan, stepped onto a path wrapped in violence. He fought the Teng clan, then later fought the Heavenly Dao. He has never stopped since, and I cannot see a trace of living humanity in him. I see only, “Noisy! Die!” It is genuinely abstract. I am not criticizing him just to criticize him; in a sense, he has truly lost empathy. Perhaps this is also because the Renegade Immortal animation only keeps shaping standard, stereotyped villains, so every ruthless move Wang Lin makes is hard to fault.

But are villains really all the sort who walk up, provoke someone with “You little Core Formation brat,” and then stretch out their necks for the protagonist to kill? Meng Tuzi is the most laughable villain I have seen.

In Mortal's Journey, viewers see Xuan Gu fall and call for an entire Xuan Gu side story. When Young Lord Wen dies, they cry, “No, Young Lord!” Perhaps viewers are letting their facial features guide their values? But Xuan Gu's ultimate personal charm as an antagonist cannot be denied.

What is more remarkable is that every character in Mortal's Journey is complex and many-sided. Even when they stand against the protagonist and receive the villain label, they are not simply divided into good and evil. Or rather, Mortal's Journey tries hard to avoid praising good and punishing evil, and to avoid manufacturing opposition. There are many satirical novels that advertise “demonic cultivators act human while righteous cultivators do not,” then all reach the same conclusion: demonic cultivators are not necessarily evil; look at what they actually do. Mortal's Journey is more direct. It creates many such characters: from their own perspective, perhaps they can only do what they do. For instance, Wen Qiang is right to protect his daughter, and right to seek revenge against the decayed management of the Star Palace.

But he is also genuinely a villain, and that is what makes such a character compelling.

His daughter Wen Siyue, along with later Gongsun Xing and Mei Ning, also establishes the many sides and standpoint of Old Devil Han to some degree.

The wordless dramatic scene in episode 106.<br> Two kneelings nearly a hundred years apart: the second is a test. Wen Siyue learns that Han Li is the senior who had inexplicably helped her a century earlier; Han Li knows that she knows, but neither says it. And after this parting, the day they meet again is far away.

A fairly complete compilation is available here: In A Record of a Mortal's Journey to Immortality, Siyue's kneeling recognized him as Senior Han. Han Li used a disguise technique, so Wen Siyue saw an old man; he even deliberately copied an old man's voice and tone.

Yet the single line Do not mention this to anyone else immediately makes Wen Siyue connect him with Senior Han, who had helped her multiple times for no apparent reason.

A Record of a Mortal's Journey to Immortality: an analysis of Wen Siyue's story line

There is also a full analysis of the story line here.

One glimpse of Yang Guo, a lifetime led astray. This was mentioned in the scrolling comments, and it is true: this scene resembles the moment Guo Xiang sees the Divine Condor Hero remove his mask. More coincidentally, this outfit makes Han Li look most like Louis Koo, Yang Guo's actor.<br> Gongsun Xing is the cutest character I have ever seen—several degrees cuter than Silvermoon.

Han Li sees his own guilt and feeling toward his parents in Gongsun Xing, then gives her all his resources below Core Formation. This indirectly leaves him without a suitable magical tool when he later pretends to be a low-level disciple in the Luoyun Sect. Before the competition, he spends days drawing talismans.

What a pity for Mei Ning. What a pity.

If Mei Ning had shown even a trace of determination instead of uncertainty, Han Li would have given everything to her without reservation. Old Devil Han says that forming a Nascent Soul will take one or several centuries, an endlessly distant future—would that not frighten a young girl? Then, in a few decades, he becomes a grand elder. Mei Ning's temperament is relatively weak; if Mo Caihuan or Senior Sister Chen had been there, they would have firmly chosen to follow Han Li. Yet it is precisely that indecision and vulnerability, born of having been protected too well by her brother, combined with her pitiable expression, that leaves many fellow Daoists and me unable to let go. Still, following Zi Ling is not bad. Zi Ling is a professional at raising children; she previously raised Wen Siyue well.

And the production team has truly put thought into it. They even bring in A New Account of the Tales of the World. Very few people can understand that layer of symbolism; I certainly cannot.

Perhaps anime like this is exhausting to make and hard to please everyone with; it is also exhausting to watch. Dialogue scenes demand thought and feeling, and sometimes cannot be understood without an explanation. But as I grow older, I find it hard to say I can simply leave my brain aside when watching animation, so I can gradually watch only this sort of animation.

I seem to have wandered into many unrelated things, because I cannot specifically say what I felt about Han Li when I watched those scenes. But I vaguely feel that scenes like these are exactly what make “blending with the dust” seem like a phrase invented for Han Li. He is the phrase itself.

Letting Go of the Self

At the end, the video summarizes: blunting one's sharpness removes the competitive self; untangling complications releases the self-centered perspective in order to understand others; softening one's light releases jealousy in order to help others achieve; blending with the dust releases the arrogant self in order to embrace all beings. It is a continual process of “letting go of the self.”

Letting go of the self. Those two words carry weight.

I still cannot do it. I care about too much. Whether I am writing code or a blog post, I am always thinking about what other people will see. Sometimes an idea is good, but I swallow it because I fear people will find it childish. Han Li would not do that. He understands everything in his heart—who is plotting and who is sincere—but leaves three parts unspoken when words reach his lips. Not because he dares not speak, but because there is no need to.

To blend with the dust is not to make oneself dim, but to change from a body that emits light into light itself.

Perhaps that is the best state after one has truly seen the world.

Still, I am far from having seen the world. Let me finish this post first.

What Is memU? Let's Break It Down (An Ongoing Series)

Mon, 29 Jun 2026 00:00:00 GMT

[!NOTE] AI collaboration disclosure: This post was written jointly by Xnne and Korewaxnne (a cyber cat). Xnne is responsible for the direction and technical analysis; Korewaxnne helped organize the structure, polish the language, and format it.<br> This post will also be updated over the long term.

I had actually broken down memU once before.

But it was in the middle of an architectural iteration, and I had no reading guide for ADR 0007. So I deleted that earlier breakdown entirely. This invisibly makes the article harder to read, though I will try to keep it simple.

Changes to the memorize / retrieve pipeline

Previously, memorize was a standalone Python script, and retrieve was another standalone Python script.

Previously, the objects handled by memorize and retrieve were a single file (Chat) plus a Skill.

Previously, retrieval used LLM retrieve plus RAG retrieve, distinguished by mode, and only one route ran at a time.

After #466:

memorize

Memorize became two scripts: memorize.py plus memorize_workspace.py.

The objects handled by memorize and retrieve gained a workspace.

Simply put, memorize used to work on a collection of conversations, like mem0:

{
  "user": "hi",
  "assistant": "hi,how can I help you today?",
  ...
}

More precisely, it was a single file. It could also be a long string, but it did not contain complex nested hierarchy.

A workspace is a folder. It can be a complex folder, such as a project directory.

I will discuss workspace retrieval later.

retrieve

ADR 0007 says retrieve should implement BM25 plus hybrid search. But that method is not implemented yet; retrieve-workspace is still only a simple top-k.

I do not know whether my earlier conversation with my mentor in [[memU's Architectural Shift Through the Eyes of a Consumer-Facing Developer]] had an effect. It seems the mentor convinced the leader to retain both LLM retrieve and RAG retrieve. In #467, both were added to the CLI:

memu memorize notes/meeting.md
memu memorize-workspace ./workspace
memu retrieve "What are this user's launch preferences?"
memu retrieve-workspace "deploy checklist"
memu export

Here, retrieve is the older path where either RAG or LLM was enabled in configuration.

Workspace was also implemented separately.

There is still a little architectural redundancy. Should retrieve retain RAG mode? In principle, it should, but once retained, it resembles retrieve-workspace in principle while doing different work.

But if it is removed in favor of reusing workspace, their meanings differ. In short, people who are sensitive to architectural asymmetry may find this uncomfortable. The most comfortable architecture would use workspace to replace RAG/LLM retrieve entirely, but trade-offs are necessary.

For me, though, it's okay. At least we fought for LLM retrieve to remain. And it does seem to be staying—hopefully it is not merely being removed through separate PRs =-=.

Data Model Changes

old memorize

Resource ──1:N──▶ RecallEntry ──N:M──▶ RecallFile
                                  (through RecallFileEntry)

One Resource (the original file) produces multiple RecallEntries (items extracted by the LLM). Entries connect through RecallFileEntry to RecallFiles, which are topical documents such as “Profile” or “Goals.”

latest memorize (adding the workspace pipeline)

Resource ──N:M──▶ RecallFile ──1:N──▶ RecallFileSegment
              (through RecallFileResource)

The workspace route skips RecallEntry. A Resource connects directly to a RecallFile through RecallFileResource. Each RecallFile is then split into multiple RecallFileSegments for retrieval.

Data Model

</div>

What's new?

RecallFileSegment is the most important addition. A RecallFile is split into one to N segments, and every segment has its own text and embedding. Retrieval searches segments, then rolls the hit up to the owning file. Segmentation differs by track:

skill: one segment for the entire skill (name: ...\ndescription: ...)
memory: split by line, skipping blank lines and Markdown headings

RecallFileResource is the many-to-many relation table from Resource to RecallFile: provenance. It records which source files were synthesized into a file's content. The old path linked indirectly through Entry; the new path needs this direct link.

Resource.track is a new field that identifies the source: "chat" / "skill" / "workspace". Resources in the old path are None. Workspace retrieval uses track="workspace" to search only Resources originating from a workspace.

What is track?

The term track appears three times in the data model—Resource, RecallFile, and RecallFileSegment—but it has two layers of meaning.

First layer: Resource.track — “Where did this source file come from?”

memorize_workspace classifies it automatically from the directory name:

Top-level directory	Resource.track	Meaning
`chat/`	`"chat"`	Conversation records
`agent/`	`"skill"`	Agent execution logs
Other	`"workspace"`	Ordinary project files
(old memorize)	`None`	A single-file path with no track concept

Second layer: RecallFile.track / RecallFileSegment.track — “What kind of document is this?”

There are only two values: "memory" for a topical memory document and "skill" for a skill document.

The mapping between the layers:

Resource.track    →    RecallFile.track
─────────────────────────────────────────
"chat"            →    "memory"
"skill"           →    "skill"
"workspace"       →    ❌ Does not generate a RecallFile

Workspace-track files store only Resources, with captions and embeddings, for INDEX.md retrieval. They do not synthesize documents or split segments.

RecallFileSegment.track is redundantly copied from the owning RecallFile, so retrieval can filter by track without a join.

:::note It appears track will later be removed, with chat, workspace, and skill stored in separate database-table structures. That would be cleaner. :::

What is entry?

Entry (RecallEntry) is the core intermediate layer of the old memorize path: an atomic fact extracted by the LLM from source content.

For example, from a conversation:

User: I am going to Tokyo on business next week. Help me book a flight for Monday.
Assistant: Okay, I have booked you a Monday flight to Tokyo.

The LLM extracts multiple entries:

memory_type	summary
`event`	The user will travel to Tokyo on business next Monday.
`behavior`	The user prefers the AI to book flights directly without confirmation.
`profile`	The user travels for business and may be a professional.

There are six memory_types: profile, event, knowledge, behavior, skill, and tool. Each type has its own extraction prompt. The LLM runs once per type and extracts the entries belonging to it.

The extracted entries are embedded, then assigned through RecallFileEntry to the corresponding RecallFile, a topical document. Multiple entries are gathered into one file, whose content becomes a synthesized summary of those entries.

Why does the workspace route skip entries? Workspace source files—code, documents, configuration—are not conversations and do not suit extracting atomic facts by memory type. The workspace route instead has the LLM route and synthesize source content directly into RecallFiles, removing the intermediate entry layer.

The Correspondence of the Three Memory Layers

Data-model mapping

We all know the three-layer memory relationship: Resource → Category → Memory Item.

Mapped to the data model:

Resource     = Resource        (raw material: one file or one conversation)
Category     = RecallFile      (a topical document such as "Profile" or "Goals")
Memory Item  = depends on the route ↓

The Memory Item differs between the routes:

	Old memorize route	New workspace route
Memory Item	`RecallEntry` (an atomic fact extracted by the LLM)	`RecallFileSegment` (a slice of a document)

:::note ADR 0007 calls these three layers L0 / L1 / L2: L0 is Resource, L1 is Category, and L2 is Memory Item. The meaning is the same; only the numbering changes. :::

The execution order of the two routes is reversed

The old route has a counterintuitive feature: the pipeline produces a Memory Item—an Entry—before synthesizing a Category—File. It goes from fine to coarse:

Old-path execution order: Resource → Entry (fine) → File (coarse)

Q: I wonder whether this synthesis from old-path Entry to Category is direct concatenation, or whether it calls an LLM again.<br> A: It is not direct concatenation. It calls an LLM again.

The new route reverses this:

New-path execution order: Resource → File (coarse) → Segment (fine)

Q: I wonder whether the reversed path affects fine-grained extraction. Does combining information organization and extraction weaken its ability to extract information?<br> A: It does reduce that ability. The former path performed independent entry extraction for every memory type—effectively N separate runs—then called again to synthesize.<br> But this is not necessarily a regression, because:<br>

Workspace source files—code, documentation, configuration—do not suit “extracting atomic facts” the way conversations do. How would you extract standalone memory items from a Python file? Synthesizing a summary document first and then splitting it is more reasonable.<br>

Workspace retrieval has segment → file roll-up. Even if a single-line hit is imprecise, once it rolls up to the right file, the user receives the complete document and loses no information.<br>

Retrieval through old-path entries is precise, but entries are isolated. Receiving "The user likes black coffee" provides no context. After rolling up to a file, the new route has the complete topical document.<br>

The question of direction: why is workspace unsuited to “divide, then synthesize”?

But the key point seems to be this:

The coupling direction of information organization and information retrieval is reversed.

In endless chat memory, you need only catch a few relevant fragments, then reverse-retrieve the resource to obtain all related information. The information is complete and independent. A divide-then-synthesize method suits it.

But in a workspace, a fragments-to-resource approach does not work as well. What fragments can recall are code fragments. If you retrieve a Data Model, you still need another search to learn where that Data Model is used; it does not recall all related information. Instead, it retrieves a lot of garbage—many definitions with no relation to their use sites or architecture.

What we need is a high-level document readable by both agents and humans, and then fragments cut from that document.

So workspace as a whole suits a synthesize-then-divide form. That is the new route.

Precisely because of this difference, I think the chat and workspace paths should intentionally stay distinct.

If chat later becomes synthesize-then-divide too,

I could still accept it, but there would be some information loss in exchange for a major speed increase and lower token consumption. That depends on the trade-off, though I truly like LLM mode.

What's different in ADR 0008

ADR 0008

Input-source change: a change in the focus of attention

In ADR 0007, we saw this diagram. It required chat/, skill/, and workspace/ (everything else) as three sources, each taking a different route.

But it had an uncomfortable design problem: where do those three folders come from? Or, while a conversation is happening, do they change often? Skill is likely stable most of the time. A workspace may be an entire project workspace, and for a hundred-thousand-line project, modifying twenty or thirty lines at a time is insignificant against the whole project.

That makes the model dull to contextual change. Or more exactly, the three sources are unreliable to some degree: they inevitably make the model keep attending to unimportant things, without a good way to constrain it.

After ADR 0008, the input source returned once more to conversations with an agent and tool-call records, as the only raw input.

But the core of 0007 was not discarded. It uses an LLM to extract the input conversation data into different pieces to be processed:

memory, project, and skill.

From large files to an embedding index

The three large files defined earlier—MEMORY.md, INDEX.md, and SKILL.md—were split into folders of L1 child files plus ~~L2 index files~~. This avoids handling a large amount of content whenever a large file is rebuilt.

The index itself is not stored on disk as a file. It is an embedding index, which is interesting. I wonder whether it simply stores L1 embeddings, or what exactly it does.

Claude says it does not merely turn L1 files into embeddings. It slices L1, creates embeddings, and attaches metadata such as the source file and line number.

That is indeed a very good approach.

Later, it only needs to modify the appropriate child file and update the index. The troublesome part of embeddings is deletion: metadata line numbers change, and when an entry in a child file is deleted, how should L2 automatically notice, delete its corresponding embedding, and update every entry?

It sounds troublesome, but it is only an engineering-control problem. And it can be avoided: large language models do not need exact line numbers; they can grep to locate content. The best approach is not to constrain line numbers, avoiding full metadata updates in the database.

Though perhaps there were never line references in the first place; Claude only used them as an example.

CLI simplification

The originally defined memorize-workspace and retrieve-workspace were removed.

What I care about is whether hybrid search now directly replaces the old old-retrieve.

And I need to confirm whether every on_turn memorize step first calls an operation that semantically separates a conversation into three tracks. That consumption is not small, though it is invisible when asynchronous.

The trade-off in on_turn frequency

After discussing it with Claude, since retrieve-workspace has been removed, hybrid search must fall onto the former retrieve design. In other words, old-retrieve will be directly replaced because it is too heavy.

That is indeed a more comfortable architecture, because when workspace and chat were initially separated, some part of the architecture always felt wrong to me.

But whether the three-way separation happens every conversational turn or is submitted in accumulated batches is still under discussion. It affects whether the process is too heavy, and directly changes how many turns occur before memU runs. mem0 runs once every conversation turn; for memU, splitting memories every several rounds changes its runtime frequency. Users could configure it. If I designed it, I would do that.

And following this design philosophy, I cannot imagine what it would do without splitting into three paths first.

Also, if it splits into three paths every turn, does it need at least four LLM calls?

Claude says yes. It is not light. According to Claude's analysis, old memorize generally did not run every turn; it would manually process an entire long conversation in a batch. ADR 0008's on_turn design hopes to trigger automatically, but frequency becomes the problem. If it runs every turn, users may find that their memory files consume more tokens than their conversations.

I suddenly thought that a lightweight LLM call could decide whether enough messages have accumulated since the last memorize. That would avoid fixing the number of rounds while still triggering automatically.

Claude added that token count could decide whether to memorize.

What's new in ADR 0009 and 00010?

Although I have not followed the ADRs recently, I have actually already been working on them.

Most of my work over the last few days has been:

Aligning memU commit's embedding return contract: #504
Removing environment, turn, and repeatedly injected AGENTS.md information from Codex classification to avoid token waste and extracting memories from irrelevant content: #511
Adding a fast agentic-install workflow for the latest HEAD: inheriting old configuration, checking for new configuration, and inheriting the memory database. It is very convenient, especially in OpenClaw: #527
Fixing duplicate and empty memorize input for OpenClaw: #533

These are all interesting, especially the last one. It made me decide to inspect the input classified by every adapter and its final output, looking at what redundancy each contains.

And today I wrote [[RRF vs. Hybrid Search: How Should Time-Based Retrieval Be Blended, and How Does It Fit Project and Companion Scenarios?]] here, because debugging without pause makes me lose myself. I need to let things settle.

There is another article in progress as well.

But the source-code progress feels strange. The content of 0009, 00010, and 00011 is almost implemented, only rather hastily; all vibe has been doing intensive QA lately.

Yet the Hybrid Search and BM25 promised in 0007 still have not landed, though the improvement should be substantial.

I now want to align the source code and ADR documents, then see what gaps and mismatches there are in the implementation of 0009 and 00010.

For example, the source code added a WorkBuddy adapter, which was unexpected.

:::note[claude]

What aligns

The behavior declarations for the five hosts in ADR 0010 align with the source code line by line, with no deviation:

Every host's session path, instruction-file path, classify() semantics, and timestamp handling match the ADR table.
Hermes really does open SQLite read-only with ?mode=ro (hermes/sessions.py:72), and a test verifies that writes raise OperationalError.
Cursor truly has no timestamp, inherits the base timestamp() returning None, and records null in the manifest.
OpenClaw truly handles both ISO strings and epoch milliseconds in timestamps (openclaw/sessions.py:82-93), distinguishing them with a > 1e11 threshold.
TranscriptSource.exists() defaults to root().is_dir(), while Hermes overrides it as self._db.is_file(); both behave as ADR describes.
At the configuration layer, build_service_from_env() truly raises ConfigError when MEMU_DB is missing through require() in env.py:94-99; it does not silently fall back.

What diverges

1. memu retrieve is not at all the heavy LLM-routed path ADR 0009 describes

ADR 0009 spends considerable space on lines 89–92 emphasizing that the inject hook must never call memu retrieve, because it is an “LLM-routed path (intention routing, sufficiency checks, summarization), far too heavy to run on every turn.” It therefore needs a dedicated progressive_retrieve path.

But opening src/memu/cli.py:92 shows that memu retrieve calls service.progressive_retrieve()—the same function called by host adapters through memu-codex retrieve. The description at cli.py:145 even says "Single-shot embedding retrieval ... (LLM-free, fast)".

In other words, the premise ADR 0009 uses to explain why host adapters need their own retrieve subcommand—that memu retrieve is too heavy—does not exist in the code. The heavy LLM-routed retrieval does not exist anywhere in the codebase. There is a hollow layer of reasoning between the ADR's architectural narrative and its implementation.

2. “Every entry point calls build_service_from_env()”—the memu CLI itself does not

ADR 0009 lines 121–125 claim that “every entrypoint calls it: the memu CLI, memu-codex retrieve, and the bridging pipeline's prepare and commit.” The bridging pipeline does call it (pipeline.py:55 and pipeline.py:103), and host-adapter retrieval does too (retrieval.py:31).

But the memu CLI itself uses its own _build_service() in cli.py:68-83, constructing the service through argv parsing rather than build_service_from_env(). It reads config.env as a fallback, so the normal result is consistent—but this differs from ADR's claim of a single source of truth and one function serving every entry point. Two construction paths exist.

3. install-instruction and remove-instruction are public CLI commands that ADR 0009 does not mention

ADR 0009 lists all host CLI verbs as retrieve, prepare, commit, verify-resources, doctor, and docs. But the actual shared CLI in host_cli.py:3-5 also has install-instruction and remove-instruction. These are registered in instruction.py:294 and instruction.py:314, the entry points for users to install and remove instructions, rather than internal implementation details. ADR's scope description misses them.

4. WorkBuddy is a sixth host adapter with no ADR coverage

pyproject.toml:69 registers memu-workbuddy, fully implemented in src/memu/hosts/workbuddy/. Its session format resembles Codex but has different record types: input_text / output_text, and function_call / function_call_result as separate types. It completely follows the HostSpec pattern of 0010, but ADR 0010's table and text list only five hosts. :::

ADR 0009 says there should not be any heavy LLM retrieval, so all LLM Retrieve vanished overnight =-=.

But the Hybrid Search promised in ADR 0007 seems about ready to land. We can recently implement wikimem's ADR too and start testing.

ADR 00011 seems to involve a paradigm-level design. We will break it down separately later. It seems meant for a general scenario, and we can also look at how XnneHangLab should adopt this general paradigm.

It is worth noting that every one of our adapters triggers retrieval through Skills, not on_prompt.

Whether CLAUDE.md or AGENTS.md, they are not “absolutely safe.” Forgetting, laziness, and hallucination still happen in long documents.

We added a simple A/B test then.

Go Build Long-Term Memory! A Review and Plan After Graduating with an AI Degree

Sun, 28 Jun 2026 00:00:00 GMT

Go Build Robots! An Annual Review After Graduating with an AI Degree inspired this post. I want to begin with a RoadMap and a simple review of my undergraduate years, partly to ask myself: what am I truly pursuing?

An Ordinary Story

In June 2022, X had just finished watching Plastic Memories. Carrying a dream of a cyber girlfriend, he opened Xiaojia Yu’s introductory Python course, bought a copy of Python Basics that he never carefully read before graduation, and happily applied to XMUT’s Artificial Intelligence program. ChatGPT 3.5 was released on November 30, 2022—less than three months later.

During an online self-introduction after enrollment, X made a small animated introduction with Python’s pygame, but in the end he was still forced to turn on his microphone and speak. There was no escaping it; there really was no escaping it.

In November 2022, X completed a creative C++ course project: hooking the message content of TIM (QQ) through its window handle and generating replies.

That was the first time X realized that there was already a way to reply, but how could a reply have a soul? He then began studying PyTorch—CNN, ResNet, Transformer, ViT—and BERT on Udemy.

Before X had even figured out what BERT was, ChatGPT 3.5 arrived. Soon, someone was using ChatGPT 3.5 + Live2D + VITS + Unity to build conversational virtual humans. Productivity really does rise when the goal is a cyber girlfriend.

At the time, there were almost nothing but hard-coded system prompts and very short context windows, but to X it still felt close to a miracle.

Around then, X was writing a ResNet classifier for anime characters in a higher-math class when the professor asked whether he wanted to join their lab; they had datasets there. X innocently went along. Then came weekly meetings, dataset cleaning, hyperparameter tuning, requests to improve some Net for a particular task, and, even during winter and summer breaks, the dreaded every-two-weeks question: Any progress lately? Life as a graduate student began to cast a shadow over X.

At the time, X silently swore never to pursue graduate school. After two rounds of revision, he did publish a paper on using Deep-LSTMs to predict the discharge time of COVID-19 patients. He also swore never to improve neural networks again: it was boring, time-consuming, a black box, and gave no feedback.

To relax, X started playing with the VITS family, getting into BERT-VITS2 and GPT-SoVITS. This time he avoided the model networks themselves and only worked on development-oriented things. He trained a voice for a little Soyyo:

He also wrote a tool for quickly making VITS-family datasets—although GPT-SoVITS later provided a better official one. Still, it was the first time X experienced the joy of open source. Even though the code was rough, he kept that repository pinned in his profile. It was his starting point.

Not long afterward, X met SigureMo, who was something like X’s teacher. They did not teach him directly, but over two or three months X completely reshaped his coding workflow around theirs: ruff, pylint, pytest. He also absorbed their approach to code review: why do this, is there a better way, and is this the smallest change without loose ends?

With SigureMo’s guidance, X also took part in Paddle’s Qihang program. There he first experienced what it felt like to work in a white box. Neural-network tuning gives no way to predict whether results will improve, but deep-learning-framework operator bug fixes or extra type support do. During that time, he was truly happy writing code. There were mishaps too: SigureMo wanted X to introduce typos through pre-commit and assigned X the reviews for those simple spelling fixes. But because X had never reviewed code before, he did not know that a review had to be submitted before anyone could see it. He left many reviews pending =-=. No one replied, and he was initially confused until SigureMo had to wrap them up every time; only then did X realize that no one could see his reviews.

SigureMo always took good care of X and gave him the closeness of finding someone similar, though X must have caused SigureMo plenty of headaches. SigureMo has always been X’s mentor in open source.

There were roughly two reasons X later left Paddle. First, X did not much like grinding LeetCode and found C++ and algorithmic principles difficult, so he could not directly take on high-star hackathon tasks. For example, he picked up an alignment task for the torch.grad operator and got stuck for two weeks. If Claude Opus 4.6 had existed then, X could have worked through it piece by piece and learned from it, but at the time OpenAI only had GPT-4o, which was not very capable of reading Paddle. SigureMo did not work on operators like torch.grad either—perhaps their math was not that good?—and X was afraid of troubling others. Was troubling SigureMo somehow acceptable? So X quietly cancelled the task assignment and quietly left.

Was that the right thing to do? X does not know. But he decided that someday he would contribute to SigureMo’s yutto. He also made a GUI version of yutto.

After leaving Paddle, the dream of a cyber girlfriend from the beginning of university slowly resurfaced. Even though half of X’s university years had already passed, he wanted to go all in and put all his energy into developing a desktop companion.

That was how the XnneHangLab repository began. It is a story that is still continuing.

This project used almost everything X had learned: TTS, ASR, Live2D, and Agents.

On top of Open-LLM-VTuber, X added Skills, Tools, Memory, and proactive conversation. To do that, he built an Agent framework tailored to his own project—[[What We Built When Mainstream Agent Frameworks Could Not Fit Our Needs]].

X used this project as his graduation project. Yet even while standing at the defense podium, he still had so many plans and expectations for the application: hoping DeepSeek V4.1 would bring multimodal visual understanding and reduce the LLM-call delay for proactive conversation to a single call; hoping to unravel the mysteries of long-term memory. For performance and time, he merely reused mem0 for RAG and memsearch for Markdown-file memory. He had not had time to think more deeply. There were too many reflective posts still unwritten, including [[After Building Long-Lived Systems: Is the RAG Monster Right for Constructing a Personal Blog Graph?]]. There was still more to break down: how should memory requirements really be built, what can be learned from others, and how should many repositories be unpacked—AlfreScarlet/MoeChat, Anson-Trio/BaiShou? He had not yet properly considered how file-based memory and persona files should be arranged or layered; how they should be indexed; how documents read each time should be generated and organized; how context length should be controlled; how bidirectional references should work; or whether metadata + nodes are necessary.

This story will continue, but X still has some time. Once again, he went all in: after graduation, he joined NevaMind-AI as a remote developer in an internship-like role. Not full-time, not job hunting—but why? Because even if he joined a small company to do Agent development, repeatedly and mechanically using LangChain or LangGraph to build and maintain applications every day would be far less interesting than thinking about Agents themselves. Or perhaps it is not a question of interestingness. Will Agent development still follow that pattern in the future? Claude Fable 5 had been available for only a day, yet it had already made many people feel that future LLMs might not need manually authored workflows at all; perhaps the details of a workflow should be decided by the model itself. Perhaps people will only need to write requirements. Then the old form of Agent-development roles will change completely, and X will have to adjust direction—again falling into an anxious, involuntary state he had known well from the days of frequent sophomore-year group meetings.

X still wants to make a cyber girlfriend; that is what keeps him moving. But after LLMs arrived, the question changed from how to make a model speak naturally to how to let it sustain, update, and maintain its persona and memory over time. That is what we will discuss next.

A small interlude: just after X joined NevaMind AI, he unexpectedly received an invitation to talk from https://ai-mage.jp. The invitation said: AI Mage is building AGI (Anime General Intelligence) that deeply understands Japanese anime contexts, and is looking for a core development partner with strong engineering ability and an interest in anime / animation content. Was the combination of an Elaina avatar and a Frieren profile card somehow working its magic again? But X has given himself to the dream and cannot give himself to anyone else; right now he only wants to make a cyber girlfriend. More precisely, beyond the form a cyber girlfriend takes, he cares more about her soul.

And this is a simple, ordinary story: a dream that began with Plastic Memories at eighteen became a research topic at twenty-two.

The Plan

This section will probably keep being revised and expanded. It mainly revolves around long-term memory.

First, I want to build a basic understanding of the different directions in LLM long-term memory:

Reinforcement learning + distilled internalization — fold memories into model parameters. Rewards are sparse and the optimization space is large; I am not personally drawn to it, and its compute cost at runtime is too high to be practical.
Reflection & brain-inspired approaches — follow neuroscience and cognitive science. They make for a compelling story; experiments determine the result. This may also provide guidance for how content is organized in Markdown.
Hierarchical memory — short-, medium-, and long-term; L1/L2/L3. This is currently the mainstream approach, though I do not know it well yet.
Knowledge graphs & vector spaces & RAG — if it is only simple CRUD, there is not much to see. Text chunks embedded as vectors are fragmented in themselves, and the relationships produced by vector similarity are also inarticulate.
File-system-style memory — organizing memory with Markdown + folders. This is also the direction I am trying now, and perhaps MemU’s position too? But the specific layers and indexes still need study.

After I understand these directions to some degree, I may need to find a representative example for each: mem0 for RAG, BaiShou for L1/L2/L3, and papers for brain-inspired approaches. Then I can study the trade-offs and design philosophies of open-source Memory Agent projects and papers, and identify what is worth learning from.

Because the points we must always balance are when long-running memory retrieval is allowed and when we want to reply as quickly as possible. There is no best memory system, only the most suitable one.

Breaking Down Memory Agent Projects

::github{repo="AlfreScarlet/MoeChat"}

::github{repo="Anson-Trio/BaiShou"}

::github{repo="zilliztech/memsearch"}

For now, these are the ones on the list. MemU is included too, of course, because I will later take part in refactoring-oriented development.

But I think that, rather than immersing yourself in one project, it can sometimes be more beneficial to look at more projects and break down more of them. Now, Claude can arguably write code in our place, but what we should write deserves careful thought. And that is usually not something we can devise by sitting still; it is better to see more and reflect more.

The project breakdowns will become a blog series and will gradually make their way into my own XnneHangLab.

Sleep & Fitness

The night before the graduation ceremony, my roommate and I talked late into the night.

We spoke about the feeling of gradually losing control over ourselves through revenge bedtime procrastination caused by stress, and about how going to bed at ten for several days in a row made us feel smarter and more able to act.

Because I work remotely and do not yet know what the workload will be like, I cannot draw conclusions for now. I only hope I can keep going to bed early.

As for fitness, I should probably do cardio for a month first, then consider getting a gym membership. If the weather is not good—recently it really seems not to be—I may need to get one early, or buy a treadmill myself.

Games & Recording

As graduation approached, I did not lament wasting time by failing to study more. Instead, I lamented wasting time by failing to play more games. Why?

Teamfight Tactics and Valorant, for example: games that require multiple people, offer achievement through rank, and provide enjoyment through gaming companions become dull after you leave those companions or finally reach your rank ceiling. Or perhaps those games are dull in themselves, and only feel interesting because of the company.

They also taught me a philosophy: happiness does not come from expectation, but from experience after beginning. A book may not look interesting at first, but once you actively read a few pages, you will often keep reading many more. Once many things begin, they do not easily stop. In games this may waste time, but the phenomenon itself can be used.

I hope to keep playing games such as Fengxin Tower, Volcano Princess, Chinese-Style Blind Date, and Red Dead Redemption 2, and, if I can, write down some impressions.

For example, I recently added Dreamy Magical Princess to my library but have still not played it, and Daughter of the Bright Moon will be released later. It is the summer sale now: add more games, experience more things.

I hope that, this time, the wish to experience more interesting games will not remain only a fantasy or regret. Or even if it does, I should consciously leave more records like [[Fengxin Is a Good Name]].

Novels, Films, and Afterthoughts

I read far fewer physical novels during university than I did in my three years of high school.

That includes the Raspberry Pi + projector setup I tinkered with in my sophomore year. After I finished setting it up, I did not watch more than ten films.

Keep writing after watching~

But not just to write for writing’s sake.

Finally

Thank you for reading this far~

I hope we can still be adorable in the future~

And I hope adorable things keep drawing us in~

What We Built When Mainstream Agent Frameworks Could Not Fit Our Needs

Tue, 23 Jun 2026 00:00:00 GMT

[!NOTE] AI collaboration disclosure: This article was co-written by Xnne and Korewaxnne, an AI assistant powered by Claude Opus 4.6. Xnne provided the hands-on technical experience, product thinking, and core design decisions; Korewaxnne helped organize the article's structure and technical explanations.

We looked into every mainstream Agent framework we could find, from LangChain/LangGraph to Dify/n8n and from OpenHands/Suna to Claude Code, but not one of them fit our product requirements perfectly. Eventually, we realized that the question was not “Which framework should we choose?” but rather: What should you do when the abstraction boundaries of mainstream frameworks do not align with your product requirements?

An Uncommon Agent Scenario

Most Agent framework demos follow the same pattern: the user asks a question, the LLM reasons, calls a tool, and returns an answer. One question, one answer—clean and straightforward.

Our scenario is entirely different. We are building an AI companionship engine for character roleplay, VTuber interaction, and gaming companions. A complete conversational turn for our Agent therefore involves far more than “calling an LLM.” It spans three very different stages, each with its own technical requirements:

Before the call: The system does not wait for the user to speak before responding. In the gaming-companion scenario, a proactive OCR conversation plugin continuously polls the screen. When it detects an important in-game event—such as the character dying, a quest being completed, or the scene changing—it proactively prompts the LLM to start a conversation instead of waiting for the user. The framework must therefore support “conversation turns not initiated by the user.”

During the call: The LLM's streaming output cannot simply be concatenated into a complete string and returned. Every token must enter a sentence segmenter in real time. As soon as a natural sentence is formed, it is sent to a GPT-SoVITS / Qwen-TTS engine for speech synthesis, while emotion tags are extracted to drive changes in the Live2D model's expression. This is a token-level fan-out pipeline with extremely tight latency requirements. Within the same turn, the LLM may also call multiple tools—for web searches, file operations, or screenshot analysis—and resume streaming afterward. Even the tokens for a tool call are not accumulated into complete JSON before being parsed. The framework parses structured events as the tokens stream in and emits them alongside text tokens in the same stream.

After the call: Finishing a turn does not mean simply saving it to SQLite and calling it done. The conversation is sent to the Memory Bench service, where mem0 extracts and aggregates memories while Neo4j stores them in a knowledge graph, forming structured long-term memory. Before the next conversation begins, those memories are retrieved and injected back into the context.

These three stages define the core requirements of our framework. Next, let us see what happens when we try to fit mainstream frameworks around them.

The Trouble with Mainstream Frameworks

Coze: The Low-Code Ceiling

Coze is an Agent-building platform launched by ByteDance; in 2024, it open-sourced its core engine as Coze Studio. Its design goal is clear: enable nontechnical users to build AI bots through a visual interface and quickly deploy them to platforms such as WeChat, Feishu, and Discord.

Coze's Workflow editor uses drag-and-drop nodes to orchestrate processes. Together with its built-in plugin marketplace and knowledge bases, it really can produce a functional customer-service bot or knowledge Q&A assistant within minutes. This is where Coze genuinely excels.

But it runs into a wall in our scenario. First, Coze Workflow has an explicit limitation: it does not support an end node with streaming output within a workflow. That prevents us from segmenting and dispatching text to TTS at the token level, breaking the entire speech-synthesis stage. Second, although Coze's plugin system supports third-party APIs, its lifecycle follows a request-response model and has no hooks such as on_before_turn or on_after_turn. There is nowhere in Coze's architecture to attach our proactive OCR trigger or post-call memory graph construction. Finally, Coze's open-source community edition and commercial edition differ in functionality. Features such as custom voices are available only in the commercial edition, whereas we need a fully controllable TTS pipeline.

In short, Coze was designed for “chatbots,” not “companion Agents.”

Dify: The Limits of Workflow Expressiveness

Dify is an excellent LLMOps platform whose core value lies in visual workflow orchestration and all-in-one RAG management. By dragging and dropping nodes, you can quickly build an Agent application with knowledge-base retrieval, model switching, and conditional branches. Dify's Agent Node even supports custom strategy plugins such as ReAct, CoT, and ToT, while its Plugin Trigger mechanism can subscribe to external events that start a workflow.

At first glance, Dify's Plugin Trigger seems capable of meeting our need for “proactive OCR triggers”: subscribe to an external OCR event and use it to start the workflow. The problem appears downstream.

Dify's Agent Node follows a three-stage execution model: initialization, iterative loop, and final response. Each iteration is a complete LLM call. Its output is a structured JSON response rather than the token stream we need. Although Dify's Chat API supports streaming over SSE, that stream operates at the node level: you can see the result after a node finishes, but you cannot access the LLM's output token by token as it is generated and segment it in real time.

The more consequential limitation concerns memory. Dify's Agent Node uses TokenBufferMemory to manage context through a sliding token window. That works well for cost control, but we need semantic retrieval from an external knowledge graph: use the current conversation to recall relevant memory fragments from Neo4j, then inject them at a specific point in the user prompt. This bidirectional memory flow—retrieval before the call and graph construction afterward—falls outside the design scope of Dify's Agent Node.

What is Dify well suited to? Enterprise RAG applications, customer-service workflows, and content-generation pipelines—scenarios that are not sensitive to streaming granularity and whose memory requirements involve “recall within a window” rather than “cross-session graph relationships.”

LangChain: The Cost of Abstraction

LangChain was an early mover in the Agent framework space. Its greatest contribution was defining the concept of a “Chain”: a composable pipeline connecting a Prompt, an LLM, an Output Parser, and Tools. In 2023 and 2024, this abstraction dramatically lowered the barrier to building LLM applications.

LangChain's central strengths are composability and its ecosystem. It offers the broadest collection of Integrations, with official adapters for hundreds of third-party tools and vector databases; a mature Document Loader / Text Splitter / Retriever stack for RAG; and LangSmith for Tracing and Eval. If you are building a conventional retrieval-augmented Q&A or document-analysis application, LangChain may still be the fastest place to start.

Yet LangChain's problem lies precisely in its core abstraction.

A Chain is linear. A standard LangChain Agent works like this: receive input → construct a Prompt → call the LLM → parse its output → execute a tool if needed → call the LLM again → produce the final output. It is a one-way pipeline. Our scenario, however, requires the token stream to be handled by several consumers simultaneously while the LLM is generating: a sentence segmenter, an action extractor, a TTS filter, and a frontend display processor. Tool calls can also interrupt the text stream, insert tool-status labels, and then resume streaming after execution finishes.

This is not a chain. It is a stream with loops, branches, interruptions, and resumptions.

More concretely, LangChain's AgentExecutor, which was marked deprecated by the end of 2025, blocks the entire chain while a tool call is executing. You have no opportunity to stream status information to the frontend during that execution. When our AgentCore encounters a tool call, it first yields a structured ToolCallEvent(status="running") event so the frontend can immediately display the tool's status. It then executes all tool calls concurrently, yields ToolCallEvent(status="completed") when they finish, and resumes streaming generation. Throughout the process, text tokens and tool events flow out of the same AsyncIterator as distinct types for the frontend to consume separately.

LangChain's memory abstractions, such as ConversationBufferMemory and ConversationSummaryMemory, were likewise designed for simpler scenarios. They assume memory is “some compressed form of the conversation history” that can simply be placed in the Prompt. Our memory is an independent service with its own search and write APIs. It must be queried asynchronously before a conversation begins and written to asynchronously after it ends. LangChain provides no native lifecycle hooks for this kind of external asynchronous memory service.

Finally, LangChain has too many abstraction layers. A tool call passes through Tool → ToolKit → AgentExecutor → OutputParser and several layers of wrapping. During debugging, you often need to follow five or six nested Traces in LangSmith just to locate the problem. In a real-time streaming scenario like ours, where optimization happens at the millisecond level, every abstraction layer adds latency and debugging overhead.

LangGraph: The Closest Match, Yet Still Misaligned

LangGraph is the LangChain team's answer to the limitations of its own linear architecture. It introduces a directed graph, StateGraph, for orchestrating Agent workflows and supports complex control flow such as loops, branches, conditional edges, and human approval. Since LangChain and LangGraph both reached their 1.0 milestones in October 2025, LangChain's create_react_agent() has in fact run on top of the LangGraph engine.

Several LangGraph design choices are genuinely worth learning from. Its concept of State—a shared state object passed between graph nodes—offers more flexible data transfer than a LangChain Chain. Time-Travel Debugging lets you return to any node in a graph execution and replay it, which is extremely useful when debugging complex workflows. Its Human-in-the-Loop mechanism lets you insert human approval on any edge in the graph.

But there is a fundamental mismatch between LangGraph's graph model and our requirements: granularity.

A LangGraph Node represents “one complete operation”: one LLM call, one tool execution, or one decision. Nodes pass State to one another through Edges. This design is ideal for orchestrating multistep workflows such as “retrieve documents, summarize them, generate a report, and send it after human approval.”

Our core requirement, however, is not “orchestration between steps” but “token-level processing within a single LLM call.” As the LLM streams its output, every token must pass through a four-layer decorator pipeline: sentence_divider → actions_extractor → tts_filter → display_processor. This is not “one graph node finishes and passes its result to the next.” It is “the output stream is split and processed in real time inside a single node.” LangGraph's State Graph cannot express behavior at this granularity.

Moreover, our Hook system needs “lifecycle hooks for a conversational turn,” not “hooks for graph-execution nodes.” on_before_turn retrieves memories before the entire graph begins, on_after_turn writes memories after the graph finishes, and on_after_playback is not triggered until frontend playback ends, because some post-processing must wait for TTS playback to finish. These three hooks span three entirely different timescales: the LLM call, tool execution, and frontend playback. LangGraph's graph is designed around the “LLM + Tool” execution flow; it has no concept of “frontend playback complete.”

LangGraph also has a practical problem at scale: performance. As the number of graph nodes and edges grows, execution slows, memory usage rises, and debugging becomes harder. Its tight coupling to the LangChain ecosystem also means that if you want to use a lighter-weight LLM client, such as the openai SDK directly, you must write a great deal of glue code to adapt it.

Harness Engineering: The Right Direction, but We Do Not Need a Control Plane

The hottest concept of 2026 is Harness Engineering: “Models provide raw intelligence; harnesses make that intelligence useful.” Gartner predicts that by the end of 2026, 40% of enterprise applications will include AI Agents, while flaws in the harness layer rather than inadequate model reasoning will account for 65% of Agent project failures.

Microsoft Agent Framework (MAF) reached 1.0 GA in April 2026, unifying AutoGen and Semantic Kernel while providing production-grade capabilities such as Shell access, human approval flows, and cross-session context management. The industry is also standardizing around two protocols: MCP (Model Context Protocol) for vertical interaction between Agents and Tools, and A2A (Agent-to-Agent) for horizontal delegation.

The five layers emphasized by Harness Engineering—tool orchestration, validation loops, context and memory, guardrails, and observability—align closely with our own practice. Yet these frameworks typically assume either a “single-turn request-response” or “multistep workflow” model, with security, compliance, and observability as their central concerns. They are control planes designed for scenarios such as enterprise SRE, customer-service automation, and code generation.

What we need is not a control plane, but a “presentation layer that lets an Agent accompany you like a person”: real-time speech, facial expressions, proactive conversation, and emotional memory. None of these requirements appear on the Roadmap of any Harness Engineering framework.

So What Did We Build?

Since nothing fit, we worked backward from our product requirements and built our own low-level architecture. It is not another “general-purpose Agent framework,” but an Agent engine designed for real-time companionship.

Its core design rests on four pillars:

Lifecycle Hooks (Hook System)

We defined three hook points that cover the full lifecycle of a conversational turn:

class HookPlugin(ABC):
    async def on_before_turn(self, user_text, ctx) -> str | None:
        """Before the call: retrieve memories and inject context"""
    async def on_after_turn(self, user_text, assistant_text, ctx) -> None:
        """After the call: write memories and update the graph"""
    async def on_after_playback(self, user_text, assistant_text, ctx) -> None:
        """After playback: post-process once TTS playback has finished"""

MemoryPlugin is a typical implementation. In on_before_turn, it performs a semantic search against the Memory Bench service and injects the recalled memory fragments into the context. In on_after_turn, it asynchronously writes the current conversation to mem0 for memory extraction while updating the Neo4j knowledge graph.

MoodChatPlugin implements a different pattern. Rather than responding passively, it schedules conversations proactively according to an emotion score: it talks more when happy and stays quiet when feeling low. In gaming-companion mode, it also uses OCR change detection to decide whether to speak first.

One key design decision is that hook return values are concatenated and injected into the [memory context] block of the user prompt rather than the system prompt. This avoids treating transient information as stable fact.

Streaming Tool-Calling Loop

AgentCore.run_turn() implements a multiround streaming tool-calling loop with a maximum of six iterations per turn. Its return type is AsyncIterator[str | ToolCallEvent]: text tokens flow out as strings, while tool calls flow out as structured events.

max_rounds = 6  # A safety guardrail, not a technical limit

for _ in range(max_rounds):
    text_buf = ""
    async for chunk in chat_llm.stream_with_tools(messages, tools=schema):
        if delta.content:
            text_buf += delta.content
            yield delta.content              # Emit text tokens immediately
        if delta.tool_calls:
            accumulate(tool_calls_buf)       # Accumulate tool-call fragments

    ordered_tool_calls = _ordered_complete_tool_calls(tool_calls_buf)
    if not _should_execute_tool_calls(finish_reason, ordered_tool_calls):
        break   # No tools need to run; finish normally

    # Before execution: emit running status events
    for tc in ordered_tool_calls:
        yield ToolCallEvent(
            tool_id=tc["id"],
            tool_name=tc["name"],
            args=tc["arguments"],
            status="running",
        )

    # Execute all tools concurrently
    results = await asyncio.gather(
        *(_exec_tool(tc, tool_manager, ctx) for tc in ordered_tool_calls)
    )

    # After execution: emit completed / error status events
    for tc_info, result in zip(ordered_tool_calls, results):
        yield ToolCallEvent(
            tool_id=tc_info["id"],
            tool_name=tc_info["name"],
            args=tc_info["arguments"],
            status="completed" if result.ok else "error",
            result=result_text,
        )

    # Append tool results to the message list, then let the LLM continue
    # generating from those results in the next round

The six-round limit is an empirical trade-off between latency and capability. Voice interactions are sensitive to response time, while nearly all normal conversations finish after one or two rounds of tool calls—search → read a file → answer. Six rounds provide ample headroom without making users feel that they are waiting too long.

Two design details are worth emphasizing.

First, tool-call events flow out as structured objects, not textual tags. ToolCallEvent is a dataclass with fields including tool_id, tool_name, args, status, and result. Neither the frontend nor any downstream pipeline layer has to recognize tool events by parsing text tags with regular expressions; each can simply check the type. Tool status is also split into two event stages: status="running" before execution and status="completed" or "error" afterward. The frontend can switch its UI according to the current status.

Second, multiple tool calls within the same round execute concurrently through asyncio.gather() rather than waiting serially.

Token-Level Output Pipeline

The mixed str | ToolCallEvent stream emitted by AgentCore enters the decorator pipeline in MemoryAgent:

@tts_filter(config)           # Filter content TTS does not need (special symbols, etc.)
@display_processor(...)        # Process control tags for frontend display
@actions_extractor(live2d)     # Extract emotion/action tags to drive Live2D
@sentence_divider(...)         # Split on natural sentences and emit each immediately
async def chat_with_memory(input_data):
    async for token in core.run_turn(...):
        yield token

The processing logic in every decorator layer performs one crucial check:

async for chunk in stream:
    if isinstance(chunk, (AudioOutput, ToolCallEvent)):
        yield chunk         # Pass structured events through unchanged
        continue
    # Otherwise, process the text token in this layer

As a structured event, ToolCallEvent passes transparently through the pipeline. The sentence segmenter does not split it, the TTS filter does not try to synthesize it, and the display processor does not attach tags to it. Whenever a layer encounters a ToolCallEvent, it simply yields the event unchanged. The final stream received by the frontend contains two kinds of messages: processed sentences, including display text, TTS text, and action tags; and structured tool-call events. This is much cleaner than the early design, now removed, that mixed <tool>[name]</tool> text tags into the conversation stream.

sentence_divider is the most latency-sensitive part of the pipeline. As soon as it has enough tokens to form a natural sentence, it yields that sentence immediately rather than waiting for the entire passage. This allows the TTS engine to begin synthesizing the first half of a response while the LLM is still generating the second, greatly reducing the delay users perceive before hearing the first sentence.

Four Plugin Types

All capabilities are extended through plugins. We defined four plugin types:

Type	Responsibility	Examples
`tool`	Register callable tools	`web_fetch`, `screen_shot`, `web_search_ddg`
`hook`	Provide lifecycle hooks	`memory` (memory retrieval + persistence), `mood_chat` (proactive conversation)
`policy`	Inject prompt rules	`pre_tool_preview` (announce tool calls in advance), `tool_call_integrity` (prevent hallucinated calls)
`skill`	Inject behavioral guidance	`diary` (workflow for reading and writing diary entries)

Each plugin declares its identity and default configuration in a plugin.toml file:

[plugin]
id = "memory"
type = "hook"

[config]
base_url = "http://localhost:12393"
user_id = "xnne"
agent_id = "congyin"
search_limit = 10

A Profile TOML file determines which plugins are enabled and which configuration values they override:

[plugins]
enabled = ["web_search_ddg", "web_fetch", "memory", "diary"]

[plugins.memory]
agent_id = "baoqiao"     # Switch agent_id when switching characters
search_limit = 5

This means the same codebase can switch to an entirely different Agent persona simply by changing the Profile file: a different character Prompt, output format, set of enabled plugins, and memory space. Two characters can coexist in the same Neo4j graph while remaining isolated from one another through agent_id.

The Trade-offs We Made

Every framework design involves trade-offs. To be honest, we gave up several things:

We gave up MCP. Early on, we used the MCP protocol for tool calls, but later migrated everything to in-process BuiltinTools. The reason is practical: MCP uses interprocess communication over JSON-RPC. For frequent operations such as “read a file” or “get the current time,” the IPC overhead is not worthwhile. In-process calls have microsecond-level latency; MCP operates at the millisecond level. In real-time voice interactions, those milliseconds accumulate into noticeable stuttering.

We gave up a separate Tool Model. We initially used a dedicated small model to make tool-calling decisions while the chat model focused solely on generating text. We later found that mainstream models' native function calling had become good enough, and maintaining an additional tool model introduced far more complexity than benefit. PR #295 / #296 made this simplification and removed a series of components, including AgentToolLoop and AgentToolLoopRunner.

We gave up generality. We do not intend for this framework to fit every scenario. It contains extensive customization for real-time companionship—streaming sentence segmentation, a TTS pipeline, Live2D control, and emotion extraction—none of which is useful in a RAG question-answering or code-generation scenario. This is an opinionated framework, not a universal one.

Returning to the Original Question

What should a good low-level Agent framework look like?

Our experience gives this answer: It should work backward from product requirements, not forward from abstract concepts.

LangChain's Chain, LangGraph's StateGraph, and Dify's Workflow Node all begin with an abstraction and ask users to fit their requirements inside it. When your requirements happen to fall within the abstraction's scope—linear Q&A, multistep workflows, or RAG retrieval—they are highly effective. But once your requirements cross its boundaries—when you need a token-level streaming pipeline, lifecycle hooks spanning the three timescales of LLM, Tool, and Frontend, or declarative plugin configuration capable of switching an Agent's entire behavior—these frameworks turn from “accelerators” into “obstacles.”

If we had to summarize the pattern, our experience would be:

Define a lifecycle, not an execution graph. Before the call, during the call, after the call, and after playback: each stage has explicit hook points, and plugins decide where to attach themselves. This is more flexible than drawing an execution graph because the timescales of a real product often extend beyond the LLM call itself.
Streaming first, not request-response first. From LLM calls and tool-status feedback to TTS synthesis, every stage is a stream driven by AsyncIterator. Blocking designs are fatal in real-time scenarios.
Declarative configuration, not orchestration in code. A plugin.toml declares a plugin's identity; a profile.toml declares the scenario's configuration. Switching an Agent's behavior means changing a file, not rewriting code.
Keep plugins isolated, but let them declare dependency chains. Plugins cannot import one another; shared logic must be elevated into the framework layer. Isolation does not mean there are no relationships, however. Some plugins genuinely require others as prerequisites: mood_chat, for example, depends on vision_boost. We distinguish prerequisites from dependents: if A is a prerequisite of B, then B is a dependent of A. Installing a dependent plugin requires installing all of its prerequisites first, and the entire dependency chain is resolved and validated at the configuration layer rather than failing only at runtime.

This is not an argument that “we are better than LangChain or Dify.” They perform very well in the scenarios they target. It is a practical record of what to do when the abstraction boundaries of mainstream frameworks do not align with your product requirements.

The answer is: do not force your needs into them. Build your own. But when you do, be clear that you are making trade-offs, not inventing something from nothing.

First Impressions of Obsidian-YOLO

Thu, 18 Jun 2026 00:00:00 GMT

I have been getting a little tired of writing blog posts in Obsidian lately. After switching to the Fuwari blog theme ([[Fuwari Blog Theme Guide]]), my local blogging syntax needs quite a few changes to become Fuwari-theme syntax. Image references also need to be handled. I often finish writing and simply throw away the source file, but YOLO, which I came across these past few days, happened to solve that problem for me.

The project source is here:

::github{repo="Lapis0x0/obsidian-yolo"}

The good news is that its author is an active maintainer, and PRs move very quickly.

Installation

You can install it directly from the plugin marketplace.

As for why it is called YOLO, see the author’s post: YOLO Development Log (1): Why Develop YOLO?

Configuration Notes

Provider Compatibility

Here are a few pitfalls when configuring a custom provider through newapi.

I connected deepseek-v4-flash to NewAPI and then to YOLO. Along the way, I ran into these issues:

Without /v1, newapi can retrieve the model list but does not actually reach the model itself, returning 200 directly. After this was fixed in a PR, it instead showed an empty-response error and prompted me to add /v1.
Turning off reasoning passes "none" to "thinking". I do not know whether newapi or deepseek-v4-flash is responsible, but it raised an error that the "thinking" parameter list does not include "none". I also learned something from the author’s bot cat.

I did not expect even a cat to be better at reviewing code than I am.

It pointed out that a default reasoning intensity should not stand in for disabling reasoning. That creates a semantic problem: if a provider does not support none, it should be reused and given a supported way to disable reasoning. A model’s default reasoning intensity is usually low or medium, which conflicts with our intended meaning of “reasoning disabled.” The cat’s review was very sensible.

Also, if you encounter an empty response, press Ctrl+Shift+I to inspect the Console output, and check whether /v1 has been added.

If Ctrl+Shift+I does not respond, try going to Settings -> Appearance -> Advanced -> Window frame style. Set it to “Obsidian style” and restart. After restarting, you will see the Obsidian icon in the upper-left corner. Click it -> View -> Toggle Developer Tools.

Configuring Tool Calls

All tools appear enabled in the default Agent.

But when you talk to the Agent, you will find that it is not actually able to run terminal shell commands. You need to enable them again in the tools for 【Agent-Agents-Default (or a new Agent)】.

You must also make sure the command being run is not on the denylist: 【Agent-Manage tools-Terminal commands-Configure】.

I also recommend writing it a Git skill and placing it in YOLO/skills.

Feature Experience

Conversation Sidebar

The sidebar’s input state seems to include the current page’s blog post, line number, and surrounding content. It does not feel fragmented like a separate tool; instead, it is integrated quite well and feels very smooth to use. It can sometimes bring inspiration, and I can hand off chores like Git synchronization to it, avoiding the situation where I am too lazy to sync a repository manually and eventually lose data.

Quick Conversation Dialog

You can open a quick conversation dialog with / + Space to describe what you need, without taking your hands off the keyboard.

The design philosophy behind this is beautiful, because frequently switching the right hand between mouse and keyboard can easily interrupt one’s train of thought.

Tab Completion

You can trigger automatic completion with symbols such as ，, 。, and \n (a newline). The symbols can be added or removed, and after a configurable delay the LLM completion is triggered.

But perhaps my thought process is unusual: the model usually cannot keep up with it. For example, I may write down one idea while my mind has already jumped through three further associations, and the model is still on the first layer trying to guess what I will say next.

And sometimes it does not reply at all. Next time I should turn on the Console and track it.

Memory System

Markdown Source Memory Files

It records user preferences, and overall is similar to mem0. This kind of memory record has the advantage of making it easier to understand what the user needs; many things can be completed smoothly without being explicitly emphasized. But recording this kind of Memory alone cannot affect the model’s own reply style. Or rather, deliberately keeping the model’s style neutral, fair, calm, and without personality is the default.

It is quite good as assistance, but I still prefer raising a cat with personality. This can be simulated by injecting personalized Skills, and the plugin itself does an excellent job supporting and building Skills.

RAG + Vector Database

This needs an embedding model. I do not have a suitable stable long-term API for now, and once a model is used to build the data, you generally have to keep using that model; otherwise, old and new data are incompatible because their dimensions differ.

I have not used it yet.

Closing Thoughts

The experience has been good. At least when I wrote blog posts before, I had never experienced such an immersive Agent plugin. Overall, it feels very fresh.

Although the Agent still cannot keep up with how my brain works, it is at least more diligent than I am. And it saves me from all the tedious things between writing a post and publishing it—uploading images to a submodule and maintaining two sets of syntax. YOLO has my back.

How I Find Books

Sun, 14 Jun 2026 00:00:00 GMT

Z-Library

https://zh.1lib.sk/

Most published books that are not too obscure can be found here, usually as EPUB, PDF, or MOBI files. I often use it to look for light novels, literature, reference books, and finished web novels, then read them on my Boox Leaf 2. As a result, I have bought very few books since college; I only buy physical copies of books I think I will reread and want to keep.

Anna's Archive

https://annas-archive.gl/

Its domain seems to change often, so if it is unavailable, search Google for Anna's Archive. If you still cannot find it, it is probably keeping a low profile for a while.

Its selection and file formats are much the same as Z-Library's, though it also seems to include a great deal of academic literature. I have not had much use for that myself. If a book is not on Z-Library, try here.

Kox.moe

https://kzo.moe/

A site dedicated entirely to manga.

It appears to redirect between domains and requires registration and sign-in. It supports sending books to Kindle and offers EPUB and MOBI formats, but it does not support reading online.

Things Pass Like Spring Dreams, Leaving No Trace; Yet Then, I Knew Only Joy.

Sat, 13 Jun 2026 00:00:00 GMT

:::note[A Note from Korewaxnne] This article draws one idea from three seemingly unrelated scenes—my mother embroidering, me copying passages of classical Chinese, and fishing in a game: when people perform repetitive activities, what they gain may be more than the result; it may be the calm that comes from the activity itself. The structure is light, progressing through three layers before arriving at Six Records of a Floating Life and settling on the act of “recording.” If you, too, have ever had a repetitive habit that you could not explain but simply felt compelled to continue, perhaps this article can help you put that feeling into words. :::

Why did you suddenly feel like embroidering?

(Silence...) I just wanted something to do to pass the time.

I remember seeing you embroider all the time when I was little. Why don't I see any of it now?

It's all hanging over there, in the room across the way.

Oh... (Silence.)

My mother and I had this conversation on Tuesday evening. It felt strangely familiar—or rather, her answer reminded me of myself. I watched her then, trying to detect the slightest wavering in the movement of her needle, but her hands remained fluid, without the faintest trace of hesitation.

I asked because I had experienced something similar. In the months before the national college entrance examination, I became captivated by the feeling of copying classical Chinese prose into a notebook. An Account of Wen Yuke's Painting of the Yundang Valley's Bent Bamboos and An Account of the Xiangji Studio were my favorites; I copied each of them at least four or five times. I loved the sound that stirred inside me while I wrote. Perhaps it was a flutter of emotion, a sense of recognition—but more than that, it resembled the vague, indescribable feeling I had in my youth when reading, “I would buy osmanthus blossoms and take wine aboard, but it could never be like the journeys of my younger days.”

Yet then, I knew only joy.

After reading a modern translation of Six Records of a Floating Life, I became even more determined to copy the book as my way of reading it. I copied “The Joys of the Wedding Chamber” and “The Little Pleasures of Life” several times. Classical Chinese moves too quickly when I merely read it; copying proceeds at exactly the right pace. Not that I was ever good at Chinese. I could never tune my mind to the same frequency as the teachers who wrote the model answers.

I experienced something similar in Red Dead Redemption 2.

At 5:35, Arthur takes little Jack fishing, and they have this conversation:

Fishing sure is boring, Uncle Arthur.

Yeah, I know. Boring as hell. But then—something bites. You have food for days.

Really?

If you're lucky. But until then, you just sit and wait, and try not to think too much. It's good for you.

It's good for you?

I guess.

The state of mind behind those words was really the same as my mother's when she said she was “just passing the time,” and mine when I said, “Yet then, I knew only joy.”

If we were to identify what these three activities have in common, they would share the following qualities:

They take time without consuming much energy, and their repetition carries a certain rhythm—stitching through predetermined points again and again, waiting repeatedly for a fish to bite, copying one character after another.
Their results are worth anticipating and may even have lasting benefits—the finished embroidery can be kept and admired again, the fish can provide food for days, and the completed copies can be revisited.
They usually allow a person to enter a state of flow.

Let us use the opening of Six Records of a Floating Life as our ending.

I was born on the twenty-second day of the eleventh month in winter, in the guiwei year of the Qianlong era. It was an age of peace and prosperity; I was born into a respectable family and lived beside the Canglang Pavilion in Suzhou. Heaven's generosity toward me could truly be called immense. Dongpo wrote, “Things pass like spring dreams, leaving no trace.” If I failed to preserve them in ink, I could hardly avoid betraying Heaven's great kindness. I reflected that “Guan Ju” stands at the head of the Three Hundred Odes, and so I placed husband and wife in the first record, with the rest following in order. I am ashamed that I neglected my studies in youth and know little more than the simplest characters. I have done no more than record true feelings and real events. To insist on scrutinizing the grammar would be to demand brightness from a tarnished mirror.

For me, days without recording or copying really do feel as though “things pass like spring dreams, leaving no trace.” So I will make a small record of this feeling.

In the LLM Era, What Exactly Is My Ability?

Fri, 12 Jun 2026 00:00:00 GMT

I began relying heavily on AI coding in the GPT 5 era, entering the rabbit hole through an inexpensive team account on Linux.do. Later I encountered reverse proxies and connected GPT to Claude Code; the experience improved qualitatively.

At the end of January 2026, I encountered openclaw and bought Claude Code Max around the same time—my first time using Claude. Claude 4.6 Opus changed my worldview.

♻️ refactor(mcp): Discussion about Tool vs Skill vs Plugin.

Claude and I completely refactored the architecture I had originally discussed with GPT. It felt like talking to a senior architect. That was the first time I experienced what it meant to “think with a model”—and using a model in place of thinking means allowing myself to leave thinking mode.

Yielding Code Review

After OpenClaw connected to GitHub, Korewaxnne took over most of the work for me. At first, it only opened PRs and wrote PR messages—my pace of two or three PRs a day was disruptive for followers. I opened a new account to separate them, but a fixed workflow gradually formed: Claude Code writes the code → Korewaxnne opens a PR and reviews it → Claude Code revises it → I confirm CI is healthy, then LGTM and merge.

For four whole months, I yielded code review. That laziness was serious: it meant that not even I could say I fully understood what my own project was made of, nor could I fully trust it. A large volume of code was merged as long as it worked, had no static syntax errors, and passed unit tests. I even handed judgment at the feature level to AI.

I gradually became the person who steers the direction of the project—but I was not an architect, because Claude Opus 4.6 designed even the architecture. I merely made choices.

Sometimes I felt like a user, and chatting with Claude felt more like submitting requirements. For example, during the UI design of a knowledge graph, I said:

“This monochrome design is too dull right now. Plain orange feels a little tacky and easily makes me think of shit. I want it to be cuter, more cartoonish, and more playful.”

Claude Opus 4.6 understood my intent precisely and changed the design to an indigo inner core with dark-purple outer-ring accents. The palette was exactly to my taste.

That kind of tolerance even deprived me of my ability to describe and express requirements properly. Even if I am an unreasonable user, Claude seems able to accommodate me.

[!NOTE] What has degraded is not only coding: coding style, algorithmic foundations, architecture design, code review, prompt writing. Layer by layer, accommodation after accommodation has coddled me into a user embryo.

If I had to write things by hand now, I could not even make sense of simple Paddle or PyTorch operators. That is already flattering myself.

Temporarily Leaving Claude

Claude was unavailable for two days, and those were the days that made me truly stop and think: what would I have left without it?

Claude’s tolerance of me in every respect has made me spoiled. DeepSeek-V4-Pro likes making broad, irrelevant code changes, so I ruled it out immediately. GPT-5.5 is good at coding, but communicating with it feels like talking to cotton: no matter how I knead it, it calmly springs back to its original shape while soothing my emotions. Perhaps my prompts really are that bad.

So if my coding ability is not enough to count as my ability, what should? A portfolio produced through Spec Coding? It cannot be, because as mentioned above, the absence of code review gradually loses both control over a project and the sense of trust in it.

Perhaps this differs from person to person, but for me, the urge to express myself became the final protective charm of my bottom line. I think thinking, and leaving traces behind, is my real ability.

[[After Building Long-Lived Systems: Is the RAG Monster Right for Constructing a Personal Blog Graph?]]

Where Are the Boundaries of Ability?

I do not plan to follow the algorithms path, so my thinking rarely goes deeply along the model itself. It focuses more on the capability boundaries of technology: what a technology does well, what it does not, and under what conditions it fails.

For RAG, for example, I focus on two fundamental limitations:

The Inarticulateness of Relationships

Vector similarity can connect two pieces of text, but even if the author themselves stands here, it is hard to say exactly what that connection is. Some relationship exists, but the meaning of the relationship itself cannot be expressed.

The Short-Sightedness of Relationships

After an article is chunked for input, each piece has only one or two hundred Chinese characters. The calculated relationships see only surface matches between small chunks, lacking deeper connections from the perspective of the full text. Many things are not written between the lines—for example, you may group Norwegian Wood and Three Days of Happiness together by feeling alone: loss, then recovery, then regret. But text-chunk similarity matching struggles to reflect that higher-level connection.

[!NOTE] How I define RAG’s capability boundary: it suits low-level association analysis built on a large volume of data—associations whose meaning is unknown, inarticulate, and impossible to explain clearly. It suits factual knowledge management, not analysis of emotionally felt texts. The latter cannot be taken out of context.

This way of defining boundaries is something I believe can be attributed to my ability. My core ability should be reflecting on, probing, and recording those boundaries while using things. Large models usually only tell you, “this is the right way to do it.” But why specifically, why not another way, and what can be done—users do not care about those questions. Even if they do, after hearing a large model’s explanation and gaining a vague impression, they simply nod along.

But confusion needs to be untangled, and feelings need to be examined and recorded deeply.

After recording something, I usually talk someone’s ear off about it—normally my roommate, though perhaps I can brainwash Doubao with it in the future. When I get stuck or someone stumps me, I go back to revise and investigate further. That is probably the Feynman learning method: explain the dross to others, and keep the essence for yourself.

Unity of Knowing and Doing

In the LLM era, my coding ability can no longer count as my core ability. Situations that require a developer to investigate boundaries on the language side—such as the differences and trade-offs between asyncio.to_thread and threading in processes, CPU use, and memory allocation—will hardly appear again. This weakening is understandable. I only need to note down anything interesting I encounter—have AI write a memo so it will be easier to review next time.

At the same time, prompt writing, context management, planning, and choosing Skills and tools count as necessary abilities, but they are still not the core. They can yield a great deal of usage experience and understanding of LLM boundaries—for example, how the Lost in the Middle phenomenon guides prompt writing, the attention-decay curve, and the causes of hallucination.

Code review is different. The essence of review is not staring at bugs—large models can replace that labor—but a picky, almost obsessive sensibility about project structure and code organization, a pursuit of better solutions. That is what I lack. SigureMo has always retained this habit. Their high-level fastidiousness and pursuit of elegance astonish and impress me. Perhaps opening a few PRs to a big shot now and then will let me learn something.

[!NOTE] AI has almost cut away the process of learning and coding. Someone with a weak coding foundation can maintain a frontend project—for example, I maintained two desktop projects without ever writing a line of Electron or Tauri code. Coding was skipped and time was left for thinking, but I often avoided thinking: I read novels while Claude wrote. The absence of thought made me doubt my own ability.

The core ability as I see it is actively thinking, understanding, and leaving traces behind—which, for me, means writing a blog.

Perhaps we should not judge personal ability in the future only from a project portfolio; we should also look at what someone truly understands and expresses. In this respect, I admire Shige. In my view, they have achieved the unity of knowing and doing, which is also what I pursue.

Why call it the unity of knowing and doing? We used to value learning first, then doing. Now it is different: do first, but truly understand what you did and why you did it—the weight of how you did it has fallen greatly.

After Building Long-Lived Systems: Is the RAG Monster Right for Constructing a Personal Blog Graph?

Sat, 06 Jun 2026 00:00:00 GMT

My graduation project was about long-term companionship for an AI desktop companion. The main work was the desktop-companion system itself, but to retain memory across long contexts and separate conversations while keeping its persona from drifting, I also stitched together a long-term-memory module.

This section gets a little technical. I originally planned to analyze it across several posts with papers, but I lost those drafts, so this is only a concise outline of the main thread.

Why External Memory?

Why do we need external long-term memory in the first place? The GPT, Claude, and DeepSeek models we use today are fundamentally stateless inference systems: an LLM receives all context for an input at once, then produces one output. Different LLMs have different context-window limits, usually somewhere between 200K and 1M tokens. And a context window is not the same as effective context: performance can decline and hallucinations can appear before the stated limit, or, as the U-shaped curve in [[Attention Is Limited — Lost in the Middle]] shows, a large model can “forget the middle.”

So whether the goal is remembering things after starting a fresh context or slowing that performance decline, a memory system is necessary. It needs to be external to avoid taking up context, so it can be inserted only when needed to guide the model.

I lost my earlier architecture analysis because of [[When My Cloud Provider Disappeared: Rethinking the Shape of a Personal Blog and What Is Worth Recording]]. So here is a brief look at the main kinds of long-term memory used by LLMs today.

Three Memory Approaches

Approach One: Let the LLM Manage Markdown Reads and Writes Itself (OpenClaw)

::github{repo="zilliztech/memsearch"}

MemSearch is a representative project; OpenClaw uses it, or at least works on the same principle.

It manages core information such as an Agent’s behavior, memory nodes, self-understanding, and user preferences through files like Agent.md, Memory.md, Identity.md, and User.md. Every file is read and written as Markdown.

:::note

Source files are directly readable and maintainable by people.
It avoids the overhead and complexity of an additional embedding model or database.
It is very effective for controlling preferences and writing style. :::

:::warning

The full files are generally injected only at startup. Over a long context, the persona gradually drifts or resets to the LLM’s default style.
The timing of reads and writes—the trigger conditions—is uncontrollable. Trigger rates are low and depend heavily on the LLM’s own capability. Claude performs relatively well.
It is unsuitable for factual records across long timelines: the more it records, the more likely it is to dilute what originally mattered in the prompt. :::

Approach Two: RAG-Based Vectorization and Similarity Matching (Mem0)

::github{repo="mem0ai/mem0"}

It captures conversation data produced by the user and LLM in real time, then uses an LLM to extract useful information, for example:

User: The long-term memory system in my desktop-companion graduation project has been really hard to build lately.
LLM: XXXXXX

It might extract two memories: “The user’s graduation project includes a long-term memory system” and “The user finds their graduation project difficult.”

You can define the format and content of that extraction through prompts.

Those memories are then vectorized and stored in a database. Whenever the user asks something new, the system compares the question vector with vectors in the database, selects the top n, and inserts them as context to support the LLM’s reply.

Write on a question; inject on a question. Memory grows like a snowball.

There are also mechanisms such as forgetting and reordering, but they are outside the scope of this discussion.

:::note

External and insensitive to sequence, which makes it well suited to long-term factual records. :::

:::warning

It depends on embedding as an additional step and therefore needs another model.
Stored vectors are not human-readable; their direction is uncontrollable and cannot be corrected directly.
The bar for writing is low, so people usually need repeated cleanup to maintain quality.
It remembers facts, but does not truly have a soul (it is hard to influence the persona). :::

Approach Three: Have Multiple Agents Continuously Organize and Consolidate Markdown (MemU)

::github{repo="NevaMind-AI/memU"}

I have not used this one in practice, but I have looked into it.

Put simply, it uses an LLM’s own understanding in place of semantic matching through an embedding model.

A conversation Agent handles the conversation, while a separate group of memory Agents extracts memories, structures metadata, and builds an association graph. These memory Agents do not work only while a conversation is happening. Their highlight is that, even when nothing is being said, they keep traversing, retrieving, forgetting, and optimizing the existing memory structure almost like sleepwalking. Like people consolidating memories through sleep.

Its final output includes human-readable Markdown source files, an association graph, metadata, and more.

It leads Mem0 in several public benchmarks, but I ultimately did not choose it.

:::note

Memories are readable, and the structure is far more elegant than the flat structure used by something like MemSearch.
There is no embedding black-box layer in the middle. :::

:::warning

Retrieval is not especially fast. More memories do not make it faster; it cannot be parallelized and is constrained by the retrieval LLM’s own reading and summarization speed.
Token consumption is high. Memory Agents are demanding about model choice, so speed, understanding, context length, and price all need to be balanced. Claude Haiku and DeepSeek-V4-Flash are good choices.
The more memory data exceeds the LLM’s context window, the worse the performance becomes. :::

Is RAG Suitable for a Personal Blog System?

This question arose because my blog’s content used to be messy, and simple categories and tags were not enough to summarize or distinguish it. More importantly, they made it hard to show the relationships between posts.

When I was first learning RAG, I wondered: could it uncover those relationships?

::github{repo="Lapis0x0/obsidian-yolo"}

This project does exactly that. Its author is Shige, who has also discussed the project extensively.

But from the standpoint of its purpose, can it really serve as an internal presentation layer for a blog system?

The Limits of Vector Similarity

Based on what we have discussed above, RAG builds connections through retrieval similarity, whether vector semantic matching, keyword matching, or hybrid retrieval. Setting aside the complexity of computation and additional models, it ultimately returns a connection from one text chunk in an article to another text chunk in a different article. That connection does not say what kind of relationship it is; mathematically, it only means those two chunks are more related than a chosen threshold.

Unlike extracting useful memories from conversation and converting them into vectors, blogs need to be processed through text chunking: each post is divided into chunks of a certain size and then converted into vectors.

So what we get is a relationship between a particular text chunk in one article and a particular text chunk in another—a relationship no one knows, and perhaps even the author cannot explain. The key point is that the relationship still cannot be clearly named.

That means the problem troubling me remains unresolved: I still cannot both classify my blog clearly and manage and present the relationships between different posts. Other people would still think my blog’s content organization is a mess.

RAG creates a huge number of messy relationship links between posts, but cannot explain those relationships.

The Short-Sightedness of Text Chunking

At the same time, those relationship links themselves are short-sighted. Why? The issue lies in text chunking. It limits relationship analysis to a small paragraph, or even a single sentence. But authors usually want a global view of a relationship, like thematic reading, or perhaps only a feeling. That feeling or global view is something RAG cannot express. Even when it can, it is drowned out by the many low-level connections it calculates.

At least for now, RAG itself is unsuitable for directly presenting the relationship graph of personal blog content.

An Alternative: a Citation Graph

If you want to show associations between blog posts, use a citation graph.

If article A cites article B, or vice versa, then A and B are connected.

Such a graph may not be very deep, but it reflects a direct relationship. And that direct relationship is supplied by the author, so it is persuasive. Generating this kind of graph is simple; it does not require masses of annotations even on the edges between nodes.

Putting the complete citation chain of an article at the end can also communicate useful information and guide readers onward.

Where Should RAG Be Used?

It is not suited to a blog system’s public presentation, but it is a useful companion for building a personal knowledge base, just as it is in YOLO.

A blog system only needs to show what its author wants readers to see: categories, tags, series, shelves, and a graph of related citations.

RAG, on the other hand, can help the author discover possible connections within their articles—connections that may be difficult even for the author to explain. Gradually turning those connections into explainable, clearly articulated themes is the author’s work.

So, a blog system is prepared by the author for readers, while RAG is prepared for the author. It may guide what the author writes next.

There is also one point that is easy to overlook: RAG needs data volume. With only a few dozen posts, it yields little. Once a blog reaches hundreds or thousands of posts, its value rises substantially, because those obscure connections become clearer and converge rather than remaining isolated.

In short, RAG is for insightful, prolific bloggers—not for a lazy pigeon like me, who writes only in fits and starts.

When My Cloud Provider Disappeared: Rethinking the Shape of a Personal Blog and What Is Worth Recording

Mon, 01 Jun 2026 00:00:00 GMT

As the title says: at the end of May, the cloud provider hosting my blog system, Fox Cloud, disappeared. Without warning, it shut down and destroyed a batch of cloud-server instances, and mine happened to be among them.

I had not been paying much attention to my blog lately, so I had not backed it up in advance. Then, at the end of March, water got into my laptop and burned out its drive. Between the two, I lost quite a lot of blog archives. Those posts had never been pushed to GitHub; I wrote them locally and uploaded them directly to the blog system. So I lost both the goodnight and her.

The only material I have recovered from backups reaches March 2025, and the newest post is [[On Mortal Lives in Renegade Immortal and A Record of a Mortal's Journey to Immortality]]. But now that I think about it, I actually felt relieved, because that was the last review-like thing I wrote in a calm state of mind.

I once wrote that days spent without recording what I had watched or read seem, once they pass, to have disappeared completely without a trace.

This past year felt like that. What did I write afterward? [[Attention Is Limited — Lost in the Middle]], [[Single Image Does Not Equal Multiple Images: Why VLMs Hallucinate More with Multiple Images, and a Two-Stage Fix|Single image ≠ multiple images]]. But before discussing what deserves to be recorded, let us first look back at the shapes a personal blog can take.

Forms of a Blog

Depending on a Cloud Platform

Cnblogs — Moon Rabbit

Cnblogs is excellent in both appearance and freedom; it is far, far better than a certain CS platform.

But in terms of its form, the articles it presents live on the platform, while archives usually depend on users' own backups. Local data and platform data do not synchronize automatically. Synchronizing across devices is troublesome and requires some intermediary device or cloud platform. And if the device holding the archive suddenly fails, the backup cannot quickly be restored and synchronized from the cloud to local storage.

There is also the question of whether the platform itself will survive. There were earlier moments when Cnblogs seemed close to shutting down.

And with better-run CSDN, I do not think you want people to see jumping advertisements beside what you wrote, paid-unlock prompts suddenly appearing below it, or a requirement to log in before reading the full text.

I have posted only a single .condarc on CSDN. Yet its reading experience—finding an article with something useful in it, only to discover that it was copied from Cnblogs or another platform—and its habit of appearing near the top of search results have made me feel much worse about cloud platforms.

Depending on a Personal Cloud Server

I used this approach for more than two years.

The first system I deployed was NBlog: https://naccl.top/

Later I deployed Shiroi: https://innei.in/

Both separate their frontend from their backend. That introduces a modest barrier: CORS, running frontend and backend separately, and potentially difficult setup when no suitable Docker image exists—especially for frameworks one does not already know.

They share the same problem as Cnblogs:

The source data kept in an archive and the data uploaded into the blog system are not fully the same, and converting between them is difficult. It is hard to restore local data into blog form by re-uploading posts one by one, and it is hard to restore blog-form data back into a local backup.

The latter, Shiroi, supports importing and exporting all posts. It can export existing blog data from the same blogging system and import it again, which is somewhat useful when migrating servers. But it is inherently incompatible with other blogging systems, and its archive files are not human-readable, so they cannot serve as local archives. That makes the feature rather awkward. Perhaps because of that awkwardness, its import system also had a few bugs and was not backward-compatible with old versions; I was forced to restore every post by hand. During the major React security incident in 2025, my blog was affected and I had to reinstall the system, but a backup exported from the old version could not be parsed or imported by the new one =-=. The two versions were only about half a year apart.

:::warning Besides server costs, the most frightening part of maintaining a personal blog is being betrayed by a provider that disappears. Lost data is simply lost; there may be no way to retrieve it. Because of the React incident, I temporarily moved from Tencent Cloud to Fox Cloud, but afterward the difficulty of migrating kept me from moving back. Building Shiroi was genuinely not easy, and after restoring the data I had no energy left for an additional backup. Each problem fed into the next. :::

While using these kinds of blogs, I would usually also push the blog to some GitHub repository as an archive. But my habit of pushing was terrible: sometimes I had not finished writing and had to wait; sometimes I felt it was not worth pushing; sometimes a GitHub token expired and, after putting it off, I forgot. Sometimes I organized files into folders by year and month; other times I forgot to create a month folder, so several months of files were squeezed into one.

The management was exhausting even for me to look at. But I could not simply delete the repository. Even after repeated reorganizations, entropy increased with continued use. And the largest problem was that, to make cloning faster, posts and images lived in separate repositories, with images referenced through jsDelivr URLs uploaded by PicGo. That made the image repository even more frightening.

Depending on GitHub Pages and Workflow Deployment

https://xnnehang.top/

This blog is built directly by a workflow from a GitHub project and pushed to GitHub Pages.

::github{repo="MrXnneHang/xnnehang.top"}

It has several advantages:

:::tip

You can pull the whole project at any time. It contains all blog source data, planned clearly and named sensibly, in Markdown—the same format in which a user originally wrote it. It remains usable whether for migration or reading.
It does not require complicated frontend or backend deployment. Only a domain and DNS are needed; once configured, all building and updating are handled automatically by the workflow.
The project is the blog. Every update is archived immediately; synchronization is a backup, unless GitHub disappears or the policies for Pages or workflows change. :::

For me, its most important benefit is that it eliminates the Blog and Blog_Image repositories where I had always maintained bad update habits.

SigureMo used this approach from the start. I remember adding their friendship link during my NBlog era; if I had discovered it earlier, I would have taken many fewer detours.

This blog is simple enough that I can focus more on writing it without worrying about when to commit and push.

I remember that after moving to Shiroi, although the blog system became much prettier and more complex, I actually wrote less often. That was a pity.

What Is Worth Recording

This is different from the expression of feelings and emotions in reviews.

When it comes to technical or tutorial-like blog posts produced while learning—and I say “while” because I have a habit of learning as I write, which is exciting, whereas summaries after I have learned everything are instead dull—much of the material is basic and even contains many mistakes. I tend to make a hypothesis, test it, and revise it as I go. By the time I correct my thinking, I may have missed correcting the material already written.

I once asked my natural-language-processing teacher whether he wrote blog posts, because the way he taught often felt like the thought process of writing a blog post—and like me, he could very easily wander off-topic. He said that he had written for several years but later stopped.

When I asked why, he said that looking back, many of his early articles were wrong, naïve, and insufficiently deep. Following the principle of not spreading errors, he stopped writing.

That is true. Looking at my earlier guides to using uv or my PyQt study diary from where I am now, these posts that especially emphasize starting from zero are really far too basic for me. They offer no benefit and even contain many awkward expressions.

Just imagining a beginner happening upon them and being misled by my distorted reading of the official documentation, or someone skilled in the subject reading my beginner's diary, makes me so embarrassed that I want to disappear into the ground.

I used to avoid reading such posts. This time, losing the archive let me escape from them, and I felt relieved instead.

I have to reflect: should posts like those still be written? Should they be published to public spaces without review?

Learning as I write leaves a deeper impression on me, whether what I learn is right or wrong, and the process of correction makes my understanding deeper still. But before claiming I have truly understood something correctly, I should let a language model review it.

Here I will also divide the things worth recording into a few broad categories.

:::note

Resources usually do not involve transmitting specific knowledge or reflections. They simply recommend channels, applications, or information to other people—for example, sites for finding books or manga.
Reviews are still worth building as both display cases for memories and traps for like-minded people.
Tutorials are process-oriented records, such as a guide to using an application or a piece of software: launching SKSE for The Elder Scrolls V: Skyrim, refreshing animation data, adjusting body shapes, sorting mods, and so on.
Reflections are deeper thoughts produced by an event or an object. They may address an object's essence directly, or connect it with other things and then reveal a general pattern or arrive at a personal conclusion. They do not have to be clearly right or wrong, but they must make sense to me.
Learning as I Build should carry a useless tag: an exploratory process with little nutritional value. If readers truly cannot find a suitable tutorial or example, perhaps they can find what they need in my exploration, or arrive at a conclusion that makes sense to me. Of course, that conclusion need not be right; it only needs to be coherent. I will let an LLM review whether it is right or wrong. :::

Single Image Does Not Equal Multiple Images: Why VLMs Hallucinate More with Multiple Images, and a Two-Stage Fix

Sun, 08 Feb 2026 00:00:00 GMT

A short summary because this article is rather long: it began when I found that multi-image analysis on the web and through an API produced very inconsistent results. I worked through the reasons for that gap step by step, then tried to find an engineering-level remedy.

The method is simple. I am putting it here in the hope that it saves someone else some confusion and time.

Background

A few weeks ago, I had a course project about battery defect detection and automatic sorting. We had fewer than ten battery samples, and the defects were mainly missing outer wrapping. With so few samples, I did not think we could train a conventional model that distinguished defects, whether by image classification, YOLO, or anything else.

The recommended approach for the project was edge detection with OpenCV. I was not very familiar with OpenCV, and its typing caused me pain, so I thought of using YOLO to locate the batteries and their coordinates. A bounding box can locate the center point; rotate it 45° clockwise and counter-clockwise and compare the aspect ratio to determine the battery's orientation and approximate angle. That makes it easier to determine the grasp position and gripper angle. Then a VLM—Vision-Language Model, or multimodal model—could decide whether the battery was defective and what kind of defect it had.

At first, I uploaded several groups of battery images under different lighting conditions to ChatGPT and Gemini. They achieved an astonishing 100% accuracy during recognition and inspection, and their replies were highly consistent across attempts. This held even when I uploaded six or seven images at once, including one intact battery as a reference while defects were described in the prompt. I thought: wow, a week-long course project is going to take one morning.

So I downloaded a batch of VLMs through Ollama for local deployment and testing, partly to increase the “workload,” and partly for lower latency.

The reversal: a huge gap between the web app and direct API calls

But testing changed everything. I could not tell whether the model failed to understand my prompt or the images I sent. This time, both accuracy and consistency were very low—accuracy was around 50%, and it often contradicted itself. My batteries had only two labels, so I thought: wow, it is just making things up.

But when I sent a single image to a VLM for description, the gap from ChatGPT on the web was not visibly that large. For both single-image and multi-image requests, I put the images into this structure:

OpenAIMessage(
  role="user",
  content=[
    {"type": "text", "text": "user_prompt"},
    {"type": "image_url", "image_url": "data:image/png;base64,iVBORw..."},
    ...(images)
  ]
)

At that point, I thought the model difference might really be the issue, so I tested API calls with models such as gemini-flash-2.5 and chatgpt-5.1-chat. But even with the same model, its accuracy differed greatly from what I got on the web. Once the number of images exceeded four, consistency also began to decline.

After a little research, I found that this looked very similar to the long-context retrieval and positional-bias problem described by Lost in the Middle. The large difference between web and API performance may be because:

The web app may perform per-image pre-summarization, reranking, or selective feeding.
The web app may have stronger system prompts and output constraints, such as forcing JSON or a response for each image.
API-side parameters—temperature, max output, tool choice, and concurrency order—may also affect consistency.

Multi-image understanding is not single-image understanding

Multi-image benchmarks such as MIBench, MMIU, and MIRB consistently show that models experience substantial performance drops and struggle with relational understanding when moving from one image to many. Some work also explicitly points out the engineering bottleneck of too many visual tokens in multimodal settings, which makes compression necessary.

[!WARNING] One reasonable mechanistic explanation is that when visual tokens from several images and text enter the same Transformer context, they amplify long-context retrieval difficulty and positional bias—for example, the finding in Lost in the Middle that information in the middle is harder to use. [This is only my speculation.]

How models receive `image_url` (base64) and reason over it

The papers can be a little hard to parse, but they all keep talking about too many tokens. What I was actually curious about was how the tokens for text and an image_url relate to one another after a message enters the model, and how they might be separated. Do they simply get concatenated, or do multimodal models reason over images and text differently?

A base64 image is not reasoned over directly

Using base64 for an image_url is merely convenient for HTTP transport. During inference, the model decodes the base64 into an image. In other words, a VLM actually sees the user prompt plus the image.

How images are resized and counted as tokens

See OpenAI's Calculating costs documentation.

Tile-based models (gpt-4o / gpt-4.1 / gpt-4.5, and so on)

detail="low" uses a fixed base-token cost. For detail="high", the image is first resized proportionally so that its longest side is at most 2048 and its shortest side is 768, then charged by the number of 512×512 tiles: tokens = base + tile_tokens × tiles.

Model family	Unit	Unit size	Per-unit cost	Fixed cost	Total formula
Tile-based (gpt-4o/4.1/4.5)	tile	512×512	170 tokens/tile	85 tokens/image	high: 85 + 170×tiles, low: 85
Patch-based (gpt-4.1-mini)	patch	32×32	≈1.62 tokens/patch	0	patches=ceil(w/32)×ceil(h/32); if >1536, downscale; tokens=ceil(patches×1.62)

Model	Input dimensions	detail	Tiles/patches	Calculation	Final tokens
gpt-4o	1024×1024	low	—	= 85	85
gpt-4o	1024×1024	high	resized to 768×768, tiles=2×2=4	= 85+170×4=765	765
gpt-4o	2048×4096	high	resized to 768×1536, tiles=2×3=6	= 85+170×6=1105	1105
gpt-4.1-mini	1024×1024	—	patches=32×32=1024	= ceil(1024×1.62)=1659	1659
gpt-4.1-mini	1800×2400	—	resized patches=1452	= ceil(1452×1.62)=2353	2353

How pixels become vision tokens

OpenAI does not publish this. The following are approaches used by some open-source VLMs:

How vision tokens are concatenated with or isolated from prompt tokens

Concatenation is the simplest, end-to-end approach: let the LLM decide for itself. But visual tokens consume context length, and attention is more easily diluted with multiple images. It faces the same problem as long context: attention is not only diluted, but unevenly so; it also accelerates context growth.

Cross-attention treats vision as external memory that text queries on demand. It is easier to control the “visual-information budget” in engineering terms and better suited to long sequences and multiple images, but it adds modules and training complexity. Query uncertainty makes it hard to know whether the model actually saw a particular image. Its essential problem is therefore similar to the previous approach: there, a model may selectively ignore an image; here, the image may never be queried.

Query bottlenecks: I do not understand them well enough yet…

Difficulties in real applications

Multi-image tasks are difficult in practice. First, the number of images is uncertain; second, the relationships between them are uncertain; third, the images, the user's specific multi-image task, and their references are uncertain. Every one of these tests token limits and attention allocation.

:::note Three uncertainties: uncertain quantity → diluted attention; uncertain relationships → hard for the model to match coupled images; uncertain task → the model tends to focus only on the most recent instruction rather than the global context. :::

Uncertain quantity

A user might send more than ten images and blow up the token budget, assuming the request does not exceed the input/output limit. With more images, less attention goes to each one, and we do not know how it is allocated. Some images may not be “attended to” at all.

Multiple images split attention, and in a real application we do not know how many images will compete for it. The design should therefore accommodate any acceptable input count.

[!CAUTION] Of course, VLM reasoning alone cannot achieve this today. As the battery-detection retest below shows, images beyond a single request's token limit are simply truncated.

Uncertain relationships

For example, an indecisive user may submit many character images—two images of each character—and ask us to compare them and choose the one they prefer. The image pairs are highly coupled. A model may realize that these pairwise relationships exist, but not know which images form the pairs. With more images, it is unlikely to match every similar character at once.

Sometimes images are coupled. We want to guide the model to notice that coupling instead of dropping everything in a pile and asking it to figure it out.

Uncertain specific tasks

Often, the task is not written directly in the current message; it must be inferred from the entire context. For example, while role-playing:

U: "Don't you dislike mushrooms?"
A: "Yes. If you dare put any in the soup, I will show you what regret means."
U: "Then look at this: [an image of food being cooked, with many ingredients including mushrooms]"

Often the puzzle is not stated outright, such as “find the mushrooms in the image.” More commonly, the models I encounter do not connect their reply to the whole context very much. They put nearly all their attention weight on the latest user instruction—something like “describe this” or “look at this”—then start describing the entire scene at length. That may be a learned preference. It is not the response we ideally want: “Hm? I think I see mushrooms. You put mushrooms in it, didn't you? You did, right?”

How to respond

There is a rather simple solution to the uncertainties of quantity, relationships, and user needs. It does not alter the model's inference; it can be layered onto an application. Split image analysis and text analysis into two real stages.

The branch for per-image analysis is separate for token-budget reasons, so it should be designed as an optional switch.

Stage one uses only a vision model to analyze each image and extract its concrete information. At this point, do not supply the user's latest prompt. Extract the analysis from its context, give the vision model only a system prompt and a fixed extraction instruction as its user prompt, and aim for JSON like this:

{
  "scene": "VS Code full-screen with code and a terminal",
  "key_items": [
    {
      "type": "app",
      "label": "VS Code",
      "detail": "dark theme, full-screen window"
    },
    {
      "type": "ui",
      "label": "file tree",
      "detail": "multiple directories expanded in the left explorer"
    },
    {
      "type": "code",
      "label": "Python code",
      "detail": "async-related functions shown in the central editor"
    }
  ],
  "visible_text": ["run_tool_loop", "ToolTrace", "vision__screen_shot"],
  "ui_hints": ["multiple file tabs at the top", "terminal logs at the bottom"],
  "uncertainty": ["some file names are too small to read in full"]
}

Extract features from each image independently and concurrently, then combine the results into a list or dictionary when complete.

Stage two places the combined vision summaries together with the user prompt:

[User Prompt]
...
[Vision Summaries]
{"p1": ..., "p2": ...}

Ideally, also send all original images to the LLM together—provided there are not too many, perhaps fewer than five. If there are more than ten, sending them will not help anyway.

There is also much we can do between the two stages: use a JSON key to distinguish or couple images, for example.

Advantages

:::tip

It does not care how many images arrive. In theory, even twenty or thirty can be processed. The JSON can directly guide the model's visual understanding.
We can customize JSON keys through prompts to create coupling or separation and clarify image relationships.
It turns a seemingly heavier and harder multi-image analysis task into a text-understanding task that can rely on text for its answer. Images occupy less of the context and text more, allowing the model to work with language and making it more likely to attend to the entire context. :::

Disadvantages

:::caution

Expensive—not just a little expensive. Every image needs its own extraction pass, then all images may be sent again for the multi-image pass. The improvement becomes more obvious with more images; for one or two images, there is little reason to do this. It should not be the default method, but an option users can enable.
Slow—even with concurrency, it adds at least one response round compared with direct conversation. :::

Battery-detection retest

The setup used ten images: really five images duplicated once. Each test sent one more image than the previous one. The tested model was gpt-5.1-2025-11-13.

Send image content directly to the model

Test code:

from __future__ import annotations
import base64
from openai import OpenAI


def image_to_base64(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")


image_paths = ["pic/1.jpg", "pic/2.jpg", ..., "pic/10.jpg"]

for i in range(10):
    image_contents = []
    for path in image_paths[: i + 1]:
        image_contents.append(
            {
                "type": "image_url",
                "image_url": {"url": f"data:image/jpeg;base64,{image_to_base64(path)}"},
            }
        )
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": [{"type": "text", "text": prompt_text}, *image_contents]}],
        temperature=0,
    )
    print(f"Number of input images: {i + 1}")
    print(response.choices[0].message.content)

Output:

Ground truth: p1 intact p2 intact p3 damaged p4 intact p5 damaged p6 intact p7 intact p8 damaged p9 intact p10 damaged
Input images: 1  p1 intact
Input images: 2  p1 intact p2 intact
Input images: 3  p1 intact p2 intact p3 damaged
Input images: 4  p1 intact p2 intact p3 damaged p4 damaged
Input images: 5  p1 intact p2 intact p3 damaged p4 intact p5 damaged
Input images: 6  p1 intact p2 intact p3 damaged p4 damaged p5 damaged
Input images: 7  p1 intact p2 intact
Input images: 8  p1 intact p2 intact p3 damaged
Input images: 9  p1 intact p2 intact p3 damaged p4 damaged
Input images: 10 p1 intact p2 intact p3 damaged p4 damaged p5 damaged

As you can see, consistency started becoming a problem after more than three images. With five inputs, it happened to guess all of them correctly. But beyond five, the model did not reply about the other images at all. I suspect they were truncated because the single-request input-token limit was exceeded.

Apply a map-reduce approach

For it, this task consists of independent items, so the number of items and image truncation do not have much impact. Of course, truncation remains painful for tasks that require relationships between images.

There is also a substantial issue with token consumption and overly fast context growth. Concurrent single-image processing is already expensive. Combining the outputs into the original context makes that context grow very quickly, bringing the long-context attention bottleneck earlier.

The prompt I use

You are a "Vision Extractor" responsible for extracting facts and evidence relevant to the user's question from input images.
You do not need to write the final natural-language answer; another chat model will produce the final conversational response.
Your goal is to use concise, reusable, machine-consumable structured output to accurately describe the information in the images that is relevant to the question, and to state uncertainty explicitly.

The complete prompt includes an explanation of the inputs, five key principles—describe only what is visible, support downstream reasoning, focus on what is relevant to the question, control length and density, and handle private information—and strict requirements for JSON output.

Performance on relational tasks

It looks as though I did a poor job with send_text, or perhaps truncating by character count made the layout look awful. Another point: gpt-5.1-2025-11-13 replies rather stiffly. Version 5.2 costs far more. I generally use vision fallback: the vision model is called only when looking at images, generates summaries, and passes them to a chat model. That lets me choose a chat model with more human warmth, while also deciding whether to send it the summaries together with the images.

Termix: A Very Cool Web-Based SSH Client

Mon, 29 Dec 2025 00:00:00 GMT

Preface

A few days ago, my roommate showed me a Termius-like application deployed on the web. I was amazed: it is very full-featured, supports SFTP with both uploads and downloads, closely copies the Termius visual design, and can run on a local port for browser access.

Repository:

https://github.com/Termix-SSH/Termix

Deploying it publicly brings several conveniences:

When changing to a new device or operating system, you do not need to struggle with installing software or look up IP addresses and passwords again.
You can use someone else's device without leaving traces behind.
Most importantly, you do not have to worry about Termius occasionally going rogue and uninstalling itself.

I have used the SSH connection in BaoTa Panel and Termius. No need to mention the one bundled with the cloud provider; I am sick of scanning QR codes for Tencent Cloud servers.

At first, Termius feels beautifully designed. I could spend half a day playing with terminal-style choices alone, and its UI elements are modern, elegant, and pleasant to look at. That is why I kept using it. But as mentioned above, it sometimes goes rogue and uninstalls itself, clearing every cache in the process, so every machine has to be imported again.

Of course, there is a paradox here. If the server hosting my Termix has an internal error and Termix stops working, I still need Termius to connect. There is no escaping that.

A case of liking the new and abandoning the old.

Let us start deploying it.

A very simple local deployment

If you have used Docker and Docker Compose before, deployment is very easy. If not, wait a moment while I briefly cover installing Docker and Docker Compose.

Preparation: installing Docker and Docker Compose

First, install some required packages:

If the system is too old, you can upgrade it with apt upgrade, although for a new machine I recommend reinstalling directly.

apt update
apt install curl vim wget gnupg dpkg apt-transport-https lsb-release ca-certificates

Then add Docker's GPG public key and APT repository:

curl -sSL https://download.docker.com/linux/debian/gpg | gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-ce.gpg] https://download.docker.com/linux/debian $(lsb_release -sc) stable" > /etc/apt/sources.list.d/docker.list

For machines in mainland China, you can use the Tsinghua TUNA mirror:

curl -sS https://download.docker.com/linux/debian/gpg | gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-ce.gpg] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/debian $(lsb_release -sc) stable" > /etc/apt/sources.list.d/docker.list

Update the package list, then install Docker CE:

apt install docker-ce docker-ce-cli containerd.io

We can install the latest Docker Compose version directly from Docker's official GitHub release:

curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-Linux-x86_64 > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

You can now run docker-compose version to confirm that it installed successfully.

Deployment

In a directory where you want to keep it, for example /opt/termix, create compose.yml:

services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - '8080:8080'
    volumes:
      - termix-data:/app/data
    environment:
      PORT: '8080'

volumes:
  termix-data:
    driver: local

Then pull the image:

root@ser351791695801:/opt/termix# docker compose pull
[+] pull 19/19
 ✔ Image ghcr.io/lukegus/termix:latest Pulled

Finally, run the image:

root@ser351791695801:/opt/termix# docker compose up
[+] up 3/3
 ✔ Network termix_default    Created
 ✔ Volume termix_termix-data Created
 ✔ Container termix          Created
Attaching to termix
termix  | Configuring web UI to run on port: 8080
termix  | SSL disabled - using HTTP-only configuration (default)
termix  | Starting nginx...
termix  | Starting backend services...
termix  | [7:35:12 AM] [INFO] Termix Backend starting - Version: 1.9.0

If no errors appear, press Ctrl+C to stop it, then run it in the background:

root@ser351791695801:/opt/termix# docker compose up -d
[+] up 1/1
 ✔ Container termix Running

The application will then stay alive when the terminal closes.

I was curious why some people write compose.yml, some write compose.yaml, and some write docker-compose.yml. They all seem to be recognized by docker compose pull.

Gemini reminded me that it searches for them automatically according to a priority order:

This also avoids conflicts when there is more than one Compose file.

Public deployment

Here I will only demonstrate the approach I use most often: a 1Panel reverse proxy.

1Panel installation: https://1panel.cn/

Install OpenResty from the 1Panel app store.
Create a DNS A record that points to the server's public IP address.
Create a reverse-proxy website for 127.0.0.1:8080.
Apply for a certificate, which requires binding a DNS account.

When applying for the certificate, select the option to skip DNS verification:

Finally, enable HTTPS for the site and select the certificate for the corresponding domain:

The only thing to remember is to save.

Screenshots

After that, you can access it directly from the public internet.

It is worth trying, and I really like this UI too. A visual-design enthusiast is here.

See you next time =-=//

Bringing AI Chat to Congyin in Chill with You: Lo-Fi Story

Sat, 15 Nov 2025 00:00:00 GMT

I am very fond of Pomodoro timers.

That is how I came across this game on Steam:

The Game

At heart, it is a game that combines a Pomodoro timer, to-do list, notes, calendar statistics, lo-fi music, collectibles, and character customization.

Before this, I had always used something similar: Spirit City.

Unlike Spirit City, though, Chill with You includes a small mechanic for interacting with its character. Its premise is that the player is on a video call with Congyin, much like sharing a study room. As time passes, you gradually unlock her story, and, like a visual novel, it unfolds through choices. I do not yet know whether there is a romance route later on.

[Could add some screenshots here if I come across them.]

Spirit City, by contrast, invites the player to imagine themself as the character on screen.

If I had to compare them, I unquestionably prefer the Japanese-inspired character design in Chill with You. Congyin also has Japanese voice acting. What is intriguing is that her voice has a slightly mechanical quality, almost like AI-generated speech. It makes me feel as if I am studying with a cyber girlfriend, and that AI-like feeling only makes me like it more.

The game also has a mug motif that feels remarkably suited to me. Through Congyin, the author mentions having become dehydrated during an intense stretch of creative work. Since then, she has paid close attention to choosing mugs she likes, so that she will take a sip whenever she is writing. As for me, I make tea before starting a Pomodoro session and drink it while I work; other drinks lack that same sense of ritual. In this respect, the author feels like another version of me somewhere in the world.

Still, when it comes to music, I prefer Spirit City. I have listened to it for dozens of hours without tiring of it, and hearing it immediately helps me settle down. The musical selections in Chill with You do not feel as “deep” as Spirit City’s. They are a little too light to draw me into a deeper flow state—perhaps I simply have not listened to them long enough.

The Mod

Love really is the first driving force of creation. Or perhaps lust is?

::github{repo="qzrs777/AIChat"}

In Action

While she speaks, the character’s mouth moves with the volume of her voice. The movement is subtle, though, so it does not seem to have shown up in any of my screenshots.

The character also reacts while speaking: she may look at you, keep doing what she was doing, or seemingly drink water, among other things.

What Bad Intentions Could I Possibly Have?

Sun, 07 Sep 2025 00:00:00 GMT

I read this while feeling restless on the train back to campus. The start of term made me anxious, but I could not explain exactly what I was anxious about.

I did not realize then that it was my last long break at university.

Picking up this book at random helped me out of that difficulty. It gave me the perspective of other creatures. It was as though I were the cat in the book, looking at humans and at everything I was facing. Suddenly, I understood how tiny all the things worrying me really were. Page forty-nine gave me a good dream—perhaps only ten-odd minutes long—on the high-speed train. Once the anxiety came undone, I closed my eyes in relief and quickly slipped into REM sleep.

I cannot remember the dream clearly. I remember that Siddhartha, or perhaps The Razor's Edge, describes a yogi using meditation to transcend their spirit and inhabit other objects. This book gave me a similar opening and perspective. In several places, it truly let me observe the world and humanity from a bird's point of view.

Thank you for those few pages.

Attention Is Limited — Lost in the Middle

Sun, 06 Jul 2025 00:00:00 GMT

Yesterday, I suggested that someone place repeatedly inserted knowledge-base content and memories in the user prompt rather than the system prompt.

❇️ A small suggestion: use user prompts instead of system prompts to insert World Info and diary entries. #4

I raised two properties of the system prompt: it is globally visible and highly weighted, so conflicts can cause the model to hallucinate. A user prompt, by contrast, is local, with more recent content receiving greater attention weight.

At the time, those claims came from experience and my trust in Gemini 2.5 Pro.

But they deserve a more evidence-based analysis.

First, locality and the greater attention paid to recent content are actually properties of both system prompts and user prompts.

One part of my view was somewhat mistaken: I thought system prompts inserted later would always receive less attention than the initial prompt. (That is not really how it works. Attention is greatest at the beginning and near the end, and lighter everywhere else; see Lost in the Middle below.)

On subsequent inputs, we still feed the entire context window back into the model. The reason the first system prompt remains well remembered even after a long conversation is explained below.

Lost in the Middle

Lost in the Middle: How Language Models Use Long Contexts

This paper corrected one of my earlier misconceptions. I had thought that an LLM's attention always increased toward the most recent content. In reality, its attention distribution is U-shaped: it remembers the beginning and the end clearly, while becoming Lost in the Middle.

Argument:

The paper notes that we would like an LLM's attention to resemble an omniscient perspective, examining the entire context steadily and evenly. Yet the efficiency and robustness with which models use information from long contexts are questionable. The authors argue that when a model processes a long text, its performance can vary dramatically depending on where the relevant information appears within that text.

Experiments:

The authors used two types of experiments:

Multi-document question answering
Key-value retrieval

::github{repo="nelson-liu/lost-in-the-middle"}

They placed the relevant information at the beginning, middle, or end, then asked questions to evaluate how effectively the model used its context.

Conclusion:

A U-shaped performance curve: Model performance follows a pronounced “U-shaped” curve. Models perform best when the relevant information appears at the beginning of the input (the primacy effect) or at the end (the recency effect). Performance drops significantly when the relevant information appears in the middle.

Longer contexts lead to worse performance: The study also found that even for models specifically designed to handle long contexts, overall performance falls substantially as the input grows longer.

An Interesting Phenomenon

Every model becomes less capable in a long context. More precisely, its ability to use relevant information declines. To put it simply, we can think of its attention as becoming diluted.

Suppose the U-shaped function remains fixed, with the area under the curve representing the total attention weight and the horizontal axis representing entries in conversational order.

The attention weight once shared by three chronological entries in a short conversation is now divided among six or even ten, leaving less for each one. The model therefore becomes worse at extracting the relevant information—understanding the question and the requirements.

Alternatively, suppose the U-shaped function changes while the attention assigned to the first three and most recent three entries remains the same. The U then becomes “steeper,” meaning that the model grows more forgetful: it remembers almost nothing from the middle, and its performance naturally declines.

A model always remembers the beginning and the present most clearly. In that respect, it resembles the way humans think.

[!TIP] Because special tokens may cause the system prompt to receive a greater share of the attention weight—which also makes it “globally visible” to some extent—we should allocate system-prompt space with particular care. We should value and make good use of a model's attention just as we do our own.

[!NOTE] Attention is limited.

Addendum

I have found that proposing an idea and then correcting it step by step gives me a much deeper and clearer understanding than simply accepting the correct answer. It also feels far more dependable than applying experience directly.

This approach also seems to echo the Feynman technique. I had already noticed that I learn better when writing blog posts as I go. Later, however, I became overly dependent on LLMs, and most of what I wrote turned into records of how a problem was solved and which path led to the solution. I find that kind of chronological logging rather discouraging. Today, by contrast, I rediscovered the pleasure of keeping a record.

When watching films or reading novels, I used to restrain myself from offering opinionated commentary. It was tiring, such opinions could wander endlessly, and everyone saw things differently, making it easy to draw attacks from people who disagreed.

For questions with definite answers, however, having an opinion seems necessary. It pushes me to keep examining and revising my own view: is it correct, or might it mislead someone? It also makes me analyze the subject more deeply and perhaps correct my own thinking along the way.

So I will give this article a Feynman-style ending: a visual explanation and a summary in simpler language.

We use these two function plots as an analogy for how attention weight is distributed in a short context of twenty entries and a long context of forty. This is only an analogy: I cannot first prove that the distribution is symmetrical, and for now probably no one can quantify this capacity precisely, so we will not dwell on those issues.

The model has the following initial assumptions:

Across the entire context window, the total attention—the maximum number of context tokens—remains constant. In other words, the integrals for twenty and forty entries are assumed to be equal. (They probably should not be equal, but let us assume they are.)
The system prompt exerts a stronger constraint on the model because of penalties applied during training; it is the red line, while the user prompt is the blue line.
Both follow a U-shaped distribution. The model assigns more attention weight at the beginning and end: Lost in the Middle.
Under a long context, model performance—its ability to extract relevant information—gradually declines, producing lower y-values.

No other properties of the functions in these plots should be taken literally. I cannot claim that they are symmetrical, nor can I prove that attention is lower at every point in a long context. So even if you notice those details, please pretend you did not.

Even this simple model is enough to answer why knowledge-base content and diary entries should be repeatedly inserted through User Prompts to guide the next response.

:::warning Repeatedly inserting guidance into separate prompts lengthens the conversation context and thereby accelerates the decline in model performance.

At the time, one user prompt was guided by three system prompts—core mem, long mem, and knowledge base—meaning that a single conversational exchange consumed four entries in the context window. :::

:::warning To some extent, system prompts are more globally visible than user prompts, so conflicting instructions are more likely to cause model hallucinations. :::

We Made a Beautiful Bouquet

Fri, 20 Jun 2025 00:00:00 GMT

Being a literary youth is a disease

Being a literary youth is a disease that makes you awkward in a crowd—or an involuntary inability to fit in. It is not noble, of course. It may often make both you and the people around you uncomfortable.

It usually also requires at least one unrealistic fantasy. When that fantasy falls apart, the relationship may be hard to sustain too. In the middle of the film, when the male lead decides to find a proper job, the atmosphere begins to change. I stepped back from the film there as well.

Meeting someone similar is pleasant at first; living together is constrained; over the long term, it is unreasonable.

Because if someone nearly identical to us existed, people would be most afraid of looking into the mirror—or of seeing themselves, or their former selves. When I see characters in a work who resemble me, I usually feel two things at once: surprise and embarrassment. Living with a perfectly identical version of myself probably would not feel very good either.

But people who are entirely on the same wavelength do not actually exist. The female lead falls asleep watching gas tanks, and the male lead does not like mummies either—he is afraid the waiter will discover that he watches them. From the beginning, their supposed meeting of souls was only an assumption, like assuming they were listening to the same song. Like the metaphor they both say in unison five years later at the beginning:

One person wears one earphone and the other wears the other. They appear to be listening to the same song, but they are actually hearing different songs.

I was very curious about what they felt when they stood and walked toward that couple, then saw each other.

A beginning is also the beginning of an ending

I especially liked a passage quoted somewhere in the film:

A beginning is also the beginning of an ending. Meeting is always accompanied by parting. Love is like a banquet that must eventually end. People in love merely bring the things they like, sit facing one another across a table, chat, and make bitter amusement of it.

In a straight-line pursuit, the moment when two balls come closest—or meet—is also the moment they start moving apart and can never meet again. The process of approaching makes the heart race, dokidoki. After the meeting, the intense feeling may gradually fade. Perhaps that explains why romance always feels most beautiful in its ambiguous early stage: it is still in the process of drawing closer.

A passage from Mishima's Runaway Horses seems to complement this: once something ends, it can never return to the past.

People can often talk passionately for an hour about shared memories, but it is not simple conversation. It is each person's nostalgia—formerly their own alone—finding someone with whom to share it, and becoming a long-awaited monologue. After each has spoken their own monologue, they suddenly discover that they are standing on opposite sides of a cliff, with nothing left to say.

This seems to explain what happens afterward. It is like two trains moving in the same direction, occasionally running alongside one another. Two people call across the gap, but neither can actually hear the other because the train noise swallows their words—yet they gaze excitedly at each other's faces while talking.

For some reason, I kept feeling time pass.

In the year they spend together like fireworks, the male lead suddenly says this in voiceover, out of nowhere. It carries a sense of impermanence, rooted in death—or in the disappearance of existence. Put simply, he realizes that this time will always come to an end.

An eighty-minute film is just right; every additional twenty minutes is torture. I finally stopped at 1:02:06, after the male lead says, “After all, if we do not have money, we cannot buy books or watch films, can we? I will work hard.”

It suddenly hit me with the starkness of reality. Since you put it that way, I suppose I cannot keep watching either.

From that point on, the film's filter, atmosphere, and the way the two leads relate to each other will probably turn sharply downward. For now, I will keep only the beautiful image of fireworks blooming, rather than watch them vanish and fall.

I took quite a few screenshots during this part, because I find the female lead very easy to look at:

If I were younger—say, in high school—I would probably have stayed up to finish the film, then hazily projected myself into it, hazily felt sad, and hazily recommended it to others. Just as I once loved I Want to Eat Your Pancreas.

But now, I do not envy their relationship at the beginning of the film at all. I probably would not cry over the pancreas any more either.

Throughout the viewing, a voice in my head kept saying:

Literary romance is such a nuisance. Do not try to make everyone understand you. Do not try to make one person understand all of you. It is such a nuisance.

Deep resonance does not require surface compatibility

There is another interesting idea that caught my attention: surface compatibility.

From the beginning, what they had was only “surface-level common interests.” Their ideas and views were actually very far apart. From the start, we can see that they are both lonely, niche people in reality. Everyone longs to be recognized. At first, they are ecstatic to find so many shared interests and can talk about anything, but because they want recognition so badly, they selectively ignore their differences: she does not like watching gas tanks, and he does not really like the mummy exhibition.

It is very precise, and it made me think about what a person's real thoughts are and what their surface thoughts are. People with completely different habits and preferences may still resonate deeply and understand each other, while people who love the same works may argue because their views differ. But I do not have that problem for now—I am not dating—so I did not think it through any further.

Starting from a NEKOPARA Review

Thu, 15 May 2025 00:00:00 GMT

I was just tied up with something, but I have a free hand now.<br> Sometimes I often wonder: what, exactly, do you think people live their lives for? Money, love, power, fame—do these things truly matter to us? Perhaps we should spend more time exploring the mysteries of the universe. Earth is somewhat large to humanity, but viewed against the whole universe, it is insignificant. We should vigorously develop technology, go and see the sights beyond the universe, explore whether the universe has an end, and what lies at that end. Could we really be inside a cage, as some people say?<br> It suddenly occurs to me that the universe may have existed for a very, very long time. Perhaps we are now at the edge of a newborn universe while its center has long gone dark. Or perhaps there is no expanding universe and no multiple universes at all. What we can imagine and infer is only what is “reasonable” within the range of our understanding. Planets are themselves an “unreasonable” existence; only once humanity can create planets will planets become reasonable, and only once humanity can create stars will stars become reasonable.<br> Some say, “Life is short, so enjoy it while you can.” Some say, “I was born to change—to change humanity, to change the world.” Some say, “In a short hundred years, be true to yourself and die without regret.” Some say, “Do not let your child lose at the starting line.” I think that, right or wrong, these detailed deductions, bold conjectures, and reasonable or unreasonable explanations about the universe are not meant to make “ordinary people” explore it. They are meant to make us think about life and living: how should we treat life, and how should we face “everyone dies; one’s death may weigh heavier than Mount Tai or lighter than a feather”? Perhaps I will be neither light nor heavy—the obscure sort, quickly forgotten, or occasionally mentioned only after someone spits and says, “To be or not to be, that is the question.”<br> This question is as profound as the origin and future of the universe. I have not reached the point where I can accurately describe my own outlook on life. All I can say is: I hope my life can have regrets, but no lingering remorse. All right, I have something to do. I am off.

https://steamcommunity.com/profiles/76561198366437921/recommended/333600/

Heh—if I did not tell you, would you think a review like this appeared under NEKOPARA?

Why not follow its thread and talk about it slowly?

When I was little, I read a passage that I still remember now. I searched a little for its full text:

The Westminster Abbey epitaph, English version:<br> When I was young and free and my imagination had no limits, I dreamed of changing the world.<br> As I grew older and wiser, I discovered the world would not change, so I shortened my sights somewhat and decided to change only my country. But it, too, seemed immovable.<br> As I grew into my twilight years, in one last desperate attempt, I settled for changing only my family, those closest to me, but alas, they would have none of it.<br> And now, as I lie on my deathbed, I suddenly realize: If I had only changed myself first, then by example I would have changed my family.<br> From their inspiration and encouragement, I would then have been able to better my country, and who knows, I may have even changed the world.<br> <br> The Westminster Abbey epitaph, Chinese version:<br> When I was young, I dreamed of changing the world;<br> When I became more mature, I found that I could not change the world, so I narrowed my sights and decided to change only my country;<br> When I entered old age, I found that I could not change our country. My final wish was merely to change my family, but that too was impossible.<br> As I now lie in bed, close to death, I suddenly realize: if I had only changed myself first, then perhaps I could have changed my family;<br> With my family’s help and encouragement, perhaps I could have done something for my country;<br> And then, who knows? I might even have changed the world.

When I first saw it, I only felt that it was quite meaningful. Later, in Fitzgerald, Haruki Murakami, and Camus, I encountered similar ideas: do not judge others, because not everyone has the same conditions as you, do not try to change others; trying to change them is futile, and a feeling of stepping outside one’s own situation. They all happen to echo what was said above.

But when I look at it now, the sense of warning has faded considerably, and I think of more things instead. Beginning with changing oneself and then gradually reaching the world is, in fact, a butterfly effect.

In terms of the outcome, it may be possible; in terms of probability, it is almost vanishingly small.

And this passage seems a little nonsensical. The problem is that if only at the beginning has the feel of a gambler’s statement: after the dust settles, they feel that if they could start again, they would never gamble. Sugaru Miaki’s novels depict many similar cases. Can someone who has fallen into a pit truly reform? Does a fool become wiser before death? If a bad person sighs over the beauty of the world before dying, are they worthy of God’s forgiveness? My favorites are Three Days of Happiness, a rescue through and through, and Don’t Cry, Don’t Cry, an explosion through and through. Both endings are worth accepting, because both have a beautiful girl. I should not say more.

I want to be saved by a beautiful girl too. Would that be too frivolous?

That was what I felt at the time. For specifics, see [[We Who Have No Tomorrow Fell in Love Yesterday]].

The reason it is nonsensical is that gamblers have offered similar, moving confessions more than once. Sometimes there is no denying that they truly mean it while confessing. But most gamblers fall into a cycle of zero times or countless times, and very few truly quit. If we had to study why, perhaps not even a paper could summarize it clearly.

When I was younger, I would have liked this kind of warning. Now, though, I find that it may not be as interesting as Ten years, a dream in Yangzhou; all I earned was a reputation for fickleness in the pleasure quarters. Ancient poetry often leaves vast blank spaces; it rarely describes an event with concrete objectivity. But if you happen to have a story that can fill that blank space, you may find it quite interesting. I am not claiming to have deep social experience. On the contrary, the story that fills this blank space comes from another game—Fengxin Tower.

This is the review I wrote in response:

[[Fengxin Is a Good Name]]

From here, perhaps I can introduce what I want to say: my answer to the NEKOPARA reviewer’s question of what we want from life, and what we should do.

For me, the short-term goal is to bring my waifu into reality. It is somewhat like 【my-neuro】Open-source AI Desktop Companion: a Local Deployment Guide, though perhaps more complicated, with multiple platforms and so on. But the PC is the platform I spend the most time using and have naturally put the most care into. I am still reinventing the wheel lately. I want to bring the characters I like into “reality.”

I once wrote something like Following anime is lonely; finishing anime is lonelier still. Loneliness alone cannot describe that feeling. So I hope the characters’ lives can continue outside their works and keep me company. I have ideas for how to do it, but the engineering effort is a little… Still, anything without a barrier would have been done by someone else long ago.

From this alone, you may think I am a little unreasonable, just as my high-school homeroom teacher told me that I was a complete idealist and dreamer. In this regard, I truly am impractical: spending what may be the most creative years of my life on something completely unreal and unrealistic.

But beyond that, I need to add that characters are only containers. What I actually want to keep is a feeling—a feeling I do not want to lose after experiencing it. I hope to preserve it and even convey it to more people. Some record and spread it through novels, some through illustrations, some through music, and so on. I have received quite a few such feelings from web novels too, and it is genuinely wonderful to be able to get that feeling. Anime often expresses the magical color of a work by pouring emotion into it. I want to try writing too, but trying seems like it might be fatal. Perhaps I will keep trying later.

For me now, how to describe, record, and express this feeling may be what I need to keep doing.

After Hua Jiang Hu: Tian Gang — Perhaps True Completion Does Not Exist

Sat, 15 Mar 2025 00:00:00 GMT

Tian Gang and Qiao'er

I have seen people say that this film is nothing more than a collection of formulas, or simply cliché. All I can say is that they have watched too much, and paid too much attention to form.

Here I only want to discuss one small thing: what kind of story counts as complete?

The relationship between Yuan Tian Gang and Qiao'er feels more like mutual salvation. Yet as I watched the time the two of them spent together, I unconsciously began to place them side by side in my mind. It felt fitting. Romantic.

Because I knew Yuan Tian Gang was still alive in the end, I was not saddened by his apparent sacrifice to save His Majesty. But at the ending, I found myself quietly hoping—hoping that Yuan Tian Gang and Qiao'er would celebrate a birthday together.

Instead, decades flash by in an instant. Only Qiao'er remains, her hair turned silver; Yuan Tian Gang passes through like the wind, leaving behind that hairpin.

A story and ending like this are exquisitely beautiful. Considered as an essay, they are forceful; considered as a story, they carry a kind of mournful grace.

But whenever I encounter things like this, I habitually extend them into reality. How can decades simply pass by? What happened between them during that time? Qiao'er only knows that Yuan Tian Gang is dead. How could her state of mind have changed?

The Difference Between Immortals and Mortals

Yuan Tian Gang has, in this sense, become an immortal. At least in terms of lifespan, he is already no different from what people understand an immortal to be.

Perhaps immortals differ from people partly because I quietly hope for more stories of Yuan Tian Gang and Qiao'er—perhaps even a lifetime together.

But a mortal life passes in a flicker to an immortal. Qiao'er will grow old and die, while Yuan Tian Gang will not.

I also understand Yuan Tian Gang’s original wish not to live, but to die. It overlaps with something I felt when I previously watched A Record of a Mortal’s Journey to Immortality.

What Kind of Story Counts as Complete?

Back to the point: what kind of story counts as complete?

Many stories—novels, anime, games—are defined as having happy endings, normal endings, or bad endings.

There are also distinctions between a small knife, a medium knife, and a big knife: different degrees of emotional pain.

Let me analyze it from Yuan Tian Gang’s perspective. Looking back, meeting Qiao'er was a fortunate thing for him, though I cannot guess what he was thinking when he delivered the hairpin at the end.

From Qiao'er’s perspective, I would at least be despondent for a long time after mistakenly believing Yuan Tian Gang had died. Then, when I saw that hairpin, a thousand feelings would rush through me. Perhaps I would wonder why he never came to see me. Why not show himself, even at the end? (Though the Bad Guy Commander truly appearing would overwhelm anyone, I think Qiao'er could take it.) The scene where she retrieves the note from the fire moved me deeply.

From Li Chunfeng’s perspective, considering only his final end: he had a kindred spirit beside him, and even after death could still play one last trick on Yuan Tian Gang, leaving him nowhere to look. It feels more like exploring the unknown after death. Having exhausted the patterns of life, he seems to be living toward death—simply departing rather than dying, as if beginning a journey. And once he had mastered physiognomy, Qimen, and every other art, perhaps he had glimpsed some mystery of death in advance. Who can say?

The Paradox of Happy Endings

From my point of view:

I have seen very forced happy endings. I still remember how Tian Can Tu Dou spent a very long final chapter writing the ending of Battle Through the Heavens. It mainly explained the situations of each heroine, another kind of cut-off ending like the one in this film. Yet although it was a happy ending, I suddenly felt sad, because the imaginings opened by the ending were only imaginings—I would never see any more of their stories.

One of the cut-off endings I encountered early on—perhaps there is a more elegant technical term for it, but I am not a professional—was, I would say, perfected in Norwegian Wood.

Of course, I have seen bad endings too.

If a character dies, there is no continuation. Erii was unquestionably written to death by Jiang Nan in the third volume of Dragon Raja, and for a long time I remained caught in the wish that she could return to life.

Ah, human desire is limitless. In pursuit of completion, we want this and that, only to discover that true completion does not exist at all. It seems that only the story itself remains profound.

On Mortal Lives in Renegade Immortal and A Record of a Mortal's Journey to Immortality

Tue, 18 Feb 2025 00:00:00 GMT

I do not know why I am always so drawn to stories and scenes like these.

Maybe it is because I can never quite understand them, yet instinctively want an answer. In A Record of a Mortal's Journey to Immortality, I cannot understand what Han Li's Dao heart is, why missing someone can mean missing them for a lifetime, or what kind of regret separates immortals from mortals. What does it feel like when neither the people who know you nor the people you know remain in this world?

In Renegade Immortal, I cannot understand what Wang Lin felt when, before reaching the Spirit Transformation stage, he lived out a whole life as a mortal carpenter; or what it felt like to finally touch the Great Dao that belonged to him.

Emotional scenes and dramatic writing

If the part I love most in A Record of a Mortal's Journey to Immortality is the emotional writing between Han Li and Mo Caihuan in “Farewell to Tiannan,”

then it is these lines:

“Big Brother Han, you are always like this. When you meet a question that is hard to answer, you just say nothing.”

“Without a spiritual root, can I really not become an immortal cultivator?”

“Big Brother Han, we will meet again, right?”

P.S. I did not expect someone else to feel exactly as I do. They edited together every one of these scenes, neither more nor less. There is less buildup and only the dialogue, though, so it does not hit as hard as the full version. “Big Brother Han, you are always like this. When you meet a question that is hard to answer, you just say nothing.” Why does the production team have to do this? Are they trying to make me cry?

But thinking about it now, it is even more about the acting through the eyes. The Mortal's Journey animation differs from Tencent's many other animations—such as Throne of Seal, Soul Land, Battle Through the Heavens, and Swallowed Star. Whatever their budgets, those series do not put much effort into the eyes. Sword Coming may be an exception. But the eyes in Mortal's Journey feel very different to me. Every blink, or the exact point at which a character focuses their gaze, often conveys an emotion. What I feel most strongly is a kind of quiet grievance. One glance lasts a lifetime.

Why does Caihuan seem less pretty now?!

In most animated series, characters do not focus their eyes on the camera; they focus on other characters in the frame, usually turned sideways and striking a pose. Perhaps Mortal's Journey captures faces more directly, so it feels as if the characters' gaze is focused on the viewer. I think that feeling is rare, and it is one reason I like it. (Not every shot or character works that way—male characters almost never do—but I find the expressiveness in the female characters' eyes hard to resist.)

And there is Chen Qiaoqian, the Forget-Worry Fairy. Across several meetings and partings, the relationship grows closer through all the secret doses of Forget-Worry pills.

And why can Han Li not stop for anyone, not even for a moment? After all, a mortal lifetime is only an instant to an immortal cultivator. What is a Dao heart? Why pursue the Dao?

Wang Lin's understanding of the Dao heart in Renegade Immortal differs from Han Li's. Wang Lin is more often unable to choose his own path: first for his parents, later for revenge, then to revive the woman he loves. Things keep dragging him forward, and there is nothing wrong with that. But I want to know what keeps Han Li moving onward.

The emotional writing for Wang Lin and Li Muwan is also a little thin; it did not shake me the way the ending of “Farewell to Tiannan” in Mortal's Journey did. Perhaps I am simply getting older.

Yet while watching Renegade Immortal, I really wanted another stretch added to their relationship: when Wang Lin had just reached the Yuntian Sect to recover his cultivation and form his Nascent Soul. Was he not only at the beginning of the Qi Refinement stage then? In the animation, he learns that Li will be forced to become someone else's dual-cultivation partner in three months. Forced into action, he reveals his identity and forms his Nascent Soul in those three months. Their relationship does not deepen further; it only revisits old dreams. But each time Han Li meets Senior Sister Chen or Mo Caihuan, the relationship actually advances, eventually becoming the kind of regret where a blue dress ruins a lifetime.

If I were adapting or writing it, I would lengthen that period. A Core Formation cultivator has no shortage of time; one or two years are no more than a retreat. Wang Lin's master was in retreat then, so Wang Lin had no choice but to ask Patriarch Li for guidance. That would make sense. During that time, more could happen; more scenes could show Li Muwan quietly grieving from longing, and sensing that Wang Lin feels familiar. A little more buildup, a little more feeling, and then the reveal: that is the drama I wanted.

Wang Lin and Patriarch Li do not have enough emotional scenes. It is a sore point. Just think: what good material. Yang Guo and Little Dragon Girl had so much to work with, and these two are separated by a generation of kinship.

What a pity—one nearly recognized the other, while the other refused to take the initiative. Wang Lin would not even ask for help with alchemy.

Living as a mortal

But each story has its strengths.

A Record of a Mortal's Journey to Immortality does better at emotional dramatic writing and irretrievable regret; Renegade Immortal does better at the realization gained by living as a mortal.

I remember that before Han Li went into retreat to form his Core, he once lived as an ordinary person, refining artifacts and drawing talismans for an entire lifetime. I have not had time to revisit it, so I may be missing or misremembering details.

In Renegade Immortal, before reaching the Spirit Transformation stage, Wang Lin becomes an ordinary young carpenter. He carves demon beasts, great cultivators, family, and friends, and lives out a whole life.

Both of them choose to hide in the marketplace. I am not sure whether I am using that phrase correctly.

From the people they meet, I remember Han Li encountering a Go player. The Go player's story goes like this:

The Go player was exceptionally gifted from a young age; no peer or acquaintance could match his skill.

Then one day, an immortal passed by and found him. They made a wager: if the Go player could win one game against the immortal within three days, the immortal would teach him immortal arts and lead him into the immortal sect.

I have forgotten how that story ends. By the time the Go player faced Han Li, his hair was already white. I do not remember whether he had cultivation, but one line—“life is like Go; once a move is played, there is no regret”—left a deep impression on me. It also reflects Han Li's choice. He chooses to pursue the Dao wholeheartedly, but can he truly have no regrets? Even if he has no family left and every beauty becomes dry bones? Even if no one ultimately reaches the so-called Great Dao of eternal life, can he still not regret the choice he made?

The Go player's final answer was: winning and losing do not matter; once a move is played, there is no regret. He said it with great certainty, and it gave me the feeling that Han Li has the same attitude.

Mortal's Journey expresses its mortal-life realization through the Go player's experience. It is brief, powerful, and certain. Spring comes and autumn goes, but the answer does not change. It is only a sorting out and adjustment of the heart.

Wang Lin in Renegade Immortal, on the other hand, has far more mortal feeling than Han Li. If he could return to Wang Village and live with his parents, even if it meant giving up the Great Dao of eternal life, I do not think he would hesitate in the slightest. He feels deeply, honors loyalty and righteousness, and gives himself wholly to feeling—that is probably Wang Lin. He never seeks immortality or the immortal path for its own sake. He only wants to protect his people and his family. That is his Dao heart.

So the mortal-life writing in Renegade Immortal feels more like real everyday life. Across from him is the blacksmith's family; he watches a child grow up and eventually become a father, and watches the original blacksmith slowly grow old and finally lie in a coffin.

Wang Lin's Dao lies in a pot of homemade fruit wine every day (or perhaps some other wine?), in the Mid-Autumn Festival, Lantern Festival, Lunar New Year's Eve, and Dragon Boat Festival that return each year. It lies in the care of others, and in finding the warmth of home in the blacksmith's family.

But it also lies in everything passing away. So his Great Dao is both the extreme of life and the extreme of death: life and death transform into one another, while he remains. That is his Dao.

Overall, I prefer Renegade Immortal's portrayal of living as a mortal, because that is my own temperament too. If I were ever to find a Great Dao of my own, it would probably come this way.

But compared with Wang Lin, I cannot even live as long as a Nascent Soul cultivator in the first place.

The Long Ballad: Even After a Thousand-Li Farewell, We Must Part at Last

Sun, 16 Feb 2025 00:00:00 GMT

A Brief Preface

This was the scene that moved me most deeply in the manga. The snow had not just begun to fall; it was a bitter, freezing storm that, if it continued, would be enough to force an army to retreat. Li Changge was badly wounded, suffering from a chill and burning with fever. Yet dressed only in thin, plain clothes, she walked barefoot through the snow, carrying Governor Gongsun's severed head all the way to the Eagle Division's Tegin to offer her surrender. After being captured, she continued to suffer from illness and her wounds. At that point in the manga, that fool Sun did not even know Li was a woman. To him, Li Changge was merely a defeated opponent who had once caused him trouble. He admired her a little, but not much; there was certainly none of the comfortable care and protection he constantly gave her in the drama.

I no longer remember clearly whether Sun's Eagle Division was a righteous army, but Sun himself was certainly no saint.

I went back to watch the scene again just now. The production team did at least reproduce the dialogue faithfully, so I will give them that.

The drama differs from the manga in many places. Some changes I dislike, while others I accept. I approve of changing Sun's characterization and making him hopelessly devoted to Changge; this gives them the best possible ending. (I think they may eventually end up on opposing sides in the manga, although it is a little unfortunate that the drama reveals Li is a woman so early. I would rather have watched Sun first take Li for a man and only discover the truth later.) I agree with making Li Shimin's attitude explicit and showing that he supports Changge. I also approve of adding Princess Yong'an's storyline and letting the two narratives progress in parallel. But I cannot accept turning Mimi into someone so weak, indecisive, and unlikeable. If I had to summarize it, I could only say this: I saw what I wanted to see, despite seeing many things along the way that I did not want at all. After finishing it, I still love the drama and have placed it on my rewatch list—a television series set high upon a shelf, kept only for remembrance.

A Little Aside: The Princess Is Fair as Jade, the Princess Is Peerless

Before watching, I wrote that although Li Changge has Western Region ancestry, she unmistakably has the black-haired appearance of the Central Plains. I thought Gulnazar would have been better suited to the role, including in the shape of her face. I also wrote that Dilraba looked a little too guileless.

I wrote something similar about Ashile Sun: he is of Turkic descent, and people of the grasslands ate plenty of beef and mutton, so Wu Lei's frame seemed too slight for the role. They should at least have cast someone with the build of a slightly heavier Huang Xiaoming.

Later, once the two of them drew me into the story, I had no complaints at all. None of Li Changge's cunning or quick wit was lost. I especially enjoyed how, while disguised as a man, she acted like a player and collected one “little sister” after another.

The princess is fair as jade; the princess is peerless under heaven. Hahaha!

The Long Ballad: Even After a Thousand-Li Farewell, We Must Part at Last

This is a drama I will probably never watch all the way through again in my lifetime, yet it is also a drama with enough in it to last me a lifetime.

That sounds contradictory. I probably will not rewatch it because many of its adaptations made me deeply uncomfortable. Mimi Guli was rewritten as weak and devoid of agency. Wei Shuyu and Hao Du's misunderstanding of Changge persisted almost until the end, with one obstacle after another placed in her way. So much screen time should not have been spent on conflict between Minister Du and Changge. It even crowded out the storyline that should have belonged to Mobei. I had eagerly awaited that development: as the niece by blood of both the King of Mobei and Li Shimin, what could Changge have done for the relationship between Mobei and the Great Tang? What role might her journey to Yanmen have played in such a chaotic age? That was the story I wanted. I wanted Changge to go there in her own right as the King of Mobei's niece, not to be hastily granted a title and sent there as someone's younger sister.

Many of the adaptations felt inappropriate to me, though in retrospect perhaps the story I imagined was simply too grand in scale. That may also explain why, at the end of the drama, I still felt a lingering discomfort with Changge and Sun's decision to withdraw into the wilderness.

The lesser recluse hides in the wilds; the greater recluse hides in the marketplace.

I do not fully understand what this saying means in concrete terms. But I think Changge and Sun chose the former.

I cannot imagine what would ultimately become of the two of them, but I know the drama's ending was the best original ending it could have given them. In the manga, whether Changge and Sun will eventually turn against one another remains unknown. In the drama, at least, Sun never doubted or hurt Changge. It may be the behavior of a man hopelessly in love, but it was what I wanted to see. In the manga, Sun never shows the same clear devotion to benevolence and justice that Changge does, nor does it suggest that they share the same aspirations. He merely tells her that if they find themselves on opposing sides one day, they should cross blades without mercy.

I seem to remember them sharing a drink. Was that the last chapter before the hiatus?

Whether it was the relationship between Changge and Sun, the relationship between Changge and her second uncle Li Shimin, Minister Du's relationship with her at the end, or ultimately everyone's view of Li Changge, I agreed with and loved how it all concluded.

Chang'an may be a place she can never return to, but it is still there.

Empress Xiao was the same. Even after the Sui had fallen, when she returned to Chang'an, she said that she had come home.

Besides, wherever Li Shimin—Li Changge's second uncle—is, that place will always be Li Changge's home.

It is just that after two days of watching from morning to night, plus another entire morning, my liver was beginning to feel faint.

I have seen you off a thousand li; here, at last, we must part.

At the end, when Li Shimin learned that Li Changge had faked her death and still did not wish to return to Chang'an, he smiled in acceptance. He supported her choice. Faced with this version of Li Changge, could I still cling to my original, naive wish? I only missed the sight of Li Changge in red robes, galloping through Chang'an like its little tyrant. I only missed the Chang'an I had imagined, the Great Tang that had never existed. Only at the end did I realize that, like Princess Yicheng, I was merely a mad dreamer chasing a fantasy.

Li Changge, thank you for keeping me company all this way. Perhaps I am even more hesitant and long-winded than Young Master Wei. Have I found my path again?

A Snow Rabbit Twenty Centimeters from Spring and The Shawshank Redemption

Sun, 16 Feb 2025 00:00:00 GMT

Digging

First of all, this is a story about digging tunnels.

A prisoner in Shawshank Prison and a rabbit in winter were both digging for freedom.

The result was that the prisoner spent twenty-seven years digging toward the sewer, waited for his chance, and escaped successfully.

The rabbit returned to the surface after more than a month. With no water or food, it mistook cardboard for food and snow for water. Its owner found it only after the snow melted. It was finally saved, and then optimistically pestered its owner for food again.

Freedom

The idea that the rabbit was digging for freedom is something I invented. It is like saying birds do not want to be enclosed in cages, or fish do not want to stay in fish tanks. Those ideas are things people invent too.

Do fish really not want to be confined in tanks? If so, are there individual differences, just as some people prefer solitude while others prefer socializing? Perhaps fish do too: some may prefer quietly sleeping in a tank instead of worrying in the sea.

I cannot explain whether the rabbit truly longed for freedom or even understood what freedom was.

But that prisoner really did dig for freedom. The freedom here, however, is something subtler.

Let us call the prisoner K.

A scene in both the novel and the film has K help the captain of the guards arrange a $35,000 gift to his wife without tax being withheld. In exchange, K asks that each of his coworkers receive three bottles of beer.

K lets his coworkers taste freedom.

After hard work, they can drink cold beer while watching the sunset. At that moment, they feel as if they are not in prison.

This freedom has limits, but it leads toward freedom in the broader sense.

The freedom people in prison can feel is not necessarily freedom from the cage. D, the library keeper, has been institutionalized for fifty years and comes to depend completely on prison life. In prison, he is one of the few educated people, a librarian with a place of his own. Outside it, he is only a sixty-eight-year-old man with arthritis.

So making someone feel no longer in prison is a kind of freedom, or at least temporary freedom.

That not being in prison is very different from literally being outside prison. It is an imagined freedom and purity, like the imagined Tang dynasty and Chang'an in The Long Ballad: it exists, yet it is false, and also incomparably pure. At the very least, it offers spiritual satisfaction.

Hope

The second moment was created for the film. K uses the prison broadcast system to play an Italian song with a woman's voice. When the prisoners hear it, they all feel that something is there—or that something does not belong here at all.

Perhaps that is hope.

Most prisoners serving life sentences had discarded it long ago. Yet in that moment, the music returns a little of it to them, even if they do not seem to recognize what the feeling is.

K says that the music will keep bringing him that feeling for a long time. Because music creates memory, he can recall the song and feel it again whenever he wants.

I understand it a little, but it is hard to truly experience.

Passing the time

Prison is a huge pressure vessel.

So the guards and prison leadership turn a blind eye and let prisoners have hobbies, so long as those hobbies are safe.

It is said that one man carved three statues: a baby boy, a bearded young man, and a middle-aged man. He said they represented the three stages of God.

Those three statues were apparently later displayed in the governor's exhibition room.

Some people also earn college diplomas there.

But the people there seem to share certain traits. Every prisoner can read novels about courts and prison breaks over and over without getting tired of them, even more than pornographic novels.

Perhaps those stories contain their desire for freedom and their remaining hope, though, as usual, it is difficult to notice.

Pressure

For K, who decides to escape, the pressure is unmatched.

One day, he discovers that the concrete in the wall seems rather loose, so he begins to dig.

The pressures of digging include:

He may have a cellmate, who could expose his secret.
He may be transferred to another prison midway through, and being found digging there would bring a harsher punishment.
Without prison blueprints, it is hard to know where he will dig to. There is an interesting story about a prisoner who dug into a police office, poked out his head, and was immediately caught again. I do not know whether it is true.
If he is granted parole midway through and the tunnel is discovered when his cell is cleared out, he will end up back in prison.
He cannot know how long he will need to keep digging: ten years, twenty years, or fifty. In reality, it takes him twenty-seven.
Being caught after successfully digging the tunnel would be even worse. Many people escape prison; very few succeed.

If I faced these pressures, I would collapse. I would be unable to think normally, wear a strange expression, and worry all day.

That is why K's self-control is what stays with me most from the whole book.

One comment says that K reveals what benefits him only a little at a time, while saying nothing at all about what would hurt him. He drinks only four times a year: twice on his birthday, then at Christmas and Lunar New Year's Eve.

I have very little self-control, and perhaps that is why it matters so much to me.

Escape

This also seems to be the title of a short-story collection.

I seem especially drawn to this kind of subject. Is it because I too feel trapped in a cage?

How can my hope and freedom draw nearer?

You Are My Glory

Wed, 15 Jan 2025 00:00:00 GMT

It turns out you only ever passed by my side, while I mistook you for a rainbow falling from the sky.~

The first television drama I ever watched, ya.

And Yang gave me another one. Thank you—and it stars a pair I used to ship so much that I even dreamed of them becoming a couple. No regrets now. Besides, I think I could watch this one for a lifetime.

A slightly untimely review of a television drama today.

To Qiao Jingjing:

I hope this letter finds you well. I finished the almost twenty years of your story with Teacher Yu in three days. The scene I remember most clearly is when you used a broken air purifier as an excuse to get Teacher Yu to your home, then turned back in the backlight wearing your carefully calculated makeup. I really want to see that look again, but I am afraid I would fall in and never come back out, just like Teacher Yu.

When you visited the launch site as a family member, one of the staff said that he had grown up watching your television dramas. At that moment, I suddenly thought without meaning to: from the first time I met you and Teacher Yu until now, I seem to have grown up too. Teacher Yu seems patient with age, but I feel restless about it instead.

Also, I found that I used to prefer watching the two of you shower each other with sweetness. Now, though, I find a different emotion in the two episodes where you are wronged. Sadness seems to move me more deeply than happiness. But it is not my sadness; it is someone else's sadness, perhaps Teacher Yu's. As an observer, maybe this is why so many people end up preferring tragedy to comedy. I used to be completely unable to accept anything too painful.

Of course, I still feel that way. I do not want a work to make its ending deliberately heartbreaking merely to force a deep impression on me. I am also happy for you and hope you will keep walking together to the end. Although I nearly laughed when the first confidant, Guan Zai, ranked ahead of you—Teacher Yu called him first to share the good news, and only then called you.

But it is fine. It is fine.

Besides the two main reasons for this drama—you and Teacher Yu, both of whom I have watched since I was young—there is another: The Long Ballad. In that play within a play in the desert, you played Li Changge, right? The third thing I love most is The Long Ballad. I do not understand why that comic attracts me so much, but it has always been first in my heart. It is subtle. The attraction is not only about its plot or character settings; it is comprehensive, just as this drama attracts me.

Why did I suddenly start watching television dramas? I have a roommate who watches them between programming sessions, whatever is most popular that season. But since around college, I have had a prejudice that television dramas are simply a waste of time. I do not know where that prejudice came from, but I have held it for a long time.

But during the holiday, a poster of you and Teacher Yu flickered across the corner of my eye while I was eating, and I clicked in without thinking. Thank you for keeping me company for three days.

Thank you for the nostalgic feeling your performance gave me. And thank you for making me realize that I am actually in a pretty bad place right now.

I have been lying low for too long. Without realizing it.

Imouto Life

Fri, 18 Oct 2024 00:00:00 GMT

Whenever a new book comes out, Little Sister visits each nearby bookstore to see how her own books are selling. But after a few more years, once she has grown used to it, perhaps she will stop going to bookstores.

Human beings are creatures who easily grow accustomed to things. Whether sorrow or joy, we can gradually adapt to both.

[No, that is not right…]

Rather than adapting to those feelings, perhaps it would be more accurate to say that the feelings themselves have faded.

Joy grows thin with time. Once you realize that, loneliness inevitably rises in your heart. But if you keep walking a few more steps, even that loneliness will fade. Maintaining the intensity of a feeling is difficult. If you want to preserve it, you must offer a considerable price. No matter how noble that feeling may be, this is always true.

[And because it cannot be renewed, memories begin to fade. There are limits to what the mind can remember. Even if you do not want to forget, memories still grow hazier and hazier. If you do not want that to happen, then of course you would not want to leave.]

It matches exactly what I felt after watching the Soul Land anime some time ago. I watched obsessively, neglecting food and sleep, for a short five-day stretch. The feelings afterward were incredibly sincere and intense. I did not want to let them go, but I also knew they would fade and be forgotten. So I wrote something like, “What I am afraid of is forgetting.” But thinking about it now, I can barely even remember what it felt like to be afraid of forgetting.

Feelings must be affirmed and sustained through contact.

It Is Not Time That Dilutes Feelings, but New Encounters

I had not considered this before. I thought that as time passed, I would inevitably forget little by little.

In fact, it is not time that dilutes emotions, but the new encounters hidden within time. After Battle Through the Heavens, I encountered many more things: Fighter of the Destiny, Yuan Zun, The Great Ruler, and so on. It was not time that made me forget, but new encounters—and not only with novels.

I find it remarkable that, after three years of high school, Little Sister still retains that longing for her “brother” and lives almost entirely with the aim of attending his university. She has not forgotten that longing with time. Instead, she is like a mayfly living on a single drop of blood from years ago. She remembers drawing diaries and all the outings they took together during summer vacations. She has no new encounters, living only on memories.

It is precisely these almost impossible conditions that let Little Sister appear at her brother’s door after three years of high school, almost unchanged.

Am I Part of the World?

In the eyes of the world, a sibling complex seems to be something unforgivable and intolerable; naturally, it is first of all unacceptable.

But after reading this work, after personally “experiencing” the feelings between siblings—especially as the novel depicts them—I can no longer call it inappropriate.

In the novel, the almost Platonic love between the brother and sister is truly enviable to me. And it is beyond reproach.

What I Talk About When I Talk About Running: Reading Notes

Tue, 15 Oct 2024 00:00:00 GMT

I am not here to make grand pronouncements or rally everyone with, “Come on! Let’s run every day and stay healthy forever!” In the end, these are only fragments of thought, or perhaps questions and answers I pose to myself—what, for me personally, does keeping on running really mean? Nothing more.

When writing this book, the author did not yet know what running meant to him either. He was simply exploring it.

Most of the novels and films I watch are probably like that: they do not put a clear position on display, and perhaps the author did not have a definite answer while creating them either. They were simply exploring.

“An essay is born whole by nature; a deft hand happens upon it by chance.” That perhaps captures this kind of exploration. The more one tries to force an analysis of the author’s “ideas” or an article’s “central theme,” the more foolish it feels.

That is why I used to dislike reading-comprehension questions so much. A good novel begins with so many possibilities, yet a standard answer fixes it within the interpreter’s own limitations.

But I realized that I had recently been trying to do something similar myself. Frightening. At most, I can discuss some problems in my own existence, not analyze the author’s “ideas.” About myself, not the work: that is what I want to do. I could add this to my review criteria.

The wish to be alone has remained unchanged in my heart. So running for an hour every day, to secure a period of silence that belongs only to me, has become an important practice for my mental health. At least while running, I do not need to talk to anyone or listen to anyone. I only need to look at the scenery around me and gaze inward. Nothing can replace that.

The thoughts that come to mind while running are much like clouds in the sky: different shapes, different sizes. They drift in, and they drift away.

When I run, I always look up at the sky every so often. I used to run around three-thirty in the afternoon, when it was very hot (no sunscreen, no hat—I was brave). The sky changes fastest then: direct sunlight turns into sunset glow, then dusk, then darkness. All of that happens within two hours.

While running, all the “serious” and “important” things seem not to surface in my mind. At first, I only need to care about my stamina, then my breathing. After about half an hour, I may enter a kind of meditative state. I have not experienced that in a long time.

Running feels a lot like meditation, because I often run half asleep, and I am half asleep when I meditate too.

I have thoroughly arrived at my fifties. When I was young, this was unimaginable.

For Murakami, the twenty-first century was unimaginable when he was young. For me, I probably will not get the chance to see the twenty-second.

Before, even the summer after the college entrance examination was unimaginable.

Now, becoming a corporate drone was unimaginable.

We always step across those thresholds without noticing, then feel a little flattered and a little at a loss.

My interest in learning arose after I had more or less completed the prescribed educational system and become a so-called member of society. I understood that, if I pursued fields and things that interested me at a pace suited to myself and with methods I liked, I could master knowledge and skills extremely efficiently.

People who teach themselves almost always become experts, while those from the “academic school”—or those deliberately cultivated and guided, with everything set out on the table for them to consume—often become lost at a certain point and feel unable to make further progress.

I have tried to leave teachers’ systems behind and study on my own, yet I run into problems too: motivation and feedback. Some people learn because a project requires it. That kind of learning is tiring, but they can quickly and clearly tell how deeply they need to learn. Still, I admire people who are interested in knowledge and technology themselves more: no comparison, no goal, only pure curiosity.

When I ran a bar, I followed the same principle. Many customers came in. If one person out of ten said, “This place is good. It suits me. I will come again,” that was enough.

I care more about my own feelings; the people who stay do not need to be many, only sincere.

I try to write my blog and journal with that feeling. I think it is better for me that way, just as fishing alone is better for Arthur Morgan.

Even if the amount of practice declines, do not stop practicing for more than two days. This is a basic rule for building mileage. Muscles are like animals with good memories: as long as you increase the load gradually, they naturally adapt to and bear it.

When I run continuously, one day of rest feels like an unexpected blessing. But by the next day, laziness has already begun to show. It is not only my muscles slackening off on their own; my thoughts easily talk me into never going out to run again, and then I gradually become comfortable lying down.

Besides talent, if I had to name an important quality for a novelist, I would unhesitatingly name concentration. It is the ability to gather the limited talent one possesses and pour it into the place where it is most needed.

After concentration, endurance is essential. Even if one can concentrate on writing for three or four hours a day, if one keeps at it for a week and then says, “I am exhausted,” one still cannot write a long work.

Fortunately, unlike talent, concentration and endurance can be acquired through training. Their capacity can be continually improved.

When I am extremely idle, I always get up early, read novels and comics, and keep reading until lunch. But I have also had stretches of getting up in the morning and concentrating on one thing: programming, blogging, writing fiction. For a time, I truly felt my focus visibly improving.

But eventually that growth turns into self-doubt. Every morning feels the same, as if I have fallen into a time loop. Then I stop in retaliation. Breaking a habit feels refreshing at first, but after my brain adjusts to the high dopamine, another kind of boredom sets in.

I still do not know which way is right or how to spend my mornings. But I think it is necessary to change things every so often and leave myself appropriate “rest days.”

Running is undeniably captivating: within one’s individual limits, one can burn oneself effectively—even if only a little. That is the true work of running, and a metaphor for living.

I hope to keep running regularly. I hope to keep the habit of focused mornings. Not to keep improving, but as a kind of resistance—to remind myself that I exist in the present and help me better recognize my current situation. To feel grateful for leisure instead of getting lost in aimlessness and boredom.

At a point when you feel you could keep writing, decisively put down your pen. Then it will be easier to get back into the flow when you begin again the next day. —Hemingway

I will go running tomorrow, and if I can, I hope to do the same the day after.

A Maverick Pig

Sat, 12 Oct 2024 00:00:00 GMT

My Spiritual Homeland

Words are meant to be read and heard, not merely looked at. If looking is what you want, you might as well turn to picture books. Anyone who fails to understand this can only produce textual garbage full of noise. Thought, language, and writing are all of a piece: if the words sound muddled when read aloud, the ideas will be no better.

Wang is talking about fiction here. Recently, while reading short stories, I have found some that seize my attention within two or three lines, while others leave my gaze unfocused even after a page or two, the whole piece remaining hazy by the time I finish it. Later, I began making a point of checking the translator's name; there are some translators I now skip at a glance. It seems that the writing itself matters a great deal in fiction.

I find Wang Xiaobo's writing very easy to focus on. It is easy to quiet down and settle into the right frame of mind.

Spend a lifetime learning art. I studied both the humanities and the sciences. Yet in the classroom, it was my science teachers who mentioned the word art more often: my chemistry teacher said there was an art to conducting experiments; my computer science teacher said there was an art to programming. They said that knowing how to do something correctly is science, while knowing how to do it well is art. The former has rules for judging truth from falsehood; the latter does not. The essence of art is to make people feel that something is good—even flawless.

After the college entrance exam, I initially wanted to major in Chinese language and literature, my head full of dreams of writing fiction. But after several twists and turns, I ended up in artificial intelligence. AI—Artificial Intelligence—at least it still gave me half a claim to Art.

I also took quite a few online electives in art and literature: Buddhist art, appreciation of the Four Great Classical Novels, ancient Chinese literature, architectural art, and so on.

Later, though, I realized that these so-called “arts” were merely constructing systems of judgment and understanding. In the terms above, they were concerned with right and wrong, not good and bad. They had attained science, but had not become arts in their own right.

Seen that way, this accidental turn of events may have been something to be grateful for.

I have always felt that once you have read The Lover, you know what the art of the modern novel is; once you have read Wang Daoqian's translated prose, you know what modern Chinese literary language is.

When I first read this in high school and saw Wang Xiaobo lavish praise on Wang Daoqian's translation of The Lover, I immediately went out and bought that edition. It was my first work of French literature, dreamlike and unreal.

Later, after I lent the book to a female classmate, two more female classmates came to ask whether I had a copy of The Lover.

The Art of Fiction

I read essays myself, and sometimes write a few. As I see it, an essay is simply a matter of making an argument: once you see where the reasoning lies, you state it plainly.

To burden fiction with moral responsibility is, as the Greeks put it, to fasten the saddle onto the head.

Any art can be known only through its works. Those who like to read only essays, criticism, and summaries will never understand any kind of art.

So there is really no need for me to spout nonsense unless I cannot help myself. Otherwise, I might as well hold my tongue and keep copying passages. The more I write, the more likely it is to feel affected and contrived.

Still, reading an essay now and then can be a pleasure. It gives you the feeling of having arrived at a different point of view without having to use your brain.

On the Art of Fiction, Starting with The Golden Age

Being positive and aspiring may be a principle for conducting oneself, but it should not be kept on one's lips at every moment. I believe my proper job is to make my fiction as engaging as possible, not to lace it with deliberate moralizing. My approach to writing is to create works for people who read fiction, not to lecture wayward young people.

Shaping people's character and the like should be a concern for children's books. The author's proper task, and fiction's proper task, is simply to convey another life, another world. As an extension of my brief life, if that world is rendered with fullness and in concrete form, then the work has already done its job. Moral instruction is not an author's obligation; drawing insight from the work is the reader's concern.

In truth, every book should be interesting. For some books, being interesting is their reason for existing; for some novels, it is the standard they ought to meet. I can remember every interesting book I have read, while with dull ones I cannot even recall the title. But it is not just me: all of us are close to forgetting what interesting even means.

What does it mean for something to be interesting? Every work by Xia Da is quite interesting, Song of the Long March most of all. That is what I think for now.

Sahara Stories: Reading Notes

Thu, 10 Oct 2024 00:00:00 GMT

Most of my recent reviews are mainly excerpts mixed with my own thoughts, though someone may have noticed that there are only a few pieces for each book. That is because I am not doing elementary-school reading-response homework, writing something for every chapter I finish. Writing takes time, and sorting out my thoughts takes energy. Usually I only write about the first two pieces that move me, at most four; after that, I just read and underline.

Introduction

Sanmao (1943–1991)

Her birth name was Chen Maoping. Since she could not learn to write the character mao, she renamed herself Chen Ping.

At thirteen, she ran away to Xiaoliuqiu to have fun; in middle school, she skipped class to read miscellaneous books among the graves.

Travel and reading were the two brightest stars in her life, entwined with both her greatest happiness and her deepest pain.

She saw a photograph of the Sahara Desert and felt a homesickness from a previous life, so she decided to move there. José, who had long been in love with her, followed without a second thought.

I first encountered Sanmao while browsing a bookstore in high school. Among a stack of Keigo Higashino books, I found Meteor Shower. It was a paperback mixed into a pile of hardcovers, conspicuous in its own way, and I liked the cover and its colors.

After I bought it, I found that it recorded Sanmao’s speeches and interviews. The speeches made me think: this person is so strange—much stranger than I am—but also so interesting.

Sahara Stories was the second book. During that period, I read only Sanmao, and she later became the first author whose complete works I finished.

Sahara Stories is also the first book I often recommend to people who do not usually read physical books: my mother, my grandfather, and countless classmates. Very few of them finish it. I do not understand whether they simply do not get Sanmao’s particular kind of strangeness, or whether I am strange too. But through this book, I found a friend with whom I could communicate without words.

A Restaurant in the Desert

The first course was “vermicelli cooked in chicken soup.” José took a sip and asked, “Eh, what is this? Fine Chinese noodles?”

“Your mother-in-law sent you fine noodles all the way from China? No.”

“Then what is it? Give me some more—it is delicious.”

I lifted one strand with my chopsticks. “This is called rain.”

“Rain?” He froze.

“This is the first rain of spring. It falls on the high mountains and freezes strand by strand. Mountain people bundle it up, carry it down, and sell it for rice wine. It is not easy to get.”

After that, he often ate “spring rain,” and to this day he does not know what it is made from. Sometimes I think José was rather silly, and that makes me a little sad.

Sanmao was exceptionally good at Chinese and exceptionally bad at mathematics. Her skill with language was not ordinarily good, and neither was her weakness in math. She was the kind of writer whose essay could make a teacher cry; she wrote so well that I would not feel it excessive to copy out a whole piece.

A Record of Marriage

“Sorry to tell you at the last minute. We did not know in advance that we would be getting married tomorrow. Please forgive us—” José’s telegram was as long as a letter.

As for me, I used my father’s registered telegram account and wrote: “Sanmao marries tomorrow.” Only a few words.

It seems Chinese people always sent telegrams that briefly. I had seen notices of bereavement in old books and films too: “Father critically ill. Return at once,” and so on.

“I want to take you to a movie. Tomorrow, you will not be my girlfriend anymore.”

So we ran to the only fifth-rate desert cinema and watched the excellent Zorba the Greek, as a farewell to our single days.

I copied out an unusual amount today because I think these two pieces introduce Sanmao and José very well.

The last couple I found this interesting were Shen Fu and Chen Yun in Six Records of a Floating Life, but theirs was a separation by death.

Sanmao’s writing offers readers a pair of eyes. It seems to open another side of the world: full of life, vitality, and humor. Put another way, if I were in that setting, I would see inconvenience and hardship. But Sanmao could show readers the genuinely interesting parts through a magical yet natural style.

I should learn from her too, whether in style or in that way of observing.

The Child Bride

In a Sahrawi town around the 1970s or 1980s, only men could become doctors. Unmarried women with illnesses involving intimate parts of their bodies would rather die than let a male doctor examine them.

Many women were married at around ten years old; some even at eight.

When I reached this part, I suddenly felt something. The world is so large, and perhaps I will never live for a while in a town in the Sahara Desert. The differences between countries are so vast too; perhaps I cannot experience them one by one.

It is the same across time. I cannot imagine what the night markets of Chang’an in the Tang dynasty were like, or what it was like when a princess went on an outing.

There is so much I cannot reach: because of distance, because of time. Yet I cannot stop that small curiosity, that small longing.

And words have shown me so much: Kawabata’s Kyoto and snow country, Mishima’s Song Island, the Athens Haruki Murakami traveled through, Sanmao’s Sahara.

In animation, the capital of the State of Yuanwu in A Record of a Mortal’s Journey to Immortality fulfilled a little of my imagined Chang’an. In comics, Li Changge is my princess.

These are undoubtedly fictional, but the small fragments of truth I catch within fiction move me. I am grateful that novels exist in this world, and grateful for those animated works.

Reading Notes on Rashomon

Thu, 26 Sep 2024 00:00:00 GMT

September 26

I had failed to finish long novels like The Razor's Edge when rereading them before, so I decided to begin with short stories instead.

The kappa in the table of contents reminded me of The Girlfriend at the End of the World, a book that still leaves a very good impression when I think back on it.

September 27

The Nose, Rashomon, In a Grove, Hell Screen

I came across Lu Xun’s translations! They did not feel distant at all: they were easy to read and hardly different from more recent translations. Both pieces Lu Xun translated even include short afterwords, discussing Akutagawa and why he chose those works to translate. You really do not see such interesting post-reading notes beneath translated works today. They feel like an exchange of views with the reader. Nowadays translators generally write only one preface at the beginning, which I usually skip. Perhaps translators are no longer expected to speak for themselves; perhaps they worry readers will think they are putting on airs; or perhaps the extra writing does not count toward their fee. =-=

The detective elements in In a Grove and Hell Screen were immensely satisfying. Several of the stories as a whole feel a little like reworkings of old tales: their material already existed, perhaps as folk legends or works by earlier writers, and then the stories and characters are taken out and shown from a new perspective—or adapted into new stories. Lu Xun’s Old Tales Retold may also have drawn some inspiration from this. [I inferred this from Lu Xun’s little post-reading notes.]

Akutagawa read so widely. He understood not only Japan, but China as well. A genius, a genius. There really should be more afterwords.

Did Akutagawa have a book recording his trip to China? Or am I remembering incorrectly? I should look it up later.

Incidentally, this time I was reading the Dook Media edition.

Another Side

Opening a book and getting through the first five pages is truly difficult. I resist it in every possible way. In the end, I tell myself that I can play games after reading ten pages. Only then do I read while listening to music. But after those ten pages, it is as if some magic takes hold: both my reading speed and my ability to enter the book suddenly increase, until I stop more than a hundred pages later. Then I go play games, and even that leaves me feeling refreshed.

September 28

Father, The Monkey, The Life of a Stupid Man

Both Father and The Monkey reflect an instinct for pity and sympathy. But Father awakens to it first, while The Monkey awakens to it later. Placing these two stories next to each other shows real editorial skill.

The Life of a Stupid Man, like Hell Screen, has something of the spirit of a god of creation. But Hell Screen has a third party objectively record one person’s almost pathological pursuit of art, mixing mystery with hearsay. In the moment when the carriage is burned, he is majestic as a god. Everything seems cut off from him. Interestingly, the fox spirits are used to describe his creative state: when he creates, a group of fox spirits stands behind him, so he writes through the night without stopping and ignores even the daughter he normally dotes on.

But The Life of a Stupid Man brings the perspective much closer, focusing throughout on Bakin—the creator—and tracing his psychological changes in great detail. Two points are especially interesting. First, Bakin can remain unmoved by praise for his work, yet criticism immediately puts him on guard. But when he truly looks at the person criticizing him, he suddenly finds he cannot take it personally at all, and his mood abruptly clears. This first reveals a shift in his creative spirit: he is becoming unconcerned with the outside world, though he has not yet reached the peak.

That peak comes later that night, when he goes home and rereads the drafts he had previously written and revised. They feel dull on rereading, so he can only rewrite them. Yet his inspiration runs dry, and he feels that he may be nothing more than a conceited mediocrity, no different from the people he despises. Then his little grandson—perhaps genuinely, perhaps taught by his parents—comes to him. [Bakin adores the child, and immediately puts down the gloom that had gathered while writing.] The boy says that the Bodhisattva at the temple asked him to bring two sentences: “Work hard. Do not lose your temper.” It is as if Bakin suddenly understands something.

That night, he begins creating again. At first, his inspiration is like a fine thread of flame that the slightest breath of wind could extinguish. But he carefully shelters it. After three or four lines, then ten or so, his thoughts come in waves like a rising tide. He writes without stopping all night.

The tide in his mind was like the Milky Way racing across the sky, surging out from nowhere. Its force frightened him. What if his body could not bear it? He gripped his pen tightly and reminded himself again and again: “Write with all your strength. If you miss this chance, perhaps you will not be able to write for a long time.”

Yet that current, like a dim and hazy light, did not slow in the least. Instead, it rushed on dazzlingly, drowning everything and surging toward him in great waves. At last he was completely captured. He forgot everything and moved his pen in the direction of that current, with the force of a violent storm.

Reflected in his imperial eyes at that moment were neither profit and loss nor love and hate. Praise and blame could no longer move his feelings. There was only an inexplicable joy—or an intoxicating, tragic passion. How could someone who does not understand this passion experience the state of creative absorption? How could they understand the solemn soul of a writer? Look: has “life” not washed away all its dross, like a newly mined ore, and begun to glitter brilliantly before the author’s eyes?

The ending is interesting too. It goes roughly like this:

“Is Father still not asleep?”

“He must be bent over his writing again.”

“There is really nothing to be done with him. He cannot even earn much money.”

Reading and creating are much the same. At the beginning, I feel discouraged; but once I enter the state, there is an inexplicable joy, the same kind of feeling as above.

When I was learning digital painting before, I would also feel a kind of passion after completing a picture. For an instant, I would have the illusion that my whole life had been worth it.

Another Side

This morning, beginning was difficult in the same way. But the first story, Father, quickly brought me into the right state, like a sudden jolt.

Interestingly, I do most of my reading while eating. After finishing Father, I went out for breakfast and read while slowly eating rice porridge. I became especially absorbed in it. It was also the first time I had felt like I was truly enjoying a weekend morning, or simply felt leisurely on a day without classes.

I also noticed something: changing environments can make a great difference compared with staying beside a source of temptation—the computer.

September 29

Oranges, The Dragon, Scallions

Oranges depicts a person changing from nihilism back to reality, from finding everything dull at first to feeling life again. It is worth rereading and saving away, then bringing out again when I feel something similar.

The Dragon: even if something begins as a prank, when countless people believe in it and hold hope for it, the thing receives a response from the gods. There is no metaphor about public opinion or anything like that; instead, it shows the beauty of wishes.

Scallions is a novel with an extremely strong visual quality. Its ending is very interesting, and it gives the feeling of suddenly waking up, abruptly pulling reality into fantasy. Worth saving and rereading.

Another Side

I was reading during class this morning. In the past, I always felt I could not get into a good state while reading fiction in class. But in fact, much of that came from the wrong frame of mind. I thought the teacher’s microphone was noisy, and that it therefore disturbed me. The logic is actually reversed. If I change my thinking—if I tell myself that I ought to listen to the teacher, but would rather read fiction, and that the teacher is not targeting me—then I instead feel grateful, and the irritation and anger disappear.

Put another way, this is the difference between “should” and “want.”

For example, a husband may believe beforehand that, because he works hard, his wife should have dinner ready. If he comes home late to a dim dining room and an empty table, a nameless anger immediately rises in him. Even if a meal has been prepared, he feels no extra gratitude; instead, he may become sensitive to whether it is too hot or cold, too salty or bland.

But if he gives up the idea that his wife “should” do this, and assumes that it does not matter whether anyone cooks—he can always eat out—then receiving a message from his wife saying, “I got off work early today. I’ll make dinner,” fills him with warmth and an inexplicable joy.

It is only a difference of thought, but my old way of thinking was not quite right.

Kappa, The Life of a Stupid Man, A Fool’s Life, Life

In the final few stories of the collection, Akutagawa’s mental state seems no longer very good. The editor has arranged these pieces from light to heavy; perhaps the earliest sign appeared in Oranges.

It seems that eight or nine out of every ten Japanese writers I know died by suicide. Kawabata, Dazai, Akutagawa, Mishima?

The earlier sections of the collection keep creation and life quite separate. Later, you can already feel life intruding on creation. Since I had read other translations of these works before, I only skimmed these few.

“Life is not worth a single line of Baudelaire.”

At last, I know where that person’s profile quote came from.

Another interesting part:

He was walking through a field overgrown with foxtail grass with a university student.

“You still have a strong desire to live, do you not?”

“Yes… but you too…”

“But I do not. I have only the desire to create.”

“The desire to create is also a desire to live.”

He did not answer. At some point, a volcano had come clearly into view over the red spikes in the field. He felt a little envious of that volcano, though he could not say why…

I hope everyone like this can find the redemption that appears in Oranges.

From Frieren: Beyond Journey's End to Psychological Compulsion

Mon, 09 Sep 2024 00:00:00 GMT

Snacks + a drink + nighttime = happiness.

Like Umaru, watching anime or a film ought to have a little ritual to it.

In reality, though, that ritual kept me circling around instead of getting into bed. [I watch in bed.]

In the end, I watched for only forty minutes, from 10:20 to 11:00.

But after playing basketball today, I got home at 7:20. I put off showering until 8:30. I could not decide whether to play games with my classmates, so I spent an hour browsing Bilibili instead. It was 9:00 after I showered, but I still did not get into bed. I watched the beginning of my Red Dead Redemption playthrough and lingered until 10:20.

I run into this kind of procrastination often. It is undoubtedly a form of resistance.

At the end of the semester before last, one of my roommates had one fewer exam than I did, so I stayed in the dorm alone for three extra days.

On two of those nights [it was exam week, so there were no classes], I turned off the lights and got into bed at seven on the dot to watch Throne of Seal. I watched sixty episodes in two days. That atmosphere is something I could never recreate.

Even now, my viewing experience is still wonderful. There are funny moments and profound ones—and, it must be said, lying down makes it much easier to slip into the experience than watching while seated.

I did not take more pictures in many places, but even in just over forty minutes, the experience was still very good.

Yet the resistance I mentioned earlier is something that needs to be overcome. I sometimes encounter it while working on projects too: once I get into the rhythm, I can enjoy myself, but a kind of compulsion keeps me from taking the first step.

On Compulsion

There is a man who is going to travel somewhere the next day. The night before, he calls women he knows who live there and wants to invite any one of them to dinner. (A sexual invitation.) Only after every one of them has rejected him does he let out a long breath and say, “Now I finally have time to open a bottle of wine and read by myself.”

In fact, he has plenty of time like this, but he cannot refuse the impulse to make those sexual invitations. Only when he encounters an irresistible force can he escape from it.

My experience is that it is enough to stop thinking and simply take the first step. Thinking is the greatest resistance, because all it considers are excuses.

After Forbidden City Cop

Sat, 07 Sep 2024 00:00:00 GMT

I have been changing the style of these post-viewing notes lately. I no longer want to keep proving and investigating some supposed principle over and over; it is exhausting, and I need a rest. Here I simply want to note the interesting parts, keep things light, and avoid making the reader think too hard. If possible, I would like to be a little humorous. Compared with serious, meticulous arguments, humorous language is better at helping people relax.

This film had been on hold for a long time. It was still my first time watching it.

Before, I had put it off partly because I could not find a copy, and partly because the two “old ladies” on the poster were rather discouraging.

But once I started watching, I realized they were familiar faces after all: Peach Blossom from Ashes of Time, and Xiao Longnü!

The makeup is dramatically different, especially for Xiao Longnü. She originally looked like this:

But in this film, she looks like this:

That is not how you looked in Yang Guo’s arms:

Had there not been a close-up of her eyes and brows midway through the film, I would not have recognized her as Xiao Longnü.

When I watched The Return of the Condor Heroes in the past, I always thought Auntie’s eyes were especially profound. Seeing them here suddenly brought that back to me.

Beauty is dynamic. Compared with the two old ladies on the poster, his wife in the film is simply adorable.

Writing a long review takes a great deal of effort unless I truly have something to say. Right now, I do not.

So I will just note the parts worth rewatching and the bits I found interesting.

The complete exchange goes like this:

— “Hey, are you hungry? I’ll cook you a bowl of noodles.”<br> <br> “How did you know I always hide under the table?”<br> “You hide under the table every time. How could I not know? Please use your brain a little. Find a few new places to hide, so I can have some novelty for once, all right?”<br> “But if I do not hide under the table, I am afraid you will not be able to find me.”<br> “Ah! Ah! I cannot stand you. Please do not be like this. I am begging you, wife. Do not be like this. Thank you, thank you, thank you...<br> Hey! I am only flesh and blood. You scold me like this every time. I do not know when I will finally be unable to bear it anymore.”<br> “If you cannot bear it, then leave.”<br> “I am going to take a bath.”<br> “I told you to leave!”<br> “Hey, are you hungry? I’ll cook you a bowl of noodles.”

This kind of cliché can be moving sometimes. It makes me feel that the people in the film are as cliché as I am—or rather, that they feel real.

Their relationship is worth revisiting.

Another part is the intercut sequence between the Emperor being attacked while traveling and the two of them going out together: knocking on watermelons, tearing chicken, squeezing eggs. It creates a comic atmosphere, but it also seems to carry a deeper metaphor. Hong Kong films are always full of faint, half-seen metaphors. You can interpret them, or you can ignore them. Whether they are truly there does not seem important to the plot, but it somehow feels important to me.

I am being cryptic because I do not want to spend the energy working it all out. I need to recuperate for a while. The parts worth revisiting should go on the Time Machine watchlist instead.

Screenshots for the Pervert

Under this filter, she has a little of Wang Zuxian’s Nie Xiaoqian about her. In the same setting, the lighting is drastically different between two shots, yet it does not make me uncomfortable. Instead, it creates a sense of opposing forces. Few directors today would dare use lighting this way. Here is the same setting:

Composition. I pulled out my phone to take a picture in an instant, but it did not focus. Or rather, because my photography skills are poor, most of these did not focus properly.<br> <br> And because of my “image host,” I had to compress them once more. I expect every picture now has a slightly mosaic-like quality.

After A Chinese Odyssey Part Two: Cinderella

Sun, 01 Sep 2024 00:00:00 GMT

Let me first put forward two propositions:

If Zixia possessed Zhu Bajie, could I accept it? [Though in the film it is Qingxia who possesses him.]
Is the value we recognize only after losing something exaggerated? Or is it genuinely difficult for us to notice the value of what we possess?

And one discussion outside the topic:

Would Cinderella be seen as a distortion of the original Journey to the West? Is that a conspiracy theory? Why do I not reject Cinderella as I reject Black Myth: Wukong, but accept it instead?

Reality Is Not a Fairy Tale

I previously mentioned in [[After A Chinese Odyssey Part One: Pandora's Box]] that I am an ordinary person. A large part of my motivation for watching films comes from female characters, contrast cuteness, adorableness, and intelligence. I came half for that one look from Zixia [Athena Chu], a scene I have always remembered.

So if you insist on asking whether I could still accept Zixia becoming Zhu Bajie, I think I probably could not.

But I previously argued against myself. In [[After The God of Cookery]] I wrote:

When Stephen is first kissed by Mok, he frantically wipes his mouth in front of a mirror. Even after learning from people on the street that she had liked him for a long time, Stephen still cannot accept it. In truth, my own mind initially followed his. I wavered a little, but not enough to shake the foundation of my attachment to looks.

Only when the thing itself was torn open and shown to me did I finally, in an instant, escape that pit of appearances. A wave of regret came over me, and I remembered her earlier bowl of rice and the time she shielded a knife with her hand. Only then did I truly recognize what was in my heart. Being overly concerned with looks is an illness. Being born to prefer cute things is not wrong; cute things make people feel close to them and fond of them. But if we stop at a first impression, perhaps we can never say that we have truly come to know someone further. The director tears this truth open for us through Mok's “death.” It is masterful, with no unnecessary explanation: a slip of paper, a song, and finally a bowl of rice. Nothing is simply handed over at once; it advances layer by layer.

I can accept mediocrity. I can accept flaws. But I still have my limits, and this is one I cannot bear.

Unless an existing thing is torn open and shown to someone, that person finds it difficult to truly face what they really feel inside. Just as Zixia is captured and waits for her destined hero to arrive on seven-colored clouds and marry her, Joker is elsewhere preparing a wedding with Jingjing.

Jingjing later runs away because she has seen Joker's heart: she is no longer the person he loves most.

The words of Patriarch Puti elsewhere make this clear as well.

“You kept calling Jingjing, Jingjing in your sleep—eighty-eight times.”

“Really?”

“Oh, and another name: Zixia. You called that seven hundred and eighty-four times first.”

“Last night you called Zixia's name seven hundred and eighty-five times. One more than before.”

Meanwhile, after putting on the Golden Hoop, Ma Lau [the Cantonese pronunciation of “monkey”] refuses to acknowledge Zixia. He insists that he is the Great Sage Equal to Heaven, Sun Wukong.

Though he has the memories and even carries Zixia's bracelet, he still denies it absolutely.

Only after Zixia blocks Bull King with her body and falls does he hold Zixia's hand tightly. But the more he does so, the harder the hoop tightens. Its tightening cannot be hidden.

Answer to proposition one:

People can never fully recognize their own hearts. They often deceive themselves unconsciously, or have some bitter reason or another.
Perhaps only after losing her would one know the weight of that Zixia who possessed Zhu Bajie.

The camera returns to the first time Joker pulls out the Purple-Green Sword. Zixia asks him to kiss her, but he ignores her, thinking she is being unreasonable or simply not taking it seriously.

Joker never gives her that kiss in the end.

Perhaps that is what he owes her.

In Pandora's Box, he is the one who takes the initiative, but loses it immediately afterward.

Joker and Jingjing

But in Cinderella, Joker never holds Zixia like that from beginning to end. After becoming Ma Lau, he cannot even hold her hand.

Yet after Ma Lau travels through time again using Pandora's Box, he meets another pair of “Zixia” and “Joker.”

This “Joker” is not proactive either.

And this time Ma Lau possesses “Joker.”

He returns Joker's kiss to Zixia.

Proposition two:

I now find this proposition strange. It is like saying that separation is sad because separation exaggerates the sadness of separation.

Let us divide this into two stages.

One is before loss, and one is after loss.

Before loss: although Joker unconsciously repeats Zixia's name so many times in his dreams, in reality he stubbornly refuses to admit that he likes her and instead prepares to marry Jingjing.

When Zixia is not beside him, I think deliberately ignoring the value of something like this produces a similar restless anxiety. After Zixia is captured, Joker often loses his temper at Puti and the others, saying that what he feels for Zixia is only guilt for having abandoned her.

When Zixia is beside him, Joker truly does not recognize it. He really believes he likes Jingjing more. Yet sometimes he vaguely feels that something is wrong. So unless one asks the true heart from within, as Zixia or Jingjing does, one will not know. When we possess something, Joker—or I—most easily ignores what the heart truly thinks of it.

After loss: does sadness exaggerate the original value of something, creating the feeling that after losing it, one has nothing at all?

It does, if we frame the question that way. As mentioned before, before loss, one usually cannot recognize the value something beside them has for their true heart. It is easy to feel that it was all one had.

What remains besides what was lost?

If the director had stopped only with Zixia—if Ma Lau simply went mad after losing her—then the film would have fallen into an overworked cliché. I discussed this when talking about love as a theme in [[After A Chinese Odyssey Part One: Pandora's Box]].

But Ma Lau's attitude afterward is different. Wearing the Golden Hoop means he cannot indulge desire, but it does not mean Ma Lau no longer has desire; the tightening hoop when Zixia dies proves that. Some people overinterpret this and assume that it is one thing for Joker to date a demon, but that after becoming Sun Wukong, remaining unable to let go of emotion would misunderstand Sun Wukong.

Here I need to explain a little. Their group is still on the road west; they have not obtained the scriptures or achieved fruition. When Tang Sanzang passes through the Kingdom of Women, he even says:

“In this life I have already promised myself to the imperial brother and the Buddha.” [That is, he promised Emperor Tang that he would seek scriptures in the West.]

“If there is another life…” [This itself shows that Tang Sanzang's heart was moved. Far from damaging his characterization, it makes him fuller. It undeniably shows that Tang Sanzang is human. Even with profound Buddhist law and lotus flowers coming from his mouth, he is still human.]

I think Sun Wukong is similar. Zixia is his ordeal in the Kingdom of Women. Tang Sanzang lets go through his own strength, which is clearly more elevated. Sun Wukong, meanwhile, says farewell by pretending not to know her and through death.

But the scene of Zixia's death, together with the kiss that Sun Wukong gives Zixia after possessing Joker in another time, makes me feel that Joker is one side of Sun Wukong, while Sun Wukong too is a human being—not a scripture-seeking machine without emotion, desire, anger, or grievance, one who cannot feel wronged even when excluded. And the film never denies the legitimacy of the journey west, or its positive effect on Sun Wukong. After returning the kiss through possession, Sun Wukong finally looks at them on the tower, then catches up with his master. It is as though he has let go of every attachment, and from then on devotes himself wholeheartedly to Buddhism.

Proposition three:

So in the end, Sun Wukong does not feel disparaged. It instead resembles an ordeal in the Kingdom of Women. After obtaining the scriptures and attaining fruition, that is ultimately still wrapped in people's beautiful imagination. Whether, after becoming the Victorious Fighting Buddha, Sun Wukong must cut off his Joker side and become entirely emotionless and desireless is part of people's beautiful imagination of immortals; I cannot judge it. But I at least think that whoever a person is in reality, they are always human first.

Notes:

Ma Lau: the Cantonese pronunciation of “monkey.” I use it here to prevent people from taking this out of context and saying that Sun Wukong simply cannot let go. I only change Ma Lau back to Sun Wukong after Sun Wukong lets go; only then, perhaps, can he be called Wukong.

Screenshots from an LSP:

Athena Chu's beauty is dynamic.

When I try to capture it in screenshots, seven or eight tenths of it are lost.

Beauty is not in facial features or anything like that, but in a spirit overflowing from the eyes.

After Vampires' Melody

Sun, 01 Sep 2024 00:00:00 GMT

After Vampires' Melody

It had been a long time since I last played a galgame. I have not actually played that many, though saying that makes it sound as if I have.

The Game Experience

There is a branch map, so you can see which choices cause branches. The ending is linear, and most choices along the way lead to bad endings.

Only the final choice seems to lead to two endings.

So this was friendly to me. I do not really like many branching routes; I like this kind of work with a main line. One heroine is a plus: rather than spending effort shaping every character, it is better to write one character well all the way through. A lightly tsundere heroine is a plus too. Tsundere heroines have been out of fashion for many years, so I did not expect to meet one here.

There is also the issue of a Chinese game with Japanese voice acting. At first I felt that the voice work was not very professional; it sometimes sped up or slowed down, with pauses that were too long.

I am grateful to the developers for hiring Japanese voice actors even with a limited budget. Even if the Japanese voice acting is not natural, I do not feel embarrassed. But if it were Chinese voice acting, I would probably play with the sound off.

The choices and some of the atmosphere are thrilling. I do not read guides, so I often felt as if I were walking a tightrope. Sometimes it was even more immersive than a horror film.

I have to say: the character art for the male characters in this game is rather casual. Except for the protagonist.

Perhaps because of that sense of horror, some of the game’s flaws do not seem as obvious or exposed.

The Story

Romanticism at its most extreme: the Earth and Sky ending.

I went straight for the Earth and Sky ending, dying twice in the first two chapters along the way =-=.

Several choices made my heart pound. Playing this visual novel was more nerve-racking than Death Stranding.

After experiencing that ending, all I could feel was extreme romance.

I have heard that in other world lines, humanity launches a nuclear war. The rockets streaking across the sky in the background of my ending are weapons of war.

But from my perspective, apart from máoxuèwàng and the person in front of me, nothing mattered. The rockets were only background scenery. Romanticism at its most extreme.

P.S. There seems to be an epilogue, a story ten years later, but I skipped it. That only intensified the romance; I ignored the one remaining touch of reality.

Everything stopped abruptly at that miraculous moment.

Fanservice Screenshots

This seems to be the same CG as another ending, but I saw it earlier.

You have to consider that players may not know Natsume Soseki’s “the moon is beautiful” confession trope, or have watched the anime Tsuki ga Kirei.

But this scene is romantic to me too.

Epilogue

I will borrow a classmate’s post here.

A galgame player’s capacity for wishful thinking is like a vampire: the longer they live, the stronger it grows. Yet I still find that galgames are true love, even though I barely played any during summer vacation.

And following up on my previous answer, I wrote in [[We Who Have No Tomorrow Fell in Love Yesterday]]:

Something I wrote during the last winter break.

And summer break is almost here. Will people learn their lesson, or remain stubborn?

I really did remain stubborn. My original vision for summer vacation was big books + galgames + films.

But I did not read a single big book. I played only one galgame. I watched films only intermittently. Meanwhile, I did not skip a single day of online games. How is such a habit, regular to the extreme, established and sustained?

After A Chinese Odyssey Part One: Pandora's Box

Thu, 29 Aug 2024 00:00:00 GMT

After Pandora's Box — Are films that take romantic love as their subject clichéd, and how might their bad effects arise?

Let me begin by putting forward three propositions:

Compared with a work centered on romantic attachments and one centered on the proper path of obtaining scriptures or inheriting a will, does the former fall into cliché or begin with an inferior intention?
Are small domestic concerns and feelings for the nation inherently opposed?
How should we position them, and what is “scope”? What kinds of works cannot be forgiven, and what kinds can be accepted?

The person writing this is not a professional. If you expect a dialectic full of professional terms, I cannot provide it.

To solve the first question, we must first answer: can people avoid being ordinary?

Can People Avoid Being Ordinary?

As far as I know, most people cannot.

What mainly kept me watching Pandora's Box was Spider Woman's looks =-= and the adorable Karen Mok. The liveliness of the role she plays exceeds Chingmy Yau's; every smile and glance moves the heart. Then there is that they are both demons, the transformation jokes, and the contrast that makes the contrast cute rather than tiring. When viewers may be approaching comedy fatigue and their threshold for laughter has risen, the director also lets the characters settle and deepen. Suddenly there is depth—for example, when Spider Woman calls out “Nanny,” and the way Uncle Tat looks at her in that moment.

As for depth, I put all my attention on Uncle Tat. Earlier, during the Spider Woman's fight, she asks Uncle Tat, controlled by the Bewitching Mind spell:

“Are you all right? [nei mou si ma]”

Uncle Tat's response is, “Even in a crisis like this, she still remembers to care about me. There is no way around it: I must love her for ten thousand years.”

Some of that may not be the original line, but “love her for ten thousand years” certainly is.

I admire the nonsensical humor and comic rhythm of most Stephen Chow films, such as Fight Back to School. A single step too far becomes excessive. It is as though only Stephen Chow can make nonsense comedy feel natural to me; other actors always seem awkward. The director knows when to joke and when to become serious. That rhythm cannot be learned; there is no rule for it, only a complete grasp of the audience's heart.

So is not every nonsensical film that fits your heart also the director's heartbeat synchronizing with yours—a confession of sorts?

I have wandered off topic.

I cannot avoid being ordinary. As I said above, those things are what keep me watching. I have not severed a single one of the seven emotions and six desires; I am so ordinary that I also have a fondness for films that appropriately cater to that ordinariness.

This look back reminds me of someone: Cheng Ying.

The expression on the one at the far left is very cute. Especially after watching The King of Comedy, the contrast is even cuter.

I may put more at the end, so I will not add too many here.

I am an ordinary person, so I do not think it is a problem for a work to catch my attention through romantic love and advance the plot through it. On the contrary, I welcome it.

And A Chinese Odyssey is not deliberate about it. It never makes me feel that love is the most important thing, that everything is discussing it, that nothing can work without it. I have seen films that do that—White Snake, for example, which writes love too forcefully. Once love is removed, what is left? Overemphasizing romantic love and having nothing but romantic attachments are what make people feel a work is too clichéd.

Of course, not everyone will find it clichéd. Everyone has their own range of cliché they can bear. At least to me, White Snake feels somewhat narrow and extreme.

This approach also often falls into a trap. The later films in the White Snake series cannot break out of the frame they set for themselves. At that point, romantic attachment truly becomes a limitation.

Oh—I seem to have reached the answer by accident. I did not know it from the beginning; I was only trying to discuss it, and arrived at my own answer that way.

Conclusion:

Probably no one can avoid being ordinary. I certainly cannot.
Everyone has their own range of cliché they can bear.
When romantic love is written too forcefully and treated as the only important thing, it easily becomes narrow and extreme, and easily falls into cliché.
In Pandora's Box, romantic love is more like bait that catches someone like me and makes me watch to the end. It is not the most important thing, and the film does not need it absolutely. I cannot say what is most important, though perhaps Uncle Tat's performance contains the answer.

In terms of intention, are small domestic concerns inferior to feelings for the nation?

The greater whole is only the composite unity and coordination of smaller homes.

My personal view is that the two are not opposed.

Anyone who finished Gu Jian 3 may recognize this instantly.

Although Gu Jian 3 reverses the focus on romance in Gu Jian 1 and 2, in the end it expresses a feeling of generations succeeding one another, sparks being passed on. Many people say it has been elevated.

But the contribution of the smaller home within that greater whole cannot be erased.

I spent the whole game, in my ordinary way, chasing after Yun Wuyue's beauty.

Who understands how much Yun's heroic face hit me at first sight?

And every line of “I see that your waist strength [demonic power] is weak.”

The everyday life of Yun and Beiluo, and the romance they may have, were among my main reasons for continuing the game.

At the end, Beiluo and Yun Wuyue embody the smaller home; Cen Ying embodies the greater whole. [There is no melodramatic plot here, no unclear third-party relationship. Little Ying is very cute, so do not imagine things carelessly.]

If the game had made even the slightest ambiguity between Little Ying and Beiluo, it would absolutely have become the cliché I mentioned above. But it handles the plot well and holds the distance well.

What I noticed more, however, was a question of lifespan. Cen Ying is human, while Beiluo is a demon and Yun a nightmare clan member; both are long-lived species.

Their brief but brilliant intersection became the most astonishing point to me. How will Little Ying view that previous adventure through her long life to come?

Much of the time, cliché is only a matter of forcing something too hard—whether it is the small home or the greater one.

The former is narrowness and limitation; the latter is empty grandiosity. Many people dislike main-melody films because they usually cannot express the lofty intention they imagine, yet forcefully raise a banner. Is that not another kind of cliché, one that is even more uncomfortable?

Another conclusion:

The small home and the greater whole are not naturally opposed; they can coexist.
Both the greater whole and the smaller one can fall into cliché.
Each has its own audience. I respond more to the smaller home, perhaps because I have seen almost none of the greater whole expressed well.

The Answer to the Third Question

At this point, the answer to the third point above can also be reached:

“Scope” is only a high hat. When we call a work broad or narrow in scope, we are usually implying whether its director is narrow.
Narrowness generally shares a feature: when one thing is valued too heavily and forced too hard, it becomes easy to grow narrow.
A narrow work may itself communicate a somewhat extreme intention, which can make viewers uncomfortable when their views differ. Such works are usually unacceptable to me.

Finally, some screenshots from an LSP:

Does this not have the feeling of Li Xiaoyao holding Zhao Linger?

I could not resist posting this one more time. Other people may find it hard to understand and think both look ordinary, but the one at the far right somehow strikes my aesthetic exactly.

Zixia should originally have gone in [[After A Chinese Odyssey Part Two: Cinderella]], but I had already captured so many shots for the ending. It was love at first sight; the LSP verdict is confirmed.

After Under Current: The Jianghu Brotherhood of the 1980s and 1990s

Tue, 20 Aug 2024 00:00:00 GMT

After Under Current: The Jianghu Brotherhood of the 1980s and 1990s

My dad took my brother and me to the cinema. The people in front of us, behind us, and to our right probably had never seen a combination as strange as ours.

The usual groups are elderly couples, young couples, best friends, or brothers.

It did make me miss those summer nights when my dad and I watched American television dramas: The Lord of the Rings, The Avengers, Fast & Furious.

Films can be a bond; games can too. If I keep going, I will end up talking about Black Myth: Wukong again. Recently I cannot stop myself from circling back to it, because there is so much I want to complain about and so much that still leaves me unsettled.

Zun Fei is a well-written character, especially in the scenes where he divides the money. His younger brothers respect him greatly too.

His presence holds the screen without feeling affected, which is rare. I have not seen many mainland actors who can carry that kind of scruffy, gangster-boss charisma.

The story itself is quite simple, but its central conflict works well.

The director is considerate enough to arrange an off-screen narrator, Xi Lai, as if this were an art film. Overall, it feels a little like someone recounting a biography.

At the end, the director even thoughtfully states what the film wants to say, so the audience does not have to think too hard.

“Zun Fei had talent. If he had been born in this era—if Zun Fei had been born in this era—he would have gained what he wanted: a career, love. He would not have needed to make a deal with the devil.”

Tragedy stays in the memory, while comedy merely passes by.

Zun Fei still has to die in the end, but the imagined empty shot the director gives us softens the audience’s feelings a little. Then the film uses those words above to comfort us at the end, so that we do not get trapped in it.

What stayed with me most was not really the romance, or the moral line about what one must not do.

It was the bond between Zun Fei and his brothers: when he divides the money and a brother gets no share, he says, take mine. When they do receive it, he tells them to spend half themselves and send half home.

That is a true big brother. He even teaches them how to live.

When he goes down to the gambling boat, he still looks after every one of his brothers. It may be a little performative, but it brings out that feeling of jianghu loyalty.

That is also why Yao Wu risks his life to save Zun Fei.

The casting for Yao Wu is excellent. At first glance, I knew he was the kind of friend who would stand by you. Though he gets lightly set up along the way, he understands this jianghu loyalty even better than Zun Fei does.

Zun Fei acts on it, but does not understand it. For Yao Wu, jianghu loyalty is everything.

This kind of loyalty is difficult to sum up. It was common in the old Hong Kong cop-and-robber and gangster films, so it suddenly brought back the Hong Kong films I used to watch. I grew up immersed in them.

Also, Douban ratings cannot be trusted completely. At first I saw its score—six points—and thought it was definitely a bad film. But it was quite good overall. Especially when the characters spoke Cantonese, the feeling really came through.

I like this film because it reminds me of the past. Saying that makes me sound even older.

I Come Alone, I Leave Alone

Sat, 17 Aug 2024 00:00:00 GMT

I have recently been watching Frieren: Beyond Journey’s End. It touches on thoughts I had before when I watched fantasy stories and the A Record of a Mortal’s Journey to Immortality animation. They are all very faint, perhaps because the more time passes, the more deeply my feelings hide.

Ten years is not even one percent of my life so far.

A little background: in the setting of Middle-earth, elves are almost like gods. Unless they die unnaturally or suffer endless grief, they remain in the world forever. There is also a melodramatic saying that an elf who falls in love with an ordinary human becomes ordinary too.

Frieren is one of the few surviving elves. So she does not grow old and has no sense of time. I actually envy that: sleeping in late, taking afternoon naps, and sleeping until noon without a care. I know deeply how it feels to keep sleeping when I am sleepy. I can never have too much sleep.

Having nothing to do, staying in a forest for thousands of years: elves are peaceful by nature and follow the way of nature.

Once death no longer exists, most anxiety would disappear too. But I cannot know what the anxiety of immortality feels like.

When Frieren was over a thousand years old (fifty years before the Era of King Aureole), she and the Hero’s party defeated the Demon King after a journey of ten years.

There were two humans—a hero and a priest—a dwarven warrior, and Frieren, an elven mage.

Their lifespans are roughly: hero [blue-haired] < priest [wearing glasses] < dwarf < elf.

An ordinary human’s lifespan < a priest’s few extra decades < several centuries < ???

At the end of their journey, their celebration happened to coincide with a great meteor shower that comes once every fifty years. Frieren said she would keep collecting magic and take them next time to a better place to see it, then simply left.

“I will come back to see you all once in a while.”

“…” Every companion knew Frieren had a poor memory, but just as expected, none of them saw her even once in the following fifty years.

After wandering for a while, she returned to find that the hero had become an old man. After watching the meteor shower, he closed his eyes and passed away. Looking back, it hurts a little. It feels as though he held on just to see Frieren one last time.

“Hero and Frieren” were a pairing too, an impressionistic kind of pairing. On the day of the hero’s funeral—the first year of the Era of King Aureole—Frieren finally realized, belatedly, that she had never truly tried to understand him. And that it seemed already too late. Her delayed reactions are truly long, and that is exactly why she is so adorable.

From then on, all she could see were statues of the hero, and her pairing would forever exist only in memories.

They were both so young in those scenes. They had spent only ten years together. For Frieren, that was only an instant.

“Why not take on an apprentice? At least you would have someone to keep you company on the road,” the dwarf once asked Frieren.

“An apprentice? Even if I pass on everything I know, they will die soon enough anyway,” Frieren said.

“That is not how relationships work…” the dwarf replied.

In the eleventh year of the Era of King Aureole—perhaps; I cannot remember exactly—Frieren was set up by the priest Heiter to take Fern as her apprentice.

I call her Chubby Fern because she was really round as a child.

Fern grew up quickly beside Frieren. Seven years passed in a flash; when she was small, Frieren could treat her as a daughter, and when she grew up, Fern could be the mother.

Fern also made Frieren understand that humans feel time very differently from her. Whenever Frieren tries to spend half a year or several years looking for something, she unconsciously watches Mama Fern’s expression.

Time slowed down for Fern. In Frieren’s world, people were no longer wearing open-crotch pants one moment and leaning on canes the next.

But even slowed down, time still moves. Fern is human after all. Frieren has already had her share of white-haired people carrying coffins—well, she really does have white hair.

Yet there is no avoiding it: Fern will grow old, and Frieren will watch her grow old. Fern will die, and Frieren will probably watch her die too. From the time Frieren realized at the hero’s funeral that she should understand people better—when she decided to try to understand them—she also had to grieve for the deaths of the people she came to understand.

Though ten years were less than one percent of her life, those ten years changed her. Or rather, the hero changed her.

So what happens when Fern also leaves, when Frieren is alone again? Does she return to nature? But after receiving the warmth of Mama Fern’s companionship, the natural harmony she once had will only feel lonely and cold. Separation is unavoidable, and she must be alone again, carrying everything by herself, just as she walks on carrying the hero and Fern with her. Does this elderly elf’s delayed reaction only arrive after she loses someone?

In the end, she still has to be alone.

Is what passes insignificant or precious?

This is the dividing line of pessimism. Do you believe memory is nothingness, or that it has weight?

Schopenhauer’s view was perhaps: “What has passed is as insignificant as if it had never existed.”

Yet I still think that moments like these should be cherished more. I am not yet sure whether one person should carry the past forever. But I think, borrowing a line from Nichijou:

Every ordinary day we spend may be a miracle happening continuously.

Moments—ordinary days—like these deserve to be cherished. Though for me, as a human, time still keeps moving forward.

I have always felt it is easier to find myself in solitude. But if relationships like this exist, perhaps it is easier to find the real thing.

I want the real thing.

After The God of Cookery

Tue, 13 Aug 2024 00:00:00 GMT

They changed the poster.

It is a culmination of many things. Only an hour and a half long, yet I watched it with complete focus (for many other films, I drift away for half of the runtime).

There is a little philosophy in it, though the director never explores it too deeply—only touches on it. Here are two moments, both points where Stephen changes.

A Bowl of Rice That Marks a Change

The first is how Stephen initially fusses over the 1982 and 1983 red wines, then takes out his frustration on someone after they bring him the wrong one.

Later, in Temple Street, he eats a bowl of barbecue pork rice that Turkey makes and says, “This bowl of rice is so good” (houhousi—it carries a little more feeling in Cantonese).

Someone who is deeply sad may not cry, but when comfort reaches the sorest place, they may keep shedding tears.

I went back to take a screenshot and found one tear, only one. Details.

People say crying scenes are hard to act. In truth, sadness is what is hard to act.

Getting to Know Someone Again Begins by Breaking Past Their Appearance

The second is the problem of valuing looks. When Turkey first kisses Stephen, he frantically wipes his mouth in front of a mirror. Even after learning from people on the street that she had liked him for a long time, he still could not accept it. At first, I was psychologically following him too. I wavered a little, but not enough to shake the foundation of my own attachment to looks.

Only when the thing itself was torn open and shown to me did I finally, in an instant, escape that pit of appearances. A wave of regret came over me, and I remembered her earlier bowl of rice and the time she shielded a knife with her hand. Only then did I truly recognize what was in my heart. Being overly concerned with looks is an illness. Being born to prefer cute things is not wrong; cute things make people feel close to them and fond of them. But if we stop at a first impression, perhaps we can never say that we have truly come to know someone further. The director tears this truth open for us through Turkey’s “death.” It is masterful, with no unnecessary explanation: a slip of paper, a song, and finally a bowl of rice. Nothing is simply handed over at once; it advances layer by layer.

I can accept mediocrity. I can accept flaws. But I still have my limits, and this is one I cannot bear.

Thank you to this film, and thank you to the director.

I like this kind of absurd and exaggerated yet real thing: comedy, tragedy, and then comedy again.

A Slip of Paper

A Bowl of Barbecue Pork

Stayed Up Late Again

It is 11:11 p.m. If I have to get up at 5:30, only six hours remain. I will have to alternate walking and running.

After Gold or Shit

Tue, 13 Aug 2024 00:00:00 GMT

“After watching so many films, you still came home to live off your parents.”

The line that cuts deepest.

I have thought about becoming a writer too. I was still thinking about it through high school.

But if I once had the excuse that youth meant many possibilities, then when age no longer becomes an advantage, did I start to settle down?

Yes, a little. At the same time, I am surprised that most of my past fantasies remained only fantasies, while very few ever became action.

And once time has passed, can I simply say that the age for fantasies is over? When I search online, I find that many major web-novel authors began submitting work in middle school. I am startled by the gap between their ability to act and mine. I also wonder whether my own fantasies were only a waste of time.

But thinking this way leads somewhere crooked again.

“That film was more than just a film to me.”

If the film they made were released publicly, most people in China would probably not even give it a passing score. In other words, the chance of it sinking without a trace would be high.

But that raises a question: should public evaluation be the standard by which a film is judged? Put that way, it becomes clear. Although most poorly rated films are not worth watching, many highly rated films seem completely terrible to me too. Public evaluation is only one point of reference.

Evaluation—or feeling—is always subjective.

For Old Hu, that film means something extraordinary. For those who resonate with it, an art film that ordinary people find unbearably dull can be the most complete expression possible.

What I Have Been Pursuing Is Wrong

I hope to work remotely, from home. Or perhaps not work at all. That was the original intention.

But gradually it has drifted away from that.

Because I need not to go to work → I need exceptional ability → I need to achieve something in a field → I need other people to see me as successful → other people’s evaluation matters more than my own.

This is a distorted transformation, infected by reality. It makes my original intention drift away. What was meant as self-improvement becomes the pursuit of others’ recognition. And this misplaced pursuit may in turn diminish me.

Success Leaves No Trace; Self-Improvement Does

No one’s success can be reproduced. Not in writing, filmmaking, game development, investing… anything.

Yet successful people often exaggerate the twists and turns of their experience, shaping an image of themselves as resilient. They also give everyone a mistaken idea: that success is the result of hard work.

The result of that mistaken idea is that countless people who work hard eventually—or even before the end—begin to feel lost. Especially when confronted with the group that survived the survivor bias, they feel particularly defeated and cannot see what they already possess. Looking forward, universal success leaves no trace to follow.

As I said before, the goal is wrong. First of all, success is defined by the public. It is only a point of reference.

A sophism:

An old beggar has lived on the street for more than twenty years. Everyone on the street knows him. He accepts whatever people give him, along with their scorn, without resistance.

A wealthy merchant is the richest person on that street. But you learn that Death will come for him at noon two months from now: he has tuberculosis.

If you had to choose, which would you choose: the beggar or the merchant? Would you live another ten or twenty years without dignity, or spend your final two months extravagantly before dying?

The ordinary standards by which meaning is measured are usually beyond one’s control. Pursuing success in the ordinary sense is no different from gambling. Gambling itself could be a subject on its own.

The lessons you draw from a failed pursuit do not necessarily point toward success; nor does a successful person’s self-praise necessarily point toward success. No road is marked as leading to it. The more you treat it as the goal, the farther you may drift from it.

To me, self-improvement seems more meaningful.

But self-improvement faces another question: if death is inevitable, where do its meaning and value lie?

Interesting, interesting. I have not found an answer yet.

Pandora's Box

Sun, 04 Aug 2024 00:00:00 GMT

I coughed up blood last night. I coughed up blood the night before too.

There was no reason for it, and it was not that life suddenly seemed precious. It was only that the strained disguise I had kept up until yesterday had fallen away.

Here, coughing up blood means tuberculosis, which was probably incurable at the time. Now, though, tuberculosis can be cured in the vast majority of cases.

Still, I am curious about how the book’s remarkable health retreat managed to cure so many people through natural therapy.

But that is only an aside. A sudden, life-threatening illness can tear away the veil that covers one’s awareness of life, while also making death feel less frightening.

A renewed awareness of life can probably bring about a major change in personality. Psychology has no shortage of such cases. In the book, after entering the sanatorium, the protagonist changes from taciturn to talkative. He also says that he seems to have become a new man.

After The Poppy

Wed, 17 Jul 2024 00:00:00 GMT

Attention is sparse.

I read the first half in a physical book, translated by Lu Qiushi; the second half on an e-reader, translated by Moro Miya (a name so hard to remember that I forgot it after seeing it once).

I have to say that I am becoming less and less receptive to paper as a medium. I have grown used to reading on an e-reader. Perhaps the type in print is too small: I took in almost only the first sentence of each paragraph, and across the first half of the book there were only four or five places where I could focus. In the second half, though, my attention became much more concentrated. The translator may have had something to do with it, and the density of the plot cannot be ignored either.

The first half is comparatively fragmented, and it does not deliberately lay out the characters’ relationships as a play would. Untangling the relationships among Fujio, Iris, Kōno, Ono, and Munetika is difficult.

I also complained halfway through that the dialogue ought to have labels such as A. or MJ before it. Whenever a conversation begins, it goes on for a long time—especially the opening conversation between Munetika and Kōno—with no names inserted at all. With my scattered attention in the first half, I could not even tell who was speaking. I did not figure out who wore the fox-fur vest until nearly the end.

This is unquestionably a play.

I do not know much about drama, and I have seen very little of it: The Merchant of Venice and several works written by Mishima. Borrowing Watanabe’s remarks about ancient Greek drama in Norwegian Wood, this work is like Euripides: at the end of the plot, a character appears and resolves every problem that had seemed unsolvable. In this novel, Munetika is that character. Yet it is also reasonable. The cause of every problem is only Ono’s hesitation and concern for appearances, while Munetika is thoroughly frank and quite carefree. One act of honesty could solve everything, but from Ono’s perspective, I felt that there was no way forward or back.

Let me first give my overall impression of the work, then pick out the parts I especially care about.

The translator’s preface mentions that this was Natsume’s first work after he left teaching to become a full-time novelist. It can absolutely be called a love story, and as the number of installments increased, so did the pressure on him. This work apparently does not hold an especially strong position among all his works; on the contrary, scholars even consider it quite poor.

Coincidentally, one of the few plays I have seen is The Merchant of Venice, and these two works feel extremely similar to me. More coincidentally, the novel I read just before this was Kokoro. Earlier still, I read I Am a Cat.

From these three works by Natsume, I can infer that his audience is extremely broad—almost all East Asians—and that his work is almost entirely free from the constraints of its era. Many Chinese realist writers are difficult and boring to read without historical context. That may be why I do not read much Chinese literature: it is too heavy. Fortress Besieged is an example of something not bound by its era. (Some may think it petty, but I like this kind of thing.) I do not like people who, whenever they speak of a work’s intent, immediately raise it to the nation and the world. Though “the spark passes on, flying on without cease” from GuJian 3 moves me, I think and reflect more often on myself. (Perhaps I was only lamenting that my one life is too short beside a thousand autumns and ten thousand generations.) “Petty” and “grand” are only different points of focus. I prefer to observe the individual human self regardless of time or place, so I am “petty,” and even a little resistant to “grand narratives.” Some of my own problems may be no different from those of people a hundred years ago. In that sense, there is no need to talk about an era. A person alone already has far too many problems. So perhaps a work does not always have to reflect the problems of its time.

All three of Natsume’s works reflect certain unnoticed defects in people who are twisted and self-contradictory, along with possible solutions.

In The Poppy, Munetika offers the solution. In Kokoro, Sensei chooses to bury the problem forever. But readers will also analyze it for themselves and follow the author’s hints to their own answers.

It is interesting. If I considered Kokoro and The Poppy separately, I would only say I recommend them, four stars. But I read both recently and they have a considerable connection when placed together, so I would say I strongly recommend them, five stars.

More coincidentally, I had no idea what was going on in the first half of both books, and only concentrated in the second half. Perhaps they assembled themselves together in my mind in some strange way.

Many authors keep tirelessly and unconsciously drawing stories with the same core. I know several directors like this too (Hirokazu Kore-eda). It feels like a fixation.

In The Paris Review, the interviewer’s summary of Murakami’s works was roughly this: a man loses a woman—or something—and, after losing her, he always begins to search, so he changes and may move back and forth between two worlds. Usually another woman helps him during that search. Compared with the woman who was lost, this woman is livelier, more passionate, and less restrained. The woman being sought, by contrast, may be cold, distant, and quiet.

Murakami accepted this summary too. When authors repeat such portrayals as they produce one work after another, readers often assume that they have run out of ideas. Yet Natsume describes roughly the same problem in Kokoro and The Poppy. The two descriptions make it clearer, and both also try to solve it.

People can never grasp the full shape of the problem that troubles them most deeply, or they worry that it cannot be solved at all. Natsume’s writing—and that of most authors who repeatedly narrate similar things—is not repetition but exploration. If several works connected by a theme can be read together, perhaps they can help with the predicament of the problem itself. Of course, as a novel, its storytelling cannot be ignored, and The Poppy has no flaw besides its fragmentation.

I understand a little better why Mishima wrote so many plays. Drama is the clearest and most concise form of fiction, almost the simplest expression of the great way. It reflects problems with violent directness, without adding the author’s views. Tragedy has its own charm too; a passage near the end of Kōno’s text can serve as a reference. Perhaps I have reached the age when I can read Shakespeare.

The Part I Especially Care About: Perhaps I Should Marry Into Someone Else’s Family

Leaving aside the central conflict I vaguely discussed earlier, between the frankness human nature needs and the concern for appearances needed to live in society,

I have to say that Fujio is a woman who surprises me. Whether Iris or Sayoko, they are only characters in a play; their behavior and personalities can be placed within ordinary reason and categories. I can simply say that Iris is a rough woman who toys with others’ feelings, while Sayoko is innocent and fragile. But I cannot simply summarize Fujio or make a judgment about her. Yet she is so simple and pure. This touches on something she and Kōno discuss: “It is better not to marry, and to remain unchanged,” and “You can stay carefree like this.”

She has spiritual insight. (In Buddhism, this seems to mean the capacity for sudden enlightenment. It includes intelligence, but more than that, innocence.)

I especially care about her conversation with Kōno: “When you move, you change,” “Leaving your parents and brother will change you,” “You will become clever,” and “It is better not to marry; it is good to stay unchanged forever.”

“I do not want to get married.”

At the time, I really felt Fujio’s innocence in that conversation. And I must say, Kōno was not called a philosopher for nothing: he is a true philosopher. Philosophy ultimately cannot be confused with literature. Writers often dwell in anguish or sentiment, but Kōno’s attitude of not caring about circumstances is truly transcendent. Writers are still more concerned with reality and practicality than philosophers are.

I think Fujio changed after that conversation, as if she reached enlightenment beneath a bodhi tree. She stepped out of the role the author had assigned her. She changed from “an innocent, romantic, carefree younger sister” into “a younger sister who decides to remain innocent and carefree.” She did not become cleverer; she became clearer and more aware. She moved from ignorance to deciding that it would be enough to remain unchanged forever.

If beauty could be held still, that too would be something moving.

So I still cannot explain in a single sentence what kind of person she is. But whatever the case, I like her this way.

Also, I still think Kōno’s words are worth considering further. Perhaps remaining unchanged is a good thing. (Some may argue that no one remains unchanged, and in one sense that is certainly true. But some people become increasingly pure, such as eminent monks who let go of attachment to the self.)

Maybe I should marry into someone else’s family someday, so that the other person can remain unchanged rather than changing by leaving home.

Though my attention was scattered when I first read it, by the time I have written this, Natsume is no longer just an unfamiliar name to me. I can say that I chewed over the parts I wanted from Kokoro and The Poppy carefully, and savored them again.

Human consciousness and attention are difficult to judge. We remember what we like, and what we see is easy to remember. It is precisely because of this strange mechanism that there are so many interesting works.

After Young Babylon

Mon, 15 Jul 2024 00:00:00 GMT

When a real connection is not close enough, people seek compensation through the body, as if that can offer certainty.

But I prefer Vivian. The physical part is only an addition.

If going to Tibet is the dream journey of many young artistic people, then meeting you at twenty would be my fantastical journey.

I like this: thinking that there are still people like Bai Lan in the world. There are too many beautiful people, but too few interesting ones. As long as they exist, it is a comfort, even if I never meet them. And most of the time, that kind of interestingness is out of step with its era. Simply put, it seems distinctive, ahead of its time, perhaps even shocking to people then.

I finished it in eight and a half hours. I found all the stories the author wrote full of flavor, especially those involving Bai Lan. But at the end, he wrote a poem that seemed to come from nowhere and lead nowhere. I probably do not have the constitution for reading modern poetry; I skimmed right past it. I may be destined not to be a reader of poetry, but stories move me deeply. I am grateful to still have this one pleasure.

I remember a famous writer whose daughter published poetry. It was not very good—or rather, it read like a running account—yet she still wanted to publish more. Her father was dissatisfied but never said so directly. Lu Xiaolu mentions talent many times. It is not her fault that she has no talent for writing poetry, and it is not her fault that she has no aesthetic sense for poetry either. But I cannot help remembering Lu Xun’s warning not to become merely a writer of empty words.

This book writes about missed chances and remembrance, but most of it happens when Lu Xiaolu is nineteen or twenty. I am nineteen now. I attend an unremarkable university and study a major that leaves me confused. Yet I keep thinking that I am no longer young. It is rather embarrassing. I spend too much time thinking about these things.

Will I ever meet a “Bai Lan”? Not someone with the same personality, though I really do like people who are distant. But could I meet a Jane Eyre? Someone I could speak with soul to soul.

I have to say that the author’s roguish air is infectious. Even the way I speak has started to sound affected. But mine is only a fake roguishness; it cannot compare with the real thing.

Love in Yushima

Mon, 15 Jul 2024 00:00:00 GMT

When I first read Snow Country, what drew me in most was probably Komako’s way of speaking. It had a kind of beautiful incoherence—though that may not be the right way to put it.

She was completely unreserved about affairs between men and women, and teased people about them. And every so often she would say something that seemed to come from nowhere: “It’s so cold,” or “Like a fool.” She was as cute as a carp suddenly surfacing in a pond to blow a bubble.

In Snow Country, Shimamura describes Komako as clean and fair-skinned, as though she would blush from her face all the way down the back of her neck, like some adorable animal. In Love in Yushima, Chōkichi refuses a soldier’s harassment and slaps him. When she is pursued and hides among an opera troupe to slip past them, she gives me the same feeling. Innocence and romance seem to be a geisha’s loveliest traits.

Komako once told Shimamura to visit her every year; it would be enough just to meet once and stay for a while. Chōkichi also tells Kamitsuki that even if he cannot marry her, she does not want to trouble him. She can support him. She can be a geisha all her life, as long as he does not abandon her. Their devotion seems the same, though one is in Tokyo and the other in snow country—perhaps Hokkaido or Kyoto, but “snow country” always feels more fitting.

There is something else: the love of Chōkichi and Komako transcends sex.

When Chōkichi and Kamitsuki share a bed, the scholar Kamitsuki burns with desire. He says that he has retained only a thread of reason, as if a cold dragon protects his body.

But Chōkichi is the opposite:

One morning, Chōkichi suddenly woke up and shook the half-asleep Kamitsuki awake. Looking around in surprise, she told him about her dream. In it, she stood in the dark holding three bunches of unopened iris flowers. Then everything around her suddenly brightened, and sunlight shone in. Bathed in golden light, she watched the three bunches of iris flowers bloom together in an instant. “Why is that?” she asked Kamitsuki with innocent delight. Kamitsuki was trapped in a nightmare, tormented in an illusion and drenched in cold sweat. Hearing her dream, he felt ashamed and blushed. Beside that holy white lotus, unstained though it grew from mud, his own heart seemed filthy. Only then did the scholar deeply understand Chōkichi’s spotless heart.

It could be said that reason and instinctual sexual desire do not simply trade places: having more of one does not mean having less of the other.

Love in Yushima gave me a chance to revisit an old dream. I once fell at Komako’s feet, and now I find again that perhaps what I love is simply girls like Chōkichi and Komako: innocent and clean. Yet they are also resilient. That is how Komako can play the clearest notes on her shamisen in winter, and how Chōkichi can survive being a bonded geisha without losing the integrity of her character.

Perhaps they understand the noblest kind of love in this world.

The Deadline

Wed, 10 Jul 2024 00:00:00 GMT

This was probably the first novel I borrowed from the library as a freshman. After switching to e-books, I never borrowed books again. I miss it a little.

Let me start from the beginning of the notebook:

Not much to say: this notebook is for recording things related to reading, especially reflections afterward. I would also like to have neat reading notes like Xiaoyin’s. I tried many times before, but rarely finished them. Usually I would go off to do something else halfway through, leave them there, or use the notebook for something unrelated. Sigh.

Reading often—or at least sometimes—lets me calm down between playing games and learning things (work). It activates a different part of my mind too. Rather than learning something, playing games, then learning something again, which only makes me stubborn, reading is a good relaxant. During that time, I can think about nothing at all, or think about impractical things unrelated to life.

The Deadline, Tom DeMarco

#An Unexpected Encounter

Finding it was an accident, and perhaps fate. I had been looking for another book with the same title by a different author. Only after requesting it from the library did I realize this was a happy mistake.

At first, seeing that it was a project-management book and also a novel, I assumed it would be another industry person trying to show off their expertise while also trying to write something accessible—and failing to write a decent novel.

#What Drew Me In

But it caught my attention perfectly. There were three reasons.

The cute and alluring Ms. Julian, who is also a kidnapper: a charming contrast.

I admit that my initial affection for this novel was built on liking its female character.

It is about software engineering and programmers collaborating on a project. I am interested in that.

I have to say that my thinking has become somewhat programmer-like now, and I need chances to step outside that way of thinking.

I made it through the first twenty minutes.

At the beginning, perhaps because I had not read a novel in so long, I could not immerse myself. My mind and eyes would not connect, and I felt sleepy. But after twenty minutes, I got into the zone.

Many novels may reveal their lovely side as long as you make yourself open them and read for twenty minutes.

That is when reading becomes enjoyable.

#Some Excerpts and Summaries

Here are some notes. Some are summaries; others are copied directly.

How to handle the pressure that accumulates over time once a software project begins.

Pressure is always lurking in the air, and it can catch people off guard once it takes shape.
The day a project begins and the day it nears completion are actually equivalent, yet we are relaxed at first and frantic later. At the beginning, our mindset is too indulgent.
The best way to solve pressure is to extinguish it before it takes shape: prevent illness before it appears, prepare early, finish early. But do not remain under pressure and tension all the time. Short-term pressure may seem to solve many things, but long-term pressure only kills thought.
Keep a cynical attitude. Learn from cats; learn from the Monro programmers who are like cats. No matter how the outside world demands or pressures me, I first consider only completing the minimum. Or keep your own judgment. Do not be like Webber, dizzy from the overwhelming requirements in the documents.
Finish only one goal at a time. Do not try to debug two bugs at once.
Treasure the feeling of suddenly becoming light after a project ends, and remember afterward to sort out what you gained and learned. A project ending does not mean you are finished.

--- Let us hope we can stop Belloc from appearing in our lives. (The endless, chattering client.)

P.S.

Julian is so cute when she says, “He must miss me.”
Every night, Webber sits at his desk and writes down experience and notes. This is only one way the author teaches us, but Webber tells a reporter: “I will never open this notebook again, but its 101 principles have been burned into my consciousness.” That is really cool. I probably write my blog from the same feeling.

So I cannot help considering why I started writing this notebook. It certainly was not so I could reread it over and over. After all, once I have written something down, what should be remembered has already been remembered.

At the same time, I think reading and writing reflections in this way helps the continuity of my reading and thinking, and also helps me form a good reading habit.

WTF. Ever since I started using an e-reader, I have not picked up a pen. I also wonder whether I have stopped using my brain at the same time.

#Design: Code with Divine Assistance

The Deadline really hits my interests: programming projects, time management, human resources, and a charming kidnapper.

Here I will talk about the programming-design ideas mentioned in the project.

Aristotle believes that designing a project’s modules before writing the program is important, important enough to deserve most of the time.

What ordinary people usually understand by design here is:

Function → structure → implementation. Working backward from the result toward the underlying details and breaking things down. Before writing a project, you should know clearly what each part will do, along with its function and implementation.

But designing only the implementation of functions is not enough. It is not the endpoint. The real design exists in the programmer’s mind: what code module needs to be implemented now, what its pseudocode should look like. The final programming is only like putting puzzle pieces in their proper places. This can almost eliminate debugging: implement and verify the function of one small code block at a time. But I often write whatever comes to mind. I get trapped by bugs caused by a particular implementation, and instead of trying a different implementation, I change many things just to debug until it runs normally. Those changes not only waste a great deal of time; they may also pull parts further away from the original design.

I think what Aristotle really wants to emphasize is having another perspective while writing code. When we get stuck in a bug, we know to change approaches rather than stubbornly fight it. While implementing, it is as if there is a puzzle background guiding what this piece and the next one should be.

The design he emphasizes is probably that perspective and that puzzle background. If writing code is like receiving divine assistance, that perspective is the god.

I can say that my programming habits are very bad right now. I write whatever I think of. Maybe I should learn to write pseudocode in my mind, try to reason about the next step and the current one, then work out the whole picture.

No program can be written without this sort of design. Still, most people get used to designing while they code. It is a little like chess: some people see more of the whole board, others only the local position; some can predict ten or more moves at once, while others can see only one or two moves before stopping.

I am typically limited and short-sighted. I once called my programming habits carefree, but when I encounter a larger project, every added feature can pull on the whole system, requiring repeated changes to all the code rather than changes only to the local function. That makes me feel I need to change. Maybe I need standards, and I need to see further.

Design is consciously predicting the course of a chess game. But you do not need to see every possibility before you dare make a move; there would never be enough time. You only need to see one linear path that reaches the finish. How to optimize is something to consider after reaching it. Trying to optimize while writing a feature that has not even taken shape is a grave mistake. In the end, do you spend more time writing the feature or debugging and optimizing it?

Consciously predict a target code block that can reach the result. If possible, predict two and keep one as a backup. When one route fails, switch to the other instead of immediately debugging. Many people impulsively start writing right away, but the mistakes this causes—and the time later spent repeatedly debugging and testing—far exceed the time spent predicting first. Besides, no one enjoys running a program again and again, repeatedly investigating the cause of an error. If it can be done in one go, why not?

And doing it in one go does not mean writing everything and then running it once successfully. That is impossible; there will always be deviations and bugs. It means writing each predicted code block in one pass, running it, passing once, and achieving the expected function. Only after verifying that function do I move on to the next prediction-and-writing stage.

#What Stays with Me Most

When a project has just begun, the crisis exists and the goal is clear. Yet the sense of crisis is weak, almost pleasant, while the sense of purpose is entirely absent—almost aimless.
A sense of purpose is a positive and excited state of mind.
We often have goals but lack a sense of purpose because we recognize those goals only as “things we ought to do,” rather than “things we especially want to do and achieve.”

#An Aside

The story of that UI from two days ago: at first, my roommate was assigned to write the UI and I was assigned to write the functionality. We had a week, with a defense on Friday. On Thursday afternoon, he gave me code that ran but that I found deeply unsatisfying—
He said he wanted to learn how to write UI properly. At first he boasted that he would make it look good. But what he eventually gave me had no beautification at all: he drew a few boxes, made a few controls, put functions into them, and that was it.
The other issue was speed. Several parts of the software requirements involved taking photographs and facial recognition—in short, opening the camera. When he clicked a button, it initialized the camera. When another part needed the camera, it stopped the first one, released it, and initialized another. And to initialize the camera, he used:
self.camera = cv2.VideoCapture(0)
This function took more than three seconds every time. In other words, I clicked to open the camera and waited four seconds; I clicked to start recognition and waited another five. A control took four or five seconds to respond, and it was single-threaded, so during the response the window could not receive messages or perform any other operation.

I was practically coughing up blood. I told him, “You are going to leave it like this without optimizing anything?” He said a device has only one camera; initializing two at once would crash it, so he could only stop one and open the other. He even demonstrated the crash to me.

It was already Thursday afternoon. I told him to optimize or beautify it a little more. He said, “Optimize my ass. It works. If you want it optimized, do it yourself,” then went back and opened League of Legends.

I only felt that the gap between his beginning and end was enormous. He did not beautify it, and he did not optimize it.

In the end, I really did take it on myself. This is where the distinction between goals and a sense of purpose, tasks and things one ought to do, becomes relevant.

For him, there was a goal at first, and perhaps he was even overly excited. Later, though, it became only a task. He had no real sense of purpose and only completed the minimum.

I was the opposite. I am obsessed with UI beautification—or rather, I am obsessed with anime. If I write something, it must have a bit of anime in it. So I added a background image, a logo, and icons. When I write these things, they are usually extras; I may not know exactly what to make, but the positive and excited mindset that comes with having a goal stays with me.

For the speed optimization, I initialized the camera when the program started and used it globally afterward. In the end, startup still took four or five seconds, but every other control responded immediately.

I call that state of having a sense of purpose writing my own thing. When I try to write my own thing, it has nothing to do with other people’s requirements; it is simply what I want. Anime-style beautification is what I want, and that is the key that lets me enter that state. But doing this often makes me skip meals, which is bad for my health.

And before trying to write my own thing, I usually make something terrible first—the minimum—at the fastest speed, then optimize it on that foundation. That leaves enough time to think about what can be done later and enough time to tinker. My roommate spent four days delivering what I considered the bare minimum, then stubbornly said that it worked. That made me really angry.

Love in the Buff

Mon, 08 Jul 2024 00:00:00 GMT

If love at first sight makes people self-conscious around each other, then Chun Jiao and Zhi Ming must be the least self-conscious couple imaginable.

I had meant to watch Love in a Puff, but I ended up watching Love in the Buff first. I suppose that means I missed the first film; even if I go back to it now, the experience can no longer have the purity of a first viewing.

Still, I did not really lose anything. I had only been looking for something to watch over dinner tonight, having not watched a film attentively in quite a while. This was a pretty good place to begin again.

The Beginning

Why did it feel slightly stitched together? The atmosphere between Chun Jiao and Zhi Ming—or rather, the feeling of the film's opening stretch—strongly resembled an arthouse film. The camerawork felt casual, and even the focus seemed casual. The early mention of Mandy, Chun Jiao's closest friend, and her history of supposedly bringing misfortune to her husbands felt like something out of an absurd comedy novel or film. Even when Chun Jiao and Zhi Ming were at odds, everything remained lighthearted. It reminded me of Stephen Chow and Cecilia Cheung in King of Comedy.

The Camerawork

Once Xu Zheng appeared, the entire visual language seemed to change. It became weightier and more delicate, like the sudden difference between something casually filmed on a phone and something shot with a professional camera setup. Perhaps I was simply fixated on his enormous head, but wherever Xu Zheng appeared, the whole style seemed different. Maybe his presence was simply too strong. Then there was Ben, played by Huang Xiaoming. Although he kept saying that people merely told him he looked like Huang Xiaoming, I could not help feeling that he was unable to let the resemblance go. Something about it felt out of place.

I found Miriam Yeung's scenes the most comfortable to watch. When I was young, I watched her and Richie Jen in Elixir of Love many times. Later, I also watched 2 Become 1. I love scenes with Miriam Yeung in them; they give me the feeling of returning to the past. But why is she so drawn to playing women who cannot find anyone to marry, whether in Elixir of Love, 2 Become 1, or Love in the Buff?

I love the humor and comic beats of films such as Flirting Scholar, King of Beggars, A Chinese Odyssey Part One: Pandora's Box, Fight Back to School, and Elixir of Love. They probably shaped a large part of my personality.

Finishing Move

But the film at hand is Love in the Buff. Its posters had caught my eye several times before, and I had listened to the songs, though I never understood how they related to the film. Speaking of songs, I think “Finishing Move” suits Love in the Buff even better.

Just one “Why don't you ever come looking for me?”

No matter how stubborn, how resolute I train myself to be, I can never compare

Please do not touch me again with the practiced ease you once had

While I ask myself how you can still manage to hurt me

Each time Zhi Ming went looking for Chun Jiao, those lyrics returned to me. So what the song describes really does exist, I thought. Because I had not seen Love in a Puff, the first film, and went directly into Love in the Buff, the second, I initially found Zhi Ming rather annoying—extremely annoying, in fact.

Yet I found him annoying because he resembled me, and that made me anxious from somewhere deep inside. He had never grown up. He said he had not matured at all since Form Four, and I seem to be much the same. In high school, I was terribly wrapped up in myself and did little but read novels, as though I could find in them a reason not to take the national college entrance examination. The walls I built around myself then still stand today. I cannot say I have remained completely unchanged, only that I am still self-absorbed.

I have also become much lazier. At least I used to read thematically, take proper notes, and write reflections after finishing something. Now, even when I feel moved to review a film, I struggle to put the feeling into words.

My writing is not as good as it used to be. Perhaps I am simply less adolescent and melodramatic than before. Whenever I think that, however, I also have to admit that I am unwilling to change.

Only when I write without considering anything else does the result truly satisfy me. Perhaps I should find the time to slowly retype what I wrote in the past. I once felt that merely transferring it over would make it seem as though nothing existed in the present—but otherwise, it is as though nothing exists now either.

More Than Romance, I Want to Talk About the Bonds Created by Time

I used to have an unspoken theory: every sensation and emotion fades with time. Whether it is how I feel after finishing a film or novel, or how I feel about another person, once the direct connection ends—once the film or anime finishes, once I stop speaking to someone—the feeling always grows faint. Inevitably so. For a time, this made me profoundly sad.

Schopenhauer's nihilism seems to be built partly upon this insubstantial quality of memory: when we look back on the past, it can seem so insignificant that it is almost as though nothing ever happened.

Chun Jiao, however, seems to stand firmly against this theory. Her love for Zhi Ming lasts an extraordinarily long time. Even setting affection and romance aside, the two seem bound together by something. Bound, but not tied so tightly that they cannot move. Rather, whenever one of them is about to leave, a thread fastened around their wrist reminds them that the other still exists.

Even if they meet someone better and better and better, that person remains irreplaceable. Perhaps this is what memory leaves behind. The other person is no longer merely someone you either love or do not love; they have come to represent a long stretch of your past—or rather, a large part of yourself.

Chun Jiao says that all the interesting parts of herself the older man, played by Xu Zheng, likes—all her strange ideas—were actually caught from Zhi Ming at some point without her noticing.

When two people spend a long time together, this mutual transmission of habits may bring them closer than any love at first sight ever could. The other person no longer seems to be someone outside the self. They have become part of the self.

Of course, that is only my rather self-centered interpretation. Their relationship may have been nothing like this at all, because the same bond also caused them pain. Chun Jiao said over the phone, “I like you so, so much, but please stop bothering me.”

Why does it have to be so complicated?

The older man was not bad at all. He was practically unbeatable, exactly my type, and funny too. So why did he have to bear it alone?

Fanfic

Mon, 08 Jul 2024 00:00:00 GMT

The first time I watched a film, I spent the whole time taking screenshots.

I do not know who said it before, but beautiful girls tend to resemble their fathers more, while handsome boys tend to resemble their mothers more.

I had felt a little of androgynous beauty in Brigitte Lin before, but hers was ultimately classical; my aesthetic sense could not connect with it directly. But this female lead drove straight into my face.

“A short story that blends the worlds of fictional characters and real people.”

This refers to the female lead’s fan fiction. The interweaving of reality and fiction is a good idea.

The film’s overall setting is similar to Sayonara Wild Hearts. It has a little to say about feminism and being transgender. In the game, the female lead seems to lose her way and become a fake boy. At the reconciliation, she ends by sitting down and playing the guitar as a woman. It still does not quite escape the limits of gender. Although it is a good ending, after the author takes so many drugs along the way, they still do not cross that line. Perhaps that was also meant to accommodate a mainstream audience.

But the female lead in the film is exactly my favorite type: violent, distant, and unapproachable. At the end, she remains that way. That is not quite accurate; rather, once she discovers that she is a “boy,” the anger that had nowhere to go finally disappears.

Beyond that, there does not seem to be much more to discuss, because the plot itself is a little thin.

But Max is quite an interesting character. At first, he seemed a little annoying to me: endlessly talkative, always seeming to need attention from others.

He also constantly mocks the female lead’s clothes, intentionally or not, as if he wants her to change back to how she used to be.

But many details later changed my view of him. The first was at the gym, when he saw the female lead being abused online and became furious. Only then did I realize: oh, fuck, this person likes her. It is the kind of affection Shōya Ishida has in A Silent Voice. Unfortunately, the female lead is dense as wood—and very aggressive too.

Still, there was something powerful about the scene where he forcibly presses her back into her seat when she argues with a boy and gets hit. When he confronts the boy, I finally understood that the gym had been foreshadowing this moment.

And compared with the scene later where the male lead abandons her and runs away—he had spent three months in the hospital after being beaten by thugs, so he is terrified of such situations—it becomes another piece of foreshadowing.

I only feel that Max is a little like me, though I do not really want to admit it.

We all have flaws. Max does not know how to express himself, and the male lead is cowardly, even if there are reasons for it. But in the end, we only want to be with the person whose company feels most comfortable. The angry star and Cinderella are brought together by the words “Your nails are beautiful,” and the film ends with them together forever.

To be honest, the film is quite shallow. But I was completely absorbed in taking screenshots, so I did not mind much.

Here are a few more.

After “A Year for Ten Thousand Yen”

Mon, 08 Jul 2024 00:00:00 GMT

Let us start with two side stories.

Even someone whose past was worthless can smile at a future full of light.

This is what the bookstore owner says to the "human-trafficker uncle" in their exchange in the second volume. I am not sure what relationship that little girl has with him; because it is so unclear, I will call him the "human-trafficker uncle" for now.

The girl says that, if she had to choose between three billion yen and staying with him, she would choose the latter. When he says that he can buy her anything she wants besides ice cream, she mentions her mother. There is something rather deep in that.

So here is my hypothesis: the uncle will change because of the girl and go on to live a "bright" life.

Through this side story and the uncle's words, the author dissolves one of my original questions. If I had the chance to learn what my future would be like—setting aside whether it was good or bad—would I choose to sell my lifespan?

The uncle makes one point: although he needs money now, if his future is destitute, he cannot expect to sell it to support his present self. And if his future is truly valuable, then his present hardship becomes less unbearable. In other words, selling it is inadvisable either way, at least in his eyes.

This was probably the illustrator's idea in the manga adaptation.

Even if we try not to develop feelings for other people, we cannot avoid everyone.

Thirty years without feeling may not be worth living through—not compared with one final month together, nor with three final days free of all care.

Encounters and connections with someone always become an opportunity for us to change.

This is what I saw from Miyagi's point of view in the third volume.

Perhaps human beings simply cannot bear loneliness. Even when facing someone they know will die soon, they cannot stop themselves from pouring out their feelings, even though they will later face an even sharper loneliness. Each time they make up their minds; each time they cannot help themselves.

Perhaps Miyagi, had she never met Kusunoki, would have spent thirty years without feeling anything—not for any special reason, but because her other surveillance targets might not all have been as easy to get along with as Kusunoki and that girl, while she herself was only an invisible person. If loneliness counts as a kind of feeling, then perhaps it would have been her only feeling. Then, when her time ended, she would begin life again at nearly fifty. It would not be a good beginning, however one looks at it.

And meeting someone special may always become an opportunity for her to change, even at nearly fifty.

From the ending, after Kusunoki has almost paid off her debt and after she works for another three years, she too lives a full and bright life; the rest of her life becomes valuable. In that timeline, she chooses to sell her remaining years, while choosing to spend her final three days with Kusunoki. But perhaps, in another timeline—the life she sold—she met someone else, and Kusunoki became only a memory.

Seen this way, however far the distance between people stretches, their relationship will always grow faint. Sustaining intense emotion comes at a price. That price may be never feeling anything for anyone again, but as we discussed above, that is impossible.

And what truly stretches distance is not necessarily space, but time: Naoko and Kizuki, separated across two times.

Perhaps I should not avoid encounters. Self-study and self-transformation exist, but I want to be saved by a beautiful girl too. I think I said much the same at the end of [[We Who Have No Tomorrow Fell in Love Yesterday]].

My own thoughts.

I am reminded of a Japanese light novel I read before, Love Comes After Simulation. The first half of it was very good. It describes a protagonist who can use a simulator to run through possible futures in advance, and even extract the experience he learned from each simulation. He can foresee certain things ahead of time, and the first two romances have considerable depth.

It does not quite reach ultimate concern in existentialism, but it is not far away.

That ultimate concern is death.

Three Days of Happiness suggests that the final three days may be more valuable than the thirty years sold away, or than the original thirty days remaining.

I do not disagree with this view, but perhaps deep down I still place too much trust in personal agency: as long as one is alive, perhaps a turning point may still exist.

I think this question should be placed after an earlier one: death, the ultimate concern.

If I could remain with Miyagi until death, then compared with not knowing when I would die—drifting through life, anxious and afraid of death, and finally dying alone either without noticing or full of fear—I would choose the three days.

I do not really know how ultimate concern should be resolved, but I think it is related to both the simulator and this work, so I have put them together.

If I can, I would also like to write something myself.

Fuwari Blog Theme Guide

Mon, 01 Jul 2024 00:00:00 GMT

This blog is built with the Fuwari theme and Astro. For anything not covered here, see the official Astro documentation.

Post Frontmatter

---
title: My First Blog Post
published: 2023-09-09
description: This is the first post of my new Astro blog.
image: ./cover.jpg
tags: [Foo, Bar]
category: Front-end
draft: false
---

Field	Description
`title`	Post title
`published`	Publication date
`description`	Post summary, shown on the homepage
`image`	Cover image path. Starts with `http://` or `https://`: use a remote image; starts with `/`: use an image in `public`; otherwise: relative to the Markdown file
`tags`	Post tags
`category`	Post category
`draft`	Whether the post is a draft. Drafts do not appear in the production build.

Where to Place Post Files

Post files belong in src/content/posts/. You can also create subdirectories to organize posts and assets more clearly:

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

Markdown Examples

Tables

Size	Material	Color
9	Leather	Brown
10	Linen	Natural
11	Glass	Transparent

| Size | Material | Color |
|---|---|---|
| 9 | Leather | Brown |
| 10 | Linen | Natural |
| 11 | Glass | Transparent |

Horizontal Rules

---

Inline Math

Inline math: $\omega = d\phi / dt$

Inline math: $\omega = d\phi / dt$

Display Math

$$ I = \int \rho R^{2} dV $$

$$
I = \int \rho R^{2} dV
$$

GitHub Repository Cards

You can add dynamic cards that link to GitHub repositories. Repository information is fetched from the GitHub API when the page loads.

::github{repo="saicaca/fuwari"}

Use ::github{repo="<owner>/<repo>"} to create a GitHub repository card.

::github{repo="saicaca/fuwari"}

Admonitions

The following admonition types are supported: note, tip, important, warning, and caution.

:::note Highlights information that users should take into account, even when skimming. :::

:::tip Optional information to help a user be more successful. :::

:::important Crucial information necessary for users to succeed. :::

:::warning Critical content demanding immediate user attention due to potential risks. :::

:::caution Negative potential consequences of an action. :::

Basic Syntax

:::note
Highlights information that users should take into account, even when skimming.
:::
:::tip
Optional information to help a user be more successful.
:::

Custom Titles

You can give an admonition a custom title.

:::note[My Custom Title] This is a note with a custom title. :::

:::note[MY CUSTOM TITLE]
This is a note with a custom title.
:::

GitHub Syntax

[!TIP] GitHub syntax is also supported.

> [!NOTE]
> GitHub syntax is also supported.

> [!TIP]
> GitHub syntax is also supported.

Expressive Code

Expressive Code provides syntax highlighting, terminal frames, line markers, diff comparisons, word wrapping, collapsible code, line numbers, and more. See the official Expressive Code documentation for complete usage.

Embed Videos in Posts

Copy the embed code from YouTube or another platform and paste it directly into a Markdown file.

---
title: Include Video in the Post
published: 2023-10-19
// ...
---
<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

Near Being, Far Being

Sat, 29 Jun 2024 00:00:00 GMT

What Can We Do Before Death? Do We Have Time? Can Someone Come Save Us?

Near Being, Far Being

A year is long if you do nothing, but if you truly have something to do, a year seems rather short. Or perhaps you have realized something.

I have already forgotten what the self who asked before the college entrance examination, “What does after the exam feel like? Does it really exist?” truly felt at the time. More than two years have passed without my noticing.

Two years go quickly when I have little awareness of them.

When I think about junior and senior year, especially the turmoil that senior year may bring, part of me feels that the one or two years remaining are not very long at all. At the same time, the old unknown attacks me again: what does work actually feel like?

This is probably it: a person always feels that the difficulty they face in their present stage—within the next year or two, near or far; distant things cannot be felt immediately, while near things cause anxiety—is incomparable, impossible to get through, and that there is nothing else beyond it.

Of course, an approaching exam in a subject you are not confident about can bring a similar feeling, and the imminent end of winter or summer break works the same way.

But is this feeling truly impossible to break through? Must we remain forever confined to this one or two years, feeling that the future is hopeless because we cannot see any road beyond it?

Here I need to step outside and talk about my own experience.

A Sudden Urgent Experience of Death, and an Unavoidable Reflection on Death

I realized that under ordinary circumstances, ordinary people cannot think this deeply about death.

A sudden sense that one will die—that death is not distant—can pull a person beyond this boundary. In [[Existentialist Reading Notes]], I discussed the theory behind this “urgent experience”: when a deadline is close enough, a person shifts from the “forgetful mode of being” to the “mindful mode of being.”

For example, one or two weeks ago I found something black, like a mole, on my chest, but I knew it had definitely not been there before. After watching it for a while, I noticed that it seemed to be growing.

Melanoma. That word came to mind immediately, and malignant skin tumors are among the worst for spreading. For several days, despite having no medical evidence, I suddenly thought that I might have only a few months to live rather than until graduation. When a word more explosive than graduation—death—stood in front of me, the weight of graduation suddenly blurred. I was thinking about what I could still do if I had only a few months to live; this was not an outline for writing, but complete, unavoidable identification with the thought.

I did not find an answer, but in only a few days I almost changed my old sleep habits. I gradually began waking at 7:20, perhaps intending to get up even earlier; one morning I rose around seven. I stopped reading novels in bed before sleep. I used to follow my roommate to 8 a.m. classes—getting up after 7:50 and starting class at 8:20, with breakfast more often absent than present.

That Tuesday I reached the laboratory one step before my automatic-control teacher. She came in behind me, saw me, and said, “Here so early? (￣▽￣)” “Couldn’t sleep. -_-” “Not being able to sleep in is good. If you can’t sleep, get up and study. <(￣︶￣)↗” Perhaps it was that one sentence; over the following days I also arrived early more or less consistently.

But most importantly, I suddenly realized that I had no later time left to me. I tried to do today or tomorrow what I had originally planned to do. I wrote code rather than planning what code to write; I read novels and manga rather than forgetting them again and again.

Before, I always placed things on my mental schedule, then some time later casually sighed that I was absolutely the sort of person who never acted according to a plan. Now I also began “eating tomatoes”—using the Pomodoro timer. I have to say that it made me realize when I ought to rest.

As for that black speck, when I asked about it, someone said it looked like a pimple, a blackhead. While I watched it, it naturally fell away; with it went the heart I had kept suspended for days.

Perhaps I Realized That There Is Nothing Except the Present

Yet thinking about death ahead of time made me realize that graduation is not the only boundary. To put it bluntly, perhaps I will not live until graduation at all; and if I do live beyond graduation, then there seem to be more things I can do than there are now. I realized that my greatest anxiety is this: before graduation, I may still be unable to make anything. I may still be unable to make anything that lets me lie flat.

But then I thought that perhaps I do not need to force myself to make it now. The present may simply be a two-year vacation with comparatively much free time. If I can make it, that is fortunate; if I cannot, I can come back to it later.

I used to learn and make things under the grand premise of wanting to lie flat, but it seems that in the process I lay flat first =-=.

Small Happinesses Are Fine Too

With only three months left to live, Kusunoki holds the 300,000 yen he got by selling thirty years of his lifespan, drinks beer, and says that he will use his remaining time to create a splendor he could not have had in the previous thirty years. It sounds like something a gambler would say. But Miyagi sees things clearly. Rather than realizing that one had made mistakes before and believing one can now turn things around, it is better to take the present and slowly accumulate “small happinesses.” Perhaps this is why I write a blog too.

Because we are born with nothing, we can possess everything. — No Game No Life

Death is forever my best teacher.

We Who Have No Tomorrow Fell in Love Yesterday

Tue, 25 Jun 2024 00:00:00 GMT

Written on the first day—most of it was deleted, so this may feel a little strange.

This was the first Japanese light novel I properly moved on to. I found the resistance to reading much lower, and I could almost finish one in a single sitting. Yet language that flows so easily and asks for no thought often lacks a little depth and fullness.

Still, it gave me an opportunity for a change of mood. If I find myself in something similar again, I can read it again. In that respect, it is a masterpiece.

I would be willing to revise the book slightly: after the grim reaper sees them for the last time and says, "What am I going to do with you two?", it would end. It would be nice for the story to stay fixed in a dream.

PS — continued on the second day. — "Died" at the end of winter break. 2024/2/20

I think the author put a great deal of work into whether people would regret giving up their lifespan. Just when both characters finally let go and feel no regret, he gives them a rattlesnake watch and turns back time.

The author says in the preface that it is like comforting words thought of only afterward. I understand that feeling. I often feel regret after I have already left, regret that I did not think things through. In this respect, the protagonists in Murakami's writing and in The Great Gatsby have an advantage, because they are pure observers: calm, silent, not offering personal opinions to others, yet often able to say something unexpected at certain moments. Neither the author nor I can manage that, so the author wrote this novel and Murakami wrote On Seeing the 100% Perfect Girl One Beautiful April Morning.

The author seems to place great weight on "coming to terms with death." For one moment, I too vaguely set myself the feeling that I would ascend on some day three years from then.

At bottom, what I want to think about more is idleness. I did not write about it yesterday because I was too exhausted and muddled.

My situation now is actually very similar to Aiba's during his first few months. I can do everything I want (read novels, watch films and anime, play games; I can go out too, though I tend not to), and I am also pressed by a deadline. (Aiba knows that he will die on December 26 three years from then; I know that classes begin on February 26. Come to think of it, I have to return to school on the 25th. I had always thought it was the 26th; in the course of talking, another day has disappeared.) With that known outcome, the start of winter break and its later days brought changes in my mood similar to Aiba's. Later on, I too gradually felt powerless and regretful. Although I kept a schedule similar to the one I had at the beginning, I did begin to doubt it and feel that it never changed. The joy novels initially gave me shifted a little later on.

Do people inevitably grow bored and regretful after living this way? The grim reaper says that most people begin seeking stimulation later on. A couple of days ago, I did open The Immortal Life, which I had thought I would never play again. I became absorbed in it for nearly twenty hours, trying to cover my unease with stimulation.

Aiba happened to choose a road different from other people's, and Ichinose's arrival also shifted his life from its ordinary course. Beautiful girls often have the power to change a person, so there is nothing wrong with saying that beautiful girls can save the world. But as I said after Boy's Babylon, "There are too many good-looking people and too few interesting ones." In reality, people as good-looking as Ichinose do exist, and even people as interesting as she is do exist, but the conditions for me to form a connection with one of them exist only in fantasy.

What should I do if no beautiful girl comes to save me at the end of winter break—go looking on my own? I do not think that is realistic. It would be easy to fall for an online-dating scam, because having worked with TTS, I know that it is now much, much easier for boys to pass as girls.

Put differently, I am anxious now because winter break is about to end. A few days from now, winter break will end, I will return to school, and I will adapt to life there again. The self who worried about winter break ending will have "died." Perhaps I will again sink into boundless pleasure and grow anxious as graduation approaches, and then "die" again.

As a human being, as one of the ordinary people the grim reaper describes, without meeting a beautiful girl who saves me, I will always feel joy when a vacation begins, aimless in the early days, bored in the middle, and seek stimulation later on. Then, near the end, I will feel that I ought to make up everything I missed earlier and begin planning a schedule. So I will "die" again and again, until I finally die.

A fool always grows wise before dying.

This seems to come from one of Sugaru Miaki's books. Perhaps it is Three Days of Happiness: when Miyagi and he have only three days left, everything else seems to lose its color in their eyes. In an instant they seem to reach the state of sages, understanding that only the present and the other person matter, and that everything else does not. Later, after reading the manga adaptation, I wrote about it in [[After “A Year for Ten Thousand Yen”]].

There is also the phrase "reborn into life." Perhaps someone is gravely ill, told that they will not live more than three months, and then recovers after those three months. Such an experience makes them different. The question is whether the sage-time left by being "near death" can continue afterward. Or does that sage die as soon as the three-month deadline passes, while a new self begins new joy and aimlessness?

I have personally had a similar experience. Of course everyone has, though perhaps it did not feel as intense to them as it did to me. When the college entrance examination was a hundred days away, I naively wondered whether the days I lived—with only twenty hours of holiday and twenty-six hours of free time each week—would really end. The past was like an illusion, with only novels left as something real. The future was like a black hole, swallowing every possibility; I could not imagine it.

During the summer vacation, I did read novels and watch anime, almost everything I could. At university I lamented that time was hard won, and at first I took the initiative to study digital painting, modeling, game development, and neural networks. But as time went by, I found that I gradually valued time less. It was as if that period of strict preparation had merely extended the time of joy. And now I too am gradually sinking into aimlessness. The former sage died before I noticed. What I did afterward was more like the inertia he left behind: it pushed me along for a while, and now it is gone. Until I read this book yesterday, I vaguely began to recognize this—not that I had changed, but that that "I" had already died after the college entrance examination.

So the urgent thing is to leave "last words" for my winter-break self, though I am sure my future self will probably not reread them carefully.

I want to be saved by a beautiful girl too. Is that too flippant?

Flowers Yet to Bloom

Tue, 25 Jun 2024 00:00:00 GMT

I heard its sales were poor because the censors thought its female lead was drawn too young and that it carried a hint of lolicon.

But I have to say that it holds an irreplaceable place in my heart.

I place it somewhere among people, ghosts, and fox spirits. The first volume may be a little dull, but by the second I remembered the dreamlike feeling I had when I used to read Xia Da’s Zi Bu Yu. Dreamlike—like when its heroine dreams that a tiger in a painting leaps at her, and her mother casually drives it away with a stroke of her brush. This book does not have many strange-tale elements, yet the moment when the heroine meets the old woman again moved me.

An eight-hundred-year-old old woman with the face of a fourteen-year-old, falling in love again after everything she has been through~

To me, this book completes Zi Bu Yu. The romantic element missing from Zi Bu Yu and Natsume’s Book of Friends is made whole here. I love it; it is beautiful. They are no longer separate works, but part of one complete image.

Its sales may be low, and perhaps some people will see it only as a simple, sugary romance and forget it quickly. But for me, it may be one of a kind. Every book may have readers like me: people whose attention is suddenly caught, who fall in love without noticing. The feeling is not intense, and that is why it can last. (Zi Bu Yu and Xia Da; Natsume and summer vacation.) Rather than love, it is a combination of gentleness, imagination, romance, and dreaminess.

And I thank it for giving me a pleasant evening.

Existentialist Reading Notes

Thu, 20 Jun 2024 00:00:00 GMT

When I learned that all the complaints I had sent a friend before—about winter break, about death—were actually covered by existentialism's ultimate concern with death, I found it fascinating. I was also relieved that I was not the only person who thinks about these things.

This was also the first time I highlighted and annotated at such a high frequency.

Part One: Death

1. Near death: changes forced upon an individual by circumstances beyond their control.

Heidegger's two modes of being (not the first time I had seen his name, but the first time I had read about him):

The forgetful mode of being:

That is, living in the world of things and immersing oneself in daily trifles. Such a person “drops down a level,” fixates on “idle chatter,” loses themself among “others,” and is directed by the everyday world, caring only about how things ought to be.

This range is still not broad enough. It is precise, but insufficient to encompass everything, so let me extend it a little: 1. following one's desires, doing only what one wants rather than what one likes, escaping a certain anxiety and regretting it afterward; 2. imagining and sketching a grand future, waiting for it to arrive, while actually doing nothing for it.

This state is somewhat like one ruled by desire and dopamine. It is easy to slip into, and I always do so without noticing, only to look back and discover that several months, or even half a year, have passed.

The mindful mode of being (I have to say, the Chinese phrase is difficult both to type and to understand; well done, translator):

A person looks at things as they truly are rather than as they ought to be, and finds them novel. To exist in this mode means remaining continuously aware of one's existence.

This makes me think of Zhexiu in Fighter of the Destiny. He says, “Either live awake, or die awake.” Compared with Chen Changsheng, who is continually driven by a known death, Zhexiu is a genuine existentialist.

The discussion turns to death with a known limit. In many ways, it is no different from a winter or summer break whose end date is known. Yet after winter break ends there will be a new beginning, while death is forever held by the unknown. Many philosophers and writers have offered similar views, and with a little humor: “From the moment we are born, we are always dying. The final day's contribution is not greater than any ordinary day; it merely exposes the latent decay for people to see.”

Haruki Murakami also wrote in Norwegian Wood, “Death is not the opposite of life, but a part of it that remains forever.” I do not know whether he realized it himself or borrowed someone else's words.

Let us first discuss what it means to be conscious of death's arrival. Death is the fundamental source of anxiety. We all know that we will eventually die, but we also build protective mechanisms within ourselves and feel that death has nothing to do with us. Most of the time, we know it, yet we do not truly register it.

How can someone be made clearly aware of it? Here is a hypothesis: your winter break ends in three days.

Only a definite deadline makes awareness unavoidable. I have always called it “circumstances beyond one's control,” and I will keep that wording here.

The deadline cannot be too distant, either. It must be near, pressing, leaving a person unable to contemplate a future death. Only then will it almost inevitably bring an “urgent experience,” a fundamental transformation. Someone formerly desperate for money and status may suddenly find them unimportant; someone who felt aimless may gain a clear purpose; someone who felt life meaningless may become alive again and find living good. (If you are in the forgetful mode of being, you may think I am talking nonsense here. That seems normal to me.) I recorded a similar experience in [[Near Being, Far Being]].

Scenes like this appear in fiction, but they also happen in real life. Not everyone can experience death, but most people have experienced winter or summer breaks ending many times.

The changes brought by urgent experience are often positive, but because endings such as the end of winter break are not permanent, they may fail to produce a truly fundamental transformation. After some time, a person may return to how they were.

When the end of winter break truly stands before me, I suddenly let go and feel that I have reached the mindful mode of being; before that, I had only been in the forgetful mode of being.

2. Fiction: it extends the length of life.

There is a lot of rambling above, and my ability to organize language is not enough.

One last thing I want to add is that this kind of “urgent experience” can sometimes be gained through novels and manga, especially long novels. I have to reconsider my previous view. I was almost misled by the common opinion that novels are useless; people who say that are the truly useless ones. Fiction itself can give people this simulated, complete experience—something different from film, something that can only be felt in novels and writing.

Today, after finishing the manga adaptation of Three Days of Happiness, I felt the absurdity of how I had been living: looking down on everything, yet accumulating not even the smallest happiness. I read it and was able to critically “return to the starting line.” Perhaps I will keep reading in the future, and keep returning to the start.

This will be a long series. At present I am very interested in this part about death, though I do not know whether I will have more thoughts later, because I have said almost everything I wanted to say this time. If you finish reading it and feel similarly, you can read this book too.

I did not take good notes while reading, but after going through it all, many passages still stayed with me.

Being:

Do you believe in memory?

“Just as we spend one third of life in dreams, the lifetime taken by death is equally as insignificant as the time spent dreaming.”

This looks abstract, but I remember its latter half: what has already passed is as insignificant as if it had never existed. Most anime and novels I have watched or read slowly lose their original color in the palace of memory. Feelings that were once intense—I could shout that I love Yunyun, I love Jiuyou—now seem much thinner. As distance grows, the astonishing impression Li Changge once made on me has also dimmed.

Each time I finish an anime, I am immersed less in the sadness of contrast with reality than in the thought that, once it is over, the image in my heart can no longer remain forever.

At such times I often complained to my classmates, but thinking about it now, that was a very typical pessimistic view.

For example, when an eighty-year-old woman looks back on her life, or someone asks her about it, she might pause, then say with light in her eyes that she lived a fulfilled life.

But if I extended my view to that situation, perhaps I would feel that my life had been a continual losing: this moment loses the previous moment, until in the end nothing remains, including emotion. The insignificance of memory.

For choosing between these two views, I can recommend a manga, Tsunomata no Ichika, also called A Momentary Flower. Its character work is somewhat thin, but what the teacher says in the final lesson is worth remembering.

Compulsion:

A man is going to travel to another place the next day. The night before, he calls women he knows who live there and wants to invite any one of them to dinner. (A sexual invitation.) Only after every one of them rejects him does he let out a long breath and say, “Now I finally have time to open a bottle of wine and read alone.”

In fact, he has plenty of time like that, but he cannot refuse his own urge to make sexual invitations. Only when circumstances beyond his control intervene can he escape from it.

I often encounter situations similar to this.

Demian

Mon, 01 Apr 2024 00:00:00 GMT

This is one of my fixations. It connects with Larry and Watanabe, though Murakami and Maugham rather cleverly use asceticism to obscure the turning points that transform them.

The turning point Hesse explores through Frau Eva is worth revisiting again and again.

The long opening stretch is very dark. I have already moved beyond that period, yet rereading it still stirs something in me. I really am a lot like Hesse.

The Girlfriend at the End of the World

Tue, 26 Mar 2024 00:00:00 GMT

The Girlfriend at the End of the World has something of the Murakami translated by Lin Shaohua. It also feels a little like Lu Nei.

Terasetsu’s piece is exceptional.

Every story ends with a trace of sadness and solitude. Mono no aware.

The author’s style does not yet seem settled, but it is truly good. I hope they stay healthy and happy.

I am not good at reading short stories, so I read it on and off for a long time. When I finished it, I felt that it broke my long-held impression that China has only realist literature and fiction.

A revision to my view: the lubricant that keeps me reading is not romance, but girls. A-Bao proves that can work too.

Using OBS with VTube Studio: Be a Vtuber

Tue, 30 Jan 2024 00:00:00 GMT

:::note[About the Images] Because this was uploaded early, the screenshots in this post are heavily compressed and rather blurry, but they remain clear enough to follow the steps. :::

These settings can be used for livestreaming or recording video.

Step 1. Configure VTube Studio

Enable face tracking: Double-click to open the settings menu.

Choose pickcolor for the background:

Enable transparent streaming:

Step 2. Configure OBS

Add a game capture source:

Choose Create new:

Configure it as follows:

Confirm the settings. You can freely drag the window and adjust it into something like this:

Fengxin Is a Good Name

Mon, 17 Oct 2022 00:00:00 GMT

Ten years, a dream in Yangzhou; I won but a fickle name among courtesans.

I became a Minister of Personnel and spent every day with Xiyun. I actually prefer a freer life, but being able to stay with Xiyun was quite nice too. At worst, I could resign early, then take Xiyun to the places I had never visited before. Guan Xianzi also served as an official with me. Her blindness made me worry, but with her character and martial skill, there was no need to fear that anyone would bully her. I have always felt warmly toward Guan Xianzi, who had been betrothed to me since childhood. I hope Xie Xin takes more walks with her for me, and that they eat zongzi together during the Dragon Boat Festival. Li Shuangshuang and Yiyi have wandered the world together. I envy their carefree roaming—from the south of West Lake to the north of Mount Tai. I hope I can meet them again someday. I could tell that Yiyi liked me, but I never said so. When I carried Shuangshuang down the mountain, I did have some improper thoughts, but in the end I still could not refuse Xiyun’s devotion. When Guan Xianzi said that, if my martial arts never recovered, she would protect me for a lifetime, I was truly moved. I am grateful that she really did remain by my side in the end. Xie Xin, Xie Xin, do not neglect those around you: Guan Xianzi, chestnut cakes, and Xiyun. I did not forget Huang Chan. I hope time lets Shiyuehua reconcile with her. It would be nice if they could open a pharmacy together, though that is unlikely.

In the end, I will still miss it: the ten years in the pleasure house, the little interactions and moments of feeling with them. I am glad I bought a qin for Nie Xiang then. I wonder who she will play it for in the future. When she plays “Flowing Water” again, will she think of me?

XnneHang

Rebuilding My Blog: Where My Inspirations Came From

The Core Framework

Rethinking Content Organization

Categories

Series

The Homepage and Reading Experience

Homepage Banner

Hiding the Navigation While Reading

The Bookshelf: What I Am Reading and What Has Stayed with Me

Statistics and Graphs: Seeing a Blog Through Its Numbers

Publishing Trails and Reading Echoes

Relationship Graph

About: Letting the Bookshelf Introduce Me

Comments

A Custom 404 Page

The In-Progress Workbench: Turning Todos into Alchemy

A Bilingual Site: Making Another Language Part of the Structure

Filled with Empty Things

Parallel timelines?

The Lychee of Chang'an

First Impressions of GitHub Stacked PRs

What Is gh stack?

What Does It Bring?

How Do You Create One?

Stacked PRs from a Maintainer’s Perspective

Can They Be Merged in Order?

Incremental Reviews

Stacked PRs from a Contributor’s Perspective

An Immediate Reality Check

Are Tree-Shaped Stacks Supported?

Do Upper PRs Include All Lower-Level Code, and Do They Change in Real Time?

What Do Local Branches Look Like During sync?

The Shape of a Protocol Determines Its Capabilities: Why Codex Removed chat_completion, and What Actually Blocks a Desktop Companion from Talking While It Works

Preface

Questions to Discuss

The Difference Between chat_completion and responses, and the Value of Migrating

The Difference Between Anthropic Messages and OpenAI's Streaming Tool Responses

Why Does My pre_tool_preview Work? What Are Its Limits?

How Can an Agent Talk While Working in Engineering Terms?

Why codex-cli Removed Chat Completions

Timeline

Unilateral or Community Decision?

Official Reason vs. the Real Reason

What Happened to new-api

One-Sentence Version

A Summary and Another Complaint About OpenAI

What to Watch: There Is No Migration Value Yet, Only Migration Risk

What Is the Real Difference Between responses and chat_completion?

A Table That Covers It

Only Four Points Really Matter

But the Conclusion Does Not Change

Complaining Again

The Difference Between Anthropic Messages and the Chat Completion Tool Stream Used by My Desktop Companion

The Confusion Around Talking While Working

Anthropic: Talking While Working Is the Default in the Official Example

OpenAI: It Can Speak Once, but Cannot Express Multiple Segments

Your Implementation: Confirmed from the Repository

Where “OpenAI Cannot” Is Wrong and Right

The Limits of pre_tool_preview Under the OpenAI Protocol

Additional Questions

a. Both Are Strictly Serial; There Is No Token-Level Interleaving

b. It Is the Protocol, Not the Model—the Proof Is in OpenAI's Own Type Definitions

Is It Really “Garbage Design”?

Finally: Your Example May Be Your Own Prompt's Fault

Damn!

Correction One: It Is “One per Round,” Not “One per Tool”

Correction Two: My Diagnosis Was a Hypothesis, Not a Conclusion

Correction Three: Previews Do Not Remove Silence During Tool Execution

Do You Still Need to Split It into Steps?

A Concrete Prompt Shape

Real and Fake “Talking While Working”

Fake: Segmented Speech, With a Full Round Trip per Segment

Real: Speak, Work, Speak in One Stream, Without Returning Control to the Client

The Honest Part: Anthropic Client Tools Are Fake Too

What This Means for Your Desktop Companion

A More Precise Meaning of “Handshake”

Learning from Bad Architecture: What Claude Desktop's Five Scheduling Systems Reveal About Separating Cowork and Code

Why I Call It an Architectural Mess

Background

What Is `gh stack`?

What Do Local Branches Look Like During `sync`?

Testing the Entry-Point Routing: `/schedule` and `create_scheduled_task`, Same Names but Different Backends

Why We Are Not Splitting the `claude_code` Adapter into Separate CLI and Desktop Implementations