Where to Start Delegating — Deciding by Cost and Reversibility

When a new model appears, the first thing most people ask is what it can now do. The moment you actually go to use it, though, the question turns into a different one: which of my tasks do I hand over, and which do I keep?

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

That second question is the real subject. The developer will supply the capability list; only your own work can tell you the scope to delegate. This article folds the six threads covered so far — specifications, computer use, distribution, automation, cost, and safety — into one page.

No new facts are added here. Every figure and quotation has appeared already, checked as of 6 September 2026, and the position is unchanged: we have run no tests, and this is a reading of published documents.

Fix the order of the questions before you decide anything

There is an order to work through when deciding whether to hand something over, and settling it in advance removes almost all the hesitation.

1. Can it be undone?
2. Would I notice if it went wrong?
3. What does it cost?
4. If it stops, who finds out?

Capability appears in none of the four. Capability decides how quickly something finishes after you have decided it may be handed over. Reverse the order and you end up delegating the things you should not have.

It is easy to see why the order gets reversed. What arrives as news about a new model is capability, and it comes with numbers, so it is easy to compare. Whether your own work can be undone has no number attached. Going first to what is easiest to compare is a natural move and a poor decision procedure.

The order also has internal structure. Work that falls out at questions 1 and 2 never needs questions 3 and 4. Some work leaves the set before you ever calculate a cost. Conversely, work that clears 1 and 2 usually clears 3 and 4 as well. So spending your attention on the first two is faster overall.

One note on granularity. Asking “should I delegate this job?” produces no answer, because most jobs mix parts you can hand over with parts you should keep. Split the job into steps first, then apply the four questions to each step. That alone usually makes the boundary obvious.

The reverse-lookup table

Arranged so you can read in from what you want to do. The cost column is about which rate tier to think in, not a prediction of your bill.

The bottom rows are the point of the table. A row that cannot be reversed leaves the set before you fill in the cost column.

Question 1 — can it be undone?

This one does the most work, and it is the one people skip.

Recalculating a cost, counting parts, drafting a description, sorting files — all of these can be run again at no cost beyond the running. A wrong answer costs you the time to notice and re-run.

Ordering, publishing, deleting, sending — these settle when they happen. There is no second attempt, and a withdrawal still leaves a record. No success rate makes these safe to delegate, because the risk is not a property of the model.

The detail worth applying: the answer is per step, not per job. “Reorder consumables” is really: check stock, work out quantities, find the supplier, compose the order, press send. Only the last of those cannot be undone. The first four can be handed over today. The delegation boundary sits inside the job, not around it.

Question 2 — would you notice if it went wrong?

Second because an invisible failure is worse than a frequent one.

A miscalculated cost shows up when you look at it. A wrong row appended to a log may sit there for months. Files deleted during a tidy-up may never be noticed at all.

This is also where the reduced monitorability matters. The developer stated that chain-of-thought monitorability declined relative to the previous generation, largely on the basis of adversarial evaluations. What that costs you is a weaker route to checking work you could not verify yourself, and it costs you most on the runs that appear to have succeeded. The full reading is in the monitorability article.

The practical response is not to read more reasoning. It is to arrange for a checkable intermediate output — the numbers used, the assumptions taken, the list acted on — so that verifying does not require re-doing.

Question 3 — what does it cost?

Only now does cost enter, and only for work that survived the first two.

Three facts carry most of the weight. Batch is exactly half of standard, so anything nobody is waiting for should be there. Fast is exactly double, so it is only worth it when a person is genuinely waiting. And above 272,000 input tokens the whole request reprices at 2x input and cache and 1.5x output — which means a 3% overshoot can more than double the bill, and splitting the material into two passes avoids it entirely.

Caching is the fourth lever: reads are a tenth of standard input, but writes are higher than standard input, so cache only the preamble you reuse. The worked arithmetic is in where the price table jumps.

One thing not to do: treat the context ceiling as a target. The 1,050,000-token window is shared between input and output, more material does not reliably improve the answer, and anything near the ceiling is billing at the higher tier by definition.

Pricing tables make sense once you understand how foundation-model applications actually consume tokens.

AI Engineering: Building Applications with Foundation Models

USD 52.40 on Amazon.com (as of 2026/09/22)

Amazon

楽天市場

ポチップ

Question 4 — if it stops, who finds out?

The one people forget, and the one that decides whether automation survives contact with a real week.

At a 72.6% computer-use success rate, stopping is the normal case. So the question is not how to prevent it but what state a halt leaves behind, and whether anyone learns about it.

The model’s published behaviour matters here. It uses context to fill in routine gaps and asks focused questions when the answer could change the outcome; in Codex it can ask asynchronously while continuing independent work, and if you do not reply it proceeds with sensible assumptions where appropriate but waits on consequential decisions. Good behaviour — and it still means a loop you thought ran overnight can be sitting on a question in the morning.

So: pin down in the specification anything you would consider consequential, write progress as you go so a halt is resumable, and put a cap on iterations, on improvement, and on spend before you start. The full treatment is in running a code CAD loop unattended.

If you are going to hand it out, do not store anything

One rule covers most of the distribution question. A tool that stores nothing is a calculator; a tool that stores something makes you a data controller.

Publishing a calculator is genuinely useful — the recipient opens a URL, needs no software, and cannot break your formulas. But the moment you add “it would be handy to keep a history”, you may be collecting personal data, with transparency, consent and privacy-policy obligations attached. Adding one feature changes your legal standing.

The other half of that rule: do not put anything load-bearing there. The terms allow removal at any time, and the service is in beta. Separate tools that are convenient to hand out from tools you cannot work without. Details in turning workshop math into a tool you can send.

Do not try to do it all at once

You do not have to design the whole thing. Start small within what you can undo, and widen only the parts that worked. Trying to design the entire system up front usually ends in never starting.

The one discipline worth keeping while you widen: record what you widened and when. It is a useless record while things work, and the first place you look when they stop.

If you cannot use it, suspect the toggle first

A common way to lose an afternoon: on business plans, access is off by default until an administrator enables it — stated plainly in the announcement. If someone says “it is supposed to be available but it is not there”, check that before touching any settings. For individual accounts the rollout was staged too, so the announcement date and the day it appears on your screen need not coincide.

How to quote a number

Three habits will keep you from going far wrong on the figures you use to decide.

Quote the condition with the number. Scores are stated to be the maximum at any effort setting, and some rows carry the measurement version and task set written into the table itself.

Read as far as the footnote. One striking contrast in these materials — 39.0% against 5.5% — is undercut by its own footnote, which explains that the low figure is an artifact of a 300-turn limit that real customers would not hit, and that the same model reached 11.5% under looser conditions. Line the two up without the footnote and you are quoting a comparison the document itself rejects.

Use the value before it was rounded. There is a place where the announcement’s prose and its table disagree — 98% against 97.6%. Where an announcement has a table, read the table.

Those three alone put you at a different level of accuracy from anything routed through a summary. The whole picture of specifications and availability is in what GPT-6 Astra actually changed.

Detours people take

1. Trying to fill the ceiling. The 1,050,000 window is input and output combined, so less is available for material — and past 272,000 the rate changes anyway
2. Handing over everything and asking it to find the bit. Easy and expensive. Narrow what you send and you also stay clear of the boundary
3. Having the formula itself generated, then distributing it. You will not be able to answer when someone asks where the number came from
4. Storing history because it is convenient. One added feature, one changed legal position
5. Removing the check to go faster. Nobody remembers that a removed check was ever there
6. Iterating with no cap. A loop that never passes runs until the bill stops it

When not to bother

It is worth being clear about where this does not pay.

• One-off work. If you will not repeat it, writing the specification and the checks takes longer than doing it
• Work where you cannot articulate the criterion. If you cannot say what “correct” means, no amount of capability will produce it
• Anything whose failure you would not notice and could not undo. Both conditions together is the one combination to refuse outright

If you are starting, start in this order

1. Take one job you do regularly and split it into steps
2. Mark each step reversible or not, and draw the line there
3. Hand over the reversible steps, and keep pressing the irreversible ones yourself
4. Add a checkable intermediate output just before the line
5. Once it is stable, move to batch whatever nobody is waiting for
6. Record what you widened and when

Remaining uncertainty

• We have not run any of this. Nothing here reports observed behaviour.
• Published scores are maximum-effort values; default-setting performance is not published.
• Cost figures are calculated from published rates, not reconciled against an invoice.
• Where the model treats a decision as consequential — and so where it waits for you — we could not establish from documents.

In short

• Irreversible steps get pressed by a person. Decided independently of any capability number
• Cost jumps at a boundary. Split it, cache the preamble, batch what can wait
• If you hand it out, store nothing. Storage changes how much responsibility you hold
• Quote numbers with the condition, the footnote, and the unrounded value

None of that is new advice, which is rather the point. The capability moved; the way you decide what to delegate did not. What changed is that more steps now clear the bar — so the value of having sorted your steps properly went up, not down.

Sources

• OpenAI, “GPT-6 Astra: A new generation of intelligence”
• OpenAI, “GPT-6 Astra Model” (API reference)

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.