Voyage-Code-3

Voyage AI is a closed API with no published weights and therefore no config.json. The KV-geometry fields are left null and the record stays a vendor-context row rather than an architecture row. DRAFT — partial verification. README confirms output_dimension=2048, Matryoshka learning support, int8 and binary quantization support. Code retrieval optimized (outperforms OpenAI-v3-large and CodeSage-large by 13.80% and 16.81% on 238 code retrieval datasets per vendor). No config.json on HuggingFace, so hidden_size, num_layers, and other architecture fields are not verifiable. Not open weights — available via Voyage API and AWS SageMaker. CONTEXT_SCALING_METHOD (null): proprietary API, no config and no published context-extension method; nothing to classify. KV CACHE FIELD CORRECTED (2026-10-05): kv_cache_bytes_per_token was 0.0, which contradicted this record's own prose - the note said the KV-geometry fields are 'left null' because there is no published config to read, and the field said 0. The prose was right and the field was wrong. Zero is a CLAIM: it asserts that the model provably has no per-token KV cache, which is exactly what an unreadable closed-API architecture cannot tell you. These are embedding models over a fixed-length input, so the cache is almost certainly irrelevant, but 'almost certainly from a vendor context row' is not the same epistemic status as 'verified from config', and this repo's convention is that null means the field was not established. A reader querying for models with no KV cache would otherwise pick these up alongside genuine encoders like bge-base-en-v1-5 and Mamba models, which ARE verified. Field is now null, matching the note. See gotcha mdl-gotcha-kv-zero-means-three-different-things.