OpenAI: Text Embedding 3 Small

OpenAI: Text Embedding 3 Small is an embedding model from OpenAI, listed on api14 under the model id openai/text-embedding-3-small. It sits in the embeddings category, and OpenAI describes it as an improved, more performant version of the ada embedding model. Rather than generating chat replies, it produces embeddings, which are numerical representations of text used to measure how related two pieces of text are.

The model accepts text as its only input modality and returns embeddings as its only output modality, so it fits into pipelines where you convert strings into vectors rather than into conversational systems. It has a context length of 8192 tokens, which sets the ceiling on how much text a single request can cover before you need to split it. The details also list a max output of 7372, which is a useful figure to keep in mind when you are deciding how to chunk longer documents.

Practical uses follow directly from that shape. Because embeddings let you measure relatedness between texts, the model suits semantic search, where you embed a query and a corpus and rank documents by similarity. Retrieval augmented generation is another common fit, since a retrieval layer built on embeddings can feed relevant passages into a separate generation model. The same property supports clustering and topic grouping across large text collections, deduplication of near identical content, classification when you train a lightweight classifier on top of the vectors, and recommendation or similarity features that compare items by their text descriptions. The 8192 token context means each input can be a substantial passage, not just a single sentence, which helps when you embed whole sections rather than isolated lines.

You call the model through api14's OpenAI-compatible API using the model id openai/text-embedding-3-small. Since the interface follows the OpenAI format, existing OpenAI client libraries and code that targets the embeddings endpoint can point at api14 with minimal changes. The model's supported parameters list is empty, so there are no additional request parameters documented beyond the standard request structure for an embeddings call: you supply the model id and the text input, and you receive the vector output. Any tuning you want, such as how you chunk text or how you compare the resulting vectors, happens in your own pipeline rather than through model parameters.

Because it only handles text in and embeddings out, this model is not the right choice when you need generated text, tool calls, or any conversational behaviour; a chat or completion model covers those cases. It is also an embedding model with a fixed context window, so very long documents still need to be split before embedding. Within those bounds it is a reasonable default for teams that want a small, current OpenAI embedding model behind an OpenAI-compatible endpoint.