GLM-5 accepts text as its input modality and returns text outputs, typically through a chat-style interface (messages with roles like system/user/assistant). In practice, you’ll send JSON requests that contain a model name and a messages array, and you’ll receive a structured JSON response whose message.content (or equivalent field) contains the generated text. This makes GLM-5 straightforward to plug into existing “chat completion” style application code, including web backends, CLI tools, and internal developer portals. If you’re building an FAQ bot or documentation assistant, this message-based input format is usually the best starting point because you can layer system rules (output formatting, safety constraints) separately from user questions.
Beyond plain text, the “formats” that matter to developers are really output contracts. GLM-5 is commonly used to generate: JSON (for extraction), Markdown (for docs), unified diffs (for code changes), and structured lists/checklists (for runbooks). The key is that GLM-5 won’t magically enforce structure unless you ask it to. A practical pattern is to define a strict contract and validate it in code. For example, for extraction you can demand JSON only and validate against a JSON schema. For code changes, require a diff plus a file list, then apply the diff in a sandbox. Here’s a prompt contract that tends to work well:
System: “Return valid JSON only. No prose. Keys:
title,steps,risks.”User: the raw text you want to extract from
Validator: reject output that fails JSON parsing or schema validation, then re-prompt with the parsing error
If you plan to use tool calling, the function/tool definitions are also a “format”: you define tool schemas as JSON objects and GLM-5 returns structured tool-call requests instead of free-form text when it decides a tool is needed. Official references for these patterns live in GLM-5 overview, the function calling guide, and the migration notes that highlight tool_stream for streaming tool-call arguments: Migrate to GLM-5.
When it naturally fits, you’ll often combine these formats with retrieval. For example, you can store your docs in a vector database such as Milvus or Zilliz Cloud (managed Milvus), retrieve top-k chunks, and then ask GLM-5 to output Markdown answers that include a Sources section listing the retrieved URLs. Or you can retrieve code patterns (error-handling conventions, API usage examples) and ask GLM-5 to output a unified diff that follows those patterns. The important point is: treat “format” as a contract you enforce—GLM-5 provides flexible text generation, but your app should provide the guardrails that make the output dependable.