Skip to main content
Use this near the end of your inexpensive path, when you have the request and evidence about what that path can handle. Open this recipe in the playground, or set D1_API_KEY as in the quickstart and run the same request:

​
Use the result

Read decisions.route.action. The classes are handle and escalate; the declared costs turn them into keep and hand_off actions. top is the predicted class, not the action name your application should dispatch. The sample policy makes a mistaken keep more costly than an unnecessary handoff. Replace those costs with a policy justified by your workflow. A lower handoff rate is useful only if accepted answers remain good enough. Log reviewed failures, successful keeps and handoffs. Measure the turns kept incorrectly, handoff rate, and the actual incremental cost and quality of the stronger path. Include cases where that stronger path also fails. A self-assessment of difficulty is not proof an answer is right.

​
What was evaluated

There is no public evaluation for this recipe. Its examples demonstrate the request and action policy. Build a labelled set from your own cheap and expensive paths before automating escalation.
No public evaluation is recorded for this recipe. Its sample labels illustrate the format; measure it on your own reviewed cases before use.

​
Improve it for your application

Keep the decision IDs and outcome order stable while evaluating changes. Review a dataset, tune the wording, and compare the result against your current policy before changing production. Check fallback so you know which model actually answered.