Building with Kimi K3 and GLM-5 in Production

#ai #python #api #deepseek

Building with Kimi K3 and GLM-5 in Production

Compare two model adapters behind one client contract. Cover model pinning, structured output, fallbacks, rate verification, and a rollout checklist without unsupported benchmark claims. This draft is for review and uses dated examples; verify provider documentation before publishing.

The production problem

A model price is not a complete cost model. The application also has a model version, a provider route, a cache field, a timestamp, a retry policy, and a workload mix. After DeepSeek introduced peak/off-peak rates on 2026-08-17, those dimensions became visible to more developers. The safe response is to make every assumption explicit.

A small ledger

Record provider, model, rate_card_date, peak_class when known, input_tokens, cache_hit_tokens, output_tokens, status, latency_ms, and request_id. Keep prompt and completion bodies out of the ledger. Compute blended cost as (uncached_input * input_rate) + (cache_hit * cache_rate) + (output * output_rate). Store the native rate and currency before converting for a dashboard.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://aiwave.live/v1",
    api_key=os.environ["AIWAVE_API_KEY"],
)
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Classify this support ticket."}],
)
print(response.usage)

The key is deliberately read from an environment variable. A draft should never contain a real credential.

What to measure next

Run the same acceptance set through two model choices. Compare success, latency, output quality, cache share, and blended cost. A cheaper-looking row can lose once retries or long outputs dominate. A unified rate can be worth paying for when a team cannot schedule jobs around provider clock windows, but that is a workflow hypothesis to test with a cohort rather than a slogan.

Operational checklist

Pin model names; set a maximum output budget; use bounded retries; log the reason for a fallback; alert before a workspace budget is exhausted; review provider terms; and re-fetch the current rate card before a monthly forecast.

A worked review

Start with a small representative sample rather than a synthetic benchmark. Count repeated system context separately from new user input. If the provider reports only a combined cache field, mark the missing distinction in the report. When routing between models, preserve the request schema and compare the response against an acceptance test.

Conclusion

The durable engineering practice is not memorizing one price. It is keeping a dated rate ledger, exposing the reason for a route, and making a budget decision reproducible.

Review note

Re-run this calculation after a provider changes a model version, cache definition, billing currency, or peak schedule. Record the source URL and retrieval time so another engineer can reproduce the result.