LifeVal: OpenAI measures the task, not just the answer

What did OpenAI announce with LifeVal?

On November 2, 2026, OpenAI presented LifeVal, an evaluation of AI models aimed at everyday tasks. The news matters to anyone buying AI for one reason: a convincing answer does not prove that a job finished the way it was supposed to.

The proposal widens what gets measured. It does not retire academic benchmarks. Individual scores are not a LifeVal average and they do not guarantee performance for companies.

The editorial reading is a different one: a buyer has to choose a configuration by its ability to deliver the verifiable result of their task, inside a limit of error and cost. The question is not simply which answer looks better. It is who verifies what happened after it.

Why does this matter for the buying decision?

The OpenAI page shows 93,1% for the enrollment example after a change of address and 90,4% for a care and meal plan. These are scores for distinct tasks, so for a CTO or a CFO the relevant comparison starts by identifying which of the five tasks resembles the work they intend to hire, and which part of that work the configuration is supposed to finish.

A knowledge evaluation examines answers to problems. A task evaluation asks whether the execution meets defined criteria. One does not eliminate the other.

Consider the difference between receiving a list of schools and reaching a choice that respects location, preferences and enrollment requirements. The OpenAI example presents a list for review and still asks for a decision about preferences. The displayed score does not authorize saying that a child was actually enrolled outside the evaluated environment.

Preparing options and executing an action with an external effect are different things. The team has to define where the delegated work ends, when a person approves the next step and which evidence confirms the result.

How did LifeVal choose the tasks?

OpenAI started from the American Time Use Survey and the Multinational Time Use Study to identify everyday activities, then added a willingness-to-pay survey on AI assistance, with a sample representative of the United States by age, gender, ethnicity and income. The tasks cover care for dependents, health, education, household administration, personal finance, shopping and public services.

The page reports 3.995 respondents in the survey. The OpenAI technical paper, dated November 3, reports 3.837 people who completed the survey described in the method, with 1.826 retained after passing the five checks and 2.011 exclusions. The value estimates per activity come from that retained group. The difference between 3.995 and 3.837 remains unexplained in the passages consulted, and the totals should not be treated as equivalent.

The technical paper acknowledges three other limits. The willingness-to-pay survey concentrated on the United States and ran in English, which tends to underestimate tasks that are common outside the country. The American Time Use Survey and the Multinational Time Use Study data end in 2021, and recent activities may be missing from the list. The value measure, in turn, is self-reported: it depends on how the question is framed and on the imagination of the person answering.

That scope limits direct transfer to other regions, languages and routines. The sample reflects those choices of origin and does not automatically represent the work portfolio of a Brazilian company.

What do the individual scores show?

On the page, OpenAI presents five examples of performance per task: kindergarten enrollment after a move, volunteer coordination for a flood, finding housing for the family, remote access to a game with the grandmother and a plan for a relative with a recent diabetes diagnosis. Each score belongs to its own example.

The score does not come from a general impression of the text. The technical paper describes two automatic graders, both based on GPT-5.6. The primary grader applies a rubric to the answer and to the artifacts and compares the final state of the execution environment with the initial state. The hack grader, the second one, zeroes the task when it detects a forbidden shortcut, such as access to internal APIs of the environment. The set has 169 tasks in prepared environments, and the page does not attribute each score to a named model or configuration.

These scores are not the overall rate of tasks completed in the real world. The difference between evaluating the answer and evaluating the execution is in agent evaluation beyond the final answer. There is no basis for calculating an average of the examples and calling it a LifeVal result, nor for transferring the scores to business tasks.

Context interferes with the result. In the housing search, budget, location and family needs are part of the request. In the health example, the answer proposes a plan and questions for the care team. A prepared plan is not completed professional care.

What does the evaluation not answer for a company?

LifeVal is an evaluation published by OpenAI for consumer tasks, and the scores on the page do not answer how a configuration will handle the internal data, systems, authorizations and exceptions of another organization. It establishes no market standard and it does not replace academic evaluation. The examples measure consumer requests inside prepared environments.

The technical paper describes the environments and the rubric that produce the score. That helps interpret the results. It does not demonstrate, however, that a process will run the same way across different applications, databases and permissions. A test execution and a change persisted in the work system are different evidence.

Preparing a wrong suggestion and executing an improper change do not necessarily have the same effect. An aggregate score can hide the failure that the process does not accept. The team should record the type of error and who can approve or stop an action.

OpenAI relates its work to browser use, computer use and connectors, and presents the evolution of ChatGPT from a conversation tool to an agentic personal assistant. That is the company's interpretation of the product direction. It does not prove that any integration, authorization or supervision the reader needs already exists in their operation.

What changes in practice when evaluating a configuration?

The editorial proposal adds a task check to the choice of configuration, without abandoning knowledge measurements when they answer the right question. The contrast below describes a buying reading by the team, not an obligation created by OpenAI and not a capability that LifeVal demonstrated in production environments.

The table does not predict which configuration will win. Comparing isolated calls without recording review, retries and failures can shift the expense to another part of the process. If the configurations receive different context, tools or human review, the team has to record those conditions.

The result belongs to the whole package, not only to the model.

How do you calculate cost per completed task?

Cost per completed task divides the total observed cost of a set of executions by the number of tasks verified as completed in that same set. The account has to include attempts that failed and the review work considered in scope, not only the call that produced the final answer.

Cost per completed task = total cost of executions and review in the period ÷ number of tasks verified as completed.

The numerator carries model and tool usage, retries and review time, when measured and converted into cost. The denominator requires a criterion defined before the test: a delivered answer is not the same thing as a completed task.

The ratio needs company. Whoever abandons difficult tasks early spends little and completes little, and the cost per completion can fall for exactly that reason. Publishing the completion rate, or the coverage of the evaluated set, next to the cost per completed task prevents that reading. Without that pair, the price of a single completion passes for productivity.

Without verified completion, the division does not produce a valid cost. In that case, the team should report spend, attempts and observed failures.

The account does not settle risk. To decide routing, the team has to define which configurations passed the quality and safety limits for the task and then compare costs under the same conditions. The calculation applied to that choice is in cost per task in model routing.

What should the team do before changing the operation?

Before changing the operation, the team should test its own work under controlled conditions and separate an adequate answer from a completed task. The script below is an editorial recommendation: OpenAI does not run it inside the reader's company, and LifeVal does not replace that test.

1. Select representative tasks. Separate frequent requests and higher-impact cases, including real exceptions. Record context and instruction version for repetition.
2. Define result and evidence. State what counts as completion, who checks it and which document or state proves the result. Whatever cannot be verified stays pending.
3. Set error limits. Distinguish a wrong answer, an unauthorized action and an unconfirmed result. Require human review for actions the organization defines as sensitive or hard to reverse.
4. Measure the cost of the set. Record attempts, tools used, failures and human review. Apply the formula only to completed and verified tasks, keeping the same scope when comparing configurations.
5. Decide and follow up. Change only when quality and risk sit inside the limits. Repeat the evaluation when data, tools or instructions change.

A metric set for the first pilot is in agent evaluation metrics in a B2B pilot.

The test applies to any AI infrastructure, including the discussion about Nexforce Router, because it informs the team's decision about configurations, budget and error limits before any change. LifeVal does not demonstrate that Nexforce Router evaluates, scores or routes tasks by itself. Responsibility for defining the criteria and for validation stays with whoever operates the process. LifeVal does not run that test.

FAQ about LifeVal

LifeVal scores depend on the requests, the context and the test conditions, and they do not form a success rate for another company's operation. The decision requires its own criteria, observed costs and verification of the result in the environment where the task runs.

Does LifeVal replace academic benchmarks?

No. OpenAI proposes measuring performance on everyday tasks to go beyond knowledge evaluation, and the technical paper evaluates execution inside prepared environments. A task evaluation asks whether the execution meets defined criteria; the academic benchmark asks whether the answer is correct. Neither one replaces the other.

Do the five scores form the LifeVal average?

No. The page presents five scores for individual tasks, each tied to its own example. They do not form the benchmark average nor a universal success rate in real use, and there is no basis for adding them up. Adding the five scores and calling the total LifeVal performance would invent a measure that nobody published.

Does a high score guarantee the same result in the company?

No. Data, language, tools, permissions and completion criteria can change between the evaluation and the operation. The technical paper measures tasks in environments prepared by OpenAI, with a rubric defined before execution. The team should test representative tasks in the intended environment, record the conditions and compare only whole packages.

How do you know whether a configuration is cheaper per task?

Add costs, including failures, retries and measured review, and divide by the tasks verified as completed. The quotient only holds with the completion rate next to it, because a configuration that abandons difficult tasks can show a low cost without delivering the work. Quality and risk also have to meet the limits defined before the test.

References and Further Reading

The LifeVal page gathers the November 2 announcement and the examples cited here. The OpenAI technical paper describes how the evaluation was built, the environments it uses and the limitations its authors acknowledge, including the ones that decide how far the results travel. The survey appears with two totals. The two sources report different volumes of respondents, and the difference between 3.995 and 3.837 remains unexplained in the passages consulted.

What should we watch in the next releases?

The most useful signal will be transparency about which tasks enter the evaluation, how their criteria are scored and under which conditions the results can be reproduced. None of that is settled yet. It also matters to clarify why the page reports 3.995 respondents while the technical paper reports 3.837 completers.

For the buyer, the next decision stays in-house: test your own tasks, verify effects and account for the cost of every attempt. A good external score helps formulate the test. It does not sign off on the operation.