GLM 4.5 Air (free)

GLM-4.5-Airは、最新のフラグシップモデルファミリーの軽量バリアントであり、エージェント中心のアプリケーション向けに特別に設計されています。GLM-4.5と同様に、Mixture-of-Experts（MoE）アーキテクチャを採用していますが、より小さなパラメータサイズになっています。GLM-4.5-Airは、ハイブリッド推論モードもサポートしており、高度な推論とツール使用のための「思考モード」と、リアルタイムインタラクション用の「非思考モード」を提供しています。ユーザーは`reasoning` `enabled`ブール値を使用して推論動作を制御できます。[詳細はドキュメントをご覧ください](https://openrouter.ai/docs/use-cases/reasoning-tokens#enable-reasoning-with-default-config)

2025/7/25

131,072 トークン

仕様

モダリティ

入力

text

出力

text

サポートされているパラメータ

include_reasoning

max_tokens

reasoning

temperature

tool_choice

tools

top_p

最大出力トークン

96,000

コード例

curl https://api.fastmetal.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "glm-4.5-air-free",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

GLM 4.5 Air (free)の実際の回答

FastMetal上で実際に記録した、標準プロンプトへの回答です。

このエラーをデバッグして

以下のエラーがPythonアプリケーションで発生しています。原因を特定して修正してください。 Traceback (most recent call last): File "app.py", line 23, in get_user_orders total = sum(order["price"] * order["quantity"] for order in orders) TypeError: unsupport…

このエラーは、データベースから取得した `price` の値が文字列（`str`）型で、`quantity` が整数（`int`）型であるため、文字列と整数の乗算（`*`）ができないことが原因です。 ### 原因の詳細: - データベース（`db.query`）から返された `orders` の各要素において、`order["price"]` が文字列として取得されています。 - `order["quantity"]` は整数ですが、文字列と整数の演算は直接できません。 ### 修正方法: データベースから取得した値を適切な数値型に変換してから計算を行います。以下に修正後のコードを示します： ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) # price を float に、quantity を int に変換してから計算 total = sum(float(order["price"]) * int(order["quantity"]) for order in orders) return {"user_id": user_id, "total": total, "orders": orders} ``` ### 修正点の説明: 1. `float(order["price"])` - `price` を浮動小数点数（`floa…

応答時間 92.2秒出力 1335 トークン

コードレビュー

以下のTypeScript関数をレビューして、可読性・パフォーマンス・ベストプラクティスの観点から改善点を提案してください。 async function fetchAllUsers(page: number = 1): Promise<any[]> { let allUsers: any[] = []; let hasMore = true; let currentPage = page; while (hasMo…

以下に、可読性・パフォーマンス・ベストプラクティスの観点から改善点を提案します。対応する改善コードも併記します。 ### 主な改善点 1. **型安全性の向上** 2. **エラーハンドリングの追加** 3. **パフォーマンス改善（並列処理）** 4. **コードの読みやすさ向上** 5. **リソース管理の改善** ### 改善後のコード ```typescript interface User { id: string; first_name: string; last_name: string; email: string; status: string; } interface ApiResponse { users: User[]; } interface TransformedUser { id: string; name: string; email: string; } async function fetchAllUsers(page: number = 1): Promise<TransformedUser[]> { const allUsers: TransformedUser[] = []; let currentPage = page; const pageSize = 100; try { while (true) { const response = await fetch(`/api/users?page=${currentPage}&limit=${page…

応答時間 142.0秒出力 2313 トークン

SQLクエリの最適化

以下のSQLクエリは500万行のテーブルに対して実行すると30秒以上かかります。最適化してください。 SELECT p.product_name, c.category_name, COUNT(o.order_id) as order_count, SUM(o.amount) as total_sales, AVG(r.rating) as avg_rating FROM products p LEFT JOIN…

### クエリの問題点と改善案 #### 主な問題点 1. **インデックス不足**: - `products.is_active`, `orders.status`, `orders.created_at`, `order_details.product_id` にインデックスがないため、フィルタリングと結合が低速 - `reviews.product_id` にインデックスがないため、AVG計算が全件スキャン 2. **非効率な結合順序**: - `LEFT JOIN` を多用しているため、不要なデータが結合後の結果セットに含まれる - `orders` テーブルのフィルタリング（`status='完了'`）が遅い 3. **集計処理の非効率性**: - `AVG(rating)` がレビューデータの全件スキャンを引き起こす - `COUNT(o.order_id)` が `NULL` 値を含む行を処理 #### 最適化方針 1. **インデックス追加**: ```sql -- 必要なインデックス作成 CREATE INDEX idx_products_is_active ON products(is_active); CREATE INDEX idx_orders_status_created ON orders(status, created_at); CREATE INDEX idx_order_details_product_id ON order_details(product_id);…

応答時間 214.1秒出力 2914 トークン

Z-aiの他のモデル