Classify the workload before choosing a model

Verifiedon 2026-07-292026.7.1

The decision is not “local or hosted”

That question is too blunt to operate. Start with a unit of work: a support reply, a classification pass, a research brief, a tool-calling sequence, or a long document transformation. A model route is only useful when it serves that unit of work under named constraints.

Build a workload card

Learner artifact — decision boundary map: Draw the workload in the centre. Put hard constraints (data handling, geographic or network boundary, maximum delay, required tool use) in a red ring. Put preferences (style, vendor familiarity, novelty) in an outer grey ring. Label the person who may trade off each hard constraint.

Lab: turn a request into an experiment

Choose one non-sensitive task. Write five cases that represent normal, difficult, long-context, malformed-input, and refusal/escalation conditions. Replace names, identifiers, and customer content with safe fixtures. For each case, write a pass condition that another reviewer could judge without guessing.

Do not let a pass condition become “looks good.” Better: “returns a three-field JSON record, cites only supplied evidence, and flags missing evidence.”

Checkpoint

Which statement belongs in a workload brief?

• A. “Use the smartest model available.”
• B. “Keep median response time pleasant.”
• C. “For the five fixture cases, return the required fields; no unsupported claims; median end-to-end time stays below the team’s agreed ceiling.”

Answer: C. It gives a result, a quality rule, a measurement population, and an owned threshold. A and B are preferences disguised as requirements.

Evidence note

This lesson is original commissioning material, not a product-configuration guide. It deliberately makes no claim about a particular OpenClaw provider key, local runtime, or routing setting. Record those separately against current primary documentation before publication.