Snapshot date: August 4, 2026 Asia/Shanghai. The required same-day keyword report was missing, so this article uses the August 3 report only as fallback context. That report listed glm api, qwen api, chinese ai api, aiwave pricing and Tier 1 docs queries as monitored terms.
Why tool fees matter
Enterprise AI cost control is moving beyond text token prices. A customer-support workflow may call web search, a coding agent may use code execution, a research assistant may read documents and a compliance workflow may require structured output plus audit metadata. If the router only compares input and output token rows, the application can still lose budget control through tool fees, retries and region-specific model choices.
GLM and Qwen are useful examples because their public documentation exposes different cost surfaces. Z.AI lists GLM model token prices, cached-input rates and built-in tool fees such as web search. QwenCloud lists context-tiered text generation prices, built-in tool fees for web search and image search, and notes that function calling and MCP have no separate tool fees while their descriptions still count as input tokens. That is exactly the level of detail a production router should understand.
The AIWave angle is practical: give Tier 1 and Tier 2 teams one OpenAI-compatible endpoint while keeping provider-specific economics visible. Internal links should route readers to AIWave pricing, available models, API documentation and the GDPR-aware deployment guide. The content should avoid broad promises and show the actual control plane.
Verified pricing signals
Z.AI's official pricing page states that prices are in USD. It lists GLM-5.2 at $1.4 input, $0.26 cached input and $4.4 output per 1M tokens, with cached input storage marked as limited-time free. It also lists GLM-4.7-FlashX at $0.07 input, $0.01 cached input and $0.4 output, and web search at $0.01 per use. Those rows show why a GLM route policy should include model tier, cached-input behavior and tool call count.
QwenCloud's pricing page lists qwen3.7-plus at $0.40 input and $1.60 output per 1M tokens for requests up to 256K tokens, then $1.20 input and $4.80 output for 256K to 1M. It lists qwen3.7-flash at $0.03 input and $0.13 output up to 32K, then $0.10 input and $0.40 output from 32K to 256K. The same page lists web search at $10 per 1K calls and image search at $8 per 1K calls, while function calling and MCP have no separate tool fees.
Those details create a clear engineering rule: a router should price the whole job, not only the selected model. A Qwen request below 32K has a different rate from a long-context Qwen request. A GLM workflow with web search can be more expensive than its token row suggests. A function-calling workflow still pays for tool schemas as input tokens. A GDPR-restricted customer may reject a cheaper route if the approved model family or data region does not match policy.
| Route concern | GLM signal | Qwen signal | Router field |
|---|---|---|---|
| Text generation | Model-specific input, cached input and output rows | Context-tiered input and output rows | token_rate_plan |
| Web search | $0.01 per use | $10 per 1K calls | tool_call_budget |
| Function calling | Supported in model docs, schemas affect prompt cost | No separate fee; descriptions count as input tokens | schema_token_estimate |
| Long context | Route to higher reasoning tier only when needed | Rate changes by context tier | context_band |
| Compliance | Customer must approve route family | Customer must approve route family and region | policy_allowlist |
Router policy
A GDPR-aware router starts before the API call. Classify the request by data category: public, internal, confidential or personal data. Attach customer policy: allowed countries, allowed model families, raw prompt retention, output retention, logging detail and whether tools may fetch external sources. Only after those checks pass should the router choose GLM, Qwen or another model.
Tool policy deserves its own allowlist. Web search is not just a fee; it can move data into a different workflow and produce citations that must be stored or reviewed. Code execution can expose snippets or generated files. MCP tool descriptions can become large input payloads. For finance and legal teams, the cost and data-flow implications are inseparable.
Budget policy should use a hard cap and a soft alert. The hard cap blocks a request before spend. The soft alert records that the job is close to the budget and can be optimized later. Useful fields include estimated input tokens, context band, expected output cap, enabled tools, maximum tool calls, expected fallback route and customer policy ID. After the response, reconcile observed usage with the estimate.
Runnable policy code
The following Python code evaluates a route before any model call. It is intentionally independent of the SDK so it can run in API middleware, a queue worker or a serverless function.
from dataclasses import dataclass
from typing import Literal
DataClass = Literal["public", "internal", "confidential", "personal"]
Tool = Literal["web_search", "image_search", "function_call", "mcp"]
@dataclass
class CustomerPolicy:
customer_id: str
allowed_models: set[str]
allowed_tools: set[Tool]
personal_data_allowed: bool
raw_prompt_retention: bool
max_job_usd: float
@dataclass
class RouteRequest:
model: str
data_class: DataClass
input_tokens: int
max_output_tokens: int
tools: list[Tool]
RATES = {
"glm-5.2": {"input": 1.4, "cached": 0.26, "output": 4.4, "web_search": 0.01},
"qwen3.7-plus-small": {"input": 0.40, "cached": 0.40, "output": 1.60, "web_search": 0.01},
}
def estimate_usd(req: RouteRequest) -> float:
rates = RATES[req.model]
token_cost = req.input_tokens / 1_000_000 * rates["input"]
token_cost += req.max_output_tokens / 1_000_000 * rates["output"]
tool_cost = sum(rates.get(tool, 0.0) for tool in req.tools)
return token_cost + tool_cost
def authorize(policy: CustomerPolicy, req: RouteRequest) -> tuple[bool, str]:
if req.model not in policy.allowed_models:
return False, "model_not_allowed"
if req.data_class == "personal" and not policy.personal_data_allowed:
return False, "personal_data_blocked"
blocked_tools = set(req.tools) - policy.allowed_tools
if blocked_tools:
return False, f"tools_not_allowed:{sorted(blocked_tools)}"
estimate = estimate_usd(req)
if estimate > policy.max_job_usd:
return False, f"budget_exceeded:{estimate:.4f}"
return True, f"authorized:{estimate:.4f}"
if __name__ == "__main__":
policy = CustomerPolicy("acme-us", {"glm-5.2", "qwen3.7-plus-small"}, {"function_call"}, False, False, 0.03)
req = RouteRequest("glm-5.2", "internal", 12_000, 800, ["function_call"])
print(authorize(policy, req))
Move this policy into the request path before calling AIWave or any upstream provider. The model call should receive an already-approved route. That separation makes incidents easier to debug: authorization failed, the model call failed, validation failed or fallback failed. Blending those steps into one catch-all exception makes operations slow.
Rollout plan
Start with one tool-enabled workflow, such as internal research summaries. Disable raw prompt retention by default, allow web search only for public data and set a conservative job budget. Run the same fixtures through a GLM route and a Qwen route. Score factuality, JSON validity, citations, cost, latency and reviewer acceptance. Do not use external web search tools on confidential or personal data unless the customer policy explicitly allows it.
After the first workflow is stable, add one customer-facing use case with stricter output validation. Support drafting is a good candidate because the application can require citations to internal documents, block unsupported claims and route ambiguous cases to a human. Track cost per accepted draft, not just cost per request. If web search improves answer quality but doubles the accepted-task cost, make that tradeoff visible.
For SEO and sales, position this as cost governance and compliance-aware routing. Tier 1 engineering leaders are not looking for a one-line cheapest model. They want to know whether GLM and Qwen can be added to an existing stack without losing procurement clarity, incident response or regional policy controls. A transparent router is the durable answer.