Tencent混元のHy4正式版が2026年11月4日に出た。preview（だいたい2026年8月末）からの更新で、いちばん現場に効くのは「同じOpenAI互換呼び出しで画像を渡せる」ことだと聞いている。自分は2026年11月5日、https://api.crazyrouter.com/v1でmodelをhy4にして一通り叩いた。このゲートウェイの一覧にはhy4しかなく、hy4-previewは載っていない。なので同入口でのpreview並走比較はできない。公式が言う増分と、今日自分が触った範囲だけを分けて書く。
読者想定は、Aider / Cline / 自前のOpenAI互換クライアントでmodel IDをhy4に差し替えようとしている人。リリースノートの再掲ではなく、切替前に自分のクライアントへ入れるチェック項目の話。
Hy4の呼び出し前提（baseとmodel）
切替そのものは短い。Base URLとmodel名を揃える。
curl https://api.crazyrouter.com/v1/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "hy4",
"messages": [{"role": "user", "content": "只回复：收到"}],
"max_tokens": 256
}'
判定はHTTPステータスだけにしない。本文（choices[0].message.content）とusage、必要ならfinish_reasonも見る。401・枠不足・モデル未開放は別障害として扱う。
AiderやClineのようなCLI／IDEエージェント側でOpenAI互換プロバイダを足している場合も、やっていることは同じで、base／キー／modelをhy4に揃えるだけだ。Aiderとの接続手順やClineの設定を既に通しているなら、差分はモデル文字列が中心になる。
Hy4で最初に検証すべきは画像入力
preview側はテキスト寄り。正式版Hy4で公式に初めて強調されるのが視覚入力だ。自分のワークフローで「週次の棒グラフ」「管理画面のスクショ」「デザイン注釈」をテキストと同じ呼び出しに載せたいなら、ここが切替理由になる。
今日は自作のQ1売上棒グラフ（北80／東160／南200／西120）をhy4に渡し、各地域の数値だけ聞いた。およそ8.9秒で本文80 160 200 120が返った。以前の単独試行でも最高値はS 200と正しく出ている。ラベルがはっきりした合成図であり、潰れた写真や複雑なUIは別物だ。自分の業務サンプルでもう一度通すのが本番前の最低ライン。
視覚入力テストで使用した合成棒グラフ。
「図が同じルートに乗るか」がpreviewから正式版への、自分が手で確認できた主差分だ。パソコン操作（CLI／GUI）や長時間agentの強化は公式主張としてあるが、今日は未検証なので切替根拠には使わない。
Hy4でHTTP 200なのに本文が空になる罠
切替当日にいちばん危ないのはここだ。ステータスは200、usageにも出力トークンが載るのに、画面上の本文が空。reasoningがmax_tokensを食い切り、finish_reasonがlengthになるパターン。
今日の同日メモ：
| max_tokens | 内容 | 結果 |
|---|---|---|
| 128〜1024 | 推論寄りプロンプト | HTTP 200、本文空、reasoningが上限まで |
| 2048 | 同上 | 本文が出始める。それでもlengthになり得る |
| 2048／8192 | コーディング長プロンプト | 本文空のままになり得る |
| 4096 | 短いコーディング副作用質問 |
rows.sort()の原地副作用を指摘し改写を返す |
| 512 | 身分確認 | 「我是混元…版本号为Hy4。」（約9.5秒） |
| 256×12 | 「只回复：收到」 | 全200・全文あり、約2.6〜4.0秒（min 2649 / max 3971 / avg ≈3156ms） |
クライアントがステータスだけ見て成功扱いにしていると、空回答を本番に流す。切替チェックリストに「content空なら失敗」「finish_reason=lengthなら上限を上げて再試行」を入れる。これは「正式版がpreviewより安定」という証拠にはならない。同ゲートウェイのpreview対照がない以上、ランキングも書かない。
Hy4の短pingが通ることと、長プロンプトが足りることは別
上の12回pingは、今日の短い往復が生きていることの確認に過ぎない。短い指示＋十分な上限なら本文は出る。一方で、推論を食う長めのコーディング指示を2048や8192にしても本文が空のまま、というケースも同日に見ている。
つまり：
- 短ping全通 → ルートと短タスクの健全性
- 長プロンプト＋タイトな上限 → 空本文リスクが残る
本番前は「自分の実プロンプト」で上限を段階的に振る。256で通ったからといって、エージェントが投げる長文が足りるとは限らない。
Hy4のコーディングは補助観察。computer useは未検証
コーディングは今回の更新の主役ではない。短いPythonの副作用質問（max_tokens=4096）では、rows.sort()が呼び出し元のリストを壊す点を指摘し、sorted(...)やmax(..., default=None)への書き換えを返した。手元の小修正の下書きには使える。大規模リポジトリ改修は測っていない。
プログラミング用途の候補を並べたいときは、coding向けモデル一覧でhy4と今の主力を並べて見る程度の使い方をしている。正式版が出たからといって、コーディングが一夜で主役になる、という結論は今日のデータからは出ない。
パソコン操作や長いagentループは公式の新規主張だが、未検証。サンドボックスなしで本番権限を渡さない。
Hy4へ切り替える／しない判断
用途ベースで切る。
-
すでに図を同じ呼び出しに載せたい →
hy4に寄せる理由がある。previewが埋められなかった穴で、今日自分が確認できた差分でもある。 - 短文と軽いコード補助だけで足りている → 正式版儀式のためにIDを変えなくてよい。コーディング側に「一変した」証拠はない。
- パソコン操作や「HTTPがずっと200」だけを理由に全切替 → 自分はしない。前者は未検証。後者は今日も空本文を見ている。
価格はTencent Cloud TokenHubの公開表で確認した。previewと同档で、入力¥6／出力¥18／キャッシュ¥0.3（100万tokenあたり）。請求の突合はレスポンスのusageを見る。
まだpreview側にいるなら、最低二手でよい。(1) 自分の業務図を1枚hy4に入れて読めるか確認する。(2) max_tokensをわざと締めて、空本文を成功扱いにしていないかクライアントを確認する。 パソコン操作と特に長いagentは、自分側の検証が終わるまで切替根拠にしない。