← Releases

id 20260710-1 · 2026-07-10 · kernel v0.16.3 · tui v0.10.6

Kernel v0.16.3 · TUI/Portal v0.10.6

LingTai release day: tool knowledge ownership, one-shot installer, and leaner prompt budgets

This paired release reorganizes how the kernel owns tool knowledge — every built-in tool now lives in its own package directory with a CONTRACT.md, glossary files in EN/ZH/Wen, and a centralized glossary validator — while single-sourcing repeated tool guidance in the system prompt so #842 saves roughly 2,975 tokens per call (a different measurement scope; not a universal net). The TUI ships a one-shot GitHub-release installer with hardened uv/venv/portal/Go bootstrapping, a custom OpenAI wire selector, codex-pool model classification, mailbox search, session tool-call stats, loopback-only portal binding, and credential-labeling for Codex OAuth. The kernel adds a codex-pool exact-model auth lane, backend flag-discovery submanuals for 9 backends, IMAP attachment filename sanitization, extended credential redaction, AED manifest recognition, a skill/glossary i18n migration that grows ZH prompt descriptions by +5,224 chars (+221.17%) and Wen by +5,106 chars (+212.66%) while EN adds 0 new chars from glossary-only files (#844), and a final packaging repair (#847) that makes the native lingtai-search-sidecar platform wheels platlib-compliant.

Upgrade / runtime

$ curl -fsSL https://raw.githubusercontent.com/Lingtai-AI/lingtai/main/install.sh | bash

This release adds a one-shot GitHub-release installer that bootstraps Go, Node, uv, and the venv-managed runtime from a single command. The one-shot https://lingtai.ai/install.sh installer plus TUI-managed project and runtime updates are now the primary end-user install and upgrade path; Homebrew is no longer required, and any remaining tap is only a legacy compatibility mirror. PyPI 0.16.3 is published as the managed-runtime package source and verification point for project virtual environments — not the normal user upgrade command — with the sidecar wheel repair (#847) landing in the v0.16.3 tag.

New features and improvements

  1. 01

    Tool knowledge ownership: packages, contracts, glossaries, and a validator

    Every built-in tool is reorganized into its own package under src/tools/ with a CONTRACT.md that documents its public API, per-language glossary files (en/zh/wen) that move localized terminology out of runtime i18n JSON, and a centralized glossary_validator that enforces structure and cross-language parity at test time.

    • Kernel #839 consolidates 14 tool packages (bash, read, edit, glob, grep, daemon, email, mcp, notification, psyche, soul, system, skills, knowledge, vision, web_search, avatar, write) from scattered locations (lingtai/core, lingtai/capabilities, lingtai/intrinsics) into a unified src/tools/ namespace with per-tool ANATOMY.md updates.
    • Kernel #844 adds glossary-en.md, glossary-zh.md, and glossary-wen.md to every tool package, plus a tools/i18n/ directory with en.json/zh.json/wen.json and a glossary_validator.py (171 lines) that checks structure, required keys, and cross-language key parity. ZH glossary content grows +5,224 chars (+221.17%), Wen +5,106 chars (+212.66%); EN glossary files add 0 new chars because the EN terms are already present in the tool source; this is a glossary-file-only delta (#844).
    • TUI #614 adds lingtai-preset-skill router documentation with 12 child manuals covering Codex, Claude Agent SDK, custom, DeepSeek, Gemini, Kimi, MiMo, MiniMax, NVIDIA, OpenRouter, and Zhipu providers — so preset configuration is documented where operators actually look.

    Why it matters:When tool descriptions, localized terms, and public contracts live in the same package directory, a contributor can find and modify them without searching three separate codebases. The glossary validator ensures that adding a term in one language does not silently break another.

  2. 02

    Single-sourced tool guidance and the OpenAI wire selector

    Kernel #842 single-sources repeated tool guidance strings in the system prompt by referencing the glossary rather than inlining full descriptions per tool, saving approximately 2,975 tokens per API call on the measured test prompt. This measurement scope (the specific test prompt and model used) differs from universal token accounting and the -2,975 figure cannot be taken as a universal net saving across all configurations.

    • Kernel #842 refactors tool guidance in the system prompt to reference glossary files instead of inline localized strings, yielding a measured -2,975 token saving on the test prompt used for validation. The measurement scope is specific to that test prompt and model; it cannot be extrapolated as a universal net saving across all operator configurations and prompts. This -2,975-token figure is a wire-saving on a specific test prompt and is a different scope from the #844 glossary-file character deltas.
    • Kernel #843 adds a custom OpenAI wire API selector so operators can choose the exact OpenAI-compatible wire format (e.g. chat completions vs. responses API) per agent or preset, rather than relying on a single hardcoded default.
    • TUI #613 mirrors the kernel-side custom wire selector in the TUI preset editor, so the wire API choice is a first-class TUI setting rather than a manifest-only override.

    Why it matters:The -2,975 token saving is real for the measured prompt, but it is not a universal floor; different prompts, languages, and tool counts will yield different savings. Stating the measurement scope honestly prevents operators from expecting a fixed saving that does not hold in their configuration.

  3. 03

    Codex-pool model classification and auth metadata

    The codex-pool auth lane now classifies shared OAuth pools by exact model identifier rather than treating all models behind one credential as interchangeable, and the token ledger records safe auth metadata for auditability.

    • Kernel #841 classifies the codex-pool auth pool by exact model, so a single OAuth credential serving multiple models is no longer treated as one undifferentiated pool.
    • Kernel codex/token-ledger-auth-metadata records safe auth metadata (pool, model, source) in the token ledger without exposing credential material.
    • TUI #612 preserves and truthfully renders model-classified codex pools in the setup and pool management UI.

    Why it matters:When multiple models share one OAuth credential, cost attribution and rate-limit troubleshooting require knowing exactly which model consumed the tokens; classification makes that attribution automatic rather than a manual log hunt.

  4. 04

    One-shot installer, portal security, and TUI cockpit improvements

    The TUI ships a GitHub-release one-shot installer that bootstraps Go, Node, uv, and the venv runtime from a single curl command, hardens WSL and broken-venv fallbacks, and adds portal loopback-only binding as the secure default.

    • TUI #595 adds install.sh — a GitHub-release one-shot installer with Go, Node, uv, and venv bootstrapping, portal build support, and fallback to source builds (#596, #598, #599, #601–#604, #606).
    • TUI portal loopback binding is the default (TUI fix/portal-loopback): the portal no longer binds 0.0.0.0 by default, closing the exposure reported in earlier security audits.
    • TUI #610 adds mailbox search and archive scanning so operators can find messages by keyword without leaving the cockpit; TUI #611 shows session tool-call stats in the Details panel.
    • Codex OAuth credentials can now be labeled (TUI BatalloLu: allow labeling Codex OAuth credentials), making multi-account setups distinguishable in the login UI.

    Why it matters:A one-command installer that actually bootstraps every dependency (Go, Node, uv, the venv runtime) removes the largest adoption friction for new operators. Loopback-only portal binding is the secure default for a local-first tool.

  5. 05

    Backend knowledge, credential hardening, and the sidecar wheel repair

    The kernel adds flag-discovery submanuals for 9 daemon backends, extends credential redaction and IMAP attachment sanitization, recognizes AED manifest fields, fixes pseudo-agent mail polling, and closes the release with #847 — a packaging repair that makes the native lingtai-search-sidecar platform wheels install into platlib.

    • Kernel #830–#837 adds flag-discovery submanuals for Codex, OpenCode, claude-p, MiMo Code, built-in LingTai, Kimi Code, Qwen Code, Cursor, and Oh-My-Pi daemon backends — each documenting the exact flags, environment variables, and discovery flow for that backend.
    • Kernel #824 extends trace redaction to cover additional credential key names; kernel #770 sanitizes IMAP attachment filenames before writing to disk; kernel #825 recognizes AED (agent entity descriptor) manifest fields; kernel #806 fixes pseudo-agent outbox polling priority.
    • Kernel #828 clarifies rebuild context observation timing, and #838 clarifies peer mail during refresh. Kernel #846 fixes prompt-related-files runtime path resolution and adds tests that ignore external paths in prompt crawl checks.
    • Kernel #847 makes the native lingtai-search-sidecar platform-wheel layout correctly install into platlib rather than purelib; the Ubuntu, Intel-macOS, ARM-macOS, and Windows wheel jobs plus an independent sdist all passed on wheels-workflow run 29108219136. Intel/ARM macOS wheels declare 10.12 / 11.0 deployment-target floors, and a dependency-free sidecar smoke test avoids the unrelated PyAV/FFmpeg dependency resolution. This is a CI/packaging fix for the existing Python wheel runner, not a new Windows product or tool.

    Why it matters:Each daemon backend has its own flag conventions and environment quirks; a submanual per backend means the runtime can surface exact setup guidance instead of generic advice. Credential redaction and attachment sanitization are table-stakes for a tool that reads mail and runs unattended. And a wheel that lays its native sidecar into platlib is the difference between an install that imports and one that silently ships files to the wrong place.

  6. 06

    Release-window audit and contributors

    This entry accounts for every commit author, with strict ranges from the previous release tags through the release tags: TUI/Portal v0.10.5..v0.10.6 (41 commits; author breakdown 30 @huangzesen, 7 @TZZheng, 3 @github-actions[bot], 1 @BatalloLu) and Kernel v0.16.2..v0.16.3 (54 commits; author breakdown 48 @huangzesen, 5 @TZZheng, 1 @wchwawa). GitHub merge-commit committers and @github-actions[bot] are automation, not human authorship; @9s5bz2jvd2-lang co-authored kernel #843; AI co-authors (Claude Fable 5, Claude Opus 4.8) appear on some commit trailers.

    • TUI/Portal: 41 commits (30 @huangzesen, 7 @TZZheng, 3 @github-actions[bot] daily star-count updates, 1 @BatalloLu; the 13 merge commits are committed by GitHub); 149 files changed, +7,573 / -1,007 lines.
    • Kernel: 54 commits (48 @huangzesen, 5 @TZZheng, 1 @wchwawa; the merge commits are committed by GitHub/@huangzesen); 392 files changed, +12,506 / -2,718 lines through the candidate, and 396 files changed, +13,306 / -2,780 lines through the v0.16.3 tag once the #847 sidecar-wheel repair (5 files, +809 / -71) is included.
    • Note: kernel #842 removed -2,975 tokens of system-prompt tool guidance via single-sourcing on the measured test prompt; this measurement scope (the specific test prompt) differs from universal net accounting and the -2,975 figure is not a universal saving, and is a different scope from the #844 glossary-file character deltas (EN 0; ZH +5,224/+221.17%; Wen +5,106/+212.66%).
    • Human contributors/authors in the window: @huangzesen, @TZZheng, @9s5bz2jvd2-lang (kernel #843 co-author), @BatalloLu, @wchwawa. Automation: @github-actions[bot] (daily star updates) and the GitHub merge committer. AI co-authors: Claude Fable 5, Claude Opus 4.8.

    Why it matters:The contributor list intentionally names every human commit author, separates automation (the bot and GitHub merge committers) from humans, and acknowledges the measurement caveat around #842 so operators can form their own judgment about prompt cost changes.

Contributors

Thanks to everyone whose commits, co-authored changes, PRs, reviews, assignments, or reported/closed issues are represented in this release window.

Validation

Final release validation was run from a clean release worktree at commit kernel f3971.