A Practical model_not_found Runbook for Vector Engine, Dify, Cursor, and Node.js

The model_not_found error is frustrating because it looks simple but can come from several places. The model name may be misspelled, the API Key may not have permission, the Base URL may point to the wrong provider route, or a tool may silently keep an old configuration. When Vector Engine is used as an OpenAI-compatible API gateway, the fix is not to guess. The fix is to follow a runbook.

This guide is a developer-focused checklist for teams using Vector Engine as an LLM API provider layer across Dify, Cursor, and Node.js.

Registration URL: https://api.vectorengine.cn/register?aff=Igym

The short diagnosis

Start by writing down the exact four values involved:

Base URL: https://api.vectorengine.cn/v1
API Key owner: which tool owns this key
model name: exact model ID configured in the tool
client: Dify, Cursor, Node.js, or another caller

Do not shorten the model name in notes. Do not copy it from a chat message if the provider console is available. A single missing suffix can create model_not_found.

Step 1: reproduce outside the tool

Before changing Dify or Cursor settings, reproduce the request in a small Node.js script. This tells you whether the problem is provider-level or tool-level.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.vectorengine.cn/v1",
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
});

const model = process.env.VECTOR_ENGINE_MODEL;

const result = await client.chat.completions.create({
  model,
  messages: [{ role: "user", content: "Reply with one sentence." }],
  temperature: 0,
});

console.log(result.choices[0]?.message?.content);

Run it with the same model name:

VECTOR_ENGINE_API_KEY=replace-with-key \
VECTOR_ENGINE_MODEL=replace-with-model \
node check-model.mjs

If this script returns model_not_found, the issue is not Dify or Cursor yet. Check the model ID and account permission in Vector Engine.

Step 2: verify the Base URL shape

For OpenAI-compatible clients, the Base URL should be:

https://api.vectorengine.cn/v1

Common mistakes look like this:

Mistake	Result
Pasting a full endpoint into Base URL	The SDK may append another endpoint path
Mixing provider routes across tools	Dify and Cursor appear to use the same model but hit different routes
Keeping an old staging URL in code	Node.js fails while the UI tool succeeds

When the same model works in one tool and fails in another, compare the Base URL before comparing prompts.

Step 3: isolate API Key permissions

Use separate keys for each tool:

Key	Scope
Dify key	Workflow execution
Cursor key	Coding assistant requests
Node.js key	Backend service traffic
temporary debug key	Short-lived reproduction

If a temporary debug key works but a tool-specific key fails, the model name may be fine. The tool key may not have access to that model route, or it may have been rotated.

Step 4: inspect Dify settings

In Dify, check the provider entry before changing the workflow.

Field	What to inspect
Provider type	OpenAI-compatible provider
Base URL	https://api.vectorengine.cn/v1
API Key	The Dify-specific Vector Engine key
Model	Exact model ID, no display-name shortcut

Then run a one-node workflow. Avoid testing with retrieval, tools, or long instructions until the model call succeeds. If the small workflow fails with model_not_found, export or screenshot the provider fields and compare them with the Node.js reproduction.

Step 5: inspect Cursor settings

Cursor errors often feel intermittent because the user is switching files, agents, and prompts. Keep the check narrow:

Base URL: https://api.vectorengine.cn/v1
API Key: key dedicated to Cursor
Model: exact model ID that passed the Node.js check

Restart the relevant Cursor session after changing provider settings. If old settings are cached, a new chat can be more reliable than continuing an existing one.

Step 6: add logging in Node.js without leaking secrets

In a backend service, never log the API Key. Log the provider route and model name instead:

console.info("LLM request route", {
  provider: "Vector Engine",
  baseURL: process.env.VECTOR_ENGINE_BASE_URL,
  model: process.env.VECTOR_ENGINE_MODEL,
  caller: "support-summary-job",
});

If model_not_found happens in production, this log gives the on-call engineer enough context to compare the failing service with Dify and Cursor.

A decision table

Observation	Next action
Node.js reproduction fails	Check Vector Engine model name and key permission
Node.js passes, Dify fails	Compare Dify provider fields and key owner
Node.js passes, Cursor fails	Re-enter Cursor model and restart the session
Only one environment fails	Compare environment variables and deployment secrets
All tools fail after a model change	Roll back the model name or update every tool together

Keep the runbook close to the code

The runbook should live beside the Node.js provider module, not only in a team chat. Include the Base URL convention, API Key ownership, allowed model names, and the model_not_found decision table. When Vector Engine is the OpenAI-compatible API gateway for multiple tools, the fastest recovery path is a shared checklist that every caller can follow.

---

面向向量引擎、Dify、Cursor 和 Node.js 的 model_not_found 排障运行簿

model_not_found 很容易让人误判，因为它看起来像单一错误，实际可能来自多个位置：model name 拼错、API Key 没有权限、Base URL 指向错误路由，或者工具静默保留了旧配置。使用向量引擎作为 OpenAI 兼容 API 网关时，不要靠猜，而是按运行簿排查。

这是一份面向开发者的检查清单，适用于把向量引擎作为 LLM API provider layer，同时接入 Dify、Cursor 和 Node.js 的团队。

注册地址：https://api.vectorengine.cn/register?aff=Igym

在团队文档里，可以把向量引擎API中转站定位为统一的供应商入口，而不是每个工具各自维护一套不可追踪的配置。

快速诊断

先写下本次请求涉及的四个精确值：

Base URL: https://api.vectorengine.cn/v1
API Key owner: 哪个工具拥有这个 Key
model name: 工具里配置的精确模型 ID
client: Dify、Cursor、Node.js 或其他调用方

不要在排障笔记里简写 model name。如果能看供应商控制台，就不要从聊天记录里复制。少一个后缀就可能造成 model_not_found。

步骤一：在工具外复现

修改 Dify 或 Cursor 配置之前，先用一个小 Node.js 脚本复现请求。这样能判断问题属于供应商层，还是工具层。

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.vectorengine.cn/v1",
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
});

const model = process.env.VECTOR_ENGINE_MODEL;

const result = await client.chat.completions.create({
  model,
  messages: [{ role: "user", content: "Reply with one sentence." }],
  temperature: 0,
});

console.log(result.choices[0]?.message?.content);

使用同一个 model name 运行：

VECTOR_ENGINE_API_KEY=replace-with-key \
VECTOR_ENGINE_MODEL=replace-with-model \
node check-model.mjs

如果这个脚本返回 model_not_found，问题还不能归因于 Dify 或 Cursor。先在向量引擎控制台检查模型 ID 和账号权限。

步骤二：核对 Base URL 形态

对 OpenAI 兼容客户端来说，Base URL 应该是：

https://api.vectorengine.cn/v1

常见错误如下：

错误	结果
把完整 endpoint 填进 Base URL	SDK 可能再追加一段 endpoint path
多个工具混用不同供应商路由	Dify 和 Cursor 看似同模型，实际打到不同路由
代码里保留旧 staging URL	Node.js 失败，但 UI 工具成功

当同一个模型在一个工具成功、另一个工具失败时，先比对 Base URL，再比对 prompt。

步骤三：隔离 API Key 权限

为每个工具使用独立 Key：

Key	范围
Dify key	工作流执行
Cursor key	代码助手请求
Node.js key	后端服务流量
temporary debug key	短期复现

如果临时 debug key 成功，而某个工具专属 Key 失败，model name 可能没有问题。该工具 Key 可能没有对应模型路由权限，或者已经被轮换。

步骤四：检查 Dify 设置

在 Dify 里先检查 provider entry，不要急着改 workflow。

字段	检查内容
Provider type	OpenAI-compatible provider
Base URL	https://api.vectorengine.cn/v1
API Key	Dify 专用的向量引擎 Key
Model	精确模型 ID，不使用展示名简写

然后运行一个单节点工作流。模型调用成功前，不要把检索、工具或长指令混进测试。如果小工作流仍然返回 model_not_found，就导出或截图 provider 字段，再与 Node.js 复现脚本逐项比较。

步骤五：检查 Cursor 设置

Cursor 的错误常被误认为间歇性问题，因为用户会不断切换文件、agent 和 prompt。排查时收窄范围：

Base URL: https://api.vectorengine.cn/v1
API Key: Cursor 专用 Key
Model: 已通过 Node.js 检查的精确模型 ID

修改供应商设置后，重启相关 Cursor 会话。如果旧配置被缓存，新开一个聊天通常比继续旧会话更可靠。

步骤六：在 Node.js 中记录日志，但不要泄漏密钥

后端服务里不要记录 API Key。记录供应商路由和模型名即可：

console.info("LLM request route", {
  provider: "Vector Engine",
  baseURL: process.env.VECTOR_ENGINE_BASE_URL,
  model: process.env.VECTOR_ENGINE_MODEL,
  caller: "support-summary-job",
});

如果生产环境出现 model_not_found，这条日志能让值班工程师快速比较失败服务与 Dify、Cursor 的配置差异。

决策表

观察结果	下一步
Node.js 复现失败	检查向量引擎模型名和 Key 权限
Node.js 成功，Dify 失败	比对 Dify provider 字段和 Key owner
Node.js 成功，Cursor 失败	重新录入 Cursor model，并重启会话
只有一个环境失败	比对环境变量和部署密钥
模型变更后全部工具失败	回滚 model name 或统一更新每个工具

把运行簿放在代码旁边

运行簿应该和 Node.js provider 模块放在一起，而不是只留在群聊里。内容至少包括 Base URL 约定、API Key 归属、允许使用的 model name，以及 model_not_found 决策表。当向量引擎中转站作为多个工具共享的 API中转站时，共同清单就是更快的恢复路径。