Embedding tokens5M
Rerank tokens250k
Repositories2
API keys1
Service tierstandard
SLABest effort
Beta access to new featuresNo
Priority supportNo
MCP launch pricing for SHARC
with separate token buckets
Compare embedding and rerank quotas across Free, Starter, Pro, and Business plans.
Limited-time promotions are distributed separately via redeem codes.
Embedding tokens60M
Rerank tokens2M
Repositories10
API keys5
Service tierstandard
SLABest effort
Beta access to new featuresNo
Priority supportNo
Embedding tokens100M
Rerank tokens5M
Repositories40
API keys20
Service tierperformance
SLA99.9% uptime
Beta access to new featuresYes
Priority supportNo
Embedding tokens300M
Rerank tokens20M
RepositoriesUnlimited
API keys100
Service tierperformance
SLA99.9% uptime
Beta access to new featuresYes
Priority supportYes
FAQ
How usage maps to real codebase workflows
These estimates follow the current MCP indexing pipeline and are intended for planning, not billing precision. Provider-side tokenization can vary.
What are embedding tokens in SHARC?
Embedding tokens are used when SHARC turns your codebase chunks into vectors. The largest cost is the initial index.
Rule-of-thumb for planning: about 1 token per ~4 characters of source text.
What are rerank tokens and what affects them?
Rerank tokens are spent during search when reranking is enabled.
SHARC reranks up to min(limit * 3, 50) candidates per query, so larger limits and longer snippets increase rerank usage.
For example, limit=10 can rerank up to 30 candidates.
Why does maintenance cost stay low after first index?
SHARC persists Merkle snapshots (file-hash baselines) and compares hashes on subsequent index operations.
Unchanged files are skipped, and the active watcher applies incremental updates with hash checks instead of full re-indexing.
In normal workflows, ongoing token usage is mostly from changed files plus search traffic.
Do we need to re-index entire repos frequently?
Usually no. After initial indexing, updates are incremental (add/modify/delete per file).
A full re-index is mainly for explicit force operations or specific migration/troubleshooting scenarios.
What does standard vs performance tier mean?
The public model names remain the same: Sharc-Embedding and Sharc-Rerank.
Under the hood, service tier controls routing profile and latency characteristics.
Performance tiers are optimized for faster and more predictable search/index responsiveness.
How should developers estimate monthly usage?
Estimate initial embedding from total indexed text size first, then model ongoing usage from weekly code churn and search volume.
If your team changes 2-5% of a repo per week, maintenance embedding is typically a small fraction of the first index.
Rerank usage scales mostly with query count and search limit.
Approximate open-source repo examples
Approximate ranges assume standard ignore patterns and the current tiered chunking strategy. Initial indexing is one-time; maintenance usually tracks changed files only.
| Repository | Approximate size | Initial embedding tokens | Typical maintenance tokens |
|---|---|---|---|
| expressjs/express | 25k-40k LoC | ~0.2M-0.6M | ~10k-60k / month |
| fastapi/fastapi | 60k-100k LoC | ~0.6M-1.5M | ~30k-150k / month |
| vercel/next.js | 300k-500k LoC | ~3M-7M | ~150k-700k / month |
Maintenance assumes regular incremental development. Large refactors, dependency lockfile churn, or force re-index operations will increase usage.