Expected utility calculator
Two equally likely outcomes, each with a probability of 1/2 and with utilities of 10 and 2, give an expected utility of 6: each probability times its utility, added up. Rank risky choices by what they are worth to you, not by their average payoff. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Probabilities
- 0.5, 0.5
- Utilities
- 10, 2
- N
- 2
- Sum probabilities
- 1
- Expected utility
- 6
Expected utility is the ranking statistic of von Neumann–Morgenstern decision theory: the probability-weighted average of the utilities attached to each mutually exclusive outcome of a finite lottery. Portfolio desks use it after they have already mapped wealth into a utility number; students check homework that is not the same as expected monetary value; product teams compare launch scenarios whose payoffs are not linear in money.
What expected utility measures, and why it is not expected value
Expected utility is the probability-weighted average of the utilities attached to each mutually exclusive outcome of a lottery, not the average of the raw payoffs themselves. Two prospects can share the same expected monetary value yet differ in expected utility once a concave or convex utility transformation has been applied, which is exactly why this calculator refuses to treat outcomes as interchangeable with utilities.
You supply the utilities you already computed—from log wealth, from a CRRA transform, from a stated-preference table—and a matching list of probabilities that form a discrete measure. The engine then returns the scalar EU that textbooks, lecture slides, and investment memos all denote as E of u of X. Negative utilities are first-class: a loss state, a default, or a failed launch is allowed to sit below zero, and the weighted average still has a clear interpretation as a ranking score rather than as a cash amount.
Practical use, limits, pricing, and delivery
Use the browser tool when you want an immediate expected-utility scalar while checking a homework answer, ranking a simple insurance lottery, or explaining risk aversion without installing a decision-theory package. Results are fully deterministic: the same probabilities and utilities always yield the same expected utility. There is no language model, no external probability service, and no randomness, so the capability is safe to pin in continuous-integration checks and reproducible lesson materials.
Keep each list at or below the published item cap, pin the rounded scalar in tests, and you get a reproducible EU for homework, LMS plugins, and edge workers without standing up a computer-algebra stack of your own.
What you can do with it
Insurance and risk-averse ranking
Analysts attach utilities to loss and no-loss states, then compare buying coverage versus bearing the risk by the resulting expected-utility scalars.
Product and portfolio scenario sheets
Teams convert finite launch or market scenarios and their utilities into a stable EU for reports, oracles, and automated ranking tables.
FAQ
What happens if the probabilities do not sum to one?
The message reports the observed sum so you can correct the list. There is no silent renormalization. Validation failures are not charged.
Can utility values be negative?
Yes. Utilities may be any finite number, including negatives for losses or bad states. Only probabilities are constrained to the unit interval and to summing to one.
How is expected utility different from expected value?
Expected value averages raw outcomes. Expected utility averages the utilities of those outcomes after your preference map. Two lotteries can share a mean and still rank differently once utilities are not linear in money.
Is the expected utility calculator free?
The browser tool runs free on your device.
Where do the utility values come from?
You supply them, already computed from your own model: the log of wealth, a CRRA transform or a stated-preference table, for example. The calculator does not turn money into utility; it only weights the utilities you enter.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/fin/expected-utility \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"probabilities":[0.5,0.5],"utilities":[10,2]}'const res = await fetch("https://api.kit.forhosting.com/fin/expected-utility", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"probabilities": [
0.5,
0.5
],
"utilities": [
10,
2
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/fin/expected-utility",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"probabilities": [
0.5,
0.5
],
"utilities": [
10,
2
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/fin/expected-utility", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"probabilities":[0.5,0.5],"utilities":[10,2]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"probabilities":[0.5,0.5],"utilities":[10,2]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/fin/expected-utility", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"probabilities": [
0.5,
0.5
],
"utilities": [
10,
2
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "fin.expected_utility",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_items | 10000 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This expected utility calculator accepts an array of probabilities and a matching array of utility values, verifies that the probabilities form a discrete measure that sums to one, and returns the scalar EU equal to the sum of each p_i times u_i. Lists that fail the measure test are rejected with invalid_input so a broken model never produces a silent nonsense ranking. The arithmetic is fully deterministic, runs free in your browser, and is available over the API at $0.002 per successful request.
What expected utility measures, and why it is not expected value
In the von Neumann–Morgenstern framework a decision maker ranks risky prospects by the inner product of a probability vector and a utility vector: EU equals the sum of p_i times u_i over a finite support. That single number is the ranking statistic for choosing among portfolios, insurance contracts, exam-grade lotteries, and product-launch scenarios when the agent is not risk-neutral in money.
How this calculator validates inputs and computes EU
Call the capability with two required arrays of equal length: probabilities, the weight of each mutually exclusive state, and utilities, the von Neumann–Morgenstern number attached to that state. After validation, the core walks the support once, accumulating the probability-weighted sum of the utilities. The engine also accepts the aliases probs and p for probabilities, and utility and u for utilities, so scripts that already speak in those terms do not need a rename step. Validation rejects missing fields, empty arrays, mismatched lengths, non-finite numbers, negative probabilities, probabilities above one, and any list whose sum is not one within a tiny floating tolerance, all with invalid_input and without charging balance. There is no silent renormalization: if your weights add to ninety-nine percent, the request fails and names the observed sum, because a broken measure must not produce a ranking number that looks precise. Accepted lists keep the loop bounded for Worker isolates: up to ten thousand support points cover common classroom and business examples while still finishing quickly.
Practical use, limits, pricing, and delivery
Each successful request is one billable item at $0.002; failed validation does not consume balance. Map money into utility on your side first—this endpoint never assumes log, power, or exponential form—so a change of preference specification is a change of the utilities array, not a change of the ranking engine. Wire the endpoint into decision-theory tutorials, insurance versus self-insure worksheets, portfolio scenario sheets, or coding-interview sandboxes where you already prefer closed-form expected-utility arithmetic over approximate simulation histograms that never quite land on the same ranking twice.
Integration use cases
Homework and decision-theory labs
Students and graders verify EU = Σ p_i u_i for coins, dice, and custom lotteries, including the hard rule that probabilities must sum to one.
Technical questions
How do I compute expected utility with this calculator?
Send JSON with probabilities (array of weights that sum to 1) and utilities (matching array of finite numbers) to fin.expected_utility. The response returns n, sum_probabilities, expected_utility, and the formula EU = Σ p_i · u_i.