Ternlight Brings 7 MB Browser-Native Embeddings: 6 Private Search Workflows Builders Can Ship Now

Ternlight changes a basic assumption behind semantic search: embeddings no longer have to be a server-side API call. At 7 MB, the model can run fully inside the browser through WASM, which means a web app can embed user text locally, search locally, and keep sensitive documents off your infrastructure. For builders shipping search-heavy UX, internal knowledge tools, note apps, support portals, or local-first document products, that is a meaningful architectural shift.

The market cares because embedding workloads are usually high-volume and low-margin. A chatbot might answer one question with one model call, but a search product may embed every note, ticket, paragraph, message, and query. Hosted embedding APIs are still the right choice for large indexes, multilingual quality targets, centralized analytics, and enterprise retrieval pipelines. But for small and medium document sets, Ternlight’s browser-native approach removes server inference round trips, reduces marginal search cost toward zero, improves perceived latency, and avoids sending private internal docs to a third-party embedding endpoint.

This post breaks down what Ternlight makes possible right now: private semantic search, client-side RAG for small document sets, support search, note clustering, duplicate detection, and offline/local-first AI UX. We’ll cover concrete workflows, copyable implementation outlines, recommended stacks, model choice, cost comparisons against hosted embedding workflows, and the limits that should keep you on server-side APIs.

---

What changed: embeddings moved into the browser

Embedding models turn text into vectors so software can compare meaning instead of only matching keywords. That powers semantic search, clustering, deduplication, RAG retrieval, recommendation, and “find related” features. Historically, production apps handled this with a hosted embedding API, a server job, and a vector database.

Ternlight compresses that loop into the client. The model is small enough to download as part of a web app or lazy-load when the user opens a search feature. WASM execution means it can run across modern browsers without requiring GPU access, a native app install, or a server inference endpoint.

The important change is not just cost. It is product design. When embeddings are local, you can build features that feel immediate and private:

Capability	Hosted embedding flow	Ternlight browser-native flow
Query embedding	Browser → server/API → browser	Browser only
Private docs	Sent to app backend or embedding API	Stay on device
Offline use	Not available without server	Available after model load
Marginal embedding cost	Scales with tokens	Near-zero after download
Latency	Network + queue + inference	Local inference
Best fit	Large centralized indexes	Small/private/local indexes

The architecture also changes compliance conversations. If an app indexes a user’s HR notes, legal drafts, medical research, sales call notes, or support exports entirely in the browser, the vendor does not need to store or process that text for embeddings. That is a simpler privacy story than “we send your documents to a third-party API and store vectors in our cloud.”

[stat] 7 MB
Ternlight is small enough to ship as a browser-loaded embedding model instead of a backend inference dependency.

---

Six practical workflows Ternlight unlocks now

Browser-native embeddings are most valuable when the data set is personal, sensitive, or small enough to fit inside the client. Here are six workflows builders can ship immediately.

1. Private semantic search for internal documents

A user drops in PDFs, Markdown files, policy docs, customer notes, or meeting transcripts. The browser chunks them, creates embeddings locally, stores vectors in IndexedDB, and returns semantic matches without sending the content to a server.

This is ideal for internal tools where privacy friction blocks adoption. Examples include legal clause search, HR policy lookup, board memo search, field notes, medical education notes, and enterprise “bring your own docs” apps.

Recommended stack:

Layer	Recommendation
Embedding	Ternlight in WASM
Chunking	300-800 token chunks with overlap
Storage	IndexedDB or OPFS
Vector search	hnswlib-wasm, voy-search, or custom cosine search for small sets
UI	React/Vue/Svelte search panel with highlighted snippets
Optional answer generation	GPT-5 mini, Gemini 2.5 Flash, or Claude Haiku 4.5

The key is to separate retrieval from generation. Ternlight handles local retrieval. If the user wants an answer, send only the top 3-8 snippets to an LLM, not the entire document collection.

2. Client-side RAG for small document sets

For small document sets, RAG does not need a hosted vector database. A browser app can create a local vector index, retrieve relevant chunks, then call a hosted LLM only for the final answer. This reduces both embedding cost and privacy exposure.

A strong pattern is “local retrieval, hosted synthesis.” The documents stay local during indexing. The app sends only the relevant passages to the language model. For sensitive documents, you can add a setting that forces answer generation to be extractive only, or requires the user to approve snippets before sending them.

Best use cases:

• Personal knowledge base Q&A
• Research paper assistants for a folder of PDFs
• Contract review over a limited deal room
• Support answer drafts from a local help center export
• Field technician manuals on a tablet
• Offline-first onboarding docs

Hosted RAG still wins for millions of chunks, team-wide indexes, permission-aware enterprise search, and continuously updated corpora. But for a user’s own 50-2,000 documents, browser-native retrieval is now a practical default.

3. Support search inside a help center or ticket export

Support teams often need semantic search over a narrow corpus: help articles, resolved tickets, macros, release notes, and troubleshooting guides. A hosted vector index works, but it creates operational overhead and recurring embedding costs.

With Ternlight, a support web app can ship a compressed index or build one locally from cached articles. Agents can search “customer can’t reset authenticator after phone change” and retrieve relevant help articles even if the exact keywords do not match.

Two variants are useful:

Variant	Best for	How it works
Prebuilt static vectors	Public help centers	Build vectors at deploy time and download index
Fully local vectors	Private ticket exports	Embed the user’s export in browser

The fully local version is especially valuable for teams that do not want private ticket text processed by another service. A customer success manager can import a CSV of prior cases, search semantically, and find similar resolutions without uploading the file.

4. Note clustering and auto-organization

Embeddings are not only for search. They are useful for clustering related text. A notes app can use Ternlight to group messy notes into themes, detect project areas, suggest folders, and show “related notes” without a server.

This is the workflow where browser-native embeddings create a noticeably better product experience. The user can drag in 1,000 notes, the app clusters locally, and the UI updates progressively. No account required. No upload step. No “processing on our servers” disclosure.

Useful features:

• “Related notes” sidebar
• Auto-tag suggestions
• Project clustering
• Meeting note grouping
• Research theme extraction
• Personal CRM contact grouping

For clustering, embeddings should be combined with lightweight algorithms such as k-means, HDBSCAN-style approximations, or nearest-neighbor graph grouping. Ternlight supplies the semantic representation; your app supplies the organization layer.

5. Duplicate and near-duplicate detection

Duplicate detection is a high-volume embedding task that becomes expensive if every item goes through an API. Ternlight makes it cheap to compare local text at scale.

Examples:

• Find duplicate CRM notes before import
• Merge similar support tickets
• Detect repeated knowledge base articles
• Identify overlapping research excerpts
• Clean up pasted meeting notes
• Flag repeated product feedback

The workflow is simple: embed each item locally, compare cosine similarity, then present pairs above a threshold. Exact duplicates can be handled with hashing, while near-duplicates need embeddings. This is a good fit for browser-native processing because the data is often imported by a single user and does not need to leave the device.

6. Offline and local-first AI UX

The most underrated benefit is offline UX. If the model and local index are cached, search can work on a train, in the field, at a customer site, or in a locked-down corporate environment.

This enables a class of AI-adjacent features that do not feel like “AI chat”:

• Search manuals offline
• Find related incident reports in a local app
• Organize field notes before syncing
• Search personal documents without an account
• Provide semantic autocomplete in a browser extension
• Build privacy-first Chrome extensions for Gmail, Notion exports, or local files

Offline-first AI UX is not about replacing frontier models. It is about moving the cheap, repetitive semantic layer closer to the user.

---

Workflow outline 1: private browser semantic search

This workflow is the highest-confidence starting point for builders. It gives users semantic search over local files without uploading content.

Step 1: Load Ternlight lazily

Do not load the model on the first page view. Load it when the user opens the search workspace, imports files, or enables semantic search. A 7 MB model is small, but lazy loading keeps the main app fast.

Implementation guidance:

1. Add a “semantic search” feature gate or import flow.
2. Download the WASM bundle and model file on demand.
3. Cache the model using the browser cache or service worker.
4. Show progress for first-time setup.
5. Reuse the loaded model for all later embeddings.

Step 2: Parse and chunk documents locally

Keep chunking deterministic. For plain text and Markdown, split by headings and paragraphs. For PDFs, extract text client-side when possible. Use chunks of 300-800 tokens with 50-100 tokens of overlap.

Chunk metadata should include:

Field	Purpose
docId	Rebuild or delete all chunks from one document
chunkId	Stable reference
title	Better search result display
text	Passage used for preview and optional LLM context
sourceOffset	Highlight match in original document
embedding	Vector produced by Ternlight
createdAt	Cache invalidation and reindexing

Step 3: Embed in a Web Worker

Embedding can block the UI if you run it on the main thread. Use a Web Worker for parsing, chunking, and embedding. Send progress events back to the UI after every batch.

Recommended batching:

• 10-50 chunks per batch for responsive UI
• Pause/resume support for large imports
• Store partial results immediately
• Re-embed only changed chunks

Step 4: Store vectors locally

For small data sets, IndexedDB is enough. For larger browser workloads, OPFS can be cleaner for binary vector files. A simple cosine similarity scan works well for hundreds or a few thousand chunks. Move to approximate nearest neighbor search when the index grows.

Practical threshold:

Chunk count	Search method
Under 5,000	Brute-force cosine search
5,000-100,000	Browser ANN index
100,000+	Hosted vector database

Step 5: Embed the query and rank results

When the user searches, embed the query locally and compare against stored vectors. Rank by similarity, then show the top results with title, snippet, and source location.

For better UX, combine semantic search with keyword filters:

• Document type
• Date range
• Folder/project
• Author
• Tag
• Exact keyword boost

Step 6: Optional answer generation

If the user clicks “summarize answer,” send the top snippets to a hosted LLM. Use a low-cost model for most answers. GPT-5 mini costs $0.25 per 1M input tokens and $2 per 1M output tokens, while Gemini 2.5 Flash costs $0.30 per 1M input tokens and $2.50 per 1M output tokens.

Use a prompt like:

Answer using only the provided snippets. Cite snippet IDs. If the answer is not supported, say "I don't know from these documents."

Question:
{{user_query}}

Snippets:
{{top_snippets}}

---

Workflow outline 2: local duplicate detection for imported records

Duplicate detection is a perfect browser-native embedding use case because it is bursty, local, and search-heavy. A user imports records, your app finds near-duplicates, then the data can be cleaned before it ever reaches your backend.

Step 1: Normalize each record

Create a text representation that includes the fields that matter. For CRM notes, combine company, contact, title, note body, and date. For support tickets, combine subject, issue summary, resolution, product area, and tags.

Example record text:

Subject: Password reset fails after MFA phone change
Product: Admin Console
Summary: User replaced phone and cannot receive authenticator prompts.
Resolution: Admin must reset MFA enrollment from security settings.

Step 2: Embed all records in browser

Use Ternlight to embed each normalized record. Show progress and allow cancellation. Store vectors temporarily if the user is only cleaning an import, or persist them if duplicate detection is a recurring feature.

Step 3: Compare candidates efficiently

For small imports under 5,000 records, pairwise comparison may be acceptable if optimized. For larger imports, use nearest-neighbor search and compare each item only to its top candidates.

Similarity thresholds should be explicit:

Similarity band	Suggested UI action
0.95+	Likely duplicate
0.85-0.95	Possible duplicate
0.75-0.85	Related, not duplicate
Under 0.75	Ignore

Tune these thresholds with real user data. Support tickets often have similar language, so they may need higher thresholds. Personal notes may need lower thresholds.

Step 4: Present merge decisions

Never auto-merge semantic duplicates without review. Show side-by-side cards with highlighted overlapping meaning, not only raw similarity scores.

Useful merge options:

• Keep left
• Keep right
• Merge fields
• Mark not duplicate
• Always ignore this pair
• Export cleaned CSV

Step 5: Optional server sync

After cleaning, upload only the final records. The app can discard local embeddings or keep them in IndexedDB for future imports.

This workflow reduces backend cost, reduces data exposure, and improves onboarding. Users see value before creating an account or syncing private data.

---

Model Choice and Cost

Ternlight changes the economics of embeddings because the marginal cost of local inference is not priced per token. You still pay in engineering time, browser CPU, battery, and first-load bandwidth, but you avoid recurring embedding API fees for local indexing and repeated query embedding.

Hosted embedding pricing in the available model catalog includes Gemini Embedding 2 at $0.20 per 1M input tokens. That is already inexpensive, but search-heavy workflows multiply quickly. If an app indexes 100M tokens per month, hosted embedding alone costs $20/month before vector database, backend jobs, retries, storage, and network overhead. At 1B tokens per month, embedding API cost is $200/month. For a consumer note app or browser extension, that may exceed revenue if users search frequently and do not pay much.

The larger savings come from repeated actions. Query embeddings are small, but they happen constantly. Reindexing is larger and often repeated during imports, edits, syncs, and retries.

Cost examples for common embedding workflows

The table below compares hosted embedding API cost using Gemini Embedding 2 pricing at $0.20 per 1M tokens against Ternlight’s local embedding cost. Ternlight still has client compute cost, but no per-token API charge.

Workflow	Monthly embedding volume	Hosted embedding API cost	Ternlight API cost	Best default
Personal notes app, 10k users	50M tokens	$10	$0	Ternlight
Support import cleanup	200M tokens	$40	$0	Ternlight
SMB document search	1B tokens	$200	$0	Ternlight or hybrid
Enterprise knowledge base	20B tokens	$4,000	$0 embedding API, but client impractical	Hosted
Public web-scale search	100B tokens	$20,000	Not appropriate	Hosted

The raw API price is only part of the bill. Hosted workflows also need backend queues, vector storage, auth, observability, and deletion workflows. For a centralized enterprise index, that infrastructure is necessary. For a browser-local personal index, it is avoidable complexity.

If you need answer generation, embeddings are only one layer

Ternlight does not replace LLM reasoning. If your workflow retrieves local snippets and then generates an answer, the LLM call still costs money.

Here is a practical answer-generation estimate. Assume each answer sends 6,000 input tokens of retrieved snippets and produces 800 output tokens.

Model	Input/output pricing	Estimated cost per answer	Cost per 1,000 answers
GPT-5 nano	$0.05 / $0.40 per 1M	$0.00062	$0.62
GPT-5 mini	$0.25 / $2 per 1M	$0.0031	$3.10
Gemini 2.5 Flash	$0.30 / $2.50 per 1M	$0.0038	$3.80
Claude Haiku 4.5	$1 / $5 per 1M	$0.0100	$10.00
GPT-5	$1.25 / $10 per 1M	$0.0155	$15.50
Claude Sonnet 5	$2 / $10 per 1M	$0.0200	$20.00

For most local RAG products, GPT-5 mini or Gemini 2.5 Flash is the right synthesis tier. Use GPT-5 or Claude Sonnet 5 when answers require stronger reasoning, better instruction following, or higher trust. Use GPT-5 nano for cheap extractive summaries, title generation, and classification.

Cheaper fallback options

If Ternlight is not a fit, the cheapest hosted fallback in the provided pricing set is Gemini Embedding 2 at $0.20 per 1M tokens. For generation fallback, use:

Need	Recommended model	Why
Cheapest extraction	GPT-5 nano	$0.05/$0.40 per 1M tokens
Low-cost RAG answers	GPT-5 mini	Good balance at $0.25/$2
Fast multimodal/general answers	Gemini 2.5 Flash	$0.30/$2.50, large context
Higher-quality synthesis	GPT-5	Better reasoning at $1.25/$10
Premium writing/reasoning	Claude Sonnet 5	Strong answer quality at $2/$10

You can compare model pricing directly with AI Cost Check, or review model-level pages such as Gemini Embedding 2, GPT-5 mini, and Claude Sonnet 5.

---

When browser-native embeddings beat hosted APIs

Ternlight is the better choice when the workflow is local, private, repetitive, and bounded. The clearest wins are products where users bring their own data and expect immediate utility.

Use Ternlight when:

1. Documents are sensitive. HR notes, legal drafts, private support tickets, medical education notes, and board materials should not be uploaded just to make search work.
2. The index is user-specific. Personal notes, browser extensions, local files, and per-user workspaces do not always need a shared server index.
3. The corpus is small or medium. Browser retrieval works well for thousands to tens of thousands of chunks.
4. Search happens frequently. Repeated query embeddings become effectively free after the model loads.
5. Offline matters. Field tools, travel workflows, and local-first apps benefit from cached models and indexes.
6. Onboarding must be instant. Users can import files and see semantic results before creating a cloud account.
7. You want fewer infrastructure dependencies. No embedding job queue, no vector DB for small indexes, no API retry logic for embeddings.

The product advantage is strongest when privacy is part of the value proposition. “Your documents never leave your browser” is easier to understand than a multi-paragraph subprocessors explanation.

When hosted embedding APIs still win

Browser-native embeddings do not eliminate hosted embeddings. They change where the cutoff is.

Use hosted APIs when:

Requirement	Why hosted wins
Millions of documents	Browser indexing becomes slow and memory-heavy
Shared team search	Centralized indexes and permissions are required
Cross-device sync	Server-side vectors avoid reindexing on every device
Strict quality benchmarking	Hosted embedding models may offer higher retrieval quality
Multilingual enterprise search	Larger models often perform better
Real-time updates from many users	Server pipelines handle concurrency
Analytics and monitoring	Centralized retrieval logs are easier to inspect
Hybrid keyword/vector ranking	Search backends integrate ranking, filters, and facets

Hosted embeddings also win when the user does not already have the data in the browser. If documents live in S3, Google Drive, SharePoint, or a warehouse, moving everything to the browser for indexing is inefficient. Process the corpus near the data and deliver search results through an authenticated API.

---

Recommended architecture patterns

Ternlight gives builders a new design space, but the right architecture depends on the product.

Pattern 1: fully local semantic search

Use this for personal apps, privacy-first tools, browser extensions, and offline search.

Architecture:

1. User imports files.
2. Browser chunks text.
3. Ternlight embeds chunks in a Web Worker.
4. Vectors are stored in IndexedDB or OPFS.
5. Query embeddings and vector search run locally.
6. Results are displayed without server calls.

Best for: notes, PDFs, local docs, imported CSVs, research collections.

Pattern 2: local retrieval plus hosted answer generation

Use this for local RAG where users want answers, not only search results.

Architecture:

1. Browser creates local index with Ternlight.
2. Query runs locally.
3. User reviews top snippets.
4. App sends selected snippets to a hosted LLM.
5. LLM returns answer with citations.

Best for: document Q&A, support assistants, contract review, research summarization.

Recommended generation stack: GPT-5 mini for default answers, Gemini 2.5 Flash for low-cost long-context tasks, Claude Sonnet 5 for premium synthesis.

Pattern 3: hybrid local and server search

Use this when users have both private local data and shared company data.

Architecture:

1. Private user docs are embedded locally with Ternlight.
2. Shared docs are embedded server-side.
3. Query runs against both indexes.
4. Results are merged client-side.
5. Answer generation cites both local and shared sources.

Best for: enterprise copilots, sales enablement, support ops, internal tools.

This pattern lets teams keep private drafts local while still retrieving approved company knowledge from a central index.

Pattern 4: precomputed vectors plus local query embedding

For public static corpora, you can precompute document vectors during build or deploy, ship a compact index to the browser, and use Ternlight only for query embeddings.

Best for:

• Documentation sites
• API reference search
• Static help centers
• Offline docs
• Developer tools

This avoids client-side indexing time while keeping query search local and fast.

---

Risks, limits, and product decisions

Ternlight’s small size is its superpower, but small embedding models come with tradeoffs. Builders should treat it as a product component, not a magic retrieval layer.

Retrieval quality

A 7 MB model may not match larger hosted embedding models on nuanced semantic retrieval, multilingual search, domain-specific jargon, or long technical passages. Evaluate with your actual queries before replacing a hosted pipeline.

A practical test set should include:

• 50 common queries
• 20 hard queries
• 20 ambiguous queries
• 20 no-answer queries
• Relevance labels for top 5 results
• Separate tests for keyword, semantic, and hybrid ranking

If Ternlight gets users to the right result in the top 3, it is good enough for most private search UX.

Browser performance

Local inference uses user CPU and battery. Use Web Workers, progress indicators, pause controls, and incremental indexing. Avoid embedding thousands of chunks synchronously on page load.

Recommended product defaults:

Decision	Recommendation
First model load	Lazy-load after user intent
Indexing	Run in worker
Large imports	Ask for confirmation above threshold
Mobile	Default to smaller batches
Battery saver	Pause background indexing
Storage	Let users clear local index

Security and privacy

Browser-local processing improves privacy, but it does not automatically make the app secure. If you later send snippets to an LLM, log search queries, sync local indexes, or upload documents for backup, users need clear controls.

Make privacy visible:

• “Indexed locally”
• “Never uploaded”
• “Send selected snippets to AI”
• “Clear local index”
• “Export/delete data”
• “Disable cloud answer generation”

Index portability

Local indexes are tied to a browser and device unless you sync them. For local-first products, that is acceptable. For team tools, users expect cross-device continuity. Decide early whether local indexes are disposable cache, user-owned data, or synced application state.

---

Builder checklist: should you use Ternlight?

Use this decision matrix before changing your architecture.

Question	If yes	Recommendation
Does the user already have the text in the browser?	Yes	Use Ternlight
Is the corpus under 100,000 chunks?	Yes	Use local or hybrid search
Is privacy a selling point?	Yes	Use Ternlight
Do users need offline search?	Yes	Use Ternlight
Is this a shared company-wide index?	Yes	Use hosted embeddings
Do you need best-in-class multilingual retrieval?	Yes	Benchmark hosted APIs
Do you need centralized analytics and permissions?	Yes	Use hosted or hybrid
Is answer generation required?	Yes	Pair Ternlight with a low-cost LLM

The strongest near-term products are not “chatbots in the browser.” They are search, organization, cleanup, and retrieval tools that become faster and more private because embeddings moved client-side.

---

Frequently asked questions

What is Ternlight?

Ternlight is a 7 MB embedding model designed to run fully in the browser via WASM. It lets web apps create text embeddings locally for semantic search, clustering, duplicate detection, and small-scale RAG without sending text to a hosted embedding API.

How much does browser-native embedding cost?

Ternlight has $0 per-token API cost because embedding runs locally in the user’s browser. A hosted alternative such as Gemini Embedding 2 costs $0.20 per 1M tokens, so the hosted cost is $200 per 1B embedded tokens before storage and infrastructure.

When should I use Ternlight instead of a hosted embedding API?

Use Ternlight for private documents, personal notes, browser extensions, local imports, offline search, and small-to-medium indexes. Use hosted embeddings for millions of documents, shared team search, centralized permissions, cross-device sync, and high-quality multilingual retrieval.

Can Ternlight replace a vector database?

Ternlight can replace a vector database for small local indexes where vectors are stored in IndexedDB or OPFS and searched in the browser. It should not replace a vector database for large centralized indexes, enterprise permissioning, team-wide search, or analytics-heavy retrieval systems.

What model should I pair with Ternlight for RAG answers?

Use Ternlight for local retrieval, then pair it with GPT-5 mini or Gemini 2.5 Flash for low-cost answer generation. For premium synthesis, use Claude Sonnet 5 or GPT-5, and estimate your per-run spend with AI Cost Check.

---

CTA: calculate your embedding and RAG costs

If you are building semantic search, local RAG, or support search, price the whole workflow before you choose an architecture. Use AI Cost Check to compare hosted embedding, retrieval, and answer-generation costs across models.

Useful next steps:

• Compare generation options like GPT-5 vs Gemini 3 Pro
• Review GPT-5 mini pricing for low-cost RAG answers
• Check Gemini Embedding 2 as the hosted embedding fallback
• Model your exact input/output tokens in the AI Cost Check calculator

Ternlight’s practical impact is simple: if your users already have the data in the browser, you can now give them private semantic search without paying for every embedding call. That makes local-first AI products faster to try, cheaper to run, and easier to trust.