Jan 和 GPT4All 都是免费、优先离线的桌面聊天应用，可以运行本地 GGUF 模型，也可以指向托管 API，但仍在持续发布的只有其中一个：Jan 的仓库在 2026 年 9 月 18 日仍有代码提交，而 GPT4All 的最新版本是 v3.10.0（2025 年 2 月 25 日），此后的唯一提交是一次 CI 维护提交。 这并不意味着 GPT4All 已经消亡——它没有被归档，仍然可以下载，而且其检索行为的文档比 Jan 更完善。这意味着选择应取决于任务，而不是受欢迎程度。
先澄清两个容易误写发布的名称冲突。位于 jan.ai 的 Jan 不是 Janitor AI——产品不同、受众不同，彼此没有关系。并且 nomic.ai 上的 “$20/月”横幅不是 GPT4All 的价格：它属于 Nomic Platform，这是一个面向建筑和施工的代理产品，提供图纸审查和代码合规功能。GPT4All 本身采用 MIT 许可证且免费。
按任务选择，而不是按星标数量选择
GPT4All 拥有 77,394 个星标，而 Jan 有 44,551 个（GitHub API，2026 年 9 月 19 日）。它的知名度更高，但代码库更新程度更低。以下是基于真正影响选择的维度得出的决定：
| 决策维度 | Jan | GPT4All | 胜者 |
|---|---|---|---|
| 日常聊天工作流 | 项目、助手、消息分支，自 v0.8.4 起支持原生网页搜索 | 聊天、模型/角色设置、JavaScript 代码解释器 | Jan，在广度方面 |
| 文档 | 按项目索引 PDF、DOCX、XLSX、PPTX、Markdown 和代码；检索内部机制未公开 | 使用设备端嵌入建立文件夹索引；源代码默认使用 docx/pdf/txt/md/rst，每段 512 个字符，每个提示默认 3 段；可将 .xlsx 附加到消息 | 平分——见下文 |
| 工具与执行模型 | MCP 主机；你在内嵌界面中批准每次工具调用，并可查看参数 | 文档或仓库代码搜索中均没有 MCP；代码解释器是唯一工具 | Jan |
| 托管 API 协议 | OpenAI 兼容或 Anthropic 兼容；模型发现；回退密钥 | 仅支持 OpenAI 聊天补全；手动输入模型 ID；一个密钥 | Jan |
| 成本路径 | $0 应用；本地模型按请求免费，或支付提供商的按 token 账单 | $0 应用；结论相同 | 平局——两家厂商都不抽成 |
| 迁移成本 | 两者都可以并排免费安装，也都能读取普通 GGUF 文件，因此下载的权重可以互相沿用。两者都没有记录导入对方聊天历史、项目或 LocalDocs 集合的路径。 | 低，双向皆然 | |
简而言之：除非有特定因素让你必须使用 GPT4All，否则请选择 Jan——例如 Intel Mac（Jan 明确不支持）、锁定的软件清单，或偏好一个不再频繁变动的代码库。当一个冻结且有文档记录的文件夹索引器就是你需要的功能时，请选择 GPT4All。
离线聊天与文档工作流
这是两者真正分道扬镳的维度，而且并不是那些文章比较的维度。
GPT4All LocalDocs 使用 Nomic 的免费设备端嵌入模型为文件夹建立索引，并允许你点击响应下方的 Sources，查看引用了哪些文件。其 默认设置 具体且值得在指定文档文件夹前了解：片段大小为 512 个字符，每个提示最多包含 3 个片段。两项设置都可以调高，而文档警告称调高后会使生成速度变慢。
关于哪些文件类型会被建立索引，GPT4All 的两个来源并不一致，而且已发布的来源更旧：设置页面列出 .txt、.pdf、.md 和 .rst，而已发布源代码中的默认值——localdocs/fileExtensions 位于 mysettings.cpp 的 main 中——是 docx、pdf、txt、md、rst。LocalDocs 在 v3.4.0 中新增了 .docx 支持，因此文档页面似乎尚未更新。聊天附件走的是另一条路径，有自己的列表：ChatView.qml 中的附件对话框会筛选 *.txt *.md *.rst *.xlsx——根据 更新日志，Excel 附件在 v3.4.0 中加入，文本、Markdown 和 rst 则在 v3.5.0-rc1 中加入。该筛选器中没有 PDF，因此 PDF 要么通过 LocalDocs 集合到达模型，要么根本无法到达。
Jan Projects 支持更广泛的文件类型：“PDF、Markdown、Office 文档（DOCX、XLSX、PPTX）、代码文件等”，并会分块和建立索引，以便在该项目的每次对话中进行检索，同时显示进度条和每个文件的分块数量。但 Jan 的文档明确列出没有嵌入模型、没有片段大小，也没有检索上限。同一页面的隐私说明称，所有文件都在你的计算机本地处理；如果使用云服务提供商，“文件会作为请求的一部分发送到该提供商的 API”。它没有说明这些描述的是已建立索引的项目文件还是聊天附件，也没有说明网关支持的自定义提供商应如何归类——因此应将其视为未记录，而不是已确定的事实。
两者都适用的一条边界是：嵌入步骤并不是 Kunavo 提供的服务。 Kunavo 提供聊天模型。GPT4All 默认在你自己的设备上计算嵌入，或者在启用相关选项后调用 Nomic 自己的 API；Jan 的引擎文档将该步骤列为 llama.cpp 可用、MLX 不可用，并且没有指定模型。如果你希望了解端到端的检索流程，RAG 实现涵盖了相关组成部分。
模型、硬件，以及每个应用实际能运行什么
Jan 在 llama.cpp 或 MLX 上运行本地模型，后者仅支持 macOS 14+ 上的 Apple Silicon；它会从自己的 Hub 下载 GGUF 模型，也可以导入磁盘上已有的 GGUF 文件，并通过原地链接而非复制来使用。GPT4All 提供一个精选目录，应用会从 models3.json 获取该目录——共有 32 个条目，最新的是 2025 年 1 月的 DeepSeek-R1 蒸馏模型，没有 Qwen3、Gemma 3 或 Llama 4（截至 2026 年 9 月 19 日检查）。其 Explore Models 页面也会搜索 Hugging Face 上的 GGUF 文件，因此该目录并非硬性限制——但这个精选货架可以合理反映该项目停止维护已有多久。
| 要求 | Jan Desktop | GPT4All（最低要求） |
|---|---|---|
| macOS | 13.6 或更高；不支持 Intel Mac | 根据 README，为 Monterey 12.6；要求表中 Apple CPU 和 GPU 行有 M1，没有 Intel 条目——见下文 |
| Windows | 10 或更高；要求 AVX2（Intel Haswell 2013+、AMD Excavator 2015+） | Windows 10；提供 ARM 安装程序，但来源说法不一致——见下文 |
| Linux | 支持；llama.cpp 引擎 | Ubuntu 22.04 LTS 或兼容版本；仅支持 x86-64，不支持 ARM |
| 内存 | macOS：8GB ≈ 最多运行 3B 模型，16GB ≈ 最多运行 7B，32GB ≈ 最多运行 13B。Windows：最低 8GB，建议 16GB | 16GB，或运行 3B 模型时为 8GB |
| GPU | Windows 上 NVIDIA、AMD 或 Intel Arc 至少需要 6GB 显存 | 任何支持 Direct3D 11/12 或 OpenGL 2.1 的设备 |
| 磁盘 | 至少 10GB 可用空间 | 最低要求表中未说明 |
Jan 的数据来自其 Mac 和 Windows 安装页面；GPT4All 的数据来自其 系统要求表和 README。均于 2026 年 9 月 19 日读取。
GPT4All 在两个硬件问题上自相矛盾，而且两者都没有明确答案。 关于 Intel Mac，其 README 称 macOS 构建“要求 Monterey 12.6 或更高版本”，并表示 Apple Silicon 可获得最佳效果，这读起来像是 Intel 可以运行；但系统要求表在 Apple CPU 和 GPU 行中填入 M1，且完全没有提到 Intel 处理器。关于 Windows-on-ARM，README 链接到 win64-arm 安装程序，并称该构建“支持 Qualcomm Snapdragon 和 Microsoft SQ1/SQ2 处理器”，而 README 自己指向的要求表却称不支持使用 ARM CPU 的 Windows 和 Linux PC。v3.10.0 发布版的资源中确实包含 win64-arm 安装程序；README 中指向它的链接是在该标签提交十分钟后、即 2025 年 2 月 25 日提交的，而要求表自 2024 年 9 月 13 日以来没有提交。因此 README 是较新的说法——但本页面无法替你解决这两个矛盾。在 Intel Mac 上，GPT4All 是两者中唯一值得尝试的，因为 Jan 明确排除了 Intel；在任何 ARM 设备上，请先安装并验证，再决定是否投入使用。
还有一个值得指出的缺口：nomic.ai/gpt4all 提供四个下载按钮，却没有版本号、没有更新日志，也没有系统要求；而 gpt4all.io 上的四个安装程序存根的 Last-Modified 日期均为 2025 年 2 月 4 日——早于 v3.10.0 标签。它们是在线安装程序，因此很可能会在安装时获取当前构建，但我无法找到它们拉取更新的仓库。不要从下载页面假定具体版本；安装后检查 About。
本地 API 服务器、云访问，以及哪些数据会离开设备
两个应用都提供兼容 OpenAI 的服务器，使其他工具可以与它们已加载的模型通信；对于共享设备而言，两者的默认设置差异很重要。
| 本地服务器 | Jan | GPT4All |
|---|---|---|
| 默认状态 | 从 Settings > Local API Server 启动 | 默认关闭 |
| 默认地址 | 127.0.0.1:1337，主机可配置为 0.0.0.0 | 端口 4891，仅限 localhost，仅支持 HTTP |
| 身份验证 | 可选 API 密钥；留空则禁用身份验证 | 没有记录 API 密钥；文档中的示例本身也不发送密钥 |
| 端点 | GET /v1/models、/v1/chat/completions，以及 Anthropic 风格的 /v1/messages；/v1/responses记录为“即将推出” | /v1/models, /v1/models/<name>, /v1/completions, /v1/chat/completions |
| 其他 | 可配置 API 前缀、受信任主机、请求超时、CORS；默认关闭服务器端 MCP 工具执行 | 可配置端口 |
来自 Jan 的 Local API Server 和 API preference 页面，以及 GPT4All 的 API server 文档，读取日期为 2026 年 9 月 19 日。Jan 的服务器文档说明其由 llama.cpp 驱动，且示例始终使用本地模型；文档没有说明远程自定义提供商模型是否可以通过端口 1337 访问——未记录，不等于排除，因此在依赖它构建系统前请自行验证。
在隐私方面，Jan 的 Mac 安装页面称，模型、线程、设置和日志位于 ~/Library/Application Support/Jan/data 下，且不会向云端发送任何内容——但其文件上传页面同样明确指出，使用云服务提供商时，文件会作为请求的一部分发送到该提供商的 API。两个应用都支持离线使用，但并非只能离线使用；一旦配置远程提供商，通常的数据处理问题就适用于接收数据的那一方。
让任一应用使用一个托管密钥
本地模型路径按请求不产生费用，但会受限于硬件能够容纳的模型。两个应用的另一种方式都是填写基础 URL 和密钥。这正是两者差异最大的地方。
| 自定义提供商 | Jan | GPT4All |
|---|---|---|
| 位置 | Settings > Model Providers > Add Provider > Add Custom Provider | Add Model > Remote Providers > Custom 卡片 |
| 线格式 | 兼容 OpenAI 或兼容 Anthropic | 仅支持 OpenAI 聊天补全 |
| 字段 | 提供商名称、Base URL、API key（即使是无需密钥的服务器，也必须填写占位符） | API Key、Base Url、Model Name——三者都必须非空才能安装 |
| 模型发现 | 保存时获取 {base_url}/models；不存在时手动输入 | Custom 卡片永远不会执行；你输入 ID，系统不会验证 |
| 能力标志 | 不会自动检测——手动为每个模型设置工具、视觉和音频 | 无需标记；远程模型没有工具或视觉处理管线 |
| 密钥回退 | 编号密钥，仅在 401、403 或 429 时重试，并提供 Test keys 按钮 | 一个密钥，无测试 |
| 采样器 | 为自定义提供商显示完整集合；内置云提供商则隐藏 | 只有 temperature 和 top_p 会发送到远程模型；stream 被硬编码为开启，max_tokens 则被有意省略 |
Jan 部分来自其 Custom Endpoints 页面，该页面明确将网关和代理列为支持场景。GPT4All 部分读取自 main 上发布的源代码：四个提供商卡片和 OpenAI 白名单位于 AddRemoteModelView.qml，三个字段标签位于 RemoteModelCard.qml，URL 构造位于 chatllm.cpp，硬编码的 "stream": true 和 Authorization: Bearer 标头位于 chatapi.cpp。这些内容均未进行运行时测试。
GPT4All 中没人写下来的事实：其内置 OpenAI 卡片是硬编码的白名单，注释为 // last updated 2025-02-24，仅包含 gpt-3.5-turbo、gpt-3.5-turbo-16k、gpt-4、gpt-4-32k、gpt-4-turbo 和 gpt-4o。即使使用有效的第一方 OpenAI 密钥，该卡片也无法提供 OpenAI 此后发布的模型。Groq 和 Mistral 卡片也带有相同注释日期的冻结列表——不过 Mistral 的列表包含 -latest 别名，这些别名仍会解析到 Mistral 当前提供的内容，因此对该卡片而言，“冻结列表”不等于“冻结模型”。对于 OpenAI 风格密钥上比 gpt-4o 更新的任何模型，Custom 卡片是可用路径——可以直接使用，也可以通过网关使用。
而 Jan 中最容易引发混淆的要点是：由于 Jan 无法检测自定义提供商的能力，你手动添加的模型默认会显示为未勾选工具能力，而 MCP 要求模型具备该能力。请在模型上勾选，而不只是对提供商勾选。
对于 Kunavo，两个应用中的值相同——基础 URL 为 https://api.kunavo.com/v1，Bearer 密钥以 sk-kn- 开头。在 Jan 中选择 OpenAI 兼容格式，并让它填充模型列表；在 GPT4All 中准确输入模型 ID，例如 claude-sonnet-4-6，因为 GPT4All 会将 /chat/completions 追加到你提供的任何基础 URL 后，并且从不检查该 ID。Jan 的 Anthropic 兼容格式也可以访问 Anthropic 风格的端点，但 Jan 的文档只说“使用你的网关文档所记录的基础 URL”，其示例也省略了 /v1——本页面未测试 Jan 在该路径中需要哪种基础字符串，因此除非你准备进行试验，否则请使用 OpenAI 格式。
# Both apps need the same two things: a base URL that ends in /v1 and a
# Bearer key. This is the check to run BEFORE you type either into an app.
curl -s https://api.kunavo.com/v1/models \
-H "Authorization: Bearer sk-kn-..."
# Jan calls this exact path to populate its model list.
# GPT4All never calls it for a Custom provider — you type the id by hand.托管路径的成本估算示例
这些是说明性 token 计算，不是实测任务成本，也不是账单上限。假设一个文档型会话发送 30,000 个未缓存输入 token——系统提示词、检索到的片段和持续对话——并接收 2,000 个输出 token，一个月重复 50 次。费率是实时的 Kunavo 目录每百万 token 价格。
| 模型 | 每 1M 个令牌的输入 / 输出 | 每次会话估算 | 估算值，50 次会话 |
|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.0280 | $1.40 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.0294 | $1.47 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.0840 | $4.20 |
注意检索设置会如何影响上述计算。GPT4All 默认最多使用 3 个、每个 512 个字符的片段——按照常见的每 4 个字符约对应 1 个 token 的估算，大约是 400 个 token——因此在这些默认设置下，使用托管密钥的 LocalDocs 提示词成本只比周围的基础聊天略高。提高任一设置后，成本会按比例增加。Jan 完全没有公布上限，因此项目文件在提示词中的占比取决于索引器的决定。如果从 GPT4All 切换到 Jan 后账单出现意外变动，首先应检查这一不对称之处。
在将这些数字作为预算之前，请根据自己的使用量进行缩放，并注意两个应用的本地模型路径都完全没有按请求计费——成本转而是硬件和电费。Kunavo 的目录金额是计费下限而非上限：当上游报告其费用时，账单金额取目录成本与上游成本乘以适用加价两者中的较高者。缓存费用和外部工具不包含在此示例中。最低充值金额为预付额度 $10，这是资金最低要求，而不是任务费用或订阅费用——请参阅计费详情。
安装、维护与许可证边界
| 信号 | Jan | GPT4All |
|---|---|---|
| 仓库 | janhq/jan，创建于 2023 年 8 月，未归档 | nomic-ai/gpt4all，未归档，未禁用 |
| 最后一次推送代码 | 2026 年 9 月 18 日 | 2025 年 5 月 27 日——一次 CI 维护提交；最近的功能提交在 2025 年 2 月 |
| 最新版本 | v0.8.4，2026 年 7 月 | v3.10.0，2025 年 2 月 25 日 |
| 2026 年发布节奏 | 0.7.6 Jan、0.7.7 Feb、0.7.8 Mar、0.7.9 Mar、0.8.0 May、0.8.1 May、0.8.2 Jun、0.8.3 Jun、0.8.4 Jul | 2026 年没有发布版本 |
| Stars / 未解决问题 | 44,551 / 531 | 77,394 / 771 |
| Python 软件包 | 不是分发渠道 | gpt4all 2.8.2，在 PyPI 上，2024 年 8 月 14 日 |
| 许可证 | Apache 2.0，并要求署名（GitHub 将其报告为 Other） | MIT |
所有行均于 2026 年 9 月 19 日从 GitHub 和 PyPI API 以及各项目的发布列表中读取。有两个日期注意事项：jan.ai 的更新日志将 v0.8.4 日期标为 2026 年 7 月 21 日，而 GitHub 发布版本标记为 7 月 23 日，因此上文写作“2026 年 7 月”；GPT4All 自己的更新日志将 v3.10.0 日期标为 2 月 24 日，而发布标签日期为 2 月 25 日。
有两项所有权细节需要谨慎表述，因为证据只能支持到这里。Jan由 Jan 团队在开源环境中开发，隶属 GitHub 组织 janhq，该组织的个人资料现在只显示“Jan”；旧的 menloresearch/jan URL 会返回 HTTP 301 并重定向到该地址。Jan 的 LICENSE 文件仍将 Menlo Research 列为署名方，而独立的 menloresearch 组织现在描述的是一款人形机器人产品。我没有找到任何解释这一变化的带日期公告，因此本页面不声称发生了分拆或出售，只陈述重定向和两个个人资料所显示的内容。GPT4All 的维护者明显改变了业务：nomic.ai 的主页标题现在围绕设计和施工，其产品页面则是用于图纸审查和代码合规的代理平台。GPT4All 页面作为遗留内容保留。Nomic 没有就 GPT4All 的状态发布声明，而标题为 “Is GPT4all dead?” 的问题仍处于未解决状态。
任何 GPT4All 页面都应包含的一条用户保护提示：nomic.ai 不提供移动版构建。其 GPT4All 页面只提供四个桌面安装程序，没有其他内容，GitHub 发布版本也只有桌面构建产物。仓库中的一个2024 年问题于 2024 年 12 月 20 日提出，随后以“不计划处理”关闭；该问题报告了一个名为 com.principia_tech.ai.gpt4all 的 Google Play 软件包，提问者称其与该项目毫无关系，并通过广告限制对话。只能从 nomic.ai 或 GitHub 发布页面下载。也不要将该项目与无关的“GPT4Free”混淆。
设置托管路径
Kunavo 尚未对任一应用连接其端点进行运行时测试，且两者都没有 Kunavo 设置页面——以上内容均来自官方文档，对于 GPT4All 还来自已发布源代码。可以验证的是两个应用所需的形态：一个以 /v1 结尾的 OpenAI 风格基础 URL、一个 Bearer 密钥，以及一个可用的 GET /v1/models，以便 Jan 填充模型列表。先运行上面的冒烟测试，在尝试期间保留一条可用路径，然后执行一个有界任务，并读取账户实际为其记录的费用。
准备为密钥充值时，创建 Kunavo 账户。如需背景信息，OpenAI 兼容 API解释了两个应用使用的线格式，最佳 LLM 网关介绍了如何比较托管选项；如果你仍在选择桌面客户端，AnythingLLM 与 Open WebUI比较了两个专注于文档的替代方案，它们都采用免费应用与按量计费 API 的模式。
常见问题
Jan 和 GPT4All 哪个更好？
它们回答的是不同问题，在这里星标数量会把方向指错：GPT4All 有 77,394 个星标，而 Jan 有 44,551 个（GitHub API，2026 年 9 月 19 日）；但仍在持续发布的是 Jan。如果你想要一款仍在增加功能、能在项目工作区中处理 PDF 和 Office 文档、可作为 MCP 主机并逐次请求工具批准、且可以指向 OpenAI 兼容或 Anthropic 兼容端点的本地聊天应用，请选择 Jan。如果你想要一个简单稳定、按文件夹建立索引的聊天机器人，其检索行为有完整文档记录；你使用的是 Intel Mac（Jan 明确不支持），并且可以接受其代码库最后一次发布是在 2025 年 2 月，请选择 GPT4All。
GPT4All 仍在维护吗？
它没有被归档，仍然可以下载，但更新节奏显示它处于休眠状态。nomic-ai/gpt4all 仓库报告 archived=false，有 771 个未解决问题；其最新版本是 v3.10.0，于 2025 年 2 月 25 日发布，此后 main 分支唯一的一次提交是 2025 年 5 月 27 日的 CI 维护提交。PyPI 上的 gpt4all 软件包版本为 2.8.2，发布日期是 2024 年 8 月 14 日。README 自己的“阅读博客了解新内容”链接返回 404。应用内精选目录停留在 2025 年 1 月的 DeepSeek-R1 蒸馏模型。Nomic 从未发布 GPT4All 已停止或进入维护模式的声明，因此请将以上内容视为日期证据，而不是公告。所有信息截至 2026 年 9 月 19 日核查。
Jan 免费吗？它有付费方案吗？
Jan Desktop 的费用为 $0。jan.ai 的主页将其描述为免费且开源；jan.ai/pricing 和 www.jan.ai/pricing 均不返回定价页面——www URL 返回 404（截至 2026 年 9 月 19 日核查）。LICENSE 文件采用 Apache 2.0，并额外增加了一行，请求在面向用户的文档和材料中注明出处；GitHub API 将其许可证报告为 Other，而不是 Apache-2.0。你实际支付的费用，要么是零（如果你在自己的硬件上运行本地 GGUF 模型），要么是你通过云提供商或自定义提供商配置接入的提供商或网关收取的按 token 计费 API 账单。Jan 不会在此基础上加价。
GPT4All 每月要花 $20 吗？
不。GPT4All 采用 MIT 许可证且免费，应用及其文档中没有任何内容需要付费才能使用。每月 $20 的数字来自 nomic.ai 全站横幅，该横幅也出现在遗留的 GPT4All 产品页面上；它属于 Nomic Platform，这是一个面向建筑、工程和施工的代理产品，提供图纸审查和代码合规功能。这两者没有关系。GPT4All 内唯一与付费相关的界面是 LocalDocs 设置中可选的“使用 Nomic Embed API”开关；它默认关闭，需要单独的 Nomic 密钥；默认检索路径在你自己的设备上运行，不收取费用。Kunavo 不提供嵌入模型，因此该步骤也不会产生 Kunavo 费用。
Jan 和 GPT4All 可以使用网关提供的 API 密钥，而不是本地模型吗？
两者都可以，区别很大。Jan 的自定义提供商对话框要求输入 API 格式（OpenAI 兼容或 Anthropic 兼容）、基础 URL 和密钥；保存时会尝试从 {base_url}/models 获取模型。它还支持编号的回退密钥，并会在 HTTP 401、403 或 429 时重试；同时提供“测试密钥”按钮，以及内置云提供商隐藏的完整采样器控制。GPT4All 的 Custom 卡片要求填写 API Key、Base Url 和手动输入的 Model Name，仅支持 OpenAI 聊天补全接口；自定义提供商从不调用 /models，没有回退密钥，并强制启用流式传输。两条路径都没有套餐限制。以上内容均来自 2026 年 9 月 19 日读取的官方文档和已发布源代码，而非实时会话。
哪一个更适合 PDF 和 Office 文档？
在格式覆盖方面选 Jan；在有文档记录的行为方面选 GPT4All。Jan Projects 会对上传文件进行分块和索引，以便在该项目的每次对话中检索，并将 PDF、Markdown、Office 文档（DOCX、XLSX、PPTX）和代码文件列为支持格式，但 Jan 的文档没有说明嵌入模型、片段大小或检索上限。GPT4All LocalDocs 使用设备端 Nomic 嵌入为文件夹建立索引，并显示哪些文件被引用，同时公布其检索默认值：512 个字符的片段，每个提示最多 3 个片段，二者均可调整。它的两个来源对于默认索引的文件类型存在分歧——设置页面写的是 .txt、.pdf、.md 和 .rst，而已发布源代码中的默认值是 docx、pdf、txt、md 和 rst。除此之外，GPT4All 的消息附件对话框会筛选 .txt、.md、.rst 和 .xlsx，因此也可以在那里附加电子表格；PPTX 和代码文件是 Jan 的列表中才有的格式。两者均于 2026 年 9 月 19 日从官方文档和已发布源代码中读取，而非来自实时会话。
任一应用支持 MCP 服务器吗？
Jan 支持；GPT4All 的文档和仓库代码搜索中都没有 MCP 支持的迹象。Jan 将自己描述为 MCP 主机，要求模型支持工具调用，并要求你在内嵌面板中逐次批准每个工具调用；面板会在你接受或拒绝前显示确切参数。如果你想关闭这一要求，还可以使用“允许所有 MCP 工具权限”设置。GPT4All 的桌面文档完全没有 MCP、工具或代理页面；它唯一的代理功能是内置 JavaScript 代码解释器，于 2024 年 12 月 19 日在 v3.6.0 中加入。如果你计划通过托管密钥运行工具，这一差异本身就决定了选择。
截至 2026 年 9 月 19 日检查了：两个 GitHub 仓库 API、两个发布列表、gpt4all 的 PyPI 记录、GPT4All 精选模型目录和安装程序标头、nomic.ai 博客标签链接、menloresearch/jan 重定向、jan.ai 的更新日志和定价 URL、Jan 的安装、文件上传、MCP、API 服务器和自定义端点文档、GPT4All 的 LocalDocs、设置和 API 服务器文档、其 README、更新日志、模型页面和系统要求表、上文链接的两个问题、README 与要求表的提交历史，以及 main 上的 GPT4All 源代码——远程提供商视图、ChatView.qml 的附件筛选器和 localdocs/fileExtensions 在 mysettings.cpp 中的默认值。未检查：任一应用连接 Kunavo 端点的运行时会话、GPT4All 在线安装程序今天提供的版本，以及 Jan 自定义提供商模型是否可通过 Jan 自己的本地服务器访问。Kunavo token 费率来自实时目录；此处每个美元示例都是说明性 token 计算，而非实测任务成本。