Venice 模型发现

解决什么问题

当你的 Agent 需要在运行时根据实际能力、上下文限制和当前价格动态挑选模型时，直接硬编码模型 ID 的做法很快就会失效。Venice 的模型目录会持续更新，各模态模型在视觉支持、推理、上下文长度、分辨率约束和计费方式上差异很大，手动维护一份映射表既容易过期，也很难在请求发出前做有效的参数校验。

技能如何工作

这个技能封装了 Venice API 的三个只读 GET 端点，全部需要 Bearer API key 或 x402 SIWE 认证。

• GET /models：返回完整目录及每个模型的 model_spec，包含 capabilities（如 supportsVision、supportsReasoning、supportsFunctionCalling）、constraints（按模型族区分，如文本的 token 限制、图像的宽高比与分辨率、视频的时长区间）和 pricing（按百万 token、每张图像或每秒音频计价）。
• GET /models/traits：把 default、fastest、highest_quality 等友好名称解析为具体模型 ID。
• GET /models/compatibility_mapping：将 OpenAI 风格或第三方的模型 ID 映射为 Venice 原生 ID，方便迁移现有代码。

三个端点都支持可选的 ?type= 过滤参数，取值包括 text、image、video、music、tts、asr、embedding、upscale、inpaint、code 等。

典型流程是：在运行时按能力需求过滤模型，用 constraints 校验请求参数，用 pricing 估算成本，最后把 trait 或兼容 ID 解析为实际可用的 Venice 模型 ID。

注意点

目录是动态的，建议缓存几分钟而非几天。标记为 beta: true 的模型需要对应的 beta key，否则会返回 401。offline: true 表示该模型当前不可用，调度时应视为不存在。视频模型目前不返回 model_spec.pricing，需要调用 POST /video/quote 获取单次请求报价。另外，traits 和 compatibility_mapping 都依赖 ?type=，没有全局默认值；兼容映射只解决 ID 解析，不会验证能力——如果客户端传入的 ID 需要视觉支持，仍需通过 /models 检查解析后的 supportsVision。