GLM Autoroute

Binary model routing for ZAI GLM models - lightweight vs heavyweight tasks.

Introduction

1. GLM-4.7 is the default model. Only spawn GLM-5 when the task actually needs it.
2. Use sessions_spawn to run tasks with GLM-5:

sessions_spawn({
  task: "<the full task description>",
  model: "zai/glm-5",
  label: "<short task label>"
})

1. After done with GLM-5, the main session continues with GLM-4.7 as default.

Models

GLM-4.7 (DEFAULT - zai/glm-4.7)

Use for lightweight tasks: 1. Simple Q&A - What, When, Who, Where 2. Casual chat - No reasoning needed 3. Quick lookups 4. File lookups 5. Simple tasks - repetitive tasks, formatting 6. Cron Jobs - if it needs reasoning, THEN ESCALATE TO GLM-5 7. Status checks 8. Basic confirmations 9. Provide concise output, just plain answer, no explaining

DO NOT: - ❌ DO NOT CODE WITH GLM-4.7 - ❌ DO NOT ANALYZE USING GLM-4.7 - ❌ DO NOT ATTEMPT ANY REASONING USING GLM-4.7 - ❌ DO NOT RESEARCH USING GLM-4.7 - If you think the request does not fall into point 1-8, THEN ESCALATE TO GLM-5 - If you think you will violate the DO NOT list, THEN ESCALATE TO GLM-5

GLM-5 (zai/glm-5)

Use for heavyweight tasks: 1. Coding (any complexity) 2. Analysis & debugging 3. Multi-step reasoning 4. Research & investigation 5. Critical planning 6. Architecture decisions 7. Complex problem solving 8. Deep research 9. Critical decisions 10. Detailed explanations

Examples

Other Notes

1. When the user asks to use a specific model, use it
2. Always mention which model is used in outputs — example: "(GLM-5)" or "(GLM-4.7)" at the end of responses
3. After done with GLM-5 (via sessions_spawn), continue with GLM-4.7 as default
4. If you think the request does not fall into GLM-4.7 use cases, THEN ESCALATE TO GLM-5
5. If you think you will violate the DO NOT list, THEN ESCALATE TO GLM-5
6. Coding = always GLM-5
7. When in doubt → GLM-5 (better safe than sorry)
8. Heartbeat checks → always GLM-4.7 unless complex analysis needed

Memory Management with sessions_spawn

When spawning GLM-5 sub-agent sessions for ANY task (coding, research, analysis, planning, etc.), follow this pattern:

Output Rules

1. Code Output (Important) - Full code ONLY in files — do NOT include in announce unless explicitly requested - Provide summary: what was created, file path, status, dependencies - Full code disclosure ONLY when: - User explicitly requests: "Show me the code" - Debugging needs code review - User wants to improve/modify it

2. Full Announce for Other Results - Research findings, analysis results, solutions → announce FULLY to user - Do NOT shorten, summarize, or condense non-code output - User gets complete findings, not a brief summary

3. Two-Layer Memory Strategy

MEMORY.md (Curated Long-Term) - ONLY key insights, decisions, lessons, significant findings, preferences - Clean, concise, actionable - Skip routine data, step-by-step reasoning, temporary thoughts

Detailed Reports (Task-Specific Files) - For research: research/YYYY-MM-DD-topic.md (full findings, data, analysis) - For coding: add inline docs/README in code folder if needed - For analysis: output files in relevant project directories

Examples

Research task:

sessions_spawn({
  task: "Research X. Announce full findings to user. Write full report to research/YYYY-MM-DD-X.md, then write ONLY key insights to MEMORY.md (clean, concise).",
  model: "zai/glm-5",
  label: "Research X"
})

Coding task:

sessions_spawn({
  task: "Write Python script for X. Save full code to file. Provide summary (what created, path, status, dependencies) in announce. Write key implementation decisions to MEMORY.md (important only).",
  model: "zai/glm-5",
  label: "Python script X"
})

Apply this pattern to ALL GLM-5 spawns. Code in files only, summary in announce, full disclosure on request.