Canonical: https://dotnetpower.github.io/code-context/faq/

# Frequently Asked Questions (FAQ)

 

**What should I know before using Code Context?**:  Code Context FAQ: ripgrep and vector RAG comparisons, native VS Code tools versus MCP, Windows support, privacy, and benchmark limitations.

 

**Scope and evidence**:  Local developer tooling, not a hosted source-search service. Benchmark results are workload-specific, not guarantees.

 

Where can I verify the results and limitations?

 

Read the [benchmark methodology](https://dotnetpower.github.io/code-context/benchmarks/), [architecture and privacy boundaries](https://dotnetpower.github.io/code-context/architecture/), and [technical FAQ](https://dotnetpower.github.io/code-context/faq/).

 

## How is Code Context (`cctx`) different from `ripgrep` (`rg`)?

[Section titled “How is Code Context (cctx) different from ripgrep (rg)?”](https://dotnetpower.github.io/code-context/faq/#how-is-code-context-cctx-different-from-ripgrep-rg)

 

`ripgrep` is a fast stateless CLI scanner—Code Context actually uses `rg` during initial authorized workspace discovery. However, in multi-turn coding agents, raw `rg` forces a costly two-step loop (`rg` match lines → multiple 100–200 line `view` calls) and re-scans files on every turn.

 

`cctx` keeps a warm in-memory trigram index (`17.22×` faster mixed retrieval) and returns AST block-clamped definitions in one call (`#cctxNativeContext` / `code_context`), cutting lookup payload tokens by 73.2% to 91.3% and agent round-trip tool calls by 61.9%.

  

## How does `cctx` compare to vector embeddings / semantic RAG?

[Section titled “How does cctx compare to vector embeddings / semantic RAG?”](https://dotnetpower.github.io/code-context/faq/#how-does-cctx-compare-to-vector-embeddings--semantic-rag)

 

Vector RAG requires chunking, embedding models (often cloud APIs or heavy local GPUs), approximate nearest-neighbor indexes that lag behind rapid branch switches, and fuzzy similarity matches that frequently miss exact symbol names, error codes, or regex patterns.

 

`cctx` is 100% deterministic, exact, local, and SHA-256 verified: zero API keys, zero GPU overhead, sub-millisecond warm queries, and instant incremental updates on file save.

  

## Do I need MCP if I install the VS Code extension?

[Section titled “Do I need MCP if I install the VS Code extension?”](https://dotnetpower.github.io/code-context/faq/#do-i-need-mcp-if-i-install-the-vs-code-extension)

 

For foreground VS Code Copilot sessions (VS Code 1.140+), no MCP configuration is required—the Marketplace extension (`dotnetpower.code-context-native`) registers native Language Model Tools directly.

 

Adding `cctx shared-mcp` is recommended when you also run background/unattended subagents without UI extension-host dispatch, or external MCP clients such as Claude Code, Cursor, or custom CLI agents. Both surfaces share the exact same background Rust daemon and warm cache.

  

## Does `cctx` upload my code or telemetry anywhere?

[Section titled “Does cctx upload my code or telemetry anywhere?”](https://dotnetpower.github.io/code-context/faq/#does-cctx-upload-my-code-or-telemetry-anywhere)

 

Indexing, trigram postings, document extraction, `cctx journal`, and `cctx usage` analytics run locally; the index is not automatically uploaded. Explicit `pctx http` probes contact the URLs you supply. Any AI client receiving tool output follows its own data policy. This public documentation website cannot access your local workspace.

  

## Why does `code_read` show `0.43×` (slower) on small known-file reads in the benchmark?

[Section titled “Why does code_read show 0.43× (slower) on small known-file reads in the benchmark?”](https://dotnetpower.github.io/code-context/faq/#why-does-code_read-show-043-slower-on-small-known-file-reads-in-the-benchmark)

 

Because direct in-process buffered reads of a tiny file already in the OS page cache take ~`0.081 ms`, whereas sending a request over a Unix socket / loopback RPC with policy validation, SHA-256 verification, and JSON serialization takes ~`0.190 ms`. We keep small known reads in the benchmark suite deliberately so our reported `17.22×` mixed speedup reflects realistic agent workloads rather than cherry-picked search-only numbers.

  

## What happens when `cctx` returns `CACHE_MISS`?

[Section titled “What happens when cctx returns CACHE_MISS?”](https://dotnetpower.github.io/code-context/faq/#what-happens-when-cctx-returns-cache_miss)

 

`CACHE_MISS` means the workspace root was cold and has just been queued for bounded background indexing—never that the symbol or file is absent. The agent performs a single normal host read/search for that immediate turn without waiting, and automatically gets warm `0.23 ms` hits on subsequent turns.

  

## Does `cctx` run natively on Windows without WSL?

[Section titled “Does cctx run natively on Windows without WSL?”](https://dotnetpower.github.io/code-context/faq/#does-cctx-run-natively-on-windows-without-wsl)

 

Yes. Build `cctx.exe` with `cargo build --locked --release` and place it at `%USERPROFILE%\.local\bin\cctx.exe`. The VS Code extension starts `cctx.exe daemon` automatically on demand and uses `rg` on `PATH` or VS Code’s bundled `rg.exe`. WSL2 and Windows Agent Sessions are also fully supported—see [Installation & Platform Setup](https://dotnetpower.github.io/code-context/installation/).

  

## How does `cctx` relate to `agent-tokenomics` and `tokprof`?

[Section titled “How does cctx relate to agent-tokenomics and tokprof?”](https://dotnetpower.github.io/code-context/faq/#how-does-cctx-relate-to-agent-tokenomics-and-tokprof)

 

[`agent-tokenomics`](https://dotnetpower.github.io/agent-tokenomics/) is our companion engineering playbook and zero-code LLM request profiler (`tokprof`). Use `cctx` inside your IDE and MCP clients to cut lookup tokens, clamp context, and accelerate coding tasks; use `tokprof` when building or operating custom agents to attribute every input token across system prompts, tool schemas, and conversation history.

## Sources and limitations

Measurements are from the repository's published benchmark fixtures, not a performance or billing guarantee. Hardware, workload, cache state and model pricing change results. This documentation site cannot search or read a visitor's local source code. Indexing is local; explicitly requested HTTP probes contact their supplied URLs.