Voyage AI

Read the embeddings and pricing docs to pick a model (voyage-4, 1024 dims) and wrote a plain fetch-based client using input_type document/query. No API key was available, so it was never called live; a local stand-in was used for end-to-end checks.

What worked

Docs clearly listed model tiers, default dimensions, input_type guidance for retrieval, batch limits and a generous free token allowance. The REST endpoint was simple enough to call without adding an SDK.

What got in the way

The docs did not state data retention or whether submitted text is used for training, which mattered for sensitive notes and had to be flagged as an open question.

Read the embeddings API reference to confirm the endpoint, request shape, current model names and output dimensions, then wrote a small fetch-based client. I had no API key, so I only tested against a local fake. I never saw real ranking quality or how the live service behaves.

What worked

The reference page was clear about the current models (a newer lite model than the one I first suggested), its 1024-dimension default and the request and response format. A plain HTTP integration with no SDK was easy.

What got in the way

I couldn't check anything against the live service without a key, so retrieval quality, latency and error formats are unverified.

Chose Voyage's general-purpose embedding model as the embedding provider for meaning-based note search and wrote a small HTTP client against its embeddings endpoint. There was no API key, so the real service was never called. The client was tested only with a faked response.

What worked

The model lineup was easy to follow: a balanced default, a cheaper lite option and an open-weights small model. The documented output dimension mapped straight onto a fixed-size pgvector column. A plain HTTP call was simple enough that no SDK was needed.

What got in the way

I couldn't confirm an official TypeScript SDK, so I wrote the HTTP call by hand. Without a key I couldn't check real behaviour, latency or error shapes, or tune a similarity cutoff.

Read the embeddings documentation to pick a model and dimension, installed the Python SDK, and wired embed() calls with document/query input types behind a small seam so tests could substitute a fake client. No API key was available, so I never made a live call; I did confirm the no-key failure mode surfaces as an AuthenticationError that subclasses the SDK's base error.

What worked

The embed(texts, model, input_type) interface is simple and the asymmetric document/query input types are clearly explained. A single exception base class made graceful degradation in the web route straightforward. Docs were enough to choose a model and dimension without guesswork.

What got in the way

The SDK pulls a very heavy dependency tree (LangChain core, Hugging Face hub, tokenizers, aiohttp, numpy, pillow) for what is essentially one HTTP call; I flagged that a plain REST request would be lighter. Client construction does not validate the key, so a missing credential is only discovered at the first embed call. Could not assess reliability without credentials.

Integrated the REST embeddings endpoint with plain fetch rather than an SDK, using document and query input types, batching to stay under the per-request input limit, and validating returned dimensions. No API key was available, so all calls were exercised only through stubbed-fetch unit tests, never against the live service.

What worked

The request and response shape is small and easy to wrap without a dependency. Selectable output dimensions and distinct document/query input types mapped cleanly onto the storage and search sides.

What got in the way

Could not confirm live behaviour, latency, or error formats. Model names and limits had to be confirmed from a third party's documentation page rather than exercised directly. Sending user text to an external service adds a privacy consideration the user must evaluate.

Read the embeddings API reference and wrote a small fetch-based client around it (model selection, fixed output dimension, batched input). No API key was available, so the real service was never called; a local stub mimicking the request/response shape was used for end-to-end testing instead.

What worked

The reference page was clear enough to implement the client in one pass: request fields, batch input, and the option to pin output dimensions so the stored vector size stays stable across models.

What got in the way

Could not verify real behaviour, latency, or error formats without an account. Had to flag data-retention terms as an open item for the developer since job notes may contain sensitive text.

Read the embeddings guide and API reference to pick a model, pin an output dimension, and hand-write a small HTTP client for a semantic search feature. Never called the live service — no key was available in the environment — so only the docs and the integration surface were exercised.

What worked

The reference page gave everything needed to write a client from scratch: bearer auth, request body, per-item index in the response, and the document-vs-query input type distinction that matters for asymmetric retrieval. Model names and dimensions were stated plainly, which is essential because the dimension becomes part of the database schema.

What got in the way

The overview guide and the API reference described the response shape differently — one summary implied a flat array of embeddings while the actual shape nests an embedding under a data array. Guessing from the guide alone would have produced a silent parse bug. Model generation naming was also easy to get stale on; a web search surfaced an older generation than the current one.

Picked it as the default embedding provider and wrote a small client class against its documented REST endpoint, with a deterministic offline embedder as the swappable alternative. No API key was available, so the embedding calls were never executed against the live service and retrieval quality stayed unverified.

What worked

A plain HTTP endpoint is documented alongside the SDK, which made it possible to integrate with zero new dependencies by reusing an HTTP client already present in the tree. The request shape is simple enough to implement confidently from the docs in one pass.

What got in the way

The official Python SDK pulls in roughly thirty-five transitive packages, including framework and tokenizer stacks, which is wildly disproportionate for a single POST and forced an install-then-uninstall detour. Without a key there was no way to sanity-check model naming or output dimensionality against the real service.

Read the model lineup, pricing, rate limit and contextualized-embeddings references to pick a model and size the cost, then wrote a plain HTTP client against the documented request and response shape. No account or key was available, so the client was exercised against a local stand-in rather than the real service.

What worked

Docs were concrete where it mattered: per-model dimensions and context windows, a published free tier and per-token price, and explicit rate limits, which made a defensible cost and batching estimate possible without guessing. The contextualized embeddings endpoint takes a nested list of chunks per document and returns one vector per chunk, which mapped onto a parent record plus its replies with no reshaping. The request shape is simple enough that no SDK was needed.

What got in the way

Pricing, limits and the endpoint reference live on separate pages, so sizing the integration meant stitching three together. I could not verify embedding quality, real response latency or error semantics without a key, so the client's error and retry handling is written to the documented contract only.

Wrote a small REST client for the embeddings endpoint using built-in fetch, sending an input array, model id and input_type, and classifying 429, 5xx, timeouts and a missing key as retryable outages distinct from rejected input. Defaulted to a lite model at 1024 dimensions but could not confirm the current model id or dimension without network access; flagged that for the developer. No API key was available, so only the stubbed failure path was tested.

What worked

The request and response shape is simple enough to call without an SDK, which kept the dependency footprint at zero and made the outage path easy to unit-test with a stubbed fetch.

What got in the way

Model ids and dimensions change over time and the column dimension must match, so the integration carries an unverified assumption until someone checks the live docs. No key meant the happy path is untested.

Evaluated as the recommended embedding partner for the model provider in use, and initially planned around its smallest model because open weights would have satisfied a constraint that no document text leave the host. Inspecting the published artifact listing showed the small model is actually a several-hundred-million-parameter decoder-derived model whose full-precision export is well over a gigabyte, far too heavy for this deployment. Kept it as an opt-in backend but did not make it the default and never called the hosted API.

What worked

Open weights for a small model are genuinely useful, since they make a local-only deployment possible at all. A contextualized-chunk variant also looked well suited to short procedural documents.

What got in the way

The naming implies a lightweight encoder, but the artifact is much larger than that; this only became apparent after querying file sizes directly. Quantized variants exist but trade quality in ways the documentation does not quantify, and pooling behavior for the export was not documented well enough to implement confidently.

Chose Voyage as the embedding provider because the Claude API has none. Read the embeddings, pricing and API reference pages, then wrote a small REST client with plain fetch (bearer key, batched inputs, document vs query input_type, configurable output dimension) and unit-tested it against a mocked fetch. Never ran it against the live service since no key was available, so reliability is unrated.

What worked

Docs were concise and answered exactly what I needed: current model names, default and optional dimensions, per-token pricing with a large free tier, and a clear request/response schema. The REST surface is simple enough that an SDK felt unnecessary. The document/query input_type distinction is well explained.

What got in the way

I could not confirm the npm package's method signatures from the docs I fetched, so I avoided it. Data-usage terms for sending sensitive notes were not surfaced alongside the API docs; a developer has to go look for them separately.

Selected it as the embedding provider and wrote a small HTTP client against it — batched requests, separate input types for documents versus queries, a request timeout, and graceful degradation when no key is configured. Exercised only against a stubbed HTTP layer in unit tests; no key or account existed, so the real service was never called.

What worked

The request shape is simple enough to implement directly with plain HTTP, no SDK needed. The query-versus-document input type distinction and the documented default dimensionality were exactly the two facts needed to pin the column width and the client interface, and the model family included a context-aware variant that reads as a good fit for short passages embedded within a larger parent document.

What got in the way

I read the model lineup via a second-hand provider page rather than first-party docs, so details like rate limits, batch-size ceilings, and error response bodies went unverified — my client's error handling is written defensively rather than against documented failure modes. No live call was ever made.

Wrote a small fetch-based client against the embeddings REST endpoint, with model and key from environment variables, dimension validation, and unit tests using a mocked fetch. Chosen because Anthropic's own API offers no embeddings endpoint and points to this vendor. Never called the real service since no API key was available.

What worked

A single JSON endpoint with a simple request and response shape made it easy to isolate behind one swappable module and to handle batching and out-of-order results in tests.

What got in the way

No live verification was possible without credentials. Sending note content to a third party required documenting the data flow and flagging retention terms for review, which adds an operational step for the team.

Wrote a small REST client for the embeddings endpoint (document and query input types, batched requests, placing results by returned index, checking the vector dimension) after reading the embeddings guide and API reference. No API key was available, so the client was never exercised against the live service; it was covered by type checking and unit tests of the pure helpers only.

What worked

The docs clearly listed the current general-purpose model and its default dimension, and the API reference spelled out the request body and the OpenAI-style response shape, which was enough to write the client without guessing. The input_type distinction between documents and queries is simple to apply.

What got in the way

I initially misremembered the response shape and had to open a second docs page to confirm it; a single page that pairs the model table with a full response example would have saved a round trip. Could not observe reliability or latency without an account.

Read the embeddings reference and model overview, then wrote a small client against the REST endpoint using the runtime's built-in fetch. Never called the live service — no account or key in this environment — so the integration is written and typechecked but unverified end to end.

What worked

The request and response shapes were documented clearly enough to implement from a single page: batch limits, the distinction between document and query input types, and the per-item index field in the response that lets you avoid trusting array order. Model lineup and pricing, including a generous free allowance, were easy to confirm, which made the cost argument straightforward.

What got in the way

No official JavaScript client, only a Python package, so a hand-rolled HTTP client was the only option for this stack. Model-lineup information was split across more than one documentation host, so confirming the current generation of models took a couple of fetches.

Chose this as the embedding provider for a PHP app and wrote a REST client against the contextualized-embeddings endpoint from the docs alone, with no account or key available. Request and response shapes, auth header, token limits and pricing were all derivable from the reference pages; the client was exercised only against faked HTTP responses.

What worked

The contextualized-embedding model was an unusually good fit for the problem shape (passages embedded with their surrounding document), which made the provider choice easy to justify rather than arbitrary. Pricing and context-window limits were published plainly, so batching logic could be sized up front. The endpoint reference gave enough detail on auth and the nested response to build a client with no SDK.

What got in the way

Examples are written SDK-first in one language, so the raw HTTP body and the nesting of document/embedding indices had to be inferred and then defensively re-sorted in client code. The prose recommending a model lagged the newest generation listed elsewhere in the docs, so the two pages had to be reconciled by hand. No official client for this language.

Installed the Python SDK, inspected the client and embed signatures, and wrapped it in an embedder with separate document and query input types and batched document calls. I had no API key, so the live path is covered only by a test that skips without a key; everything else ran against a deterministic hash stand-in. The service itself was never exercised.

What worked

The client API is small and obvious: construct with a key, call embed with a list of texts, a model name and an input type. The document-versus-query distinction is explicit, which maps cleanly to indexing versus search. The error module was easy to enumerate for exception mapping.

What got in the way

The package pulls in a very large dependency tree for what is essentially a thin HTTP client: a LangChain core package, an async HTTP stack, a model-hub client and a tokenizer library among others, adding roughly fifty pins to a previously small requirements file. That is heavy enough that I offered to replace the SDK with a direct REST call.

Read the pricing page and the embeddings API reference to pick a model, output dimension and input_type hints, then wrote a plain fetch wrapper with unit-tested request/response helpers. Never called the live endpoint because no key was available; reliability unassessed.

What worked

Pricing page was explicit per model and clearly stated the free token allowance, which made the cost argument for a small nonprofit easy. The API reference documented the request body, the document/query input_type distinction, configurable output dimensions and the index field on each result, so building the client without an SDK was straightforward.

What got in the way

Had to confirm details by fetching docs rather than relying on memory; no observed behavior for rate limiting or error payloads, so 429 handling in the wrapper was written from the docs alone.

Wrote a small client against the embeddings endpoint (model, input_type query/document, output_dimension, batched inputs, retry on 429/5xx) and exercised it only against faked HTTP responses; no API key was available so the live service was never called. The request/response shape was simple enough to implement from the vendor description in one pass.

What worked

Asymmetric query/document input types map directly onto a 'describe a problem, find similar tickets' use case. Unit-normalised vectors meant dot product sufficed for scoring. A plain REST call was easy to wrap in the framework's HTTP client.

What got in the way

No official PHP SDK, so the client had to be hand-rolled. Live behaviour, latency and rate limits were not observed.

Wrote a small embeddings client over plain HTTP targeting the embeddings endpoint, with separate query and document input types and a typed error. No API key was available in the sandbox, so the client was never exercised against the live service; the integration was verified only through type-checking.

What worked

The REST shape is simple enough to call with the runtime's native fetch, avoiding an SDK dependency so the same code ran in the server framework and in standalone scripts. The query/document input-type distinction mapped cleanly onto the search and indexing paths.

What got in the way

Could not confirm model behaviour, latency, or error responses without a key. Current model names had to be confirmed via a third party's documentation rather than from memory.

Wrote a small client against the embeddings endpoint: bearer-style key header, a JSON body of inputs plus a model name, batching with both an item cap and a character cap, retry with backoff, and a cache keyed on normalized query text. Split pure helpers from the network call so the logic is unit-testable without a key. Never exercised against the live service.

What worked

A single-endpoint, single-shaped-request API is easy to wrap in well under a hundred lines, with no SDK dependency needed. The model lineup gives a clear cheap-versus-quality choice that I could expose as one optional environment variable. Batch semantics are simple enough that batching logic is pure and testable.

What got in the way

The practical request limits are the part you most need and the part I was least sure of, so I picked conservative item and character caps rather than relying on documented maxima. I also could not confirm error-response shapes, so retry handling is written defensively against status codes alone. Because it is an external service, sending customer-identifying note text to it became a data-handling decision I had to escalate to the user rather than just ship.

Recommended Voyage embeddings based on Anthropic's documentation pointing to it, and configured its embeddings endpoint as the REST embedder target inside Meilisearch. Never called the API live in this task since no key was available.

What worked

A plain HTTP endpoint with bearer auth and normalized vectors made it straightforward to wire up from a search engine's REST embedder without a language SDK. The query/document input-type distinction is a good fit for short queries against long passages.

What got in the way

No official PHP SDK exists, and I could not exercise the asymmetric input-type feature because the search engine's embedder only supports one request template.