Overview

HowToFix 是一個模型存取服務台。你開設一個帳號、建立一個權杖,就能透過單一與 OpenAI 相容的基底 URL 觸及模型廣場中的每一個模型。

HowToFix 為何存在

取得現代模型的存取權,比使用它們更困難。一套能運作的環境通常意味著在多家供應商上各開幾個帳號,每個都有自己的註冊流程、自己的信用卡、自己的儀表板,以及自己的速率限制。你真正想要的模型散落在這一切之中,而每一個新專案都意味著要把這些接線重做一遍。

HowToFix 就是為了把這一切收斂成一個帳號與一個基底 URL 而打造。它所要解決的問題,依出現頻率排序如下:

問題HowToFix 的做法
供應商多、金鑰多。 一個需要 Claude、GPT 與 Gemini 的專案,得持有三把金鑰、三份 SDK 設定與三段帳務關係。 一個權杖、一個基底 URL。切換模型只是改動 model 欄位,而不是改動你的程式碼。
付款摩擦。 大多數供應商要求你先綁卡並做出月度承諾,才能送出請求。 預付餘額。你想花多少就儲值多少,帳號再依請求逐筆扣抵。持有帳號不需綁卡,未使用的帳號不會產生任何費用。
支出不透明。 帳單在月底才來,而你無法分辨是哪個專案造成的。 逐筆請求的使用紀錄與逐權杖的上限。每次呼叫都歸屬於發出它的權杖,而單一權杖可被獨立設限或撤銷。
用戶端被鎖定。 只會說某一家廠商協定的工具,無法使用別的模型。 與 OpenAI 相容,另提供原生 Anthropic /v1/messages 與 Gemini 路由。既有的 OpenAI SDK 只要改 base_url 就能運作。
看不出什麼才是好。 模型品質每個月都在變,而行銷頁面並不追蹤這件事。 使用排行顯示大家實際在跑哪些模型,模型廣場則顯示每一個模型的即時價格。

精確地說,這是什麼

HowToFix 是一個閘道。它不訓練模型,也不轉售單一供應商的容量。請求送達 api.howtofix.id,依你的餘額計量,然後轉送到提供該模型的任一家上游。這帶來三個值得直說的結果:

  • 價格按權杖計算,且在你送出前就看得到。 模型廣場就是價目表;沒有另一份費率表。
  • 可用性跟隨上游。 一個模型可能仍列在清單上,但若其上游故障,仍會回傳錯誤。你自己請求的狀態就在主控台的使用紀錄裡。
  • 你的帳號是控制單位。 餘額、權杖與紀錄全都位於 howtofix.id;API 主機只負責模型流量。

核心能力

能力說明
一把金鑰,多個模型單一 sk- 權杖即可觸及模型廣場中的每一個模型。撰寫當下共列出 113 個模型。
與 OpenAI 相容的 API/v1/chat/completions、/v1/models、embeddings、images、audio 等。把任何 OpenAI SDK 指向此基底 URL 就能運作。
原生供應商路由Anthropic /v1/messages 與 Gemini 路由皆直接提供,因此依這些協定撰寫的用戶端不需要轉譯層。
以用量計費餘額依請求逐筆扣抵。快取讀取、推理權杖與圖片輸出各自計價,而不是併入單一費率。
逐權杖控管任何權杖都能帶有自己的配額、模型允許清單與到期日,且可撤銷而不影響帳號其餘部分。
使用紀錄每次請求都會記錄模型、權杖數、費用與結果,並可依權杖與時間篩選。
團隊主控台一個帳號可容納多個權杖,供不同專案或不同人員使用,各自獨立設限。
終端機代理HowToFix CLI 是一個程式開發代理,會以此同一帳號進行驗證。

與直接呼叫供應商有何不同

面向單一供應商HowToFix
需管理的帳號每家供應商一個一個
專案中的金鑰每家供應商一把一把
切換模型新的 SDK、新的金鑰、新的設定改動 model 字串
計費依供應商,通常先綁卡一個預付餘額
支出可見度各供應商的儀表板涵蓋所有模型的單一紀錄
各專案上限通常不提供每個專案一個權杖,各自設限

文件導覽

#頁面說明
1文件完整逐步說明:帳號、註冊規則、金鑰、第一次呼叫、端點、錯誤
2CLI安裝程式開發代理、連上此帳號,並從終端機使用
3模型廣場即時價格與模型目錄
4排行哪些模型真正有人在用
5關於HowToFix 是什麼、各部分位於何處,以及授權立場
6條款 · 隱私 · Cookie規則與資料處理方式
取得金鑰閱讀文件