Model Selection for a Legal Task

Select a model for the task. Rule: the cheapest model that clears the quality bar, not the strongest one available.

Task: [describe] Volume: [calls per day] Typical input length: [tokens] Latency requirement: [interactive / background] Privacy constraint: [external provider permitted / local hosting required] Consequence of an error: [failure severity]

Produce:

1. Hard requirements — what disqualifies a model from candidacy: context window, Hebrew support, structured output, local hosting, processing jurisdiction.
2. Three candidates — for each: fit for the task, estimated monthly cost at the stated volume, expected latency, and principal risk.
3. Decision criterion — the test you will actually run to decide. It must be measured on a real domain sample, not general impression or a public benchmark.
4. Hybrid routing — whether a cheap model should handle most cases with escalation to a stronger one for hard cases. If so: what triggers escalation and how a hard case is identified in advance.
5. Fallback — what happens when the provider is unavailable. Alternative model, degraded response, or explicit failure. Choose and explain.
6. Switching trigger — what would prompt reconsideration in six months, and how to keep the switch possible (provider abstraction, no dependence on a proprietary format).

If the task is solvable without an LLM — with regular expressions, search, or a business rule — say so first.