Cloudflare Vectorize Id 64-Byte Limit#

Cloudflare Vectorize caps vector ids at 64 BYTES, not 64 characters. The naive if id.length <= 64 skip-hashing check passes Unicode through and then fails at upsert time. The right pattern is unconditional SHA-256 hex hashing with the original id stored in metadata so query results round-trip back to your source-of-truth row.

TL;DR#

• The limit is 64 bytes, not 64 chars. Multibyte UTF-8 hits it sooner than ASCII.
• Always hash the id. Never branch on length.
• Put the original id in metadata.id. Resolve back at query time.
• A single oversized id fails the WHOLE batch — partial-success semantics.

The error#

VECTOR_UPSERT_ERROR (code = 40008): id too long; max is 64 bytes, got 67 bytes

This is a 4xx-class refusal at the upsert API. One bad id in a vectorize.upsert([...]) batch rejects every vector in the call — it is not partial-success-with-warnings. If you batch 100 vectors and one has a 67-byte id, all 100 silently fail to land.

FTS5 vs Cloudflare Vectorize#

The “FTS5 vs vectors” debate is usually hand-wavy. Both sides cite plausible reasons, neither runs the same queries through both engines on the same corpus, and the conclusion is whichever one the author shipped. With identical data and identical queries you can measure exactly where each wins.

The result: FTS5 and Vectorize have non-overlapping strengths. The right answer for most knowledge-base workloads is “ship both” behind an opt-in flag — not pick one. This page is the measurements, the cost math, and the dual-engine pattern.

Agent Memory and Retrieval#

An agent without memory repeats mistakes, forgets context, and relearns the same facts every session. An agent with too much memory wastes context window tokens on irrelevant history and retrieves noise instead of signal. Effective memory sits between these extremes – storing what matters, retrieving what is relevant, and forgetting what is stale.

This reference covers the concrete patterns for building agent memory systems, from simple file-based approaches to production-grade retrieval pipelines.

RAG for Codebases Without Cloud APIs#

When a codebase has hundreds of files, neither direct concatenation nor summarize-then-correlate is ideal for targeted questions like “where is authentication handled?” or “what calls the payment API?” RAG (Retrieval-Augmented Generation) indexes the codebase into a vector database and retrieves only the relevant chunks for each query.

The key advantage: query time is constant regardless of codebase size. Whether the codebase has 50 files or 5,000, a query takes the same time because only the top-K relevant chunks are retrieved and sent to the model.