7b8c2917f9
* test(embedding): add reproducer for missing encoding_format on openai paths The openai SDK defaults encoding_format to base64 when it is not passed. OpenAI-compatible providers that don't support base64 embeddings (e.g. OpenRouter with nvidia/nemotron-3-embed-1b:free) return HTTP 200 with empty data, and every embedding call fails with 'No embedding data received'. * fix(embedding): request float encoding_format on openai embedding calls The openai SDK defaults encoding_format to base64 when the caller does not pass one. OpenAI-compatible providers that don't support base64 embeddings (e.g. OpenRouter hosting nvidia/nemotron-3-embed-1b:free) answer HTTP 200 with empty embedding data, and every embedding call fails with 'No embedding data received', breaking conclusions, semantic search, and the deriver. Pass encoding_format='float' explicitly on both the single-query and batch call paths. * test(embedding): cover openai-compatible providers in the live embedding matrix The existing openai family runs against real OpenAI, which serves base64 embeddings happily, so the matrix passes with or without the #932 fix. Adds an `openai_compatible_embedding` family (openai transport, third-party base_url) so the matrix can reach a provider that rejects base64. Empty default_models keeps it skipped unless LIVE_EMBEDDING_OPENAI_COMPATIBLE_MODELS is set. Also adds test_live_openai_float_encoding_matches_base64, which pins the other direction: switching the wire format must not move vectors on real OpenAI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(embedding): keep an explicit embedding-count check on the openai paths Passing `encoding_format` disables the openai SDK's own empty-data guard, so a provider answering 200 with missing embeddings surfaced as `IndexError: list index out of range` on the single path and `zip() argument 2 is shorter than argument 1` on the batch path. The latter is also #745's signature, which would have left it with two unrelated causes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(live-llm): correct the openai-compatible embedding matrix env docs The documented default dimensions said 2048 after the family moved to 3072, and LIVE_EMBEDDING_OPENAI_COMPATIBLE_SEND_DIMENSIONS was missing entirely. Also points the example and the coverage note at a model that is actually reachable, and records that OpenRouter load-balances, so the base64 failure is per-attempt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(embedding): resolve openai encoding_format by mode instead of pinning float Requesting float unconditionally costs ~3.6x the response bytes of base64 and up to +83% latency on a 500-item batch, which the default deployment on real OpenAI pays for nothing: only third-party OpenAI-compatible providers reject base64. Adds EMBEDDING_MODEL_CONFIG__ENCODING_FORMAT_MODE, mirroring dimensions_mode. `auto` keeps base64 when no base_url override is set or it points at api.openai.com, and picks float elsewhere. The format is still always sent explicitly, since the SDK otherwise injects base64 on its own. Also corrects the _validate_embedding_count docstring, which said "fewer" where the guard is an inequality. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(embedding): request base64 embeddings by omission, not by name The openai SDK decodes a base64 response only when it injected the default itself; naming any format makes it skip the decode and hand back the raw string, which then fails the dimension check with "Expected 1536, got 8192". base64 mode therefore has to omit the kwarg rather than pass it. The unit fake returned float lists whatever was asked for, so it could not catch this. It now mirrors the SDK and returns a base64 string for a named base64 request, which fails against the previous commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Aakash Kattelu <aakash@plasticlabs.ai> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| changelog | ||
| images | ||
| logo | ||
| snippets | ||
| v1 | ||
| v2 | ||
| v3 | ||
| README.md | ||
| bun.lock | ||
| docs.json | ||
| favicon.svg | ||
| package.json | ||
README.md
Honcho Docs
These docs are built using Next.js via mintlify.
Setting Up Honcho's Docs Locally
- Clone the repository:
git clone git@github.com:plastic-labs/honcho.git
- Navigate into the
docsfolder:
cd honcho/docs/
The docs folder contains the markdown files that make up the documentation. The majority of the files are in the pages directory. Some notable files in this folder include:
- Verify that you have Node.js and npm installed in your system. You can check by running:
node --version
npm --version
-
If not installed, download Node.js and npm from the respective official websites.
-
Once you have Node.js and npm running, proceed to install
pnpm- another package manager that helps to manage project dependencies:
npm install -g pnpm
- Install the project dependencies using pnpm:
pnpm i
- After the successful installation of the project dependencies, start the local server:
pnpm dev
Now, you should be able to view the docs on your local environment by visiting http://localhost:3000. You can explore the different markdown files and make changes as you see fit.