How to Fix 'embedding dimension mismatch' in CrewAI (TypeScript)

When CrewAI throws embedding dimension mismatch, it means the vector you’re trying to store or search does not match the embedding size expected by your vector database or memory layer. In practice, this usually shows up when you switch embedding models, reuse an old index, or mix embeddings from different providers in the same store.

The error often appears during knowledge ingestion, memory writes, or retrieval. You’ll see it when CrewAI tries to upsert vectors into a collection that was created with a different dimension than the one your current embedding model produces.

The Most Common Cause

The #1 cause is changing the embedding model without rebuilding the vector store.

If you created a Chroma/Pinecone/Qdrant collection with one embedding model and later changed models, the stored collection keeps its original dimension. CrewAI then tries to insert new vectors and the backend rejects them.

Broken vs fixed pattern

// BROKEN: collection was created earlier with a different embedding size
import { Crew, Agent, Task } from "crewai";
import { ChromaClient } from "chromadb";
import { OpenAIEmbeddings } from "@langchain/openai";

const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-large", // 3072 dims
});

const client = new ChromaClient();

const collection = await client.getOrCreateCollection({
  name: "customer-support-knowledge",
});

await collection.add({
  ids: ["doc-1"],
  documents: ["Policy details..."],
  embeddings: await embeddings.embedDocuments(["Policy details..."]),
});
// Error from backend:
// "embedding dimension mismatch"
// or
// "Expected dimension 1536, got 3072"

// FIXED: recreate the collection or use a new one for this embedding model
import { ChromaClient } from "chromadb";
import { OpenAIEmbeddings } from "@langchain/openai";

const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-large",
});

const client = new ChromaClient();

// Use a fresh collection name for this model/version
const collection = await client.getOrCreateCollection({
  name: "customer-support-knowledge-v2",
});

await collection.add({
  ids: ["doc-1"],
  documents: ["Policy details..."],
  embeddings: await embeddings.embedDocuments(["Policy details..."]),
});

If you’re using CrewAI’s knowledge/memory abstractions, the same rule applies. A Crew, Agent, or Task isn’t the problem; the vector store behind them is.

Other Possible Causes

1) Different models for ingestion and retrieval

You indexed docs with one embedder and queried with another.

// Ingestion
const ingestEmbeddings = new OpenAIEmbeddings({ model: "text-embedding-3-small" }); // 1536

// Querying later
const queryEmbeddings = new OpenAIEmbeddings({ model: "text-embedding-3-large" }); // 3072

Fix: use the same embedding model for both indexing and querying.

2) Stale local data after changing config

If you use local storage, old persisted vectors survive config changes.

# Old persisted index still exists
rm -rf .chroma
rm -rf ./vector-store

Fix: delete the local index and rebuild it after changing embedding dimensions.

3) Mixing providers in one namespace

This happens when one service writes OpenAI vectors and another writes Cohere/Voyage vectors into the same collection.

// Bad: same namespace/collection for different providers
namespace: "support-kb"

// Good:
namespace: "support-kb-openai"
namespace: "support-kb-voyage"

Fix: isolate by provider, model, or version.

4) Wrong collection schema in Pinecone/Qdrant/Weaviate

Some backends require explicit dimension setup at creation time.

// Example: Pinecone index created at 1536 dims
// but current embedder returns 1024 dims.

Fix: recreate the index with the correct dimension, or switch to an embedder that matches it.

How to Debug It

1. •

   Print the actual embedding length

   const vec = await embeddings.embedQuery("hello");
   console.log(vec.length);
   

   Compare that number to your vector DB’s expected dimension.

2. •

   Check what created the existing index Look at old deployment config, migration scripts, or bootstrap code. If the store was created by text-embedding-ada-002 or text-embedding-3-small, don’t feed it text-embedding-3-large vectors unless you rebuild it.

3. •

   Inspect CrewAI knowledge/memory wiring Search for where your Crew, Agent, or knowledge source is configured. The bug is often in a shared helper:

   const memory = new Memory({ provider: "chroma", ... });
   

   If that helper changed models silently, every agent using it will fail.

4. •

   Verify backend metadata In Pinecone/Qdrant/Weaviate/Chroma, check index/collection metadata and confirm its stored dimension matches your current embedder output.

Prevention

• •Pick one embedding model per project phase and version your vector stores when you change it.
• •Add a startup assertion that checks embedQuery("test").length against expected dimension before ingesting anything.
• •Treat vector indexes like schema migrations: if dimensions change, rebuild or migrate explicitly.

The real fix is usually boring: match dimensions exactly, don’t mix models in one store, and clear stale indexes when you change embedders. Once you do that, CrewAI stops failing at ingestion time and your agents can retrieve normally.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.