Treg

发布之后的表现

收入:indie(TrustMRR)库里没有 Treg(按 domain=treg.to、name≈treg、founder≈jasonzhou 均无)。所以没有任何第三方可核的收入、MRR、订阅数、挂牌价。

• 自报:创始人 2026-10-18 在播客「Crossroads」称「发布约三周后,Treg 收入已是 SuperDesign 的数倍」,未给具体数字〔自报,BigGo Finance 转载 finance.biggo.com/news/41e8fa59207733bf〕。SuperDesign 的收入本身也没有公开来源,这句无法换算。

开发者关注(最强的一组信号)库:

• superdesigndev/treg,建库 2026-07-15,2026-11-02 为 6,946 star / 611 fork,fork/star = 8.8%(新库 ≥5,000 star 的中位约 11%,不算异常),suspect 为空,未归档,pushed_at 2026-11-01。
• 星数曲线:10-09 4,874 → 10-15 5,316 → 10-19 5,779 → 10-28 6,420 → 11-01 6,847(+215,观测期最大单日)→ 11-02 6,946。24 天 +2,072,约 +86/天;lifetime_per_day 63。
• trending:3 次上 GitHub Python daily 榜(10-19 第 13、10-28 第 2、11-01 第 12)库。
• 活跃度:3,990 次提交、1,016 个分支、open_issues 29、open_prs 201(11-02 GitHub 页面)——PR 里大量是 dependabot/自动化,但也说明在持续发版(最新 release 0.29.0,11-01)。

讨论:

• Hacker News 仅 1 条:2026-10-06「Treg (OpenRouter for Tools)」,48 分 / 10 评论,作者 trollied库。评论里的质疑集中在两点:一是多数上游供应商的 T&C 不允许这种转售/代调用(toobulkeh、chickencoder);二是「好得不像真的」「官网太重、不像 OpenRouter」(Pieczasz、wiether)。正面一条来自 florianpipes:说它只是 GTM 自动化的一半,缺 webhook/调度这类有状态能力,pipe0/clay 仍有优势。
• X 本地库(core 层 560 人):只有 1 条真正讲 Treg 的中文帖(indie_maker_fox,2026-10-09,37 赞),其余 4 条是「Kylon」产品文案里的词边界误匹配库。创始人 @jasonzhou1993 不在本地库名单里,所以本地库看不到他的自述帖;网页搜索可见其持续发帖推广(9-10「Enrich Arena」、9-23「Clay for agents」、10-13 转「有人用 treg 分析 100 万条推文花 $60」等)。

官网和公开网页:

• 站活着且在更新:changelog/blog 页最后更新 2026-10-25,有 10-29 的新 launch 页(REA for Growth)、10-17、10-15 等密集上新官网。
• 公开自报口径:早期目录 2,630 端点/47 家 → 现在 4,000+/121 家;第三方目录 unfair.so 称「9-01 至 10-06 共 13 次发布,累计 282 万浏览」第三方,无法独立核实。
• 无融资/收购消息(公开搜索只命中同名生物公司 TRexBio 的 $5,000 万融资,与本品无关)。
• 异常事件:2026-10-23 安全事件〔官网 treg.to/blog/security-incident-2026-10-23〕:攻击者利用服务端功能漏洞进入生产系…,目标明确是偷平台存的 API key(包括用户自带 key);官方禁用该功能、轮换全部凭据、重置所有 token(期间大量 agent 调用返回 401)、撤销 Slack/LinkedIn/Facebook/Meta Ads 连接,并承诺对核实的损失赔付。对一个「替你保管所有 key」的产品,这是最伤的那类事故。

自报 vs 实际

为什么成了 / 没成

成了的部分是分发,不是产品本身:创始人 YouTube 20 万订阅 + SuperDesign 攒下的 7,571 star 老库,让 treg 新库 4 个月做到 6,946 star,还 3 次进 Python trending;PH 159 票、日榜第 7 也说明冷启动流量不缺。

没被证明的是留存和收入。三个具体理由:①收入完全在库外,连 TrustMRR 这种「愿意公开流水」的池子里都没有,一个宣称 0% 加价、靠走量赚钱的模式,没有流水证据就无法判断单位经济;②HN 那条 48 分帖点到了根子——转售上游 API 的合规风险,这不是执行问题而是模式天花板,供应商一封 key 目录就塌一块;③10-23 事故正好打在它唯一的护城河(凭据托管)上,「把 key 交给我」的信任一旦破一次,付费转化的阻力会显著变大,而这恰好发生在发布后两个月、本应放量的窗口。

对想跟的人

方向有位置,但别做「网关」,做「网关之上那层」。理由就在这档案里的数字:HN 只有 48 分、10 条评论,却已经有 florianpipes 指出它缺 webhook/调度/状态——也就是说 4,000 个端点被接完了,但「按信号定时跑、有状态地交付结果」这半边没人接;另一边,它 611 个 fork 里沉淀的是「怎么把 key 安全注入 agent」的代码,而 10-23 那次事故说明凭据安全本身就能做成一个独立产品。最大的坑是上游 T&C:HN 第一条评论就是「这些供应商的条款没有一家法律上允许你这么做」,跟着做转售路由,等于把命门交给别人的服务条款。

没查到的

• indie(TrustMRR):库里没有 Treg,收入 / MRR / 订阅数 / 是否挂牌出售全部答不了。
• appstore、googleplay、macappstore:库里没有;chromestore:库里没有(它没有浏览器扩展)。
• 官网定价页没有「档位表」(因为它没有档位),只能引原文;无免费额度以外的价格锚点。
• X 本地库看不到创始人自述帖(@jasonzhou1993 不在 core 名单),无法量化其推文互动;未使用 X 实时接口。
• 公司实体、注册地、融资、团队现有人数均无公开可靠来源(悉尼 / 澳大利亚为媒体口径);GitHub 只有 superdesigndev 组织,无 stargazer 明细、无贡献者名单,无法判断 star 来源质量(仅确认 suspect 为空、fork/star 比 8.8% 正常)。