Transparent lab notes. Lab notes ที่โปร่งใส ตรวจสอบได้

Code-aware retrieval that walks the call graph, not the text. Retrieval ที่เดินตาม call graph จริง ไม่ใช่แค่ match ข้อความ

The core retrieval claim: when your AI asks "who calls authenticate_user?" or "if I change the return type of add_task, what breaks?", Cosmos walks the real call graph instead of grep-matching symbol mentions. Measured against BM25 over the same source dumped as markdown — the strongest "plain memory" baseline. ข้อ claim หลักด้าน retrieval: เมื่อ AI ถาม "ใครเรียก authenticate_user?" หรือ "ถ้าเปลี่ยน return type ของ add_task อะไรพัง?" Cosmos เดินตาม call graph จริง ไม่ใช่ grep หาชื่อ symbol. เทียบกับ BM25 บน source เดียวกันที่ dump เป็น markdown — baseline "plain memory" ที่แข็งที่สุด

The second corpus (requests) was chosen and questions auto-mined the same way as the first — methodology was frozen before the second run started, no question hand-picked after seeing data. Both runs cleared the pre-registered gate (≥1.8× gap AND Cosmos MRR > 0.7) so the headline number is the minimum of the two: 2.09×. corpus ตัวที่สอง (requests) เราเลือกมาและ auto-mine คำถามด้วยวิธีเดียวกับตัวแรก — lock methodology ไว้ก่อนเริ่ม run รอบสอง ไม่มีการเลือกคำถามเองหลังเห็นข้อมูล ทั้งสอง run ผ่าน gate ที่ pre-register ไว้ (gap ≥1.8 เท่า และ Cosmos MRR > 0.7) ตัวเลข headline เลยใช้ค่าต่ำสุดของสองตัว: 2.09 เท่า

Active surfacing: 90% session-intent coverage. Active surfacing: ครอบคลุม session intent ถึง 90%

Companion test of the intent-aware preamble — given the user's first prompt as intent, does Cosmos surface enough context that the AI shows up ready? Measured on 10 plausible session-start scenarios per corpus: การทดสอบคู่กันของ intent-aware preamble — ให้ prompt แรกของผู้ใช้เป็น intent แล้ว Cosmos จะดึง context มาพอให้ AI พร้อมทำงานทันทีไหม? วัดจาก 10 สถานการณ์เริ่ม session ที่เป็นไปได้ ต่อ corpus:

What we are NOT claiming. สิ่งที่เรา "ไม่" claim

• Cosmos beats Mem0 / Letta — those weren't tested (no API budget this round). Cosmos ชนะ Mem0 / Letta — รอบนี้ยังไม่ได้เทสต์ (ไม่มี API budget)
• Cosmos wins on natural-language paraphrase. At Tier 0 (no embeddings) we're roughly even with BM25 on that axis. The 2.09×/2.57× gap is specifically on AST-aware retrieval. Cosmos ชนะเรื่อง natural-language paraphrase — ที่ Tier 0 (ไม่มี embeddings) เราสูสีกับ BM25 บนแกนนั้น ส่วน gap 2.09×/2.57× คือเรื่อง AST-aware retrieval โดยเฉพาะ
• Results extend to non-Python codebases — Track 1 is Python source only so far. ผลครอบคลุมถึง codebase ที่ไม่ใช่ Python — Track 1 ตอนนี้ทดสอบแค่ Python source

Harness, corpus, questions, and raw result JSON live in benchmarks/longitudinal/ inside the Cosmos repo. Source will be made publicly readable when the project opens up; if you're in the private alpha already, you have it. n = 30 AST + 20 intent = 50 total queries. Harness, corpus, คำถาม, และ raw result JSON อยู่ใน benchmarks/longitudinal/ ใน Cosmos repo. source จะเปิด public ตอน project เปิดให้คนทั่วไป — ใครอยู่ใน private alpha ตอนนี้ มี source แล้ว. n = 30 AST + 20 intent = 50 query

Indexed lookup is fast and local. Indexed lookup เร็วและทำงาน local

This section measures plumbing — how fast the engine returns indexed context once the question is asked. It does not measure whether the lessons that ride on top help your AI; that is the next section.

ส่วนนี้วัด plumbing — engine ส่ง indexed context กลับมาเร็วแค่ไหนหลังถูกถาม. ไม่ วัดว่า lessons ที่ทับอยู่ข้างบนช่วย AI ได้จริงไหม — เรื่องนั้นอยู่ section ถัดไป

Cosmos pre-indexes your code via SQLite + FTS5. Once the index exists, a symbol lookup against an in-process query runs at the speed SQLite gives you. The numbers below are the median latency we measured, locally, on Apple Silicon, after the index is warm. Index build time is excluded — building the FTS5 index for a 1,448-file repo takes ~6-12 seconds on first run; later launches reuse it.

Cosmos pre-index โค้ดของคุณผ่าน SQLite + FTS5. หลัง index มีแล้ว การค้น symbol จาก query ใน process เดียวกันรันเร็วเท่าที่ SQLite ให้. ตัวเลขด้านล่างคือ median latency ที่เราวัด locally บน Apple Silicon หลัง index warm แล้ว. เวลา build index ไม่นับรวม — build FTS5 index สำหรับ repo ขนาด 1,448 ไฟล์ใช้เวลา ~6-12 วินาทีตอนรันครั้งแรก ครั้งต่อ ๆ ไป reuse ของเดิม

Method: 5 warm runs per query, median reported, file filter *.py *.ts *.tsx, excluded node_modules .venv .git dist. Slowest-case (p95) numbers are in the raw CSV below for the curious.

วิธีวัด: 5 warm run ต่อ query, รายงานค่า median, file filter *.py *.ts *.tsx, exclude node_modules .venv .git dist. ตัวเลข p95 (case ช้าสุด) อยู่ใน CSV ด้านล่างถ้าอยากดู

50,000 real files, indexed locally in ~5 minutes. ไฟล์จริง 50,000 ไฟล์ · index บนเครื่องเสร็จใน ~5 นาที

Section 01 measured warm-lookup latency and excluded the one-time index build. This section measures the build itself, on a real corpus: 49,718 TypeScript/JavaScript files (456 MB) drawn from DefinitelyTyped — including 44 type-definition files over 1 MB, the largest 8.7 MB. Everything runs on one machine; nothing leaves it. The headline that matters isn't a speed-up multiple — it's that search latency stays in the same single-digit-millisecond band at 50,000 files as it does at 63.

Section 01 วัด warm-lookup latency โดยไม่รวมเวลา build index ครั้งแรก ส่วนนี้วัดตัว build เองบน corpus จริง: ไฟล์ TypeScript/JavaScript 49,718 ไฟล์ (456 MB) จาก DefinitelyTyped — รวมไฟล์ type-definition ที่ใหญ่เกิน 1 MB อยู่ 44 ไฟล์ ใหญ่สุด 8.7 MB ทุกอย่างรันบนเครื่องเดียว ไม่มีอะไรออกนอกเครื่อง จุดสำคัญไม่ใช่ตัวคูณความเร็ว — แต่คือ search latency อยู่ในช่วงหลักหน่วย ms เท่ากันทั้งที่ 50,000 ไฟล์และที่ 63 ไฟล์

Method: full cold index (parse + symbol store + FTS5 + call graph), isolated SQLite DB, on a single MacBook Air M4 · 16 GB RAM, CPU verified not thermally throttled during the run. Peak memory at the 50k scale was 1.4 GB RSS — comfortably within a 16 GB laptop. Build time scales with symbol density, not just file count — cpython is ~17 files/s (dense), DefinitelyTyped ~160 files/s (broad). Raw per-phase numbers (incl. the pre-fix run below) are in the JSONL linked at the end of this section.

วิธีวัด: full cold index (parse + symbol store + FTS5 + call graph) บน SQLite DB แยกต่างหาก รันบน MacBook Air M4 · 16 GB RAM เครื่องเดียว ยืนยันว่า CPU ไม่โดน thermal throttle ระหว่าง run · peak memory ที่ scale 50k อยู่ที่ 1.4 GB RSS — สบายๆ บน laptop 16 GB เวลา build แปรผันตาม symbol density ไม่ใช่แค่จำนวนไฟล์ — cpython ~17 ไฟล์/วิ (dense), DefinitelyTyped ~160 ไฟล์/วิ (broad) ตัวเลข raw ราย phase (รวม run ก่อนแก้ด้านล่าง) อยู่ใน JSONL ท้าย section

What we are NOT claiming. สิ่งที่เรา "ไม่" claim

• "5 minutes for any 50k repo" — build time depends on symbol density and file size; a denser codebase takes longer per file. We report both ends. "50k repo ไหนก็ 5 นาที" — เวลา build ขึ้นกับ symbol density และขนาดไฟล์ codebase ที่ dense กว่าก็ใช้เวลาต่อไฟล์นานกว่า เรารายงานทั้งสองปลาย
• A speed-up multiple as a feature — the 14→5 min change was fixing our own regression, not a new optimization. It belongs in the changelog, not on a banner. ตัวคูณความเร็วเป็น feature — การเปลี่ยน 14→5 นาทีคือการแก้ regression ของเราเอง ไม่ใช่ optimization ใหม่ มันควรอยู่ใน changelog ไม่ใช่บน banner

What we are NOT claiming. สิ่งที่เรา "ไม่" claim

• "5 minutes for any 50k repo" — build time depends on symbol density and file size; a denser codebase takes longer per file. We report both ends. "50k repo ไหนก็ 5 นาที" — เวลา build ขึ้นกับ symbol density และขนาดไฟล์ codebase ที่ dense กว่าก็ใช้เวลาต่อไฟล์นานกว่า เรารายงานทั้งสองปลาย
• A speed-up multiple as a feature — the 14→5 min change was fixing our own regression, not a new optimization. It belongs in the changelog, not on a banner. ตัวคูณความเร็วเป็น feature — การเปลี่ยน 14→5 นาทีคือการแก้ regression ของเราเอง ไม่ใช่ optimization ใหม่ มันควรอยู่ใน changelog ไม่ใช่บน banner

Does the rules block actually move the needle? rules block ช่วยให้ผลดีขึ้นจริงไหม?

We pre-registered a three-mode comparison — baseline (no Cosmos), mcp_only (Cosmos engine, no rules block in the prompt), and mcp_plus_rules (Cosmos engine + rules block prefixed). The 14-task moat-category subset (8 past_lesson + 6 apply_lesson) ran on a curated brain on 2026-05-07. Result does not clear the publication threshold; reported here as directional / internal evidence. N=14 is small. A 50-bug multi-repo regression suite is the next milestone — see section 03 below.

เรา pre-register การเปรียบเทียบ 3 mode — baseline (ไม่มี Cosmos), mcp_only (มี Cosmos engine แต่ไม่ใส่ rules block ใน prompt) และ mcp_plus_rules (Cosmos engine + rules block) ชุด moat-category 14 task (past_lesson 8 + apply_lesson 6) รันบน curated brain เมื่อ 2026-05-07 ผลลัพธ์ ยังไม่ผ่านเกณฑ์เผยแพร่ — รายงานในนี้ในฐานะ directional / หลักฐานภายใน N=14 ถือว่าน้อย milestone ถัดไปคือ regression suite 50 bug หลาย repo — ดู section 03 ด้านล่าง

The protocol calls this Tier 2 — directional / internal evidence. Both the CI gate and the exclusion-rate gate fail independently; either one alone would block a Tier 1 headline, and we hit both. Per section 9 of the protocol: we will not publish this as a "Cosmos cuts cost / improves correctness by X%" claim. We will instead say what's actually true: the rules block earns its weight when paired with curated lessons; on tasks that don't need recall it is overhead.

Protocol เรียกแบบนี้ว่า Tier 2 — directional / หลักฐานภายใน. ทั้ง CI gate และ exclusion-rate gate ไม่ผ่านแยกกัน — แต่ละอันลำพังก็พอจะ block headline ระดับ Tier 1 ได้แล้ว เราเจอทั้งคู่. ตาม section 9 ของ protocol: เราจะไม่เผยแพร่เป็น claim "Cosmos cut cost / improve correctness ได้ X%". เราจะพูดเฉพาะสิ่งที่จริง: rules block คุ้มที่จะใส่ เมื่อใช้กับ curated lessons — กับ task ที่ไม่ต้องการ recall มันคือภาระ

Where this directly applies: the snapshot test + integration test that caught the two newest bugs in Cosmos's own audit cycle. Both are documented as Project Lessons → /lessons.

ตัวอย่างที่ใช้จริง: snapshot test + integration test ที่จับ bug ใหม่ล่าสุด 2 ตัว ใน audit cycle ของ Cosmos เอง. ทั้งคู่ถูก document เป็น Project Lessons → /lessons

We ran a tighter pilot. The headline isn't what we hoped. เรารัน pilot ที่กระชับขึ้น. headline ไม่เป็นแบบที่หวัง

Added 10 internal past_lesson tasks to the Phase 3 task set and re-ran the 3-mode comparison (no Cosmos / Cosmos MCP / Cosmos MCP + rules block). Planned N=18; got N=8 after the sweep hit a 5-hour subscription quota cap mid-run. Stopped at the playbook's N=8 floor. Published with full disclosure.

เพิ่ม 10 internal past_lesson task เข้าใน Phase 3 task set แล้ว re-run การเปรียบเทียบ 3 mode (no Cosmos / Cosmos MCP / Cosmos MCP + rules block). วางแผน N=18 — ได้จริง N=8 หลังโดน 5-hour subscription quota cap กลางทาง. หยุดที่ floor N=8 ตาม playbook. เผยแพร่พร้อมรายงานครบ

Three task profiles tell the real story สาม task ที่เล่าเรื่องจริงได้ดีที่สุด

What this finding actually shapes ผลนี้ทำให้เราตัดสินใจอะไรบ้าง

• → Marketing copy was always going to avoid token-savings claims (decided pre-pilot). Pilot data confirms that pivot was right — we'd have been claiming something this run doesn't support. marketing copy ตั้งใจเลี่ยงการเคลม token-savings อยู่แล้ว (ตัดสินใจก่อนทำ pilot) ข้อมูลจาก pilot ยืนยันว่าตัดสินใจถูก — ไม่งั้นเราคงเคลมในสิ่งที่ผลรอบนี้ไม่ได้รองรับ
• → Regression-50 will measure task completion + correctness, not raw token cost. T-PL7 (baseline gives up) suggests "Cosmos finds answers baseline can't reach" is the real metric to chase. Regression-50 จะวัด task completion + correctness ไม่ใช่ raw token cost. T-PL7 (baseline ยอมแพ้) บอกว่า "Cosmos หาคำตอบที่ baseline เข้าไม่ถึง" คือ metric ที่ควรไล่
• → Rules block needs a refinement before scaling: "if no lesson hits in one MCP call, fall back to grep" — prevents T-PL5-style token blowup on broad queries. Rules block ต้อง refine ก่อน scale: "ถ้าใน 1 MCP call ไม่เจอ lesson ให้ fall back ไป grep" — ป้องกัน T-PL5-style token blowup จาก query แบบกว้าง
• → Sweep infrastructure for Regression-50 switches from the subscription path to direct Anthropic API — predictable per-run cost, no rolling-quota cap. Budget ~$70 sweep + ~$30 judges. Sweep infrastructure ของ Regression-50 เปลี่ยนจาก subscription path ไปเป็น direct Anthropic API — cost ต่อ run predict ได้ ไม่มี rolling-quota cap. Budget ~$70 sweep + ~$30 judges

Full pilot writeup, raw JSON / CSV, and task definitions live in the Cosmos repo — currently private during alpha; full data will be public when the repo opens alongside the public download. Pilot writeup ฉบับเต็ม, raw JSON / CSV, และนิยาม task อยู่ใน Cosmos repo — ตอนนี้ private ระหว่าง alpha; data ทั้งหมดจะเปิด public พร้อมตอน repo เปิดและ public download

"86% fewer tokens" — true, but only against the worst baseline. "ลด token 86%" — จริง แต่จริงเฉพาะเทียบ baseline ที่แย่ที่สุด

We ran the same questions entirely on a local model — Qwen3-8B (4-bit), on a MacBook Air M4 / 16 GB, nothing sent to the cloud — measuring how many context tokens the model needs to answer, and whether the answer stays correct (graded 0–4 by a blind claude CLI judge). A "86% fewer tokens" line is easy to print. So we tightened the baseline three times and report where the number holds — and where it shrinks.

เรารันคำถามชุดเดียวกันบน local model — Qwen3-8B (4-bit) บน MacBook Air M4 / 16 GB ไม่มีอะไรส่งขึ้นคลาวด์ — วัดว่าโมเดลต้องใช้ context token เท่าไรในการตอบ และคำตอบยังถูกไหม (ให้คะแนน 0–4 โดย judge claude CLI แบบปิดตา). คำว่า "ลด token 86%" พิมพ์ง่าย เราเลยรัดเกณฑ์ baseline เข้มขึ้น 3 รอบ แล้วรายงานว่าตัวเลขจริงตรงไหน และหดตรงไหน

Round 1 — vs a naive dump. รอบ 1 — เทียบกับ naive dump

Baseline = paste the whole file / a batch of notes into the prompt (an assistant with no retrieval). Cosmos = one tool call's compact result. baseline = แปะทั้งไฟล์ / โน้ตทั้งกองลงไปใน prompt (ผู้ช่วยที่ไม่มี retrieval) Cosmos = ผลลัพธ์กระชับจาก tool call เดียว

Caveat: a dump is the worst-case baseline — nobody pastes a 47k-token file by hand. The 86% is the value of any retrieval, not something unique to Cosmos. Two different models land at the same 86% because it's a ratio, not a model quirk. ข้อควรรู้: dump คือ baseline กรณีแย่ที่สุด — ไม่มีใครแปะไฟล์ 47k token ด้วยมือ ตัวเลข 86% คือคุณค่าของ retrieval แบบไหนก็ได้ ไม่ใช่อะไรที่เป็นของ Cosmos โดยเฉพาะ สอง model คนละตัวได้ 86% เท่ากันเพราะมันคืออัตราส่วน ไม่ใช่ลักษณะเฉพาะของ model

Round 2 — when the file is bigger than the context window. รอบ 2 — เมื่อไฟล์ใหญ่กว่า context window

Real source files here are 37–47k tokens — larger than the 16k window. Pasting them overflows: the no-retrieval model can't answer at all. Cosmos retrieves just the relevant function. ไฟล์ต้นฉบับจริงในชุดนี้มีขนาด 37–47k token — ใหญ่กว่า window 16k ถ้าแปะทั้งไฟล์ลงไปมันจะ overflow: model ที่ไม่มี retrieval ตอบไม่ได้เลย ส่วน Cosmos ดึงมาเฉพาะ function ที่เกี่ยวข้อง

Read this as: here Cosmos isn't "cheaper" — it's the only mode that can answer, because the content doesn't fit at all. This is the regime where retrieval is a requirement, not an optimisation. อ่านแบบนี้: ตรงนี้ Cosmos ไม่ได้ "ถูกกว่า" — แต่เป็น mode เดียว ที่ตอบได้ เพราะเนื้อหามันใหญ่เกินจะใส่เข้าไปได้เลย นี่คือกรณีที่ retrieval เป็นสิ่งจำเป็น ไม่ใช่แค่การ optimise

Round 3 — vs grep / BM25, the baseline you'd actually use. รอบ 3 — เทียบกับ grep / BM25, baseline ที่ใช้จริง

The honest comparison: ripgrep over the code, SQLite FTS5 BM25 over the notes — what a competent dev/AI does without Cosmos. Same questions, same corpus, blind-judged. การเปรียบเทียบแบบตรงไปตรงมา: ripgrep บน code, SQLite FTS5 BM25 บน notes — สิ่งที่ dev/AI เก่งๆ ทำเวลาไม่มี Cosmos คำถามชุดเดียวกัน corpus เดียวกัน ตัดสินแบบปิดตา

The honest headline: the 86% is vs a naive dump only. Against grep/BM25 — the baseline a real engineer uses — Cosmos is anywhere from roughly tied to ~23% leaner, depending on the task (on 2 of 5 tasks it used more). Cosmos comes out slightly ahead on accuracy overall (2.2 vs 1.8), driven by the code side. headline แบบตรงๆ: 86% นั้น เทียบกับ naive dump เท่านั้น ถ้าเทียบกับ grep/BM25 — baseline ที่ engineer จริงใช้ — Cosmos อยู่ระหว่าง สูสีกัน ถึงประหยัดกว่า ~23% ขึ้นกับ task (มี 2 จาก 5 task ที่ใช้ มากกว่า) โดยรวม Cosmos นำด้าน accuracy เล็กน้อย (2.2 vs 1.8) ซึ่งมาจากฝั่ง code

What we are NOT claiming. สิ่งที่เรา "ไม่" claim

• "Cosmos uses X% fewer tokens" as a bare headline — the big number is vs a dump; vs grep it's modest and task-dependent. "Cosmos ใช้ token น้อยลง X%" แบบ headline ลอยๆ — ตัวเลขใหญ่นั้นเทียบกับ dump; เทียบกับ grep มันเล็กน้อยและขึ้นกับ task
• "More accurate than search on note lookups" — against BM25 it's roughly even, not a clear win. "แม่นกว่า search ในงานหา notes" — เทียบกับ BM25 มันสูสีกัน ไม่ใช่ชนะขาด

What this round does support. สิ่งที่รอบนี้ยืนยันได้

• ✓ When content overflows the context window, retrieval is the only way the model answers — Cosmos does, a dump can't. เมื่อเนื้อหา overflow context window, retrieval เป็นทาง เดียว ที่ model ตอบได้ — Cosmos ทำได้ dump ทำไม่ได้
• ✓ For code, structured chunks beat raw grep lines for an LLM — and it's one call instead of a grep-then-read loop. สำหรับ code, chunk ที่มีโครงสร้างดีกว่าบรรทัด grep ดิบสำหรับ LLM — และเป็น call เดียว ไม่ต้องวน grep-แล้ว-read ซ้ำ

Method: 3-mode comparison on Qwen3-8B (4-bit, GGUF) + Gemma-4-e4b, MacBook Air M4 / 16 GB, fully local; accuracy graded 0–4 by a blind claude CLI judge against hand-written ground truth; code baseline = ripgrep, notes baseline = SQLite FTS5 BM25. Harness + raw per-task JSON live in the Cosmos repo — private during alpha. Method: เทียบ 3 mode บน Qwen3-8B (4-bit, GGUF) + Gemma-4-e4b, MacBook Air M4 / 16 GB, local ทั้งหมด; ให้คะแนน accuracy 0–4 โดย judge claude CLI แบบปิดตา เทียบกับ ground truth ที่เขียนมือ; code baseline = ripgrep, notes baseline = SQLite FTS5 BM25 harness + raw JSON รายตัวอยู่ใน Cosmos repo — private ระหว่าง alpha

Regression-50: replaying real bugs we didn't write. Regression-50: replay bug จริงที่เราไม่ได้เขียนเอง

Section 02's directional read came from 14 hand-crafted tasks on Cosmos's own brain — useful internally, not enough to publish. The next pass replays 50 real bugs from 5 open-source repositories the operator did not author (click, fastapi, astro, tauri, pydantic), three modes per bug, judged by the same five-condition statistical bar section 02 used. The harness is shipped; bug curation is in progress.

ผลเชิงทิศทางใน section 02 มาจาก 14 task ที่ทำมือบน brain ของ Cosmos เอง — มีประโยชน์ภายใน แต่ยังไม่พอจะ publish รอบถัดไปจะ replay bug จริง 50 ตัว จาก 5 open-source repo ที่ operator ไม่ได้เขียนเอง (click, fastapi, astro, tauri, pydantic), 3 mode ต่อ bug, ตัดสินด้วยเกณฑ์สถิติ 5 เงื่อนไขชุดเดียวกับ section 02 harness ปล่อยแล้ว ส่วนการคัด bug กำลังทำอยู่

Why publish "0 / 50" instead of waiting until the data lands? Because the apparatus matters: an outside reader can clone the repo, run python -m benchmarks.regression_50.runner --dry-run, see the full code path execute end-to-end with no API spend, and verify the harness exists before any number does. The commitment is the public commitment. Numbers replace this status grid as runs land.

ทำไมถึง publish "0 / 50" แทนที่จะรอให้ข้อมูลมาครบ? เพราะตัว apparatus มันสำคัญ: คนนอกโคลน repo มารัน python -m benchmarks.regression_50.runner --dry-run เห็น code path ทั้งเส้นทำงานจบ end-to-end โดยไม่เสียค่า API เลย แล้วยืนยันได้ว่า harness มีจริงก่อนตัวเลขจะมา commitment คือ public commitment ตัวเลขจะมาแทน status grid นี้เมื่อ run จริงเข้ามา

Source: benchmarks/regression_50/ in the repo. Pre-registration: benchmarks/regression_50/protocol.md. Same five-condition statistical bar as section 02; same paired- bootstrap CI method; same blinded two-judge scoring pattern.

Source: benchmarks/regression_50/ ใน repo Pre-registration: benchmarks/regression_50/protocol.md ใช้เกณฑ์สถิติ 5 เงื่อนไขชุดเดียวกับ section 02; วิธี paired-bootstrap CI เดียวกัน; รูปแบบ two-judge scoring แบบปิดตาเหมือนกัน

Things we will say, with caveats attached. สิ่งที่เราจะพูด พร้อม caveat แนบไว้

Things you'll see other tools say. We won't, until the data clears. สิ่งที่เครื่องมืออื่นพูด · เราจะไม่พูด จนกว่าข้อมูลจะผ่าน

The bar to graduate any of these into a published claim is in section 9.1 of the protocol: Bonferroni-corrected p < 0.0083 + paired bootstrap 95% CI strictly above zero + Cohen's |d_z| > 0.3 + exclusion rate < 10% + CI width less than the absolute effect. When a future run clears all five, the claim lands here. Until then, it stays in this list.

เกณฑ์ที่จะทำให้ข้อใดข้อหนึ่งเลื่อนขั้นเป็น claim ที่ publish ได้อยู่ใน section 9.1 ของ protocol: Bonferroni-corrected p < 0.0083 + paired bootstrap 95% CI อยู่เหนือศูนย์ทั้งหมด + Cohen's |d_z| > 0.3 + exclusion rate < 10% + ความกว้าง CI น้อยกว่า effect จริง เมื่อ run ในอนาคตผ่านครบทั้ง 5 ข้อ claim นั้นจะมาอยู่ตรงนี้ จนกว่าจะถึงตอนนั้น มันอยู่ใน list นี้

Run it yourself. รันการทดสอบด้วยตัวเอง

Engine performance (section 01) is free to re-run — no API calls. The three-mode comparison (section 02) needs a working Claude CLI on your machine, but no separate API key if you have a Claude.ai subscription. Hard cost cap is wired in the runner; default $15.

engine performance (section 01) รันซ้ำได้ฟรี — ไม่มี API call ส่วนการเทียบ 3 mode (section 02) ต้องมี Claude CLI ที่ใช้งานได้บนเครื่องคุณ แต่ไม่ต้องมี API key แยกถ้าคุณมี subscription Claude.ai อยู่แล้ว ตัว runner มี hard cost cap อยู่; default $15

# Source repo is private during alpha; download the .zip below or
# request access via the waitlist. CSVs + protocols above are
# already public, no clone needed for those.
cd cosmos
python3.12 -m venv .venv && source .venv/bin/activate
pip install -r requirements-tier0.txt

# section 01 — engine performance (free)
python -m benchmarks.tier_benchmark

# section 02 — three-mode comparison (uses your Claude.ai auth)
# Curated brain, moat-category subset:
python -m benchmarks.phase3_modes \
  --categories past_lesson,apply_lesson \
  --only-brain curated

# section 03 — Regression-50 harness, dry-run (free, exercises every code path)
python -m benchmarks.regression_50.runner --dry-run

# section 03 — Regression-50, single bug live (~$1.50, sanity-check before sweep)
python -m benchmarks.regression_50.runner --limit 1