An OpenAI API key works with both endpoints. The model names do not. Put gpt-5.4-nano, gpt-4o-mini or any other chat model into a field that expects an embeddings model, and the request is rejected — but if the work happens in a background task, nobody is told. The application then behaves exactly like one that is broken.

What you see

• The setting saved without complaint, so the credentials look accepted.
• Pressing the button reports something reassuring: "Learning the tag vocabulary in the background."
• Nothing is ever produced — no tags, no related items, no matches.
• Your provider dashboard shows zero usage, as though no request was ever made.
• A preview or test screen says you need to build the vocabulary first — which is what it also says to somebody who has never pressed the button at all.
• The AdminCP support tool reports no problems, correctly, because there is no longer anything to report.

That last point is the one that wastes the afternoon. Every signal available to the admin says the system is fine.

The fix

Use an embeddings model. For OpenAI, text-embedding-3-small. For Voyage, voyage-3.5-lite. Then run the vocabulary build again — the old attempt stored nothing, so there is nothing to clean up.

Chat models and embeddings models are not interchangeable in either direction. A chat model returns generated text; an embeddings model returns a vector. Code that expects one cannot use the other, and the endpoints are separate URLs.

Why it goes quiet — for developers

This is worth understanding if you build applications for Invision Community, because the trap is in the queue contract rather than in anyone's API client.

A job that cannot succeed has exactly one way to stop itself: throw OutOfRangeException. But that exception does not mean "I failed" — it means "I am finished, remove me from the queue." So the natural-looking error handler destroys its own evidence:

try
{
    $done = Vocabulary::embed( $slice );
}
catch ( \Throwable $e )
{
    Log::log( $e, 'my_app' );   // the only trace, and nobody reads it

    throw new OutOfRangeException; // "finished" - the row is deleted
}

The row is gone, so the AdminCP has nothing pending to show, and the support tool is right to say there are no problems. The reason survives only in the system log, which no admin has any cue to open.

Two things fix it, and they are worth doing together:

• Persist the reason where the interface can find it — a setting, a column, anything that outlives the job. Then show it on your own settings screen, quoting the provider verbatim. "You tried to use a chat model in the embeddings endpoint" diagnoses itself when an admin can actually read it.
• Validate at the point of entry. Send one short test string with the provider, key and model the admin just typed, before saving, and refuse the save with the provider's own wording if it fails. A model name is free text; there is no way for the admin to know it is wrong, and half an hour later in a background task is the worst possible moment to find out.

Also make sure "not configured yet" and "the last attempt failed" are different messages. If they are the same string, you are telling somebody who just pressed the button to press the button.

A note on how this was found

It took four exchanges with the customer to identify, and the first three answers were confidently wrong — scheduled tasks, the queue, the cron. The model name only came up because the customer mentioned it themselves. If a feature calls an external API and reports no activity at all, ask which model and which key are configured before discussing anything else. A model meant for a different endpoint produces exactly the symptoms of a job that never ran.

Related: Why a similarity threshold is never enough for automatic classification, Your classifier does not learn, and everyone will assume it does, Your AI assistant is only as good as what you gave it to read

Related application: Auto Tagging — Auto Tagging tests the embeddings settings as they are saved and refuses a chat model at that point, and reports the provider's reason on its own screen when a vocabulary build has failed.