Embedding vector length issue in Copilot

[arvigilg]

Hi,
First of all, thank you for your great work on the Copilot plugin — it has been really useful in my Obsidian workflow!
I’ve run into a small issue with embeddings. I’m using a local llama.cpp proxy (using the opain compatible fortmat) that returns vectors of length 768 for nomic-embed-v1.5-768d. However, in the Obsidian developer console, Copilot always detects this model as having a vector length of 192 and builds the semantic index that way.
This mismatch leads to problems with indexing, since the plugin doesn’t seem to pick up the vectorLength field that my server provides in /v1/models.
Would it be possible for Copilot to respect the vector length reported by the backend, instead of defaulting to 192? That would make it easier to use custom embeddings without running into conflicts.
Happy to share logs if that would help. Thanks again for all the effort you’ve put into making this plugin so powerful!
Best regards,
Alicia

[arvigilg]

fixed_llamacpp_proxy.py thats the proxy i am using

[ichts]

I think copilot currently determines vector length by running a sample embedding without checking the field in /v1/models cc @logancyang

[arvigilg]

Thanks for the clarification. I tried adjusting my proxy so that /v1/models reports the correct schema (vectorLength=768), but Copilot still ends up detecting 192 when it probes /v1/embeddings.

From the logs, it looks like Copilot ignores /v1/models and instead determines the dimension by running a sample embedding. The issue seems to be that my backend (llama.cpp / nomic-embed) returns 192-length vectors during that probe, even though the model is supposed to be 768.

Here are the relevant logs from Obsidian:

plugin:copilot:342 Detected vector length: 192 for model: nomic-embed-text-v1.5-768d
plugin:copilot:119 Created new semantic index database for /.copilot-index.
Embedding model: nomic-embed-text-v1.5-768d with vector length 192.

Here’s the /v1/models response my proxy is returning:

{
"object": "list",
"data": [
{
"id": "nomic-embed-v1.5-768d",
"object": "model",
"owned_by": "local",
"type": "embedding",
"embedding_dimensions": 768,
"schema": {
"embedding": "nomic-embed-v1.5-768d-768d",
"vectorLength": "768"
}
}
]
}

And here’s a sample /v1/embeddings response (from my proxy):

{
"object": "list",
"data": [
{
"object": "embedding",
"embedding": [0.0, 0.0, 0.0, ... 192 elements total ...],
"index": 0
}
],
"model": "nomic-embed-v1.5-768d",
"usage": {
"prompt_tokens": 0,
"total_tokens": 0
},
"schema": {
"embedding": "nomic-embed-v1.5-768d",
"vectorLength": "768"
}
}

So /v1/models says 768, /v1/embeddings also declares 768 in the schema, but the actual embedding array length ends up being 192. Copilot seems to trust the length of the array, not the schema.

I also tried padding the vectors to 768 before returning them, but Copilot still initializes with 192.

Do you know if Copilot caches the first detected dimension, or if there’s a specific expected response during its probe that I should mimic (e.g. always returning a fixed-length 768 vector no matter what the backend produces)?

Any guidance on how to make Copilot respect the correct vector length would be super helpful.

[ichts]

Have you tried to:

• clear local index
• force reindex

Or maybe simply delete copilot index folder manually