Cost, reliability and operations

The price of a single decision call is the easiest number in the project to find and one of the least useful.

A decision service can be inexpensive per request and still produce an expensive workflow. Retries, upstream extraction, logging, engineering time and, above all, the human review it creates or removes decide whether the operating model actually improves. A model that is cheap to call but sends half the work back to people may cost more than the process it replaced.

This part covers the economics and the run model: what to count, what to measure, how to fail safely and who owns the thing once it is live. Kloofvale Local Municipality is fictional, and its systems and figures are illustrative. This is an independent CloudNala analysis, and pricing below is a dated snapshot, not a quote.

In plain language:

Count the cost per resolved report, not per call. The call is the smallest part of the bill.

What the pricing page shows

On 13 October 2026 the Jev AI pricing page listed three one-time credit packages, shown with a dollar sign and no currency named:

The packages do not auto-renew. The page did not say how many credits a request consumes, which is the number you need to turn a package into a monthly cost. Responses do report token usage, so the pilot can measure it. Until it has, any per-report figure is a guess.

Treat the table as a dated snapshot. Recheck it before budgeting, and allow for exchange-rate movement and tax: a South African organisation is buying a dollar-priced service with rand. TypeSafe's direct API has its own commercial terms, which need to be compared on the same basis.

The cost model

A more honest estimate looks like this:

Monthly workflow cost
= base platform or credit cost
+ successful decision requests
+ retry and failure traffic
+ upstream extraction or retrieval
+ human review effort
+ observability and storage
+ engineering and support
+ currency and tax allowance

For Kloofvale the decision credits are small next to everything else. Fix-It's 1,400 weekly reports are short text messages, so each call carries little state. Any upstream step added later, such as transcribing voice notes, would bring its own cost and its own error rate. Engineering and support are real but mostly fixed. The line that moves is review effort. If the pilot routes 60 percent of routine reports automatically, the two call-centre staff spend their time on the hard 40 percent and on residents who need a person. If it only manages 15 percent, the municipality has added a system without removing much work.

That is why Kloofvale's headline measure is cost per resolved report, compared before and after, and why the shadow week in Part 10 measures review demand as carefully as accuracy.

Production service-level indicators

Track technical health and decision quality together. A service that is up but wrong is not healthy, and neither is one that is accurate but too slow for the queue.

Two of these are easy to miss. Fallback rate is how often the workflow ran without the model. A high fallback rate during an outage is the system working. A creeping fallback rate on a normal day is a problem nobody has noticed yet. Confidence drift is the early warning that the input has changed: a new suburb, a new service, a new way residents describe a problem. Alerts should be based on business impact, such as "urgent water reports waiting more than an hour", not only on HTTP status codes.

Retry policy

Both access routes document the same error codes, and they call for different responses:

• 401 unauthorised. Do not retry. Something is wrong with the key or configuration. Alert, investigate, and send the report to triage.
• 422 validation error. Do not retry. The request itself is wrong, usually a state or question that breaks the schema. Fix it, and send the report to triage meanwhile.
• 429 rate limit and 529 overloaded. These are temporary. Retry with exponential backoff and jitter.
• Timeouts behave like overload: retry within the same budget.

Every retry needs two limits: a maximum number of attempts and an overall deadline. Kloofvale's adapter gives each call a three-second timeout, allows at most two retries, and gives each report a ten-second total budget. If several reports in a row exhaust their budget, a circuit breaker opens and new reports go straight to the triage queue without calling the service at all, until a probe request succeeds.

The point of the design is in the diagram's title: no response, and no absence of a response, drops a report. An outage makes Fix-It slower, because more reports reach people. It never makes a report disappear.

Duplicate protection belongs here too. A retried decision must not create a second case or a second notification. The adapter keys every decision on the report id, so the case system assigns a queue and sends a notification once per report, however many times the decision was asked.

Model portfolio risk

Jev AI offers about a dozen decision models from several providers behind the same request shape. That is convenient for experimentation. It is also a trap if it is mistaken for interchangeability. The same schema does not mean the same behaviour. Each model needs its own evaluation results, latency profile, cost and approval before it touches production.

So the rule is simple: do not fail over to an alternative model during an outage unless it has already passed the workflow's acceptance tests. An untested model behind a familiar interface is a new system that nobody has evaluated. The triage queue is the tested fallback.

Change management

Any of these is a production change, however small it looks:

• The model identifier, including an alias that now points somewhere new
• Question wording
• Choice descriptions, and their order
• Score levels
• Noul criteria
• Thresholds
• State fields
• Upstream extraction
• Fallback behaviour

Version them, run the locked regression set, release to a small share of traffic first, and keep a rollback. At Kloofvale a change to the "water" description goes through the same pull request, review and regression run as a code change, because it is one. Our evals that gate real work article covers how to make the regression run a real gate rather than a report nobody reads.

Operating ownership

A decision workflow that nobody owns becomes an invisible dependency that nobody feels confident enough to fix. Each one needs named people for:

• The decision. Kloofvale's head of customer services owns what a correct route means.
• The integration. The digital services tech lead owns the adapter and its behaviour.
• The data. The data analyst owns the state fields, their sources and the redaction rules.
• Risk. The municipality's risk officer approves thresholds and review boundaries.
• Operations. The call-centre supervisor owns the triage queue and its alerts.
• Change approval. A named approver signs off material changes to wording, thresholds or model.

The list looks long for one routing decision. Most of these people already exist. The work is writing their names down before go-live, rather than discovering after an incident that everyone assumed someone else was watching.

Key points

Count the whole workflow. Credits are the smallest line. Review effort usually decides whether the pilot pays.

Pricing is a dated snapshot. Dollar-denominated, credit-based, with the per-request credit cost unstated. Measure it in the pilot and recheck before budgeting.

Retry only what is temporary. Back off on 429, 529 and timeouts within a budget. Fix 422. Investigate 401.

Fall back to something tested. The review queue is a safe fallback. An unevaluated alternative model is not.

Name the owners. Decision, integration, data, risk, operations and change approval, written down before go-live.

Previous: Part 8, security, POPIA and procurement. Next: Part 10, when to use Jev and when not to. All parts are on the series page.

How CloudNala can help

We help teams put a decision service into production with a run model they can live with: a cost model that counts review effort, indicators that join technical health to business outcomes, a retry and fallback design that never loses work, change control for wording and thresholds, and named owners for each part. The goal is a service that is still trusted, and still understood, a year after the pilot team has moved on.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Decision Review or write to us at consult@cloudnala.co.za