If you have gone looking for a Claude embeddings endpoint, you will not find one. Claude is a reasoning and generation model, and Anthropic does not ship a vector-embedding API alongside it. That surprises a lot of Australian teams who assumed one model would cover the whole retrieval pipeline. The practical answer is a two-model design: a dedicated embedding model turns your documents into vectors, and Claude does the reading and reasoning on top of what those vectors retrieve.
This split is a feature, not a workaround. It lets you pick the best embedding model for your data, swap it later without touching your reasoning layer, and keep Claude focused on the job it is strongest at.
Why Claude does not produce embeddings
Embeddings and generation are different tasks. An embedding model reads a chunk of text and returns a fixed-length list of numbers that captures its meaning, so similar passages sit close together in vector space. A generation model like Claude reads text and writes a coherent, reasoned response. Anthropic has deliberately kept Claude to the second job and pointed customers at third-party embedding providers for the first.
So the question is never how to get embeddings out of Claude. It is which embedding model you pair with Claude, and how you hand the retrieved context across cleanly.
The two-model pattern
A retrieval-augmented setup that uses Claude has four moving parts. Each one is independent, which is what makes the design easy to maintain:
An embedding model, for example Voyage AI (which Anthropic recommends), or an OpenAI or Cohere model, that converts every document chunk into a vector.
A vector store such as Pinecone, Weaviate, or pgvector on Postgres, that indexes those vectors and answers similarity searches.
A retrieval step that embeds the user's question with the same model, finds the closest chunks, and pulls back the original text.
Claude, which receives the question plus the retrieved passages and produces the grounded answer with citations.
The rule that catches people out: you must embed your queries with the exact same model you used for your documents. Vectors from two different embedding models are not comparable, so mixing them quietly wrecks retrieval quality.
Choosing an embedding model
Anthropic's own guidance points to Voyage AI as a strong default, and its retrieval models score well on public benchmarks. But the right choice depends on your data and your constraints rather than a leaderboard alone. Weigh these factors:
Domain fit: legal, medical, or financial text often benefits from a model tuned for that domain over a general-purpose one.
Dimension count: bigger vectors can retrieve more precisely but cost more to store and search at scale.
Data residency: if your documents cannot leave Australia, check where the embedding provider processes and stores data before you commit.
Context length: some embedding models cap the chunk size they accept, which shapes how you split your documents.
A sensible move is to keep the embedding model behind a thin interface in your own code. If you decide to switch providers in six months, you re-embed your corpus once and the rest of the system stays put.
Where the reasoning actually happens
Vectors find candidate passages, but they do not understand them. That is Claude's part. Once retrieval returns the top handful of chunks, Claude reads them in full, resolves conflicts between sources, ignores near-misses that the similarity score dragged in, and writes an answer a person can trust. This is why a mediocre embedding model paired with strong reasoning often beats the reverse.
Claude's large context window helps here. You can afford to pass ten or twenty retrieved chunks rather than one or two, and let the model sort signal from noise instead of betting everything on the top vector match. Ask Claude to cite which passage each claim came from, and you get answers your team can audit rather than take on faith.
A costing example for an Australian team
Consider a Sydney professional-services firm with 40,000 internal documents building an internal knowledge assistant. Embedding the full corpus once is cheap, often a few hundred dollars of one-off compute. The recurring costs are query embeddings and Claude calls. A team running roughly 3,000 assistant queries a month typically lands in the range of $600 to $1,200 a month all-in, and a full build and rollout of that assistant might run around $60,000 depending on data cleanup and integration work. The embedding spend is a small slice of that. The reasoning quality Claude brings is where the value sits.
Keeping it compliant
Because two vendors now touch your data, your privacy review has to cover both. Under the Privacy Act, you are responsible for where personal information flows, so map exactly what the embedding provider receives and whether it stores or trains on your text. Anthropic does not train on business API traffic by default, and you should confirm the same for your embedding vendor in writing. For an APRA-regulated financial firm, or anything touching AUSTRAC reporting obligations, treat the embedding provider as a material service provider and document it accordingly. Keeping the vector store inside your own Australian cloud tenancy, with only query text leaving for embedding, is a common way to keep the data footprint tight.
Getting started
Start small. Pick one document set, one embedding model, and pgvector on a database you already run. Wire retrieval into a single Claude call and measure whether the answers hold up against how your team actually asks questions. Once the pattern proves out, scaling it is mostly a matter of more documents and a sturdier vector store, not a redesign. If you want help designing the retrieval layer or choosing the right embedding model for Australian data-residency rules, book a brainstorm with us and we will map it to your stack.
