Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarytools and plugins / 2026-07-14

The model is a dial

Frontier models change the useful abstraction level of prompting. Define the outcome precisely, then allocate model effort to ambiguity, failure cost, time horizon, and reviewability.

9 parts / Hover to explore. Click to read.

Frontier models change the useful abstraction level of prompting. Define the outcome precisely, then allocate model effort to ambiguity, failure cost, time horizon, and reviewability.

Outcome contract
       +
Context + tools + saved state
       |
Assess uncertainty + failure cost
       |
Choose model + effort
       |
Execute -> independent review
Choose the model after defining acceptance and inspecting what the job needs. Extra reasoning cannot supply missing context, tools or authority, and review remains a separate job.
Context Pack (for agents)
A System 7 control panel with a central model dial and separate controls for effort, context, tools, memory, and review
Choose the model alongside the context, tools, saved state and review the job needs.

Start by deciding what would count as a useful result. Who needs it? What must be true? What evidence will you inspect before accepting it?

A capable model can often work out an implementation route after it sees the environment. You do not always need to predict every file edit in advance. You do need to give it the destination and the boundaries.

That was the July argument behind this page: put more precision into the outcome, then choose a model and working setup that can carry the job.

AI-assisted: this page was developed with AI as an accelerator. The thesis, framing and final approval remain human decisions.

Model choice becomes a question of . Where does the task need deeper ? Where would a smaller, well-supported attempt be enough? The answer depends on the remaining uncertainty, the cost of being wrong and how you will check the result.

Decide how much route to prescribe

“Open this file, find this function, add this branch, run this command” can be a useful instruction. If the procedure is deterministic or brittle, the steps may be part of the requirement.

For exploratory work, the same detail can lock in decisions before the model has inspected anything. A route you guessed at the start may be worse than one the available evidence reveals.

A brief sets the goal, constraints and acceptance criteria. An outcome contract goes further by specifying how the result earns acceptance. That gives the model room to inspect, test and revise its approach while keeping the important conditions fixed.

Three ways to frame a task. Explicit steps still help when the procedure is fixed or brittle.

A capable model may find a route you did not anticipate. It cannot reliably recover an audience you never named, a failure condition you never stated or authority you never assigned.

Leave room in the method where it helps. Be precise about what the work must deliver.

Six fields that make the result checkable

“Build a polished page” leaves most of the decision unmade. A page can look finished while serving the wrong audience or failing the important interaction.

An outcome contract gives you six places to be specific:

  • Result: the observable thing that must exist.
  • Audience: the person or system it must serve.
  • Constraints: boundaries the work must stay within.
  • Evidence: tests, sources, measurements or inspectable artefacts that support acceptance.
  • Failure conditions: states that block completion even when the output looks plausible.
  • Review gate: the person or independent process authorised to accept it.
outcome_contract:
  result: "What must exist when the work is finished"
  audience: "Who or what must be able to use it"
  constraints:
    - "A boundary the route cannot cross"
  evidence:
    - "A test, source, measurement, or inspectable artefact"
  failure_conditions:
    - "A state that blocks completion"
  review_gate: "The independent check or human approval required"

The model still needs relevant files, interfaces and references. The contract does not replace context. It tells the model what to work towards and gives the reviewer something more useful than a confident completion message.

Four questions for choosing effort

1. How unclear is the path?

A known transformation on a known file has little route discovery. A cross-system architecture decision has much more. Where choosing the route is part of the job, allow effort for inspection and synthesis.

2. What does a mistake cost?

A reversible draft can tolerate a modest first attempt. A destructive migration, public claim or production decision needs stronger safeguards and review. Size is a poor substitute for consequence: one line can affect a great deal.

3. How long must the work hold together?

A single-turn transformation has a short horizon. A build that inspects, edits, tests, diagnoses and revises has a longer one. It puts more pressure on the and on the files that preserve state between decisions.

More capable reasoning may help. So may a clearer handoff, a smaller task or a saved checkpoint. The model does not have to carry the entire history unaided.

4. How will you notice and reverse a bad result?

Clear tests and a small diff make some mistakes easier to catch. Weak observability makes them harder. That affects how much care the first attempt needs, but more model effort cannot replace a missing way to inspect the outcome. If the result cannot be reviewed, improve the checking plan before trusting it.

A hand-set scoring example using historical profile labels. It does not measure or rank models.

The matrix is a deliberately simple illustration. Its hand-set weights and cut-offs generate an example profile; they do not measure model performance or establish a provider ranking.

These were the working profile labels in the original account:

ProfileIntended kind of work
Haiku with light effortBounded, reversible, short work with a clear check
Sonnet with standard effortModerate synthesis or familiar implementation with visible review evidence
Opus with deep effortAmbiguous synthesis, costly failure or decisions that shape a long chain
Codex with high effortTool-led implementation dominated by inspection, editing and verification

Treat them as historical examples. Actual model versions, supported effort settings, permissions and task performance need checking in the host you use. The names do not make the profiles equivalent across providers.

Give the other controls their own jobs

The model selector is one decision. , context, tools, saved state and review are other decisions.

You might need a relevant source rather than a larger model. A deterministic tool rather than another paragraph of instructions. A saved state file rather than a longer conversation. A fresh audit or human decision rather than another self-check.

A configuration example. Available settings and combinations depend on the actual model and host.

This panel explores those choices. It does not configure a real run. Its 32k, 128k and 1m context labels, effort levels and permission choices are examples, not a promise that every model supports every combination. The controls are conceptually separate; real hosts may constrain them together.

More spent without relevant evidence can still produce a slow guess. A lighter setup with a clear contract, useful sources and strong checks can be enough for a bounded task. Establish what is missing before changing the model.

Allocate effort in this order

  1. Define acceptance. Write the result, audience, constraints, evidence, failure conditions and review gate.
  2. Separate the uncertainties. An unclear destination needs a better brief. An unclear route needs investigation and reasoning.
  3. Price the failure. Include reversal, public exposure, data loss and later work that would depend on the result.
  4. Inspect the environment. Identify the context, tools, tests and checkpoints already available.
  5. Choose the smallest sufficient profile. Use a profile that can carry the remaining ambiguity and consequence. Increase effort when the job calls for it.
  6. Budget review separately. Reasoning before action and independent review address different failure modes. Neither guarantees that every error will be caught.

Extra effort has a cost in , tokens, attention and throughput. Spend it where it changes the likely result or makes that result easier to trust.

Four ways this goes wrong

Maximum effort by default. The model spends longer on a route and check that were already obvious. A vague acceptance condition remains vague, however busy the model appears.

Choosing the model first. The task description is then stretched to justify the choice. Define the work before allocating the profile.

Calling a wish an outcome. Replacing instructions with a broad aspiration removes structure. Evidence and failure conditions are what make the destination usable.

Asking one control to do every job. A different model cannot supply an unavailable tool, an unread source, missing saved state or authority to accept the work. Address each of those directly.

The rule to keep

Describe the route when the route itself matters. Otherwise, define the result and its evidence clearly enough that the agent can investigate how to get there.

Then allocate effort to the uncertainty and failure cost that remain. Keep review as its own job.

Source note

The named profiles come from the original practical account. They are not benchmarks, a current buying recommendation or claims of equivalent capability. The reusable method is the set of questions: ambiguity, consequence, time horizon and reviewability.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 11