How to Debug model_not_found in Dify, Cursor, and Node.js with Vector Engine
DEV tags: ai, node, tutorial, llm
When an application returns model_not_found, the error often looks simple, but the actual cause may exist at several layers:
- The model name does not match the provider-side identifier.
- The Base URL points to the wrong endpoint.
- The API Key belongs to a different account or project.
- Dify or Cursor saved an outdated model configuration.
- The Node.js request uses a model alias that is not available through the current provider.
This tutorial explains how to diagnose these problems when using Vector Engine as an OpenAI-compatible API gateway. It also shows how to keep Dify, Cursor, and Node.js connected through a consistent LLM API provider layer.
Why model_not_found Is Usually a Configuration Problem
A typical language model request contains four important values:
- Base URL
- API Key
- model name
- request path and payload
If any of these values do not match the provider configuration, the request may fail before model inference begins.
A common mistake is assuming that a public model name, a dashboard display name, and an API model identifier are always identical. In practice, a provider may display a readable model label in the dashboard while requiring a different identifier in API requests.
For example, a dashboard might display:
Text Model Pro
But the API request may require:
text-model-pro
The exact model name should always be copied from the model list or API documentation available in the current account.
A Simple Request Flow
When Dify, Cursor, or a Node.js service sends a request through Vector Engine, the flow normally looks like this:
Application
↓
OpenAI-compatible API gateway
↓
LLM API provider layer
↓
Selected model provider
↓
Model response
A model_not_found error may be generated by the application layer, the gateway layer, or the underlying provider layer. The troubleshooting process should therefore verify each layer separately.
Step 1: Verify the Base URL
Copy the Base URL directly from the provider configuration page.
Do not manually add or remove path segments unless the documentation explicitly requires it. For example, some clients expect the Base URL to include /v1, while other clients append API paths automatically.
These two values are not always interchangeable:
https://example-provider.com
https://example-provider.com/v1
Before testing Dify or Cursor, confirm the Base URL with a direct HTTP request.
You can store it in an environment variable:
VECTOR_ENGINE_BASE_URL="YOUR_BASE_URL"
VECTOR_ENGINE_API_KEY="YOUR_API_KEY"
VECTOR_ENGINE_MODEL="YOUR_MODEL_NAME"
Avoid placing a long-term API Key directly inside frontend JavaScript, browser extensions, public repositories, screenshots, or shared configuration files.
Step 2: Verify the Model List
If the gateway supports an OpenAI-compatible model-list endpoint, test it before sending a chat request.
curl "$VECTOR_ENGINE_BASE_URL/models" \
-H "Authorization: Bearer $VECTOR_ENGINE_API_KEY"
Review the returned model identifiers and compare them with the model name configured in Dify, Cursor, or Node.js.
Check for:
- Uppercase and lowercase differences
- Extra spaces
- Missing provider prefixes
- Version suffixes
- Deprecated aliases
- Models that are visible but not enabled for the current account
For example, these identifiers should be treated as different values:
Text-Model-Pro
text-model-pro
text-model-pro-latest
provider/text-model-pro
Use the exact identifier returned by the model list.
Step 3: Test the Request with Node.js
A direct Node.js test helps separate provider problems from Dify or Cursor configuration problems.
The following example uses the native fetch function available in modern Node.js versions:
const baseURL = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;
if (!baseURL || !apiKey || !model) {
throw new Error(
"Missing VECTOR_ENGINE_BASE_URL, VECTOR_ENGINE_API_KEY, or VECTOR_ENGINE_MODEL"
);
}
const normalizedBaseURL = baseURL.replace(/\/$/, "");
const endpoint = `${normalizedBaseURL}/chat/completions`;
async function testModel() {
const response = await fetch(endpoint, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${apiKey}`,
},
body: JSON.stringify({
model,
messages: [
{
role: "user",
content: "Reply with a short connection test message.",
},
],
temperature: 0.2,
}),
});
const responseText = await response.text();
console.log("HTTP status:", response.status);
console.log("Response body:", responseText);
if (!response.ok) {
throw new Error(`Request failed with HTTP ${response.status}`);
}
}
testModel().catch((error) => {
console.error("Connection test failed:", error.message);
process.exitCode = 1;
});
Run the script:
node test-model.js
If this request succeeds, the Base URL, API Key, and model name are probably valid. The remaining problem is likely inside Dify or Cursor.
If it fails, inspect both the HTTP status code and the response body.
Step 4: Configure Dify
When adding Vector Engine to Dify through an OpenAI-compatible provider configuration, verify the following fields:
| Dify field | What to enter |
|---|---|
| Provider type | OpenAI-compatible |
| Base URL | The exact Base URL from the current provider configuration |
| API Key | A valid key from the same account or project |
| Model name | The exact API model identifier |
| Model type | Chat, completion, embedding, or another supported type |
A frequent Dify issue is selecting the wrong model type.
For example, a chat model should not be registered as an embedding model. Even when the model identifier is correct, the provider configuration may fail if the model category does not match the endpoint.
After changing a model configuration:
- Save the provider settings.
- Remove outdated duplicate model entries.
- Create a small test application.
- Send a minimal prompt.
- Check Dify logs for the complete provider response.
Do not rely only on the short error displayed in the application interface. The provider log often contains a more specific error message.
Step 5: Configure Cursor
Cursor may use a custom OpenAI-compatible provider configuration for model requests.
Verify these values:
- The custom Base URL matches the current provider configuration.
- The API Key has not expired or been replaced.
- The model name matches the API identifier.
- No old model alias remains in the selected model field.
- The request is not being sent to a previously saved provider profile.
After modifying the provider settings, restart the related Cursor session and create a new chat. Existing conversations may retain an older model selection.
If Cursor returns model_not_found while the Node.js script works, compare the actual model string used by Cursor with the working Node.js request.
Step 6: Read the Error Response Carefully
The text model_not_found is only the error category. The surrounding response usually provides more information.
A response may look like this:
{
"error": {
"message": "The requested model is not available for this account.",
"type": "invalid_request_error",
"code": "model_not_found"
}
}
This response suggests that the endpoint is reachable and the API Key was recognized, but the selected model is unavailable for that account.
Another response may look like this:
{
"error": {
"message": "Unknown model identifier.",
"code": "model_not_found"
}
}
This usually indicates a spelling problem, an outdated alias, or a model name copied from a display label rather than an API identifier.
Troubleshooting Table
| Symptom | Likely cause | Recommended check |
|---|---|---|
| HTTP 401 | Invalid or missing API Key | Recreate the key and confirm the authorization header |
| HTTP 403 | Account or project lacks permission | Check account access and model availability |
| HTTP 404 | Incorrect Base URL or request path | Compare the endpoint with the provider configuration |
model_not_found |
Incorrect or unavailable model name | Query the model list and copy the exact identifier |
| Node.js works, Dify fails | Dify provider configuration issue | Check model type, cached settings, and provider logs |
| Node.js works, Cursor fails | Cursor uses an outdated model or provider profile | Re-enter the model name and restart the session |
| Model list works, chat fails | Wrong endpoint type or unsupported model category | Confirm chat, completion, or embedding compatibility |
| Intermittent errors | Routing or provider availability issue | Record timestamps, request IDs, and selected model |
Add Structured Logging
In production, log enough information to identify configuration problems without exposing secrets.
Useful fields include:
{
"provider": "vector-engine",
"base_url_host": "configured-provider-host",
"model": "text-model-pro",
"status_code": 404,
"error_code": "model_not_found",
"request_id": "request-id-from-response",
"duration_ms": 860
}
Do not log the complete API Key.
A safe logging strategy can record:
- The API Key prefix or internal key ID
- The requested model name
- The response status
- The provider request ID
- Request duration
- Retry count
- Application name
- Environment name
This makes it easier to compare failures across Dify, Cursor, and Node.js.
Treat the Gateway as a Provider Layer
Using Vector Engine only as a replacement endpoint misses an important engineering opportunity.
A more maintainable design treats it as an LLM API provider layer between applications and model providers.
This layer can centralize:
- API Key management
- Model naming rules
- Cost and usage records
- Tool-specific configuration
- Provider migration
- Error normalization
- Request logging
- Model routing policies
Applications should depend on internal model aliases rather than provider-specific names whenever the architecture allows it.
For example:
{
"writing-model": "provider/text-model-pro",
"coding-model": "provider/code-model-standard",
"embedding-model": "provider/embedding-model-v2"
}
When a provider changes a model identifier, the team can update the mapping in one place instead of modifying every application.
A Practical Preflight Checklist
Before connecting a production application, confirm:
[ ] The Base URL was copied from the current provider configuration.
[ ] The API Key belongs to the correct account and environment.
[ ] The model name matches the exact API identifier.
[ ] The model appears in the available model list.
[ ] A direct Node.js request succeeds.
[ ] Dify uses the correct model category.
[ ] Cursor uses the current provider profile.
[ ] Logs capture status codes and provider request IDs.
[ ] No API Key is stored in frontend code or public files.
[ ] A fallback model or controlled error message is configured.
Conclusion
A model_not_found response should not be handled by repeatedly changing random settings.
Use a controlled troubleshooting sequence:
- Verify the Base URL.
- Verify the API Key.
- Query the model list.
- Copy the exact model name.
- Test with Node.js.
- Compare the working request with Dify and Cursor.
- Record the full provider response.
This approach makes it easier to determine whether the failure belongs to the application, the OpenAI-compatible API gateway, or the underlying LLM API provider layer.
Vector Engine can be used to connect multiple tools through a consistent provider configuration, but model identifiers, permissions, and endpoint paths still need to be validated carefully.
Registration URL: https://api.vectorengine.cn/register?aff=Igym
使用向量引擎排查 Dify、Cursor 和 Node.js 中的 model_not_found
当应用返回 model_not_found 时，错误信息看起来很简单，但实际原因可能出现在多个层级：
- model name 与服务端模型标识不一致。
- Base URL 指向了错误的接口地址。
- API Key 属于其他账号、项目或环境。
- Dify 或 Cursor 保存了旧的模型配置。
- Node.js 请求使用了当前服务商不支持的模型别名。
本文介绍如何在使用向量引擎作为 OpenAI 兼容服务入口时，系统排查这些问题，并将 Dify、Cursor 和 Node.js 接入统一的模型服务层。
对于正在评估向量引擎API中转站、向量引擎中转站或其他 API中转站方案的开发团队，这套检查流程也可以用于上线前验证。
为什么 model_not_found 通常属于配置问题
一个常见的大语言模型请求通常包含四项重要信息：
- Base URL
- API Key
- model name
- 请求路径和请求参数
只要其中一项与服务商配置不一致，请求就可能在模型推理开始之前失败。
常见误区是认为模型的公开名称、控制台展示名称和 API 模型标识一定完全相同。实际上，控制台可能显示一个便于阅读的名称，而 API 请求需要使用另一个固定标识。
例如，控制台中可能显示：
Text Model Pro
但 API 请求要求填写：
text-model-pro
因此，model name 应从当前账号的模型列表或接口说明中直接复制，不要根据展示名称自行推测。
请求链路说明
当 Dify、Cursor 或 Node.js 服务通过向量引擎发起请求时，链路通常如下：
应用程序
↓
OpenAI 兼容服务入口
↓
模型服务层
↓
具体模型服务商
↓
模型响应
model_not_found 可能由应用层、服务入口层或底层模型服务商返回，因此排查时需要逐层验证。
步骤一：检查 Base URL
应直接从当前服务商的配置页面复制 Base URL。
除非接口说明明确要求，否则不要自行添加或删除路径。有些客户端要求 Base URL 已经包含 /v1，另一些客户端则会自动拼接接口路径。
以下两个地址不一定可以互相替换：
https://example-provider.com
https://example-provider.com/v1
在测试 Dify 或 Cursor 之前，可以先通过直接请求验证 Base URL。
建议使用环境变量保存配置：
VECTOR_ENGINE_BASE_URL="YOUR_BASE_URL"
VECTOR_ENGINE_API_KEY="YOUR_API_KEY"
VECTOR_ENGINE_MODEL="YOUR_MODEL_NAME"
不要把长期使用的 API Key 写入前端 JavaScript、浏览器扩展、公开代码仓库、截图或多人共享的配置文件。
步骤二：检查模型列表
如果服务入口支持 OpenAI 兼容的模型列表接口，可以先查询模型列表，再发送对话请求。
curl "$VECTOR_ENGINE_BASE_URL/models" \
-H "Authorization: Bearer $VECTOR_ENGINE_API_KEY"
检查返回的模型标识，并与 Dify、Cursor 或 Node.js 中配置的 model name 逐项比较。
重点检查：
- 大小写是否一致
- 是否存在多余空格
- 是否缺少服务商前缀
- 是否缺少版本后缀
- 是否使用了已停用的别名
- 当前账号是否已经开通该模型
例如，以下标识应视为不同的模型名称：
Text-Model-Pro
text-model-pro
text-model-pro-latest
provider/text-model-pro
实际请求应使用模型列表返回的完整标识。
步骤三：使用 Node.js 直接测试
通过 Node.js 直接测试，可以把服务商问题与 Dify、Cursor 的配置问题分开。
下面示例使用现代 Node.js 内置的 fetch：
const baseURL = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;
if (!baseURL || !apiKey || !model) {
throw new Error(
"缺少 VECTOR_ENGINE_BASE_URL、VECTOR_ENGINE_API_KEY 或 VECTOR_ENGINE_MODEL"
);
}
const normalizedBaseURL = baseURL.replace(/\/$/, "");
const endpoint = `${normalizedBaseURL}/chat/completions`;
async function testModel() {
const response = await fetch(endpoint, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${apiKey}`,
},
body: JSON.stringify({
model,
messages: [
{
role: "user",
content: "请返回一句简短的连接测试结果。",
},
],
temperature: 0.2,
}),
});
const responseText = await response.text();
console.log("HTTP 状态码：", response.status);
console.log("响应正文：", responseText);
if (!response.ok) {
throw new Error(`请求失败，HTTP 状态码为 ${response.status}`);
}
}
testModel().catch((error) => {
console.error("连接测试失败：", error.message);
process.exitCode = 1;
});
运行脚本：
node test-model.js
如果该请求成功，说明 Base URL、API Key 和 model name 大概率有效，剩余问题通常位于 Dify 或 Cursor 配置中。
如果请求失败，应同时检查 HTTP 状态码和完整响应正文。
步骤四：配置 Dify
通过 OpenAI 兼容服务商配置将向量引擎接入 Dify 时，需要检查以下字段：
| Dify 字段 | 填写内容 |
|---|---|
| 服务商类型 | OpenAI 兼容 |
| Base URL | 当前服务配置中的完整 Base URL |
| API Key | 同一账号或项目下的有效密钥 |
| model name | 完整的 API 模型标识 |
| 模型类型 | 对话、补全、向量或其他支持类型 |
Dify 中较常见的问题是模型类型选择错误。
例如，对话模型不应被配置为向量模型。即使模型标识填写正确，只要模型分类与接口类型不一致，配置仍可能失败。
修改模型配置后，应执行以下操作：
- 保存服务商配置。
- 删除重复或失效的旧模型记录。
- 新建一个简单测试应用。
- 发送一条简短提示词。
- 查看 Dify 日志中的完整服务商响应。
不要只参考应用界面中显示的简短错误。服务商日志通常包含更明确的错误原因。
步骤五：配置 Cursor
Cursor 可以通过自定义 OpenAI 兼容配置连接模型服务。
需要检查：
- 自定义 Base URL 是否与当前服务配置一致。
- API Key 是否已经失效或被替换。
- model name 是否与 API 标识完全一致。
- 当前选择框中是否保留了旧模型别名。
- 请求是否仍然使用之前保存的服务商配置。
修改配置后，建议重新启动相关 Cursor 会话，并创建一个新的对话。已有对话可能仍然保存旧的模型选择。
如果 Node.js 测试成功，但 Cursor 返回 model_not_found，应对比 Cursor 实际发送的模型字符串与 Node.js 成功请求中的模型字符串。
步骤六：查看完整错误响应
model_not_found 只是错误分类，响应中的其他字段通常会提供更多信息。
例如：
{
"error": {
"message": "The requested model is not available for this account.",
"type": "invalid_request_error",
"code": "model_not_found"
}
}
该响应通常表示接口可以访问，API Key 也已被识别，但当前账号没有该模型的使用权限。
另一种响应可能是：
{
"error": {
"message": "Unknown model identifier.",
"code": "model_not_found"
}
}
这种情况通常说明模型名称拼写错误、使用了旧别名，或复制了控制台展示名称，而不是 API 模型标识。
排错对照表
| 现象 | 可能原因 | 建议检查 |
|---|---|---|
| HTTP 401 | API Key 错误或缺失 | 重新创建密钥并检查 Authorization 请求头 |
| HTTP 403 | 账号或项目没有权限 | 检查账号权限和模型开通状态 |
| HTTP 404 | Base URL 或请求路径错误 | 对照当前服务配置检查接口地址 |
model_not_found |
模型名称错误或当前账号不可用 | 查询模型列表并复制完整标识 |
| Node.js 成功，Dify 失败 | Dify 服务商配置错误 | 检查模型类型、缓存配置和服务商日志 |
| Node.js 成功，Cursor 失败 | Cursor 使用旧模型或旧配置 | 重新填写模型名称并重启会话 |
| 模型列表成功，对话失败 | 请求接口类型不匹配 | 检查对话、补全或向量接口兼容性 |
| 偶发失败 | 路由或服务商可用性波动 | 记录时间、请求 ID 和所选模型 |
增加结构化日志
生产环境中应记录足够的信息来定位配置问题，同时避免泄露密钥。
可以记录以下字段：
{
"provider": "vector-engine",
"base_url_host": "configured-provider-host",
"model": "text-model-pro",
"status_code": 404,
"error_code": "model_not_found",
"request_id": "request-id-from-response",
"duration_ms": 860
}
不要记录完整 API Key。
相对稳妥的日志字段包括：
- API Key 前缀或内部密钥编号
- 请求使用的模型名称
- 响应状态码
- 服务商请求 ID
- 请求耗时
- 重试次数
- 应用名称
- 环境名称
这些信息有助于对比 Dify、Cursor 和 Node.js 中的失败请求。
将向量引擎作为模型服务层
如果只把向量引擎当作一个替换接口，可能无法充分发挥统一接入架构的价值。
更容易维护的方式，是把向量引擎作为应用和模型服务商之间的统一模型服务层。
这一层可以集中管理：
- API Key
- 模型命名规则
- 成本和用量记录
- 不同工具的接入配置
- 服务商迁移
- 错误格式统一
- 请求日志
- 模型路由策略
在架构允许的情况下，业务应用可以依赖内部模型别名，而不是直接依赖服务商模型名称。
例如：
{
"writing-model": "provider/text-model-pro",
"coding-model": "provider/code-model-standard",
"embedding-model": "provider/embedding-model-v2"
}
当服务商修改模型标识时，团队只需要修改统一映射，不必逐个调整所有应用。
这也是评估向量引擎API中转站或其他 API中转站时，应重点检查的工程能力之一：它是否能够成为可管理、可追踪、可替换的模型服务层，而不只是一个请求转发地址。
上线前检查清单
生产应用接入前，可以完成以下检查：
[ ] Base URL 来自当前服务配置。
[ ] API Key 属于正确账号和环境。
[ ] model name 与 API 模型标识完全一致。
[ ] 模型能够在可用模型列表中查询到。
[ ] Node.js 直接请求已经成功。
[ ] Dify 选择了正确的模型类型。
[ ] Cursor 使用的是当前服务商配置。
[ ] 日志记录了状态码和服务商请求 ID。
[ ] API Key 未出现在前端代码或公开文件中。
[ ] 已配置备用模型或可控的错误提示。
总结
遇到 model_not_found 时，不应通过反复随机修改配置来尝试解决。
可以按照固定顺序排查：
- 检查 Base URL。
- 检查 API Key。
- 查询模型列表。
- 复制完整 model name。
- 使用 Node.js 直接测试。
- 对比 Dify 和 Cursor 的实际配置。
- 记录完整的服务商响应。
通过这套流程，可以判断问题究竟位于应用程序、OpenAI 兼容服务入口，还是底层模型服务商。
向量引擎可以帮助多个工具使用一致的服务商配置，但模型名称、账号权限和接口路径仍然需要在接入前进行完整验证。
对于向量引擎中转站和 API中转站类架构而言，稳定的配置管理、日志追踪和模型映射机制，比单纯更换请求地址更有工程价值。
Top comments (0)