voyage-4 is Voyage AI's mid-sized text embedding model in the Voyage 4 family. It converts query and document text into numerical vectors for general-purpose and multilingual retrieval. The family's defining capability is a shared embedding space: voyage-4, voyage-4-large, voyage-4-lite and voyage-4-nano produce compatible representations, allowing the query and document sides of a search task to use different models in that family.
The manufacturer calls the use of different query and corpus models asymmetric retrieval. One documented pattern is to prepare the corpus with voyage-4-large and search it using voyage-4 query embeddings. The corpus is embedded once or when its source material changes, while query vectors are created as searches arrive. The shared space lets the query-side model choice change within the family without requiring the corpus to be embedded again solely for that switch.
Keep the output dimension and representation compatible across the compared vectors. The shared-space statement concerns the named Voyage 4 text models; it is not established merely by two unrelated models returning arrays of the same length. A practical task can therefore use voyage-4 on both sides of search, or use its query vectors with an existing voyage-4-large document index when their representation settings match.
For retrieval, Voyage recommends identifying input text as a query or a document. The input-role option supplies the corresponding retrieval instruction before vectorization. Prepare corpus passages as documents and the user's search wording as a query, retaining the actual source text and identifiers alongside each stored vector.
For example, a knowledge-search collection can index technical instructions and product explanations. A query about what happens after a failed import should return the source passage describing that behavior. Preserve headings, relevant conditions and the source location with the passage so the resulting search hit can be inspected or used by a later RAG answer stage. The embedding is the numeric retrieval representation; the underlying passage is the evidence used in that later stage.
The documented per-text context window is 32,000 tokens. Selectable dimensions are 256, 512, 1024 and 2048, with 1024 as the default. Matryoshka learning supplies these nested representation sizes. Output can use 32-bit floating point, signed or unsigned 8-bit integers, or packed binary values, enabled by the family's quantization-aware preparation.
With packed binary output, each returned byte stores eight embedding bits, so the byte-list length is one eighth of the selected dimension. The byte count and the embedding dimension have different meanings. Choose the representation your search index can interpret, and inspect candidate relevance on the questions and languages actually used by the collection before selecting a compressed configuration.
The maker's current text-embedding guide allows up to 1,000 strings and 320,000 total tokens in a voyage-4 request. The batch allowance is separate from the 32,000-token window for each input. Truncation is enabled by default: over-length text is shortened to fit. If truncation is disabled, an over-length item produces an error instead.
For a long report or transcript, prepare answer-bearing passages deliberately rather than relying on a cut at the input boundary. Keep each passage linked to its parent document and source version. Ordinary voyage-4 embedding inputs are individual texts; contextualized chunk-group processing belongs to the separately documented contextual embedding models.
Store the vectors with the passage text and stable source identifiers, compare each query vector with the compatible document vectors and return candidate passages. The family release evaluates retrieval across material including technical documents, conversations, long documents, code, law, finance and web text. A separate reranker can refine candidates and a later answer stage can use their text. Evaluate those returned passages against the task; shared-space compatibility enables the model combination, while the usefulness of a result still depends on the source material and the question.
", "aboutText": "voyage-4 is Voyage AI's mid-sized text embedding model in the Voyage 4 family. It converts query and document text into numerical vectors for general-purpose and multilingual retrieval. The family's defining capability is a shared embedding space: voyage-4, voyage-4-large, voyage-4-lite and voyage-4-nano produce compatible representations, allowing the query and document sides of a search task to use different models in that family.\n\n### Shared space and asymmetric retrieval\n\nThe manufacturer calls the use of different query and corpus models asymmetric retrieval. One documented pattern is to prepare the corpus with voyage-4-large and search it using voyage-4 query embeddings. The corpus is embedded once or when its source material changes, while query vectors are created as searches arrive. The shared space lets the query-side model choice change within the family without requiring the corpus to be embedded again solely for that switch.\n\nKeep the output dimension and representation compatible across the compared vectors. The shared-space statement concerns the named Voyage 4 text models; it is not established merely by two unrelated models returning arrays of the same length. A practical task can therefore use voyage-4 on both sides of search, or use its query vectors with an existing voyage-4-large document index when their representation settings match.\n\n### Query and document roles\n\nFor retrieval, Voyage recommends identifying input text as a query or a document. The input-role option supplies the corresponding retrieval instruction before vectorization. Prepare corpus passages as documents and the user's search wording as a query, retaining the actual source text and identifiers alongside each stored vector.\n\nFor example, a knowledge-search collection can index technical instructions and product explanations. A query about what happens after a failed import should return the source passage describing that behavior. Preserve headings, relevant conditions and the source location with the passage so the resulting search hit can be inspected or used by a later RAG answer stage. The embedding is the numeric retrieval representation; the underlying passage is the evidence used in that later stage.\n\n### Dimensions and output data types\n\nThe documented per-text context window is 32,000 tokens. Selectable dimensions are 256, 512, 1024 and 2048, with 1024 as the default. Matryoshka learning supplies these nested representation sizes. Output can use 32-bit floating point, signed or unsigned 8-bit integers, or packed binary values, enabled by the family's quantization-aware preparation.\n\nWith packed binary output, each returned byte stores eight embedding bits, so the byte-list length is one eighth of the selected dimension. The byte count and the embedding dimension have different meanings. Choose the representation your search index can interpret, and inspect candidate relevance on the questions and languages actually used by the collection before selecting a compressed configuration.\n\n### Input length, batching and truncation\n\nThe maker's current text-embedding guide allows up to 1,000 strings and 320,000 total tokens in a voyage-4 request. The batch allowance is separate from the 32,000-token window for each input. Truncation is enabled by default: over-length text is shortened to fit. If truncation is disabled, an over-length item produces an error instead.\n\nFor a long report or transcript, prepare answer-bearing passages deliberately rather than relying on a cut at the input boundary. Keep each passage linked to its parent document and source version. Ordinary voyage-4 embedding inputs are individual texts; contextualized chunk-group processing belongs to the separately documented contextual embedding models.\n\n### Use the retrieval result\n\nStore the vectors with the passage text and stable source identifiers, compare each query vector with the compatible document vectors and return candidate passages. The family release evaluates retrieval across material including technical documents, conversations, long documents, code, law, finance and web text. A separate reranker can refine candidates and a later answer stage can use their text. Evaluate those returned passages against the task; shared-space compatibility enables the model combination, while the usefulness of a result still depends on the source material and the question.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "f71b2b8f807f10d36567e1a91e645bc3e2d5423a8ff7745d6c2ffeeb5381d97f", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "voyageai/voyage-4voyage-4 embeds text for general-purpose and multilingual retrieval, with a shared vector space across the Voyage 4 family. It supports 32,000-token inputs, selectable 256–2048-dimensional outputs and query/document roles for search and RAG.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
voyage-4 is Voyage AI's mid-sized text embedding model in the Voyage 4 family. It converts query and document text into numerical vectors for general-purpose and multilingual retrieval. The family's defining capability is a shared embedding space: voyage-4, voyage-4-large, voyage-4-lite and voyage-4-nano produce compatible representations, allowing the query and document sides of a search task to use different models in that family.
The manufacturer calls the use of different query and corpus models asymmetric retrieval. One documented pattern is to prepare the corpus with voyage-4-large and search it using voyage-4 query embeddings. The corpus is embedded once or when its source material changes, while query vectors are created as searches arrive. The shared space lets the query-side model choice change within the family without requiring the corpus to be embedded again solely for that switch.
Keep the output dimension and representation compatible across the compared vectors. The shared-space statement concerns the named Voyage 4 text models; it is not established merely by two unrelated models returning arrays of the same length. A practical task can therefore use voyage-4 on both sides of search, or use its query vectors with an existing voyage-4-large document index when their representation settings match.
For retrieval, Voyage recommends identifying input text as a query or a document. The input-role option supplies the corresponding retrieval instruction before vectorization. Prepare corpus passages as documents and the user's search wording as a query, retaining the actual source text and identifiers alongside each stored vector.
For example, a knowledge-search collection can index technical instructions and product explanations. A query about what happens after a failed import should return the source passage describing that behavior. Preserve headings, relevant conditions and the source location with the passage so the resulting search hit can be inspected or used by a later RAG answer stage. The embedding is the numeric retrieval representation; the underlying passage is the evidence used in that later stage.
The documented per-text context window is 32,000 tokens. Selectable dimensions are 256, 512, 1024 and 2048, with 1024 as the default. Matryoshka learning supplies these nested representation sizes. Output can use 32-bit floating point, signed or unsigned 8-bit integers, or packed binary values, enabled by the family's quantization-aware preparation.
With packed binary output, each returned byte stores eight embedding bits, so the byte-list length is one eighth of the selected dimension. The byte count and the embedding dimension have different meanings. Choose the representation your search index can interpret, and inspect candidate relevance on the questions and languages actually used by the collection before selecting a compressed configuration.
The maker's current text-embedding guide allows up to 1,000 strings and 320,000 total tokens in a voyage-4 request. The batch allowance is separate from the 32,000-token window for each input. Truncation is enabled by default: over-length text is shortened to fit. If truncation is disabled, an over-length item produces an error instead.
For a long report or transcript, prepare answer-bearing passages deliberately rather than relying on a cut at the input boundary. Keep each passage linked to its parent document and source version. Ordinary voyage-4 embedding inputs are individual texts; contextualized chunk-group processing belongs to the separately documented contextual embedding models.
Store the vectors with the passage text and stable source identifiers, compare each query vector with the compatible document vectors and return candidate passages. The family release evaluates retrieval across material including technical documents, conversations, long documents, code, law, finance and web text. A separate reranker can refine candidates and a later answer stage can use their text. Evaluate those returned passages against the task; shared-space compatibility enables the model combination, while the usefulness of a result still depends on the source material and the question.
POST /v1/embeddingstext, token_idsembedding| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits voyageai/voyage-4 | Default— |
Fieldinput | Typestring|string[]|integer[]|integer[][] | RequirementRequired | Values & limits Minimum items: 1 Conditions: Nonempty homogeneous batch. Token IDs are nonnegative integers. Input budget: Maximum: 32,000 · Text unit: UTF8 bytes · Token unit: token-array elements | Default— |
Fieldencoding_format | Typestring | RequirementOptional | Values & limits float | Defaultfloat |
Fielddimensions | Typeinteger | RequirementNot supported | Values & limits Minimum: 1 | Default— |
Fielduser | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldsession_id | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldtrace | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options rejected | Default— |
text_to_embedding
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, input |
Parameterinput_shapes | Contractstring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parameterencoding_format | Contractfloat |
Parameterdimensions_override | Contractfalse |
Parametermax_input_budget_units | Contract32000 |
Parametermultimodal_objects | Contractfalse |
Parametermaterial_types | Contracttext, token_ids |
Lifecycle: synchronous_json
Keep every vector index and dimension.
Multimodal model name does not admit image objects on this exact path.
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.00012 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "voyageai/voyage-4", "input": ["First document", "Second document"]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/embeddings \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("data",[]): print(json.dumps({"index":x.get("index"),"embedding":x.get("embedding")}))\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.embeddings.create(model='voyageai/voyage-4',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Keep every complete returned response, file and content part.
Keep every vector with its index. Vector count must equal input count; dimensions must be consistent.
No embedding job endpoint is introduced.
| Field | Type |
|---|---|
Fieldobject | Typestring |
Fieldmodel | Typestring |
Fielddata[].index | Typeinteger |
Fielddata[].embedding | Typefinite float[] |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra voyageai/voyage-4
Use the method paths shown above.