Ask Jev before your agent spends a dollar

An agent can spend a dollar on a technically valid call that does nothing for the task. Before buying the next render or lookup, give Jev the task, the proposed call and the evidence already collected. Ask whether the call advances the job. Then let code decide whether to execute it within the user's permission and budget.

A second classifier call is worthwhile only if it improves the whole run. Count its cost, the delay it introduces and the useful work it mistakenly blocks. The design below is a proposed spending gate; its savings have to be measured on the work you intend to run.

Reject the obvious mistakes before asking a model

Suppose an agent is making a square product image. It proposes a third render, although the second already passed review. That might be a duplicate. It might also be a requested revision to fix a logo. The budget alone cannot distinguish the two.

Some checks need no model. Validate the service and parameters against an allowlist. Check whether a completed output matches the same inputs and version. Check whether an earlier asynchronous job is still running. Reject a call that exceeds the remaining job budget before paying for a classification of it.

Keep authorization explicit. Permission to make a draft does not authorize an ad purchase. A relevance score must never expand the list of allowed actions.

Give Jev evidence it can judge

Jev returns typed decisions. Your application supplies the possible choices and the criteria for each; a separate model can write text later if the task needs it. The TypeSafe introduction describes that interface.

For a proposed purchase, supply a compact record: the task's acceptance criteria, the intended service and inputs, the current quote, the remaining allowance, and summaries of relevant completed outputs. Preserve source IDs in your application so a reviewer can open the underlying evidence.

Ask three narrow questions against that same state:

Question	Suggested decision contract	How code uses it
Does this call address an unmet requirement?	needed, unrelated, uncertain	Unrelated work stops; uncertain work needs review
Does an existing output already satisfy the requirement?	sufficient, insufficient, uncertain	Sufficient output can be reused
Is a supplied cheaper option adequate?	adequate, inadequate, uncertain	Consider only an option whose availability and quote were checked

These are application-level labels, not a raw API response. Parse and validate the provider's result before applying policy. A score is evidence for a branch; it is not a proof that the branch is correct.

Do not ask Jev to discover a cheaper provider from memory. Fetch the candidates first, including their relevant limits. A cheaper endpoint that cannot preserve the product reference is not an equivalent alternative.

Keep the purchase behind ordinary code

The sequence is short enough to inspect:

Proposed call
  -> input, permission, cache and budget checks
  -> Jev judges the remaining ambiguity
  -> code applies the acceptance policy
  -> reserve the permitted spend
  -> execute through Vaaya
  -> record the result and final charge

Reserve budget atomically in your application so two concurrent calls cannot both consume the same remaining allowance. Account for the Jev call too. When a quote changes, recheck the amount before execution rather than treating an earlier approval as unlimited.

For an asynchronous render, retain the returned job ID and retrieve that job's result. Resubmitting the generation creates another attempt. Vaaya's tool reference separates execution from result retrieval.

A timeout at the decision step needs a predefined fallback. For optional work, return the best existing result or request review. For required work already authorized by a deterministic policy, follow that policy within its cap. A network failure should not silently create a larger spending allowance.

A blocked quote is not money saved

Consider a hypothetical batch of 100 proposed renders at a quoted $1 each. The gate declines 20. You can report $20 of proposed spending blocked. That is not yet a measured $20 saving: some calls might have failed, the ungated agent might have stopped early, and the gate may have rejected useful work.

Compare complete runs using the same acceptance criteria:

Gated cost = Jev usage + executed calls + billed retries and fallbacks
Net cost difference = baseline run cost - gated run cost

Record each attempt once. A later aggregate settlement of already counted usage is not an additional model call. Keep skipped proposals in a separate decision log; they have no downstream purchase receipt because that purchase never happened.

The review needs completed-task rate, total billed cost, time to a usable result, and false blocks. Sample rejected calls for human review. A system that spends less by refusing to finish the task has not met the same objective.

What the routing benchmark does show

Vaaya's published Jev routing benchmark reported 34.7% lower usage cost and 34% slower end-to-end p95 latency in its 50-prompt comparison. Jev classified tasks, and code chose the answer model. The test produced text and plans; it did not execute their purchases or tool actions.

That result is a reason to measure both cost and delay. It does not establish the savings of this proposed spending gate. The AI SDR spending-policy guide applies the same accounting question to a narrower sequence of research and outreach decisions.

Start with shadow mode on one workflow. Record what Jev would have stopped without changing execution. Have a reviewer inspect the disagreements, freeze the policy, then test the gate on a bounded set of jobs. Keep the record that connects each proposed call, decision, executed action and receipt.

You can use Jev on Vaaya, along with 500+ model options and 1,500+ endpoints. One API key, one balance, a receipt for every call.

Questions

Can Jev authorize an agent to spend money?

Jev can judge whether a proposed call supports a task. Your application must enforce the user's permission, allowed actions and remaining budget. A model score does not grant authorization.

Does the Jev routing benchmark prove that a spending gate saves money?

No. That benchmark compared model-routing policies for text answers. It did not execute purchases or test a gate that blocks paid tool calls. A spending gate needs its own evaluation.

Should every paid call go through Jev?

Use ordinary code for exact duplicates, invalid inputs, cached results and exhausted budgets. Use Jev for judgments that remain ambiguous, and include its own cost and delay in the comparison.