sweet-index

name	sweet-index
description	Use when (re)indexing a Sweet Search project. Runs the full-profile indexer with GPU model prewarming (CoreML cascade on M3+, candle Metal on M1/M2, ORT CPU elsewhere), kills ORT CPU models during indexing to avoid memory contention, and rewarms them for query readiness on completion. Incremental runs under 20 files stay on ORT CPU.
category	developer-tooling
priority	high
tokenEstimate	600
agents	[]
implementation_status	active
optimization_version	1
last_optimized	"2026-04-17T00:00:00.000Z"
dependencies	["sweet-search"]
quick_reference_card	true
tags	["indexing","embeddings","late-interaction","gpu","coreml","metal","ort","prewarming","sweet-search"]
trust_tier	1

/sweet-index — Index the Codebase

<default_to_action> When the user invokes /sweet-index, run the full-profile indexing command immediately. Do not ask clarifying questions — the indexer is idempotent, safe to re-run, and handles incremental vs full reindex automatically. </default_to_action>

What this does

Runs core/indexing/index-codebase-v21.js with the --full flag so every artifact is rebuilt from scratch. The indexer itself manages the model lifecycle end-to-end:

1. Kill resident ORT CPU models — prevents memory contention and mutex fighting with the GPU models about to be loaded.
2. Detect best backend via hardware-capability.js — coreml-cascade on M3+ Apple Silicon, candle-metal on M1/M2, candle-cuda on Linux + NVIDIA, and the optimized ORT INT8 CPU path on any host with no usable accelerator (no GPU models are loaded there).
3. Load GPU models + warmup forward pass (accelerator hosts only) — compiles Metal pipelines, CoreML variant bundles, and BLAS thread pools so the first indexing batch pays no cold-start cost.
4. Index the codebase — code graph, vector embeddings, HNSW, late-interaction index, quantized artifacts, sparse-gram index.
5. Kill GPU models — releases Metal queues and Neural Engine.
6. Load + warmup ORT CPU models — both embedding and LI get one dummy forward pass so the first query after indexing is warm.

On small-changeset incremental runs (under 20 files) — and on any host with no usable accelerator — the indexer skips the GPU swap entirely and indexes on the optimized ORT INT8 CPU path.

Usage

node core/indexing/index-codebase-v21.js --full

Or via npm script:

npm run index:full

What to report

After the command completes, pick out these lines from stderr:

• GPU index pool armed (<backend>) → confirms which backend was used
• embed=<load>+<warm>ms, li=<load>+<warm>ms → prewarm timings
• CPU models warmed for queries: load=…ms, warm=…ms (embed=ok, li=ok) → confirms ORT CPU is armed for subsequent searches
• INDEXING COMPLETE (FULL) with Duration, Files indexed, Entities, Relationships → headline stats

Flags (full list)

Flag	Purpose
--full	Full reindex — rebuild everything. Always armed via this skill.
--no-late-interaction	Skip LI index (faster, lower quality). Rarely wanted.
--late-interaction-pool=N	Token pooling factor (2 halves tokens).
--vectors-only	Skip code graph — breaks GraphRAG. Avoid.
--graph-only	Only build code graph, skip vectors.
--verbose / -v	Force per-phase progress output.

Do not pass --sqlite-fast — it disables fsync between phases and is only safe for benchmarking on throwaway state.

When not to use

• Single-file edits: the indexer auto-detects small changesets and stays on CPU, so /sweet-index is still safe, but a watcher-triggered incremental run is cheaper.
• Queries feel slow: usually means the ORT CPU models are not loaded. Run /sweet-index once to rewarm them, or restart the sweet-search server.