Scope decision: thin embed() helper, or explicit non-goal?

Motivation

llm ships a full embeddings subsystem (stores, similarity search, CLI); LiteLLM exposes a unified /embeddings across providers. chatlas deliberately stays out of RAG infrastructure — docs/misc/RAG.qmd explicitly recommends reaching for llama-index (or similar) for vector stores/retrieval, and #44 ("[SPIKE] RAG support", closed) landed on the same conclusion, with @cpsievert noting "if we do work on it, it will come in the form of another Python package." That's the right call for retrieval infrastructure. But a thin embed(texts) -> list[list[float]] helper is arguably a different, smaller thing: a data-scientist primitive for turning text into feature vectors for clustering/classification in a pandas/polars workflow, with no store or retriever attached — closer to token_usage() in scope than to RAG.

Options

A. Thin embed() per supporting provider. A module-level function (or provider method) unifying the handful of embeddings-capable providers (OpenAI, Google, Mistral, Ollama, ...), returning plain list[list[float]], reusing each provider's existing HTTP client setup for auth/retries. No index, no similarity search, no persistence — just the API call.

B. Document the status quo. Keep docs/misc/RAG.qmd's current recommendation (use the provider SDK directly, e.g. openai.embeddings.create()) and simply make this a documented non-goal, cross-linking from docs/why-chatlas.qmd's "what chatlas doesn't do" section (see companion issue on that page).

C. Separate small package (e.g. chatlas-embed or similar), consistent with the #44 conclusion and giving embeddings their own release cadence independent of chatlas core.

Prior art (ellmer)

This exact question was raised in ellmer as tidyverse/ellmer#171 "Also support embedding APIs?" (closed, no PR landed). Hadley's initial take: "currently out of scope for ellmer, but we might end up implementing in a separate package." He later reconsidered because so much HTTP/auth/retry plumbing would be duplicated by a separate package, and left the door open to a contributed PR — but as of this writing ellmer still has no embed_* functions (confirmed: no matching files in tidyverse/ellmer's R/ directory). So there's no ellmer precedent to align with either way — this would be a genuinely new decision for the project family, not a port.

Recommendation (light)

Option A, scoped narrowly (no persistence/index/similarity helpers, just the raw call unified across providers), seems like the best fit for chatlas's "primitives, not infrastructure" philosophy — but given ellmer explicitly punted on this and chatlas's own RAG doc/spike reached a similar conclusion, this is presented as a decision point rather than a pre-approved plan.

Open questions

• If A: which providers first (OpenAI + Google + Mistral cover most users)? Does this live in each _provider_*.py or as a standalone chatlas.embed()?
• Does adding this reopen the "does chatlas do RAG" scope question that #44 tried to close?

Drafted from a competitive review of llm / Pydantic AI / LangChain / LiteLLM (July 2026); filed via Claude Code on behalf of @cpsievert.

Start with docs/misc/RAG.qmd, docs/why-chatlas.qmd, and closed issue #44, then compare the three options and the provider and scope questions listed here. Done means the project has a recorded decision on whether embeddings belong in chatlas, with the chosen scope and provider or package boundary made explicit.