# รอบการปล่อย ปลายกรกฎาคม 2026: Octocode 0.19.0, Octobrain 0.9.4, Octolib 0.26.1, Vext 1.3.0 > สองสัปดาห์ครึ่งนับจากรอบกรกฎาคม และ stack ก็เรียนรู้ที่จะตรวจงานของตัวเอง Octocode 0.19.0 ออก reasoning retrieval — LLM re-ranker ที่หลอมเข้ากับ hybrid search ด้วย weighted RRF, MRR +36% บน benchmark Octobrain ทำให้ knowledge sync ไม่ block, Octolib รักษารายชื่อโมเดลและราคา embedding ให้ทันสมัย และ Vext 1.3.0 มาพร้อม redesign แบบ glass, diarization ระดับคำ และสองภาษาใหม่ [บันทึกรอบกรกฎาคม](/blog/release-round-july-2026) ออกไปเมื่อวันที่ 11 สิบเจ็ดวันต่อมาก็มีเรื่องพอสำหรับอีกฉบับ — และคราวนี้ release ไม่ได้แค่อยู่เคียงกัน แต่เชื่อมโยงถึงกัน สองตัวในนั้นได้โพสต์ของตัวเองไปแล้ว: [Octocode สอนการค้นหาให้คิด](/blog/reasoning-retrieval-code-search) ด้วยขั้น LLM reasoning ที่ re-rank โค้ดที่ดึงมา และเราเขียนเรื่อง[วิธีจับคู่การค้นหานั้นกับความจำของ Octobrain](/blog/pairing-code-search-with-memory-for-ai-agents) เพื่อให้ agent ทั้งหาโค้ดเจอและจำได้ว่าตัดสินใจอะไรเกี่ยวกับมันไว้ โพสต์นี้เก็บส่วนที่เหลือ — และไล่เส้นด้ายที่โยงพวกมันเข้าด้วยกัน เส้นด้ายของรอบนี้คือ **verification** Octocode เลิกเชื่อคะแนน similarity แล้วหันมาถามโมเดลว่าผลลัพธ์ตอบ query จริงหรือเปล่า supervisor ของ Octomind เลิกเชื่อคำว่า "task complete" แล้วหันมาตรวจแผนเทียบกับสิ่งที่เกิดขึ้นจริง แม้แต่ diarization ของ Vext ก็เลิกเชื่อป้ายผู้พูดระดับ chunk แล้วหันมาแยกที่ระดับคำ ทั่วทั้ง stack ตอนนี้ output แรกเป็นแค่ฉบับร่าง — มีบางอย่างตรวจมันก่อนที่คุณจะเห็น --- ## Octocode 0.18.1 → 0.19.0 — การค้นหาที่ตรวจผลลัพธ์ของตัวเอง [**github.com/muvon/octocode**](https://github.com/muvon/octocode) · 0.18.1 → **0.19.0** · 26 กรกฎาคม พาดหัวมี[โพสต์ของตัวเอง](/blog/reasoning-retrieval-code-search): ขั้น LLM reasoning แบบ optional ที่อ่าน candidate ที่ดึงมา ตัดสินความเกี่ยวข้องจริง แล้ว re-rank — หลอมเข้ากับ hybrid search ผ่าน weighted RRF บน benchmark 127 query ที่ [0.18.0 ทำให้ทำซ้ำได้](/blog/octocode-0-18-0-retrieval-benchmarks-graphrag-expansion) มันยก MRR ขึ้น +36% และดัน Hit@5 ไปถึง 0.953 นี่คือจุดแรกที่ต้องลากเส้นเชื่อม: ทั้งหมดนั้นไม่มีกลไกใหม่เลย RRF fusion คือไอเดียเดียวกับที่ [Octobrain 0.9.0 ออกในมิถุนายน](/blog/octobrain-0-9-0-knowledge-goes-multiplayer) สำหรับ multi-query memory recall — พิสูจน์แล้วใน memory layer ตอนนี้ถูกถ่วงน้ำหนักแล้วย้ายเข้ามาใน code search และ verdict แบบ structured ของขั้น reasoning ก็ขี่อยู่บน response schema enforcement ของ Octolib จาก 0.24.0 — layer ข้างล่างเรียนรู้ที่จะการันตีว่า output ของโมเดล parse ได้เสมอ layer ข้างบนจึงกล้าวาง LLM ไว้ในเส้นทางการจัดอันดับ นี่คือเหตุผลที่ stack ship เป็นห้าชิ้น: ไอเดียลงจอดครั้งเดียว แล้วทุกเครื่องมือรับมรดกไป สิ่งที่ไม่ได้โพสต์ของตัวเอง: - **Config v2 พร้อม atomic writes** ระบบ configuration ถูกปรับให้ทันสมัย: schema v2 พร้อม migration อัตโนมัติจาก config เดิมของคุณ, การอัปเดตแบบ atomic เพื่อไม่ให้ process ที่ทำงานพร้อมกันทำมันพังได้ และการเขียนไฟล์ที่แข็งแรงขึ้นพร้อมการโหลดที่เร็วขึ้นตามหลังมา - **งานหน่วยความจำของ indexer** รอบเก็บงานด้าน allocation efficiency ใน indexer — แรงกดดันหน่วยความจำน้อยลงบน repo ขนาดใหญ่ สานต่อรอบเสถียรภาพของ 0.18.1 - **Index แบบ read-only โดยไม่ต้องมี git** MCP server เลิกยืนกรานว่าต้องมี git repository สำหรับการเข้าถึง index แบบ read-only — ชี้มันไปที่ directory ธรรมดา แล้วการค้นหาก็ทำงาน - **วงจรชีวิต LSP ที่ deterministic** child process ของ LSP ตอนนี้ถูกเก็บกวาดอย่าง deterministic — ไม่มี language server หลงเหลือรอดข้าม session ของมันอีก - **AGENTS.md** ไฟล์ instructions ถูกเปลี่ยนชื่อตามธรรมเนียม AGENTS.md ที่ [Octomind รับมาใน 0.36.0](/blog/release-round-july-2026) — จุดที่สอง: ธรรมเนียมเดียว แพร่ผ่าน stack ทีละ release ```bash cargo install octocode --version 0.19.0 # or grab a binary at https://github.com/muvon/octocode/releases ``` --- ## Octobrain 0.9.1 → 0.9.4 — knowledge sync เลิกขวางทาง [**github.com/muvon/octobrain**](https://github.com/muvon/octobrain) · 0.9.1 → **0.9.4** · 26 กรกฎาคม สาม release เล็กๆ ที่มีทิศทางชัดเจนหนึ่งเดียว: ทำให้ multiplayer knowledge layer จาก [0.9.0](/blog/octobrain-0-9-0-knowledge-goes-multiplayer) รู้สึกเหมือนล่องหน - **Git operations แบบ async (0.9.4)** knowledge box ที่หนุนด้วย git ตอนนี้ sync ในพื้นหลัง — pull หรือ push ไม่ block memory call ที่จุดชนวนมันอีกแล้ว ถ้าทีมของคุณแชร์ knowledge repo กัน การ recall ยังเร็วอยู่แม้ตอนที่ repo ไม่เร็ว - **MCP tool schema ที่แบนราบขึ้น (0.9.2)** tool schema ถูกทำให้แบนและเอกสารถูกขัดเกลา — รูปทรงที่เรียบง่ายขึ้นซึ่ง MCP client จำนวนมากขึ้นจัดการได้ถูกต้อง แรงจูงใจเดียวกับที่ Octocode เลิกบังคับ git ด้านบน: เครื่องมือเดินไปหา client ในที่ที่พวกมันอยู่ แทนที่จะเขียนเอกสาร workaround - **การแก้ embedding provider (0.9.4)** response ของ provider ที่มาเป็น tuple ถูกจัดการอย่างถูกต้อง — การแก้ interop สำหรับสวนสัตว์ embedding backend ที่โตขึ้นเรื่อยๆ ถ้าอยากเห็นว่าการผสมค้นหา-บวก-ความจำมีไว้ทำอะไรกันแน่ [โพสต์จับคู่](/blog/pairing-code-search-with-memory-for-ai-agents) ต่อสาย Octocode กับ Octobrain เข้าด้วยกันใน agent setup เดียว ```bash cargo install octobrain --version 0.9.4 # or grab a binary at https://github.com/muvon/octobrain/releases ``` --- ## Octolib 0.25.0 → 0.26.1 — รายชื่อโมเดลยังทันสมัย มิเตอร์ยังซื่อตรง [**github.com/muvon/octolib**](https://github.com/muvon/octolib) · 0.25.0 → **0.26.1** · 26 กรกฎาคม รอบก่อน [Octolib](/blog/octolib-the-engine-behind-our-ai-stack) เริ่มติดตามค่าใช้จ่าย embedding เคียงคู่ค่าใช้จ่าย completion รอบนี้มันทำงานนั้นจนจบและขยับรายชื่อโมเดลต่อไป — เรายังเขียนเรื่อง[ห้าเดือนของการสร้าง layer นี้สอนอะไรเราบ้าง](/blog/lessons-building-a-unified-llm-provider-layer-in-rust) ด้วย - **ราคา embedding สำหรับ Voyage และ Jina (0.25.1)** — รวมถึง Jina v5 omni เมื่อรวมกับการติดตามการใช้งานจาก 0.25.0 ต้นทุน embedding ตอนนี้เป็นตัวเลขจริงสำหรับทุก provider ที่ Octocode ใช้ index ได้ จุดที่สาม: นี่คือเดือนเดียวกับที่ Octocode ทำให้ _คุณภาพ_ ของ retrieval เป็นตัวเลข คุณภาพต่อ query และต้นทุนต่อ index — วัดได้ทั้งคู่ อยู่ใน stack เดียวกันทั้งคู่ - **Custom HTTP headers บน LLM requests (0.26.0)** header เฉพาะ provider แบบไหนก็ตาม — auth schemes, routing hints, beta flags — ผ่านเส้นทาง request แบบ unified เดียวกันทั้งหมด ช่องทางหนีที่ทำให้ "unified" ไม่กลายเป็น "ตัวหารร่วมต่ำสุด" - **รายชื่อโมเดล: Kimi K3, Inkling, Claude Opus 5** Kimi K3 ของ Moonshot และโมเดลอ้างอิง Inkling ลงจอดใน 0.25.2, Claude Opus 5 ใน 0.26.1 — ไม่กี่วันหลังแต่ละตัวเปิดตัว เหมือนทุกเดือนที่ผ่านมา ถ้ามันเรียก LLM จาก Rust มันควรผ่าน layer นี้: trait เดียว, retry เดียวกัน, cost accounting เดียวกัน — ทั้ง completions และ embeddings --- ## Vext 1.3.0 — release ที่ใหญ่ที่สุดนับตั้งแต่เปิดตัว [**vext.muvon.io**](https://vext.muvon.io) · 1.2.0 → **1.3.0** · 27 กรกฎาคม [Vext](/blog/introducing-vext-voice-to-text-for-mac) ออกอัปเดตที่ใหญ่ที่สุดเท่าที่เคยมี และมันขยับสามแนวรบพร้อมกัน **ทั้งแอปได้ redesign แบบ glass** glass design system ใหม่พร้อม motion primitives — ในที่สุด UI ก็ดูเหมือน macOS ที่มันรันอยู่ **Diarization ขยับจากระดับ chunk สู่ระดับคำ** [two-pass diarization ของ 1.2.0](/blog/vext-1-2-0-two-pass-diarization-and-five-languages) ติดป้ายผู้พูดต่อ chunk; 1.3.0 แยกที่ระดับคำ ดังนั้นบทสนทนาโต้ตอบเร็วๆ ระหว่างคนสองคนไม่ถูกกาวติดเป็นผู้พูดคนเดียวอีก speaker recognition และการจับคู่ผู้พูดปรับปรุงตามไปด้วย และ edge case ยากๆ สองกรณีถูกแก้: ป้ายแบบ live รอดเมื่อ offline pass ยุบ stream และไม่มี chunk ไหนถูกทิ้งเมื่อการ re-split แบบ offline กรอง run ออกทั้งหมด นั่นคือเส้นด้าย verification อีกครั้ง — offline pass มีอยู่เพื่อตรวจทาน pass แบบ live และตอนนี้การตรวจทานทำข้อมูลหายไม่ได้แล้ว **Echo cancellation แบบน่าเบื่อ** เราสร้าง acoustic echo cancellation ของตัวเอง แล้วแทนที่มันด้วย voice-processing I/O ของระบบ — AEC ของแพลตฟอร์มดีกว่าของเรา ของเราจึงหายไป การรองรับ custom vocabulary ลงจอดเคียงข้างกัน ดังนั้นศัพท์เฉพาะวงการและชื่อเฉพาะรอดผ่านการถอดความ ยังมีใน 1.3.0: **เยอรมันและดัตช์** พา UI ไปถึงเจ็ดภาษา (EN, ES, DE, NL, RU, HI, TH), การยกเครื่องระบบ hotkey และรอบเสถียรภาพพร้อมการแก้สองจุดที่ควรเอ่ยถึง — งานถอดความที่ถูกยกเลิกไม่ busy-spin ที่ CPU 100% อีก และ finalization ในพื้นหลังไม่ย้อนคืนการแก้ไขที่คุณทำกับ transcript ของมีตติ้งระหว่างที่มันรันอีกต่อไป ทั้งหมดนี้ยังรันบนเครื่องเต็มรูปแบบ — [นี่คือเหตุผลว่าทำไมเรื่องนี้ต่อรองไม่ได้สำหรับเรา](/blog/why-we-run-speech-recognition-fully-on-device) --- ## คงที่ โดยตั้งใจ **[Octofs](/blog/introducing-octofs)** คงที่ที่ 0.5.2 — การรื้อ line targeting จากต้นกรกฎาคมลงตัวแล้ว และ filesystem layer กลับไปน่าเบื่อ ซึ่งคืองานของมัน **[Timex](/blog/introducing-timex-time-tracker-for-mac)** คงที่ที่ 1.2.0 และ **[TypeTab](/blog/introducing-typetab-autocomplete-for-mac)** ที่ 1.1.0 — แม้ Timex จะได้บทความเดือนนี้เรื่อง[ทำไมทั้งแอปคือไฟล์ SQLite ไฟล์เดียว](/blog/one-sqlite-file-the-local-first-architecture-of-a-mac-time-tracker) --- ## Octomind 0.36.0 → 0.39.0 — เล่าบน octomind.run runtime ship เจ็ด release ในสิบเจ็ดวัน โดย [Octomind 0.39.0](https://github.com/muvon/octomind) ตัดออกวันที่ 26 กรกฎาคม: โหมด workflow execution แบบ graph, login flow แบบ device-authorization (RFC 8628), การจัดการบัญชีและการใช้งาน และ — เส้นด้ายเดิมอีกครั้ง — งาน supervisor ด้าน plan-completion verification และ observational verification ที่ supervisor ตรวจความคืบหน้าที่ถูกอ้างเทียบกับสิ่งที่ session ทำจริง โดยทุกการเปลี่ยนแปลงถูกคุมประตูด้วย SWE-bench baseline บทความเต็มอยู่บน [octomind.run](https://octomind.run) --- ## พวกมันเข้ากันอย่างไร ลากเส้นเชื่อมทุกจุดแล้วภาพที่ได้คือท่าเดียวที่ทำห้าครั้ง: **generate แล้ว verify** Octocode ดึงข้อมูล แล้วขั้น reasoning ก็ re-rank Octobrain recall จากหลาย query แล้ว RRF ก็หลอมรวม supervisor ของ Octomind วางแผน แล้วตรวจความสำเร็จเทียบกับสิ่งที่สังเกตได้จริง Vext ถอดความสด แล้ว offline pass ก็แยกผู้พูดใหม่ — ตอนนี้โดยไม่ทำคำหายแม้แต่คำเดียว และ Octolib ข้างใต้ทำให้ขั้น verify ทั้งจ่ายไหวและวัดได้: output ที่บังคับตาม schema เข้าไป cost accounting ออกมา - **[Octolib 0.26.1](https://github.com/muvon/octolib)** — ทุก LLM call, ทุกโมเดลของฤดูร้อน, ทุกต้นทุนถูกติดตาม - **[Octobrain 0.9.4](https://github.com/muvon/octobrain)** — ความจำถาวร knowledge ที่ sync โดยไม่ block - **[Octofs 0.5.2](https://github.com/muvon/octofs)** — การเข้าถึง filesystem อย่างปลอดภัย น่าเบื่อโดยตั้งใจ - **[Octocode 0.19.0](https://github.com/muvon/octocode)** — code search ที่ reason เกี่ยวกับผลลัพธ์ของตัวเอง - **[Octomind 0.39.0](https://github.com/muvon/octomind)** — runtime ที่ตอนนี้ verify ความคืบหน้าของตัวเอง binary เดี่ยว, Apache-2.0, ทั้งหมด สิงหาคมขยับแล้ว ถ้าตัวไหนในนี้ปลดล็อกสิ่งที่คุณอยากสร้างมานาน [เปิด issue](https://github.com/muvon) — feature ที่ถูกขอในรอบเหล่านี้กลายเป็นพาดหัวของรอบถัดไปอยู่เรื่อยๆ — Don