Jev 是开源的吗？权重闭源，工具链并非如此

不。Jev 1.13（typesafe/jev-1.13）不是开源的，找不到权重仓库，而且在 TypeSafe 的 GitHub 组织里再怎么翻，也不会翻出一个检查点、一份架构文档或一个参数量。那里有的是围绕模型的软件：十一个公开仓库，每一个都采用 MIT 或 Apache-2.0 许可，没有一个包含 Jev 本身。这就是那句诚实的一句话答案——工具链是开放的，模型不是——而这也是读者仅从“闭源、托管、未发布”中永远无法得到的那一半故事。两个日期框定了它。TypeSafe 于 2026-09-15 发布了该模型，这超出了本博客所报道的七天窗口，所以这不是一篇发布文章，其中任何内容都不应被当作发布文章来解读。有明确日期的事件是 2026-09-24，OrcaRouter 将 typesafe/jev-1.13 加入了自己的目录：这是 Jev 首次可以通过第三方网关调用，而不是只能通过 TypeSafe 自己的端点。这就是本页面所依据的例外——一个在原本无法运行之处变得可运行的模型。

这对读者而言带来的变化既有限又实际。在 2026-09-24 之前，评估 Jev 意味着在你能够测试哪怕单个决策之前，就得先开启第二段供应商关系。在此之后，Jev 与同一工作流的生成部分共用同一个密钥：一个 API 覆盖 200+ 个模型，0% 加价（按供应商标价原样透传，因此供应商降价当天这里就会同步生效），并可通过 typesafe/jev-1.13 访问该模型。你仍然按其自身的形态调用它——POST /v1/systemone，非流式——因为它不是 OpenAI 聊天补全那条路由，但你签署的合同和你轮换的密钥都是你已经拥有的那些。

答案是两个答案，而且两者都需要。

“Jev 是开源的吗？”读起来像是一个是/否问题，实际却表现得像一个由两部分组成的问题。第一部分：模型。它是闭源的。TypeSafe 没有发布 Jev 1.13 的权重、架构、训练计算量数据，也没有公布参数量，而且没有以它命名的代码仓库。第二部分：周边软件。它是开源的、得到积极维护，而且确实有用，这也是为什么寻找代码仓库的读者并非全然无望。

把两者混为一谈，无论朝哪个方向都会得出错误的结论。假设整件事是开放的，你就会花一下午去寻找一个根本不存在的检查点。假设整件事是封闭的，那么如果你担心锁定问题，就会错过真正重要的那部分——一个 MIT 许可的适配器，让你可以基于类型化决策接口进行构建，并更换其背后的实现。

TypeSafe 实际发布了什么

于2026-09-30查看，该组织有十一个公共代码仓库。星标数和推送日期会变化，因此请将其视为快照，而不是项目的固定属性。除非另有说明，所有许可证均为MIT或Apache-2.0。

• skills — MIT，约 2.4k 星标，最后推送于 2026-09-12。"用于基于 TypeSafe 的 System One API 构建的智能体技能。"

• system-one-adapter-python — MIT，356 星标，最后推送于 2026-09-22。"由 LLM API 驱动的 TypeSafeClient 直接替换方案。"

• typesafe-sdk-js — MIT，257 个星标，最后推送于 2026-09-15。TypeSafe API 的官方 TypeScript/JavaScript 库。

• typesafe-sdk-python — MIT，254 颗星，最后推送于 2026-09-26。官方 Python 库；v0.7.2 于当日新增了 `http2` 扩展，v0.7.1 于 2026-09-21 新增了与 AI 网关配合使用的示例。

• daggerverse — Apache-2.0，23 颗星，最近推送于 2026-09-25。一组 Dagger 模块集合。

• WorkflowEvals — Apache-2.0，7 颗星，最后推送于 2026-09-29。“evals.typesafe.ai 工作流代码已发布。”

• n8n-nodes-typesafe-ai — MIT，1 颗星，最后推送于 2026-09-29。

• typesafe-ai.github.io — 未声明许可证，2 颗星，最后推送于 2026-06-04。

另外三个是无关项目的分支，将在下文讨论：pulumi-clickhouse、LLaDA 和 vllm。

那个列表里没有任何东西是模型。没有 Jev 仓库，没有权重文件，没有分词器，没有服务配置——没有任何能让你搭建出一个可运行副本的东西。那些仓库是客户端侧的外围设施：两个官方 SDK、一个 agent-skills 包、一个 CI 模块集合、一套已发布的评测套件、一个 n8n 节点、组织站点，以及适配器。那是一个真实且维护良好的对外界面，而它不是模型。

如果你想避免被锁定，这是唯一重要的代码库

system-one-adapter-python 是任何人在做采用决策时影响最大的入口，其自身描述就点明了这一点：一个“由 LLM API 驱动的可直接替换 TypeSafeClient 的替代方案”。

仔细读一下这一点，因为它正在做一件很具体的事。在 System One 集成中，持久的资产是接口，而不是它背后的端点：你定义一份状态和一组具名问题，然后由某个东西针对每个问题返回一个带类型的答案。你的代码库最终就是围绕这份契约成形的。适配器把契约与实现解耦——你继续针对这个类型化决策接口来构建，而在底层产生这些决策的，是一次可替换的 LLM API 调用。

两点坦诚的限定。适配器不是模型：通过这条路径由通用 LLM 生成的答案，并不是 Jev 返回的那种经过校准的概率，所以它是一种保持接口可移植的方式，而不是一种在没有 Jev 的情况下获得 Jev 行为的方式。而且它明确是一个 TypeSafe 项目——这个逃生舱门是由你可能想要逃离的那家供应商构建的，这聊胜于无，但并不等同于一个独立的逃生舱门。

两个分叉，以及它们所引出的推论

这十一个仓库中有三个是复刻仓库。pulumi-clickhouse 是 ClickHouse Cloud 的 Pulumi 提供程序，Apache-2.0 许可，3 颗星，最后推送于 2026-07-08。另外两个则是被当作证据来解读的仓库，而这两种解读都是错的。

• vllm — Apache-2.0，3 颗星，最后推送于 2025-05-23。高吞吐量推理与服务引擎的一个分支。

• LLaDA — MIT，12 星标，最后推送于 2025-06-17。"大型语言扩散模型"官方 PyTorch 实现的一个分支。

偷懒的推断不言自明：他们 fork 了一个扩散语言模型仓库，所以 Jev 一定基于扩散。事实并非如此，而那个 fork 完全说明不了 Jev 的架构。fork 是别人代码的副本，受别人的许可证约束，待在某个组织里，其原因从它自己的最后推送日期就一目了然——2025 年 5 月和 6 月，比 Jev 公开发布早了一年多，而且此后一直没被碰过。这两个仓库都不是 TypeSafe 在九月发布的内容的一部分。如果你想知道 Jev 是怎么工作的，TypeSafe 并没有公开这些，其组织里也没有任何 fork 能填补这个空白。

关闭权重究竟会让你付出什么代价

四件事，而且它们是具体的，而非哲学性的。

• 你无法自行托管。没有可运行的工件，因此，供应商服务中断或访问权限变更，并不是你通过自行部署一份副本来就能绕开的事情。

• 你无法审计。TypeSafe 确实为 Jev 1.13 发布了一份参差性页面——最后审阅于 2026-09-17——其中列出了模型不可靠的地方：按字面而非意图解读措辞、任何涉及算术的事情、日期和时间比较、间接表达和双重否定、充满无关细节的大型状态、状态中的对抗性内容、相互矛盾的指令和标准，以及它并不保证的结构性不变量，例如真/假答案与其等价的是/否选择不一致。那份页面异常坦诚，但这仍然是厂商在给自己的作业打分。TypeSafe 之外无人检查过这些权重。

• 你无法进行微调。没有可供适配的基础模型，因此 Jev 处理得很糟糕的决策任务会一直处理得很糟糕，直到供应商改变它——jaggedness 页面自己给出的补救措施是你代码中的变通方法，而不是训练运行。

• 你无法固定到超出厂商别名的版本。typesafe/jev-1.13 是一个托管名称，因此下个月响应调用的，就是届时 TypeSafe 以该名称所提供的任何内容。

这些都不是 Jev 独有的，也全都算不上丑闻；这是托管式决策模型所做的取舍，而与之相抵的是，你永远不必背负检查点、GPU 账单或推理栈。在基于它构建之前，值得弄清楚你站在这个取舍的哪一边。

既然你现在可以这样称呼它，Jev 是什么

Jev 不是聊天模型，也不生成散文。你发送一个状态——要评判的材料，可以是文本、对象或数组——再加上一组命名问题，它会为每个问题返回一个结构化答案。每个问题都是三种原语之一：

• noul — 一个真/假判断，以校准后的概率返回。

• 选择 — 从最多 255 个带标签的选项中挑选一个。

• 评分 —— 按照 2 到 10 个级别的有序量表进行评分。

TypeSafe 自己的文档展示了一个以 0 为起始索引的评分示例；Jev 1.13 模型卡则公布了 2–10 个等级。两者均出自供应商自己的材料，本页并未在它们之间杜撰出一种调和说法。

该训练方法是 TypeSafe 自创的说法：面向校准决策的强化学习（Reinforcement Learning for Calibrated Decisions，RLCD），并在发布文章中围绕带有诚实概率的校准决策这一维度，将其与 RLHF 和 RLVR 进行对比。RLCD 是 TypeSafe 的术语，而不是通用的机器学习缩写，应将其理解为厂商描述，而非一种经过独立刻画的技术。

访问不再受限：Jev 自 2026-09-21 起已全面可用，“候补名单”这一说法已弃用。“抢先体验”仍是 TypeSafe 在其首页上当前使用的措辞，因此它不是一个可以随意否定的说法——它只是厂商的标签，而与之同时发布的运营限制则是具体明确的。

我们卡片上的数字：65,536 token 的上下文，供应商记录的则是合并状态加问题合计约 64K 的输入。如果你看到过为 Jev 引用的更小数字，那只是状态预算本身，而不是另一项与之竞争的测量值，两者不应被呈现为相互矛盾。价格为每百万输入 token 0.042 美元，输出计费为零——输出没有 token 可计量，因为类型化决策不是散文。

我们自己的服务数据，来自我们自己的流量而非供应商的基准测试，在截至 2026-09-30 的七天内：p50 151 毫秒，p95 247 毫秒，约每秒 349 个输出 token，错误率 0.49%，共服务了 7620 万个 token。该时间段内每日 p50 依次为 175 → 170 → 163 → 161 → 170 → 147 → 143 毫秒，其中有一个真正的异常值——2026-09-28 的 p95 为 2,448 毫秒，它属于该序列，但并非常态。

TypeSafe 的主要宣传语——标注为厂商自述、且未经独立复现：“速度提升 193.6 倍，成本降低 444.6 倍”，脚注指向 System One 工作流；一个完整算例：0.114 秒花费 0.000081 美元，而 LLM 为 8.566 秒花费 0.013880 美元；“每十亿输入 token 42 美元”；以及“零幻觉”——这只是一个关于置信度估计的说法，而非零错误的证明——我们评测卡上 0.49% 的错误率才是诚实的制衡。TypeSafe 还直言，它无法证明其定价没有受到补贴，并且其公开发布的评测通常是在该服务所在的西海岸用笔记本电脑运行的。它自己的基准测试卡仍标记为待定。

第三方仓库确实存在，但我们并不为其背书

搜索 "jev github" 最终会浮现出并非 TypeSafe 所有的仓库：包装器、提示词集合、适配器实验，以及任何新模型周围都会出现的那个熟悉的 "awesome" 列表。它们不属于厂商发布的内容，未经厂商审核，其 star 数衡量的是好奇心而非正确性。它们可能有用；但它们不是文档，其中没有任何内容能说明 Jev 是如何工作的。

什么会改变这个答案

一份权重发布、一个已公开的架构，或一项针对决策质量而非延迟的独立评估。这三者中的任何一个都会改变本页面的第一个词。在那之前，搜索有一个稳定的答案，而其中值得付诸行动的部分是工具链：如果你要基于类型化决策接口来构建，那么一个采用 MIT 许可证、可替换底层模型的适配器，就是你能重新审视的决策与无法重新审视的决策之间的区别。

Jev 1.13 已收录在我们的目录中，位于 typesafe/jev-1.13 下，与堆栈其余部分使用同一密钥，并通过专用的 systemone 端点路由，而非 chat-completions 形式。模型是闭源的，工具链是开源的，而这两部分现在都可以从同一个地方访问。