T3 Code ships search rewrite with 4× accuracy after agent-driven testing

• T3 Code's search rewrite is “4x more accurate,” according to T3 Code developer theo's change list. The pull request reports first-result accuracy rising from 41/54 to 53/54 on its example queries.
• An 18-hour optimization loop used cloned databases, 50 synthetic examples and multiple models, as theo described in his testing thread.
• The rewrite initially shipped in nightly, with stable expected within one to two days, according to the rollout reply.

Search now remembers which thread you picked, and late message hits cannot shove thread results down the list. Its SQLite index even skips streaming deltas.

The optimization loop started with searches that failed against theo's own data. He described four steps:

1. Clone his real T3 Code databases.
2. Collect queries that did not return the desired results.
3. Synthesize 50 more examples based on his usage.
4. Hill-climb with Opus, Sol and Wonder Full until 53 of 54 cases passed.

The PR's evaluation used 584 threads and 15,800 messages, with an expected first result for each query:

• Main baseline: 41/54 correct first results, or 75.9%.
• Preceding search PR: 48/54, or 88.9%.
• This rewrite: 53/54, or 98.1%, 22.2 percentage points above main.
• Mean reciprocal rank: 0.80 → 0.99.
• Other matchers on the same set: uFuzzy scored 36/54; fzf and cmdk's command-score each scored 40/54.

Those are results on the workload used during iteration. The published evaluation does not identify a separate held-out query set or define a calculation behind the “4x” description.

The resulting PR changed 69 files and reports 16 rounds of review by three model reviewers. Cmd+K got quite the workout.

The shared scorer lives in packages/shared/src/paletteSearch.ts and adds no matcher dependency. It prefers matches in this order:

1. Whole words.
2. Word prefixes.
3. Joined words, such as vscode matching “VS Code.”
4. One-letter typos.
5. Matches inside words.

Thread scores then incorporate recent writing and opening activity, with a cap that prevents usage from beating a better word match. Ranking 584 threads reportedly takes 0.5–1.9 ms per keystroke.

Picking a result records the query through thread.visit. Each thread retains its last three picked queries and a decayed open count in roughly 100 bytes; a previously selected query promotes that thread among word matches for three weeks.

That state lives on the server and synchronizes across devices. Older servers ignore the added fields.

The announcement's demo shows the revised palette in action:

The rewrite separates results into two tiers:

• Threads: ranked locally on every keystroke.
• In messages: fetched from the server and always placed below thread results.

Existing rows retain their positions when another environment answers late, and the keyboard highlight stays attached to its row. A footer displays “Searching messages…” without changing the palette's height.

Rows explain matches with context such as a branch name or PR number. Rows that cannot explain their match are omitted, and subagent threads are excluded.

The same ranking reaches web, desktop, mobile and the MCP t3_thread_search tool. Selecting a message result opens web find at the matched message; mobile loads history through that message and scrolls to it, as described in the search documentation.

Migration 069 adds a contentless FTS5 trigram index with case and Latin-accent folding. A backfill indexes existing messages, and triggers maintain it afterward; SQLite builds without trigram support fall back to the previous scan.

The PR reports these measurements through the real search service:

• Original dataset: 3–27 ms per message search.
• Dataset with 20 times as many messages: 19–88 ms.
• Index storage: 21 MB for 7.6 MB of text.
• One-time backfill: 1.4 seconds for 15,800 messages.

Candidate retrieval stops at the newest 10,000 index hits. The shared word rules then rank adjacent query words ahead of nearby words, followed by words farther apart; snippets begin where the matching words meet.

The PR merged on October 24. At announcement, theo said the feature was nightly-only:

The release list shows October 24 nightly builds alongside stable v0.1.2. The stated one-to-two-day stable timeline was a plan, rather than confirmation of a stable release.

Before the announcement, theo asked Grok what users disliked about T3 Code. He subsequently committed to shipping one meaningful improvement every day, identifying search as that day's improvement.

The PR's follow-up list records several remaining failures:

• cant does not find “Can't.”
• vscoed does not find “VS Code.”
• Two-letter words cannot search messages on their own.
• An exact match for a misspelled query can suppress the typo pass, leaving correctly spelled alternatives missing.
• A phrase spanning code formatting or paragraph boundaries can appear in a collapsed snippet but produce no results when opened in find.

Mobile navigation was exercised on an Android 15 emulator. iOS coverage consisted of unit tests and typechecking.