v0.12.4

New features and improvements

1. 01

   Root agent cache identity is stable and aligned

   A root agent now has a single, deterministic cache identity that it presents to Codex across every turn of its life, instead of values that drifted or were generated fresh per request.

   • The kernel derives a stable 8-character hash as the first 8 hex characters of the sha256 of the resolved agent/init.json path; resolving the path first means the same agent maps to the same hash regardless of how it was addressed.
   • That single hash is used byte-identically as the Codex session-id, the thread-id, and the prompt_cache_key, so all three routing/cache surfaces agree for the same logical agent.
   • Because the identity is derived from a resolved on-disk path rather than per-call state, it is stable across restarts, reconnects, and repeated turns within the same agent.

   Why it matters:Codex prompt caching rewards a stable, repeated conversation identity. When session-id, thread-id, and prompt_cache_key all agree and persist, the provider can recognize that a new turn continues an existing context, so the shared prefix is served from cache instead of re-billed and re-encoded.

2. 02

   Daemon runs get their own scoped cache anchors

   LingTai-backend daemon runs no longer borrow the parent or a single global identity. Each run is given a daemon-scoped service and a per-run Codex anchor, so daemons are both cacheable and isolated.

   • Each LingTai-backend daemon run now runs through its own daemon-scoped LLMService rather than sharing the parent agent service.
   • The Codex anchor for a run is derived from the resolved per-run daemon.json path, using the same resolved-path hashing scheme as the root-agent identity, so each run has a distinct but stable anchor.
   • Preset daemons keep their own dedicated service, and the Codex presets they use now also receive daemon anchors, so preset-driven daemon work shares the same identity discipline as ad-hoc runs.

   Why it matters:Daemons are how a LingTai agent offloads isolated work. If every daemon reused one parent/global identity, independent runs would collide in the same cache namespace and poison each other; if each generated an unstable identity, none would ever hit cache. Per-run resolved-path anchors give each daemon a stable identity of its own while keeping independent runs cleanly separated.

3. 03

   Why the cache rate rises, and why hits did not happen before

   This release is small in code but specific in mechanism. It is worth stating plainly what changed in cache behavior and why the previous arrangement left hits on the table.

   • After: repeated turns from the same root agent present one stable, aligned routing/cache identity to Codex, so the provider treats them as a continuing conversation and serves the shared prefix from cache.
   • After: daemon runs no longer all reuse a single parent/global identity nor generate unstable per-call identities; within one run, session-id, thread-id, and prompt_cache_key align.
   • Before: session-id, thread-id, and prompt_cache_key were not stable or aligned enough for root agents and daemon runs, so equivalent prompts looked unrelated to Codex and missed the cache.
   • Before: daemon runs could share a parent service/cache identity or collide and poison each other, so prompts that should have reused a prefix either crossed isolation boundaries or invalidated each other.

   Why it matters:Prompt caching is a recognition problem: the provider only reuses work when it can recognize that two requests share a logical conversation. The previous identity scheme made that recognition unreliable for exactly the two units that repeat the most — root agents and daemon runs. Fixing identity at those two boundaries is where the hit-rate improvement comes from.

4. 04

   How this compares to OpenClaw, Hermes, and Codex CLI

   This is an architectural comparison, not a benchmark claim. The shared lesson across external CLI/proxy systems is that cache reuse follows whoever owns a stable conversation identity; v0.12.4 makes LingTai own that identity at the agent and run level.

   • External coding CLIs and provider proxies (Codex CLI, and CLI/proxy systems in the same family as OpenClaw and Hermes) tend to preserve a stable CLI-side session/thread/conversation identity across turns, which is what lets the provider reuse the cached prefix.
   • Before v0.12.4, LingTai did not consistently present such a stable identity for its own repeated units, so it could not benefit from the same provider-side reuse even when the prompts were effectively continuations.
   • v0.12.4 gives LingTai its own stable agent/run anchors derived from resolved paths, so Codex sees the same logical unit consistently across turns — the same property that makes CLI-side sessions cache well.
   • The difference from a single long-lived CLI session is isolation: LingTai still keeps independent daemons separate via per-run anchors, so it gains the reuse benefit without merging unrelated runs into one shared identity.

   Why it matters:The point of the comparison is to be honest about where the gain comes from. LingTai is not inventing a new caching trick; it is adopting the same stable-identity discipline that well-behaved CLIs already rely on, and applying it at the agent and daemon-run boundaries that are specific to a LingTai network.