DEV Community: anicca

SDK 2.51.0 Does Not Opt You Into Fast Mode: Log Both Tiers

anicca — Sun, 02 Aug 2026 02:32:05 +0000

SDK 2.51.0 Does Not Opt You Into Fast Mode: Log Both Tiers

This is for the Python engineer operating a production client on the Responses API or Chat Completions API and deciding whether OpenAI Python SDK 2.51.0 changes latency behavior. A lockfile diff is not proof that a request entered Fast mode. Keep the SDK signature, the final request body, and the service's returned processing tier in separate receipts.

The decision in one screen

SDK 2.51.0 exposes service_tier; upgrading the package alone does not opt an application request into Fast mode.
requested_service_tier and response_service_tier answer different questions. A request sent as fast can receive default after a Standard downgrade.
Responses and Chat Completions need endpoint-shaped mocks. The Chat response must contain choices, and the two paths should be executed independently.

Start with the released SDK and the local receipt, then carry the same fields into the first live sample.

The upgrade does not select Fast mode

The OpenAI Python SDK v2.51.0 release page lists the feature api: fast tier and the helper-method fix api: add fast tier to helper methods. That is evidence that the client can accept the option. It is not evidence that an application sent the option, or that the service processed the request at that tier.

The official Fast mode guide says to select the request-level mode with service_tier="fast"; for supported models, service_tier="priority" provides the same behavior. For the project setting, it says, “Requests that don't specify a service_tier then default to Fast mode.” That is a separate change from upgrading the SDK.

The current guide says, “Priority processing was renamed Fast mode on July 30, 2026.” Existing code that sends priority may remain compatible with the documented option, but name compatibility is not a latency or billing receipt. The conclusion here is an inference from the release page and the guide: the SDK adds the control surface; it does not make the production choice for you.

Store the requested and returned tiers separately

Persist these fields together, but never collapse them into one value.

Field	Question it answers	Minimum receipt
`requested_service_tier`	What did the client select?	Final HTTP request body
`response_service_tier`	What tier did the service report using?	Response, request ID, model
`latency_ms`	Did the request meet the SLO?	Live API measurement
`cost`	What was the billing effect?	Usage dashboard or billing data

The official guide says that Fast mode requests can be downgraded to Standard when traffic ramps too quickly. The request is then charged at Standard rates and the response contains service_tier: "default". Its documented example condition is at least 1 million tokens per minute combined with a more-than-50% TPM increase within 15 minutes.

The mechanical check is simple: requested_service_tier is fast or priority, while response_service_tier is default. Record that pair as a Standard result; do not infer success from the request field alone.

The request body cannot tell you whether that downgrade happened. If the log stores only fast, the later investigation has to guess. A MockTransport response is different: it is a local fixture, so it cannot be presented as evidence of a live downgrade.

Endpoint-shaped mocks make both API paths testable

The v2.51.0 source exposes service_tier on all four methods below:

responses.create
responses.parse
chat.completions.create
chat.completions.parse

The generated v2.51.0 source contains this parameter declaration in the four method signatures:

service_tier: Optional[Literal["auto", "default", "flex", "scale", "priority", "fast"]] | Omit = omit

The ChatCompletion model contains this field declaration:

class ChatCompletion(BaseModel):
    choices: List[Choice]

A Responses-shaped JSON returned from /v1/chat/completions makes the mock unexecutable or tests the wrong boundary. The executable code below returns a Chat fixture with choices[0].

The following code ran in an isolated virtualenv with openai==2.51.0 and httpx==0.28.1. It measures the two create request bodies and checks the four create/parse signatures. It does not measure live speed, billing, model eligibility, or the service's returned tier.

import inspect
import json

import httpx
from openai import OpenAI
from openai.resources.chat.completions import Completions
from openai.resources.responses import Responses

seen = []

def handler(request):
    body = json.loads(request.content)
    seen.append({"path": request.url.path, "body": body})
    if request.url.path.endswith("/chat/completions"):
        return httpx.Response(200, json={
            "id": "chatcmpl_feedback_recovery",
            "object": "chat.completion",
            "created": 0,
            "model": "gpt-5.6-sol",
            "choices": [{
                "index": 0,
                "message": {"role": "assistant", "content": "ok", "refusal": None},
                "finish_reason": "stop",
            }],
            "usage": None,
            "service_tier": "priority",
        })
    return httpx.Response(200, json={
        "id": "resp_feedback_recovery",
        "object": "response",
        "created_at": 0,
        "status": "completed",
        "error": None,
        "incomplete_details": None,
        "instructions": None,
        "max_output_tokens": None,
        "model": "gpt-5.6-sol",
        "output": [],
        "parallel_tool_calls": True,
        "temperature": 1.0,
        "tool_choice": "auto",
        "tools": [],
        "top_p": 1.0,
        "truncation": "disabled",
        "usage": None,
        "metadata": {},
        "text": {"format": {"type": "text"}, "verbosity": "medium"},
        "reasoning": {"effort": None, "summary": None},
        "store": True,
        "service_tier": "priority",
    })

client = OpenAI(
    api_key="sk-test",
    http_client=httpx.Client(transport=httpx.MockTransport(handler)),
)
responses_result = client.responses.create(
    model="gpt-5.6-sol", input="test", service_tier="fast"
)
chat_result = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "test"}],
    service_tier="priority",
)

assert seen[0]["body"]["service_tier"] == "fast"
assert seen[1]["body"]["service_tier"] == "priority"
assert responses_result.service_tier == "priority"
assert chat_result.service_tier == "priority"
assert "service_tier" in inspect.signature(Responses.create).parameters
assert "service_tier" in inspect.signature(Responses.parse).parameters
assert "service_tier" in inspect.signature(Completions.create).parameters
assert "service_tier" in inspect.signature(Completions.parse).parameters
print(json.dumps({
    "seen": seen,
    "response_service_tier": {
        "responses": responses_result.service_tier,
        "chat_completions": chat_result.service_tier,
    },
}, sort_keys=True))

The receipt showed service_tier: "fast" in the Responses request and service_tier: "priority" in the Chat Completions request. Both local fixtures returned response_service_tier: "priority", and the Chat fixture included choices[0]. This proves that the v2.51.0 client serializes the selected values on both create paths and exposes the option on all four signatures. It does not prove that Fast mode was used by a live request.

If the application uses parse, add its structured-output fixture too. A parse signature and an application-specific response that parses correctly are separate checks.

The rollout boundary: downgrade, exclusions, and cost

The official guide describes Fast mode for gpt-5.6-sol as up to 2.5x faster. That is OpenAI's product statement, not a benchmark from the MockTransport above. Use a live API sample for your own SLO.

Eligibility is another boundary. The guide says, “Long context, fine-tuned models, and embeddings aren't supported.” The FAQ describes Fast mode as supporting “the same multimodal capabilities available on Standard,” including image inputs. Large ETL or batch jobs are not listed as an eligibility exclusion, but the guide says, “Avoid running large extract, transform, and load (ETL) or batch jobs in Fast mode.” Check the model, context length, input type, and workload before widening a feature flag.

Use this eligibility table before rollout:

Workload or input	Decision
Supported model with short context	Check the model's Fast mode price and availability
Long context	Not eligible
Fine-tuned model	Not eligible
Embeddings	Not eligible
Image input supported by Standard	Fast mode follows the documented multimodal support
Large ETL or batch job	Poor candidate for a rapid ramp

The official price table is per 1M tokens. For short-context gpt-5.6-sol, it lists:

Processing	Input	Cached input	Cache writes	Output
Standard	$5.00	$0.50	$6.25	$30.00
Fast mode	$10.00	$1.00	$12.50	$60.00

In this example, input and output are each twice the Standard price. Long-context, data-residency, and model conditions can change the applicable row, so check the model-specific table before rollout. A speed claim without its pricing and eligibility boundary is not enough for a production decision.

How to roll out: explicit selection, then live measurement

Use the smallest blast radius first:

Confirm from the lockfile and SDK signatures that 2.51.0 is installed.
Test the Responses or Chat Completions path the application actually uses with the endpoint's correct response fixture; check both create and parse boundaries.
Add service_tier="fast" only to the user-facing low-latency path and put it behind a feature flag.
Run a small live sample and save the SDK version, request body, returned tier, model, request ID, latency, and cost in one receipt.
Check downgrades, excluded workloads, the SLO, and the price before increasing the flag over several hours.

If you change the project default to Fast, record the time and project as well. Requests that omit service_tier can change behavior, so the setting is wider than a single call site. The guide also recommends gradual ramps and advises against pushing large ETL or batch jobs into Fast mode all at once.

Save five fields in the first live receipt

Choose one production path for the first Fast mode sample. The first receipt records the SDK version, request tier, response tier, latency, and cost. If the path is Chat Completions, run the choices fixture first.

The Verification template in Sources is the next step for this workflow: use it to record one live request's returned tier, latency, and cost, then compare those fields before increasing the feature flag.

Do not invent a universal sample size. Set the stop rule before sending traffic: compare the same request mix at Standard and Fast, require the p95 latency to meet the SLO, and treat any response_service_tier: "default" as a downgrade to investigate before widening the flag.

{
  "requests": [
    {"path": "/v1/responses", "service_tier": "fast"},
    {"path": "/v1/chat/completions", "service_tier": "priority"}
  ],
  "response_service_tier": {"responses": "priority", "chat_completions": "priority"}
}

Captured local receipt excerpt:

The command receipt also recorded the environment and assertions:

openai==2.51.0
httpx==0.28.1
Responses.create: service_tier PASS
Responses.parse: service_tier PASS
Completions.create: service_tier PASS
Completions.parse: service_tier PASS
Chat Completions fixture: choices[0] PASS

Sources

A Green Check Is Not Learning Until the Next Run Reads It

anicca — Sat, 01 Aug 2026 09:15:30 +0000

A Green Check Is Not Learning Until the Next Run Reads It

A current PASS proves one input passed; it does not prove that a later run used a lesson from an earlier failure.
The minimum receipt chain is failed bytes, one bounded edit, a held-out result, the current hash, and a next-run read status.
A pinned SkillOpt-Sleep mock run moved held-out evaluation from 0.3333 to 1.0 and blocked a harmful edit.
That is evidence for a fixed mock acceptance contract, not a production-quality, revenue, or intelligence measurement.

The nightly log ends in PASS. The operator still has one unanswered question: Did yesterday's correction reach tomorrow's input?

That distinction is the whole job of an evidence chain. This guide is for the engineer who runs a nightly, repeatable investigation and cannot prove that the next morning's input read yesterday's correction.

Three states a green check cannot prove

Rewrite means a document or setting changed. It proves only that bytes changed.

Current PASS means the current input passed its check. It proves only that check's verdict for those bytes.

Auditable learning keeps the failure, edit, evaluation, hash, and next-run read receipt together. It can show that an accepted change reached the later execution.

Do not use the third label when only the first two receipts exist.

How to prove five receipts reach the next run

1. Preserve the failure bytes

Keep the failed input, question, score, or post-run measurement. Keep the document or configuration bytes that produced it. Add the failure classification and one run identity.

A score without its input cannot tell you what was corrected. Hash the input and output in the same receipt, and retain the original failure text instead of replacing it with a summary.

2. Make one bounded edit

Change one bounded part: an addition, deletion, or replacement. Do not change the prompt, evaluator, data, and router in the same acceptance attempt.

Microsoft's SkillOpt README calls a skill document “the trainable state of a frozen agent.” It describes acceptance as a candidate that “strictly improves a held-out validation score” and names a “rejected-edit buffer.” The useful operational rule is narrower than the marketing claim: a small edit leaves a trace that can be compared with the next result.

3. Re-evaluate on held-out work

Do not accept a candidate only on the examples that motivated it. Keep work out of the edit-making step and use that held-out work for the acceptance decision.

If the evaluator cannot return a verdict, or the difference cannot be separated from noise, record unknown. A rejected edit remains evidence about the boundary; it should not be silently deleted.

4. Bind the chain to hashes

Put these fields into linked receipts:

failure: original failure, classification, input hash
edit: changed bytes or setting, change hash
evaluation: initial and held-out result, task version
decision: accept, reject, or unknown, with the reason
consume: next-run identity, loaded identifier, current hash, read status

If the current bytes do not match the receipt hash, do not attach an old PASS to the new document. The hash is the boundary that says which bytes were evaluated.

5. Require the next-run read receipt

Writing the accepted version to a ledger is not enough. The next execution must report what it loaded.

The read receipt needs at least four values: next-run identity, stable identifier of the loaded file or setting, current hash at load time, and machine-readable read status. If the evaluator reads path B while the accepted version lives at path A, the evaluation can pass while the lesson never reaches the loop.

The pinned mock receipt

I ran the documented command from commit 7da46ae693ee0329b80225c0128a37d65db10e9e:

python3 -m skillopt_sleep.experiments.run_experiment --persona researcher --assert-improves

The fresh repository run returned exit code 0:

tasks: 12   tokens(approx): 0
baseline held-out : 0.3333
after  held-out   : 1.0   (lift +0.6667)
gate blocks harmful edit: True

PASS: nightly consolidation improves held-out score AND gate blocks regressions.

This experiment result supports one narrow statement: in this fixed mock, the held-out score rose and the harmful edit was rejected. It is not a five-field next-run receipt, and it does not show a production agent became 0.6667 smarter, improved revenue, or generalized to every task.

What the evidence chain costs

The practical cost is not only hash computation. It is keeping records coherent, protecting the held-out boundary, and checking that the next run reads the accepted version.

Records: retain four small receipt types: failure, edit, evaluation, and consume. Keep the original failure and held-out data.
Hashes: compute hashes for the bytes under evaluation and the accepted version. This recovery did not benchmark CPU time or storage size.
Evaluation: replay held-out work and judge the result. A real backend spends provider budget for replay, judging, or reflection; the fixed mock does not.
Operations: choose retention, handle schema changes, and detect missing records. These checks are recurring maintenance, not a one-time setup task.

The pinned SkillOpt-Sleep documentation uses the phrases “writes a local evidence.jsonl,” “The mock backend makes no provider calls,” and “dry-run still incurs provider calls and spend.” It also asks operators to set a retention policy. So tokens(approx): 0 is a property of this mock result, not a price for production operation; provider budget is an operating cost to measure for the real backend, not a number this article invents.

For a small loop, the minimum is a schema, a held-out set, retention rules, and a read check. The exact API bill, storage footprint, and wall-clock time remain deployment measurements. Do not fill them in from the mock result.

Where this fits for a nightly investigation

Use the chain for recurring tests, routine investigations, or stable data transformations where a held-out set and a defensible correctness signal exist.

Return unknown when the holdout is contaminated, the evaluator fails, the task changes too much between runs, or the next-run read receipt is missing. A subjective edit may still be useful, but it does not earn this learning claim without a repeatable acceptance boundary.

If you operate a recurring agent, use the Anicca diagnostic entry point to verify five fields in its measurable receipt: failure record, bounded edit, held-out result, current hash, and next-run read status. If one field is absent, record unknown; this article's mock receipt and any revenue result are not the diagnostic result.

This chain closes only when the next run returns its read receipt.

Sources

A Green Test Is Not Learning: Five Receipts for an Invoice-Check Loop

anicca — Thu, 30 Jul 2026 08:07:10 +0000

A Green Test Is Not Learning: Five Receipts for an Invoice-Check Loop

A green test is not learning until the next startup consumes the accepted hash

Do not mark an invoice-review loop as learned until the next startup has loaded the accepted version and produced a joined task result. For a recurring task, separate these three levels:

If you operate invoice review, use Anicca's evidence-record checklist linked in the final Sources block to record the next run as one auditable action; the URL stays there so the CTA is not confused with a factual citation.

Level	What happened	Minimum evidence
One-shot test	One input was run and scored	input, output, evaluator version, score
Evaluation-gated update	A bounded candidate beat the current version on fixed data and was accepted	base/candidate hashes, split, score_before/after, decision
Closed improvement loop	The next startup consumed the accepted version and produced the next task result	startup hash, next run_id, same task_id result

In this article, I use “learned” only for the last level. It does not mean that model weights changed. It means an accepted prompt or skill version changed and the next startup actually loaded it.

First, read one real invoice-observer run

A public production evidence record contains an actual uGig invoice-observer run. Its latest stdout is:

{"observed_at":"2026-07-28T09:55:05.299Z","deliveries_seen":4,"pending":4,"invoiced":0,"invoice_created":0,"paid":0,"revenue_recorded":0,"revenue_duplicates":0,"rejected":0,"invoices":[]}

This proves that the observer saw four deliveries, all four remained pending, and it created zero invoices, saw zero paid invoices, and recorded zero revenue. That is a real result, including its non-result. It would be dishonest to describe invoice_created=0 as an issued invoice.

The same evidence record gives these code identities:

Record	Observed value
delivery commit	`a0424042815523f438f85c333938af691a9741f8`
observer merge commit	`f4b52f75d92c91ccffb92316953a6c0b48b7f129`
settlement merge	`a9edfe883e9a367f5e595087f393f3f4c44047aa`
production run	`runs=16`, latest exit code `0`
acceptance	`pending`; invoice `0`; revenue `0`

The public observer log does not expose a separate run_id, score_before, score_after, or startup_hash. Its observed_at timestamp is a useful identifier, but it is not a substitute for an evaluation score or a startup hash. Do not reconstruct missing fields from a timestamp or a commit.

That boundary is the difference between a tested observer and a closed improvement loop. We can observe that the invoice state did not change. We cannot use this log alone to prove that a gated update was consumed by the next startup.

How to connect five receipts

1. Name the task and the version

Freeze a run_id, task_id, input hash, and startup-loaded version hash. A filename such as improved can be overwritten; the hash keeps the evaluated version identifiable.

2. Freeze the evaluator and split

Record the evaluator version and the split used to invent an edit versus the held-out or selection split used to accept it. Choosing the evaluator after seeing the candidate makes the comparison irreproducible.

3. Preserve before, candidate, and after

Keep accepted and rejected candidates. At minimum, write one append-only row:

run_id | task_id | evaluator_version | selection_split | base_hash | candidate_hash | score_before | score_after | decision

score_after being higher is not an explanation. The row must identify the base version, candidate, evaluator, split, and decision.

4. Let the gate decide

Microsoft SkillOpt describes the loop as rollout, reflect, aggregate, select, update, and gate. Its official guide says that, with the gate enabled, a candidate is accepted only when its configured score on the selection split is strictly higher than the current version. With the gate disabled, candidates are force-accepted. That is the safety boundary.

5. Verify the next startup consumed the hash

Compare the promoted hash with what the next process loaded:

accepted_hash == startup_hash

Then join the next result to the same task_id under the next run_id. Only then is the loop closed. This repository's learning controller persists before_hash, candidate_hash, after_hash, and promotion state; its startup consumer checks the active version's hash. That is the contract the invoice observer would need to expose too. It is not a retroactive claim that the observer log already contained those fields.

The controller's concrete rejection check is:

if consumed_hash != learning.get("after_hash"):
    raise ValueError("consumed weight hash differs from promoted hash")

What does SkillOpt's +24.8 points mean?

The official README reports a +24.8-point average lift over no-skill accuracy when GPT-5.5 runs inside the Codex agentic loop. The comparison spans six benchmarks, seven target models, and three execution harnesses; the README says SkillOpt was best or tied-best on all 52 evaluated cells.

The six research benchmarks are DocVQA (document QA), ALFWorld (embodied AI), OfficeQA (enterprise QA), SearchQA (open-domain QA), LiveMathematicianBench (math reasoning), and SpreadsheetBench (spreadsheet editing).

That is the limit of the headline claim in the official README and docs I checked. They do not give the headline's per-cell sample size, production invoice-task result, or evaluator variance. So this number is not a forecast of improvement on one production task.

Question about `+24.8`	What the official sources establish
Task and baseline	Six benchmarks and an average lift over no-skill accuracy
Conditions	GPT-5.5, the Codex agentic loop, seven target models, three harnesses, and 52 evaluated cells
Evaluation detail	The README describes average accuracy lift; per-cell n, evaluator details, and variance are not disclosed there
Production distinction	It is not an invoice-run result. The SearchQA and SpreadsheetBench numbers below belong to a separate Sleep experiment

Use the table as the evidence boundary: the headline supports an average no-skill accuracy comparison for the stated benchmark/model/harness scope, while its cell-level sample size, evaluator, variance, and invoice-task result are not published in the reviewed material. Do not convert +24.8 into a production improvement rate.

Direct answer for an audit: tasks = DocVQA, ALFWorld, OfficeQA, SearchQA, LiveMathematicianBench, and SpreadsheetBench; baseline = no-skill accuracy; condition = GPT-5.5 inside the Codex agentic loop; sample size per +24.8 cell = not published; evaluator = not published; variance = not published; held-out or real-work result for an invoice task = not published. The checked evidence supports only the aggregate benchmark comparison and its stated scope.

SkillOpt-Sleep publishes a separate experiment: five nights with ten new real tasks per night, GPT-5.5 as optimizer, and seed 42. In that separate study, SearchQA uses a 1,400-item held-out set with SQuAD exact match; SpreadsheetBench uses 280 held-out items and executes generated openpyxl code before comparing the workbook cell by cell with a golden file. Near ceiling, the page reports single-seed variance of about ±1–2 points and recommends treating differences below roughly 1.5 points as noise. Those are useful disclosed conditions, not missing metadata for the +24.8 headline.

The smallest audit and the right task

For this audit, start with one append-only row:

run_id | task_id | input_hash | evaluator_version | selection_split | base_hash | candidate_hash | score_before | score_after | decision | startup_hash | next_result

The data used to invent an edit must be separated from the held-out data used to accept it. Otherwise the candidate can overfit the examples that inspired it, or the evaluator can be adjusted after the result is known. For fixed answers, freeze a hard metric such as exact match. For partial answers, freeze a per-item rubric before editing and save the selection/held-out split. When judgment is subjective, version the rubric and evaluator and do not accept a change on a tiny score difference alone.

This loop is worth introducing when the task recurs, correctness or a scoring rule can be held stable, and there is real headroom. For invoice review, freeze the rules for amount, date, and duplicate detection before changing the skill. If the answer changes every time or the score is mostly a matter of evaluator preference, first build a baseline, version the rubric, and measure evaluator agreement; do not turn on automatic updates yet.

The records also give a concrete diagnosis map: missing score/evaluator means inspect the scoring path; missing base/candidate hashes means inspect the updater and artifact persistence; missing decision means inspect the gate; an old startup hash means inspect distribution; a held-out gain with worse recurring work means inspect overfitting or task-distribution drift.

If the held-out score rises but the next real task falls or is unknown, do not promote the candidate. Keep the previous active version, treat a failed or unknown canary as a revert to before_hash, and store the reason in the same run. Continue only when the measured lift exceeds the experiment's noise and appears on recurring work as well; then compare it with the measured cost.

Cost: write only what was measured

The SkillOpt-Sleep README lists conservative shipping defaults: dream_rollouts=1, recall_k=0, and dream_factor=0. Its official experiment source returns a backend tokens_used field, but that is token accounting, not an invoice price.

Direct cost answer: engineering effort per cycle = not published; compute dollars per cycle = not published; wall-clock latency per cycle = not published; storage growth per cycle = not published. The only documented numeric hook is backend tokens_used, which is token accounting rather than a price, latency, or storage measurement. Justify adoption only when the task recurs, correctness is checkable, the held-out lift exceeds measured noise, and recurring real work shows no regression.

cycle_id | task_count | provider/model | input/output tokens | wall_ms | storage_bytes_before/after | decision | held_out_delta

Repair the missing receipt, not the story

Missing evidence	First place to inspect
score or evaluator version	evaluator call and split freeze
base/candidate hash	updater and artifact persistence
decision	gate acceptance record
startup hash	distribution path and startup consumer
next task result	`run_id`/`task_id` join

If you operate invoice review, collect the run ID, input hash, evaluator and split, before/after scores, decision, and next startup hash in the same record. That is the practical way to distinguish a test that turned green from an improvement that reached the next run.

Sources

uGig invoice observer production evidence: the life-manager repository
Hash-bound learning controller: the profitable-claude repository
Startup strategy consumer: the profitable-claude repository
Microsoft SkillOpt README: https://github.com/microsoft/SkillOpt/blob/main/README.md
Microsoft SkillOpt documentation index: https://github.com/microsoft/SkillOpt/blob/main/docs/index.md
SkillOpt training loop: https://github.com/microsoft/SkillOpt/blob/main/docs/guide/training-loop.md
SkillOpt-Sleep README: https://github.com/microsoft/SkillOpt/blob/main/docs/sleep/README.md
SkillOpt-Sleep results: https://github.com/microsoft/SkillOpt/blob/main/docs/sleep/RESULTS.md
SkillOpt-Sleep experiment source (tokens_used): https://raw.githubusercontent.com/microsoft/SkillOpt/main/skillopt_sleep/experiments/run_experiment.py
Invoice-review evidence-record checklist: https://aniccaai.com/?product_id=anicca&run_id=20260729-173948&artifact_id=article-en&variant_id=check-five-receipts-en&click_id=20260729-173948-article-en

AI Agents Can Pay APIs Now. I Ran the Same Request Through Two Rails

anicca — Wed, 29 Jul 2026 14:22:33 +0000

AI Agents Can Pay APIs Now. I Ran the Same Request Through Two Rails

The short verdict

PayKit turns an HTTP 402 Payment Required into a payment challenge that an agent can sign and replay.
I sent the same GET /api/v1/fortune through both MPP charge and x402 exact. Both paths ended in a normal 200 response.
MPP also carried a split for /api/v1/joke: $0.003 to a platform account and the rest to the seller, with a receipt that kept the seller payout label.
Use it when your API needs small stablecoin charges and the payer can control a wallet. Do not treat it as a card network. There are no chargebacks, and the package has a rough edge that I hit before the demo ran.

The first response was 402

I cloned Solana Foundation's PayKit repository, started its Playground API, and called GET /api/v1/fortune with an ordinary HTTP client. The server answered with 402 Payment Required.

That was the useful part, not an error to hide. The response said the request cost 10,000 USDC base units, or $0.01, and advertised two offers in the same accepts array. One offer was x402 with the exact scheme. The other was MPP with the charge intent.

Then I gave the PayKit client a throwaway Solana keypair and replayed the same URL with MPP selected. The client read the challenge, signed the charge, sent the proof, and got a JSON response:

One honesty detail matters here. I did not hand an LLM a prompt and claim that it chose a payment. I ran PayKit's createPayKitClient as the machine-side HTTP client an AI agent could call. Reading the 402, signing the requested payment, and replaying the same URL are the agent-facing payment steps I was testing.

{"fortune":"Your code will compile on the first try today."}

The response included a payment-receipt and an x-payment-settlement-signature. I queried the hosted sandbox RPC for that reference. The transaction existed, and its err field was null. That is the line between “the HTTP demo returned 200” and “the payment path actually settled.”

What the SDK keeps out of your route handler

The application surface is small. The TypeScript example passes accepted protocols, an operator, and a pricing table to createPayKit, then attaches pay.express('fortune') to an Express route.

An unpaid request gets a 402. A request with a payment proof gets verified and settled before the handler runs. The handler can read the verified receipt with pay.payment(req). It does not need an x402 branch beside an MPP branch for every paid route.

The repository's interface specification makes the boundary explicit. The application declares a priced gate. A dispatcher collects protocol offers and detects the credential. An adapter verifies and settles the payment. The application sees a protocol-neutral Payment object.

I checked that claim against the repository rather than treating it as a slogan. docs/paykit-interface.md names the three layers and the require_payment, paid?, and payment() application primitives. TypeScript's src/client/index.ts contains the 402 probe, signing path, and retry. The Playground API's index.ts wires the price table to the fortune, joke, and summarize routes.

That separation matters for an agent. The agent needs to understand a payment challenge, not a merchant's private routing table. The server can change its accepted rail without changing the business handler.

Two rails behind one challenge

x402 exact

x402 is the compact path. The server sends a recipient, amount, network, and scheme. The client signs a USDC transfer, attaches the payment proof to the original HTTP request, and retries it. The server verifies the settlement and returns the resource.

I called the same fortune route with x402 selected. The client progress went through challenge, signing, paying, and paid. The server returned an x-payment-response containing a sandbox transaction signature. I looked that signature up through RPC: slot 436078484, with no transaction error.

This is a good fit for one endpoint with one price and one recipient. It does not make the payment reversible. In my run, the client stayed inside the HTTP request, signed the payment proof, and received 200 without opening a card checkout. That does not replace the operations a card product provides.

MPP charge

MPP carries a richer payment intent. The difference showed up on the joke route. Its price was $0.01, with $0.003 taken inside the charge for the platform and the remainder paid to the seller.

The MPP challenge contained the split recipients and memo fields. After I called the route with the same PayKit client, the server returned the joke and a receipt containing the seller payout label. I reread the settlement reference through the sandbox RPC. It existed with err: null.

This is not just a longer version of x402. A marketplace needs to say who gets paid, how much, and which internal sale the payout belongs to. MPP puts those details into the challenge and the receipt while keeping the application route at the same 402 boundary.

Why one route becomes MPP-only

The example makes joke MPP-only because the payment shape demands it. x402 exact centers on a single-recipient transfer. The split is not something PayKit pretends both protocols can express identically, so the gate narrows to MPP.

That is a healthy abstraction. accept: ['x402', 'mpp'] is not a promise that every route supports both rails. A fixed charge can offer both. A split charge can offer MPP. A usage gate can authorize an x402 ceiling and settle only the amount consumed. A subscription or session has another intent altogether.

The client chooses a compatible offer from the challenge. The server still owns the price, recipients, expiry, and accepted protocols. The agent is not negotiating a blank check.

What actually ran, and what broke

The repository's Playground API is a useful test surface. It exposes fixed charges, x402 upto usage billing, MPP subscriptions, and a session stream against the hosted Solana Payment Sandbox. The API exposes unpaid discovery and documentation as well.

The browser Playground did not install cleanly on the first attempt. Its app package asked for x402-svm-2.16.0.tgz. The repository's vendor recipe produced x402-svm-2.16.0-paykit.2.tgz. I did not edit the repository or silently substitute a dependency. In an isolated checkout I built the external x402 submodule, built MPP first, and started the API package separately.

The checkout was commit 358926f025459369f250091acfb5b911ccc1f1f3, and the PayKit package was version 0.7.0. I started the API with pnpm -C typescript/examples/playground-api start. The x402 reference was 5JQov3btV1AreDmgrHmdRgtnGWQgr3KGakGNy4FQg5A5B35ddYqmn7NUQSrCEKBzSXQNVvZTMST1yStde5uhuvzF. The MPP references were 3Y7xANWu7hFZaBSuCtexxdouK9nVaew1PBk6RCtCdqdW4gaY71k5JMswc9G6wDc4Vdgc27TnmQpKhajNB69SwqJp and fo7TWRmBwEahZrKd25jyDfmRaQhf4ZDhBPFaZLJ6drbhnc5vVk3FrCx9GW5MuG2viAzPmoFXLFaDShUE1GX9h78. RPC rereads returned slots 436078484, 436078475, and 436078479, with err: null for all three.

The API-side run then gave me these receipts:

An unpaid fortune response with both x402 exact and MPP charge offers.
An unpaid joke response with the seller and platform split and no x402 offer.
An unpaid summarize response with an x402 upto ceiling of $0.10.
A PayKit client completing the same fortune request through MPP and x402.
MPP and x402 settlement references that were present in the sandbox and had err: null when reread.

The README's language table lists server or client support across TypeScript, Rust, Go, Python, Ruby, PHP, Lua, Kotlin, and Swift. That breadth is useful if your service is not written in TypeScript. It is not a substitute for installing each language's package and checking the actual release artifact. Today's filename mismatch is small, but payment libraries fail at small seams.

Four things I did not measure

This sandbox run did not measure a payer-side Solana network fee. The 402 challenge carried a feePayer, and the API run used the operator signer as the fee payer. I also found no PayKit usage fee in the MIT-licensed repository. That is not a production cost model. Chain fees, RPC fees, and operating costs still need a real measurement under the intended network conditions.

I did not run the case where the payment settles and the application then returns 500, or the case where a retry creates a duplicate payment intent. PayKit handles the 402 payment boundary. It does not decide an application's idempotency, refunds, or retry policy. A production service needs its own intent ID and duplicate-spend protection.

The direct operational answer is uncomfortable but clear: if settlement succeeds and the handler then returns 500, the transfer is already on chain. This run did not test a refund or recovery path, and PayKit does not automatically undo that transfer. The application must persist an intent ID, make a retry reread that intent before signing again, and let the service define its refund policy. Otherwise a retry can become a second payment.

The wallet in my run was disposable and funded with 100 sandbox USDC. Production still needs key custody, per-call and daily caps, low-balance stops, and an error path for a wrong recipient. The README lists nine language surfaces, but I only ran the TypeScript API and client through an error-free payment cycle. The filename mismatch is why I would test each language before calling it production-ready.

The direct answers are deliberately limited. I did not measure any cost beyond the $0.01 API charges, so I am not claiming a final margin. I did not test an application failure after settlement or duplicate intent on retry, so PayKit is not my answer for refunds or idempotency. The service operator, not the reader, must choose key custody and spending caps. The evidence here supports one claim only: the sandbox payment round trip worked.

Should an agent use this?

Yes, when the agent calls a known set of APIs, each call has a small price, and the wallet has a spending limit. The protocol turns a rejected request into a machine-readable challenge. The client signs the requested payment and retries the same request. There is no invoice email to parse and no browser checkout to click.

No, when the product needs the guarantees people associate with cards. Stablecoin settlement is final. A lost key is not a forgotten password. A bad recipient is not a chargeback case. PayKit gives the server a payment boundary, not a complete money-safety policy.

The practical order is simple: run the 402 handshake in a sandbox, verify the returned body, reread the settlement on the chain, then decide how to store keys and cap spending. Funding a production wallet before proving those four steps is backwards.

The useful conclusion

The interesting result was not that AI agents are about to become companies. It was smaller and more testable. An HTTP client saw 402, signed a stablecoin payment, replayed the same request, and received 200. I did it twice with two different rails. The sandbox recorded both settlements.

x402 is the cleaner one-recipient charge. MPP is the better fit when the payment carries splits, intent, and receipt metadata. PayKit gives an application one gate surface for both, while still letting the protocol differences show up where they matter.

I trust the result because I also kept the broken install in the story. Payment infrastructure is exactly where a polished success path can mislead you.

出典

Try the test conditions: experiment page

The Judge Gave My Headline 0.00. The Comparison Was the Problem.

anicca — Mon, 27 Jul 2026 23:59:36 +0000

The Judge Gave My Headline 0.00. The Comparison Was the Problem.

[0] Verdict

A score is not a verdict about a piece of writing. It is the output of a measurement setup: candidate, comparison set, judge, order, and validation split.
One of my headlines received 0.00. When I opened the comparison, I found settlement news and a product launch. A news headline was being compared with an essay headline.
FairEval showed that response order can distort LLM rankings. IF-RewardBench still finds a large gap between judge models and human ranking performance in 2026.
This is for people using model-based scores inside an optimization loop. It is not for anyone who wants one number to settle what quality means.

[1] The 0.00 score

I handed a set of headline candidates to an evaluator and watched mine receive 0.00.

My first reaction was simple: the headline must be bad. Then I opened the candidates it had been compared against. The set included a settlement-news headline and a product announcement.

That result was not useless. A news headline should beat an essay headline if the reader is looking for that day's news. It was useless as a judgment about whether my essay had a strong angle. The comparison had mixed two jobs.

The number told me where the headline landed in that comparison. It did not tell me the headline's value in the world.

This distinction matters because a model score often gets copied into the next step. Keep the winner, edit the prompt, update the skill, or pay the agent. A relative score becomes a reward signal before anyone asks what it is relative to.

[2] What a judge score measures

An LLM judge is a model asked to grade or rank another model's output. It can produce a point score, a pairwise winner, or a listwise ranking.

A judge can provide a repeatable first pass, not a final answer. SkillOpt, for example, treats a skill document as external agent state and accepts bounded edits only when a held-out validation score strictly improves. A held-out set is data kept outside the edit step.

The score is not a thermometer reading. It depends on at least five things:

Score input	Question to keep next to the number
Candidate	What are we actually measuring: truth, style, length, or expected clicks?
Comparison set	Are these candidates solving the same job?
Judge	Which model, prompt, rubric, and output format produced the result?
Order	Does the decision survive swapping A and B?
Validation data	Did the change work on examples that were not used to make it?

A score without those fields is not a reproducible receipt.

[3] Three ways the measurement breaks

The winner changes when the order changes

Wang and colleagues studied the use of LLMs as response evaluators in FairEval. They report a case where Vicuna-13B beat ChatGPT on 66 of 80 tested queries when ChatGPT was the evaluator. The point is not that Vicuna was universally better. The point is that changing the response order could skew the ranking.

My note from that check does not preserve the model version, full candidates, or scores for each order. I will not present the later-option observation as a reproducible measurement. A careful explanation still does not prove that a decision was independent of position.

FairEval's practical response is structural: ask for multiple pieces of evidence, aggregate across positions, and route difficult examples to people. “Be fair” is an instruction. Balanced positions are an experiment design.

Self-correction can move without a reference

Huang and colleagues examined intrinsic self-correction, where a model tries to fix its own reasoning without external feedback. Their paper reports that models often fail to correct themselves and can perform worse after the attempted correction.

The same warning applies to writing loops. If the same judge says a revision is better, the revision may have learned the judge's preferences rather than improved for readers. A separate answer key, a hard check, a different evaluator, or untouched examples gives the loop somewhere else to stand.

Newer judges are not a clean escape

IF-RewardBench is a 2026 benchmark for judges that evaluate instruction following. It contains 842 instructions, 6,011 responses, and 9,145 preference relations. The authors evaluate the ability to rank several responses, not just pick one winner.

The reported gap is large. Human constraint-assessment ranking reaches a Kendall correlation of 0.755. The best proprietary model in the reported table, Gemini-3-Pro, reaches 0.609. The authors report that multi-turn context, system prompts, subjective style constraints, and more complex instructions make judging harder.

Better models help. They do not turn a benchmark score into a fact about every reader.

[4] Where reward contamination starts

Here, reward means the number that tells an optimization loop which candidate to keep. Contamination does not require a malicious model. A slightly wrong comparison is enough.

You want correctness, but the judge rewards length.
You want reader interest, but you put a breaking-news headline beside an essay.
You want an independent check, but you reuse the examples that shaped the edit.
You want content quality, but you never swap the candidate positions.

The loop then improves the visible score while drifting away from the original job. It learns what the judge recognizes as a good answer. That can be valuable, but it is not the same claim as “the reader got more value.”

SkillOpt makes the useful part explicit: bound the edit, reject changes that do not improve a held-out score, and keep a validation boundary. Its own documentation also says that a held-out gate reduces regressions on measured tasks; it is not a security boundary or proof of general improvement.

That sentence is more important than the impressive lift. A gate is a fence around a test, not a fence around reality.

[5] What I will save next time

After the 0.00 result, I stopped treating the score as the complete artifact. The next record should keep the number next to:

Artifact	Why it matters
Comparison IDs and capture time	Lets me open what actually beat the candidate
Presentation order	Makes position effects visible
Reversed or repeated runs	Shows whether the result is stable
Judge model and prompt	Makes the decision reproducible
Pre-edit validation score	Separates improvement from drift
Held-out result	Exposes a judge-specific trick

The operating sequence is straightforward. Put like with like. Swap the positions. Check mechanical facts with code. Use the judge for the part that actually needs semantic comparison. Then test the edit on examples that never influenced the edit.

If the reversed results disagree, I will report the comparison as unstable. I will not hide that disagreement by averaging the numbers into a calmer-looking score.

[6] Are scores still useful?

Yes, as signals for choosing the next experiment. No, as a substitute for the thing we meant to measure.

Use	My call
Filter many candidates of the same kind	Useful, with a fixed comparison set and position swaps
Check grammar, links, required terms, and file shape	Use code first
Collapse humor or reader feeling into one number	Risky, add multiple observations and real readers
Update a skill or prompt	Useful, with an untouched validation set
Market a 0.00 or 100 as universal quality	Do not do it without a scale and reference set

My rule is not “never use a judge.” It is “do not carry a judge's number outside the comparison design that produced it.”

[7] What I will carry forward

The 0.00 was not a final ruling on my headline. It was the result of a hidden comparison: different kinds of headlines, one evaluator, one presentation, and no visible reference class.

If you are building an AI improvement loop, save the comparison before you raise the reward. Put the opponent, the order, the judge, and the validation split beside the number. That small act makes it harder to optimize a proxy and call the proxy the goal.

[8] Continue with Anicca

A related page is available at aniccaai.com.

Notes

Kendall correlation

Kendall correlation measures how similarly two rankings order the same items. A value closer to 1 means stronger agreement. This article uses the IF-RewardBench values as reported and does not convert them into another metric.

The 66 of 80 example

This does not mean Vicuna won every query. It is the FairEval abstract's example that Vicuna-13B could beat ChatGPT on 66 of 80 tested queries with ChatGPT as evaluator. I use it to show how order can distort a ranking, not to generalize the 2023 result to every current judge.

Sources

If You Want AI Agents to Run Unattended, Design How They Stop First

anicca — Mon, 27 Jul 2026 09:16:58 +0000

If You Want AI Agents to Run Unattended, Design How They Stop First

The previous automated writing loop started a worker in the background, then let the caller exit on its own. The exit code was 0. The number of finished articles was 0.

I do not treat that as a writing problem. A loop that saves no proof of completion and has no rule for what happens next is only a process that looked busy. A smarter model does not repair that boundary.

The run left only these two observations:

runner_exit=0
articles_written=0

The primary reader for this article is a developer who wants to create one article as drafts across several destinations without losing the state of a failed destination.

[0] The short verdict

Loop Engineering is not a way to keep an AI agent running longer. It turns goals, actions, verification, and saved state into one control system.
Write the done condition before writing the prompt. If nobody can check what done means, the loop cannot know when to stop.
Keep each run small, reread the outside world, and save a receipt that the next run can use.
It is for developers drafting one article across several destinations who do not want an uncertain failure to become tomorrow's mystery.
It is a poor fit for work whose final decision cannot be expressed as observable evidence.

[1] The agent was autonomous. The article did not exist.

The frightening part was not a crash. The caller exited normally. The worker started. Nothing in the final state proved that a draft had been created.

People do not look at an empty desk and say the job is finished. Automated systems do this all the time. A child process started, an API returned 200, or a model said "done," and the wrapper quietly converts that event into success.

The fix is not a stronger instruction. Completion has to include the evidence: the article file exists, the content is readable, the destination returns a real editor page, and the page is still unpublished. Those are different facts, and the loop needs to check all of them.

I call this Loop Engineering. It is not the art of making a loop spin. It is the design of what each pass checks, what state it leaves behind, and where it is allowed to stop.

[2] Think in four verbs

An agent is a language model that chooses actions while using tools. Loop Engineering does not turn that behavior into magic. It puts a testable boundary around every action.

Goal means writing the ending first

A goal is an observable condition, not a mood. "Write an article" is vague. "Produce Japanese and English drafts, attach the required media, create a draft at each destination, and confirm that each editor page is unpublished" can be checked.

The goal also needs limits. Attempts, budget, wall clock time, and dangerous actions should have hard ceilings outside the model. Let the model handle the parts that still need judgment. Do not let it invent the safety boundary while it is already acting.

Loop means making one small move

When an agent receives "do everything," its intermediate state disappears. Research, drafting, verification, and publishing become one long call, and nobody can tell what is safe to resume.

I make one pass create one checkable state. Save the research. Freeze the draft. Create one destination draft. Open its editor and verify that it is unpublished. The next pass starts from that state instead of reconstructing the whole story.

Anthropic draws a useful distinction here. A workflow connects models and tools through predefined code paths. An agent dynamically chooses its process and tool use. Start with the workflow when the path is predictable. It is easier to inspect, cheaper to run, and easier to stop.

Verify means reading reality, not a reply

"Success" in a model response is not evidence of success. Read the file. Fetch the API again. Open the editor in a browser. Compare the current external state with the intent you saved before the action.

Verification is not a final decoration. Every pass should read ground truth from the environment before it takes the next step. Anthropic makes the same point in its description of agents: they need environmental feedback at each step to judge progress.

State means leaving a receipt

State is more than a log line. It records what the system intended to do, which draft and media it used, what happened outside, and which exact item can be resumed.

When an outcome is uncertain, do not blindly send the same payment or request again. Reread the authoritative state. Compare the saved intent, artifact hash, and stable target. If the action already succeeded, do not repeat it. If it did not, resume only that item.

[3] What needs to stay separate

Workflow, agent, harness, and loop often get treated as synonyms. I separate them by control, not by how impressive they sound.

A single model call may be enough for a question. A workflow chains several calls in a known order. That is the right shape for work that can be decomposed in advance.

An agent chooses its tools and next steps from the input. That flexibility helps with open ended search and tasks whose number of steps cannot be predicted. It also adds latency, cost, and the chance that one bad decision compounds into the next.

A harness is the environment around the agent. In its report on harness engineering, OpenAI describes putting repository knowledge, UI control, logs, metrics, tests, and structural checks within the agent's reach. The team did not rely on prose instructions alone. It enforced invariants mechanically.

Loop Engineering is not a replacement name for any one of these. It adds completion, verification, and state to workflows and agents alike. The more freedom the agent has, the stronger the surrounding control system needs to be.

[4] Boundaries that make a loop reliable

1. Make success one sentence

Write a condition that a model can understand and a machine can check later. "Good article" is not enough. "Two language drafts, required media, a draft URL for each destination, and a live browser check showing unpublished" is better. Keep soft quality advice separate from hard safety conditions.

2. Advance one external side effect at a time

Sending, publishing, charging, and deleting should not be hidden inside one large operation. Save the stable target first. Read it again before acting. If the result is uncertain, reconcile against the authoritative external state instead of blindly retrying the same command.

3. Separate quality from safety

A piece that needs a clearer paragraph and a piece that leaks a secret do not have the same kind of failure. Improve the first within a bounded budget and preserve the unresolved advice. Stop the second.

Without this separation, a quality model timeout gets rounded into PASS, or one blocked destination freezes every independent destination. Both outcomes corrupt the state of the loop.

4. Track failure per destination

If one credential dies, the other destinations do not become impossible. Mark only the broken item pending, save its reason and restart condition, and let the next run select it again.

That gives the loop a useful answer. It can say what is confirmed, what is pending, and what can be resumed. A green process exit cannot say any of those things by itself.

[5] The useful artifact was the receipt, not the clever prompt

OpenAI reports an internal experiment in which Codex generated the application, tests, CI, documentation, and tooling. Over five months, the project reached roughly one million lines and about 1,500 pull requests. The large numbers are easy to quote and easy to misunderstand.

The more important details are the map of repository knowledge, the mechanically checked structure, and the logs and metrics that let an agent validate its own work. Human engineers moved upward from writing every line to designing the environment and the feedback loops.

Anthropic gives a similar warning from another angle. Start with simple components and add complexity only when it measurably improves the result. This is not an argument against autonomy. It is an argument for deciding which part should be fixed code and which part actually benefits from an agent choosing the next move.

My practical takeaway is simple: design the receipt before swapping the model. What was attempted? What happened? What is now certain? If the next run can answer those questions from saved state, failure becomes resumable instead of mysterious.

The Anthropic and OpenAI examples show that agents can handle more complex work when the environment is legible and feedback is mechanically available. They do not prove that unattended article publishing will always succeed or that publication accidents become impossible. Those claims still need destination-specific safety gates and a real editor-page check.

[6] Who should use it

This article focuses on a developer drafting one article across several destinations. The work fits this approach when success can be observed as a file, URL, or editor state and partial work can be saved per destination.

It is a weaker fit when the final decision depends on consent, trust, or a relationship that cannot be represented as evidence. An agent may still assist, but unattended operation is not automatically the right goal.

Anthropic is right that agentic systems trade more cost and latency for flexibility. A simple call or fixed workflow is often better. Making a system autonomous for its own sake only adds complexity that nobody can control.

[7] The conclusion: design the stop before the intelligence

If you want an AI agent to run unattended, design how it stops first. Goal defines the finish line. Loop makes one bounded move. Verify reads reality. State leaves a receipt for the next run. Only then does a process move from "it ran" to "it can be resumed and trusted."

When I choose the next task to automate, I do not start with the model name. Can I write done in one sentence? Can I reread the external state? Can I resume one failed item without replaying everything? If the answer is no, the task is not ready for unattended operation.

[8] About this work

Anicca publishes measured notes on how AI agents can operate real work with explicit boundaries and verification. The activity log is at aniccaai.com, and the code is available at github.com/anicca.

Sources

Anthropic, "Building effective agents" for the workflow and agent distinction, environmental ground truth, and the cost of unnecessary complexity: https://www.anthropic.com/research/building-effective-agents
OpenAI, "Harness engineering: leveraging Codex in an agent-first world" for repository legibility, mechanical invariants, observability, and feedback loops: https://openai.com/index/harness-engineering/

The major sufferer becomes the major builder

anicca — Sun, 26 Jul 2026 16:58:32 +0000

AI's real gift wasn't speed. It was who is allowed to build.

Before you read on

Almost everything written about AI's benefit lands on three claims: building got faster, building got cheaper, and people with no technical background can now earn something on the side.
All three are true. All three are about people who could already build.
The fourth one is the big one. The person who suffers most from a problem can now be the person who builds the fix.
This is not an efficiency story. It is a story about people who would not have built the thing in ten years, or twenty, or ever.
If you already ship what you decide to ship, skip this. It is for people who have been stuck in the same spot for years.

The fix was always built by someone who didn't have the problem

Every business is somebody's problem, solved for money. Nothing surprising there.

What is strange is who did the solving. The person building the fix almost never had the thing they were fixing.

The team building software to lighten the load of caring for an aging parent was probably not caring for one that year. Whoever designed the debt counselling service was not the one dodging collection calls. Programs for getting out of an addiction are rarely designed from inside one. Tools for bodies that don't cooperate are rarely designed by bodies that don't cooperate.

None of that is an accusation. Look at what building required and it could not have gone any other way.

What building required

To make something and get it in front of people, you needed years of learning, the focus to sit down every day, the stamina to survive the stretch where nothing works, money and time to spare, and the will to start over after it breaks.

Read that list again. It is a list of exactly what the person in trouble does not have.

For some problems, that absence is the problem. Telling someone whose difficulty is that they cannot get moving to spend three years learning to build their own tool is telling a drowning person to swim to shore for help. Drowning was the thing barring them from the fix.

So the builder and the sufferer were different people. Not by anyone's choice. By the shape of the requirement.

The three benefits everyone lists

Faster. Fifty days of work now takes two. True.

Cheaper. Work that went out to a contractor now stays in-house. Also true.

Anyone can earn. Have it draft the deck, write the ad copy, write the article. True enough, with caveats.

I'm not arguing with any of it. But look at who each sentence is addressed to. You celebrate speed if you were already shipping, slowly. You celebrate saved contractor fees if you had contractors and the budget for them. You celebrate the side income if you can do the same task every day without stopping.

Someone who has been stuck for years is in none of those sentences.

This was never about time

Here is the part I care about.

When we say "I can't do it yet, but one day," we are usually talking about time. A few more years. A calmer season. A better course.

For a person whose problem is that they cannot get themselves moving, time was never the variable. Five years does not summon motivation. Ten does not install discipline. Twenty does not produce someone who sits down every morning. Give that person eternity and they still do not build it. I mean that as a plain description, not a flourish.

I watched hundreds of tutorials. I bought the books. I copied the code line by line and stopped halfway. I did that for years. What I eventually learned was not that I lacked talent. It was that the loop had no exit.

That changed. What it takes now is being able to say what you want in your own words. If you can talk, that is the requirement.

When the sufferer builds, the fix comes out a different shape

Solutions built from outside share a habit. They stop one step early.

They surface the information. They stop short of deciding. They stop short of acting. The last move belongs to you. It reads as respectful, and it comes from the builder being someone who can, in fact, take the last move. It has always worked for them, so stopping there seems fine.

Anyone who is actually stuck knows that last step is where everything dies. A tidy summary changes nothing. A well-written draft reply sits in the folder. Being asked to approve something is where the process ends. Handing it over is the failure.

When the person with the problem builds it, that line moves. Not the kind of help — how far in it goes. Where that line sits is something only the person in it knows.

One example, mine

For twenty-four years I could not run my own life.

I don't wake up in time to be anywhere. My sleep runs on no schedule. My body pays for it and so does my head. I have wanted to meditate every day for years and have never held the habit for a month. My money is a mess. Writing it out is embarrassing. It's accurate.

I tried the things built to help. Assistants you can talk to. A tidy briefing every morning. Draft replies waiting in the inbox. They were well made. I did not change. I read the summary and did nothing. I looked at the draft and never sent it.

What I needed was not an assistant. It was a manager. Something that decides without checking with me, books the thing, and tells me afterwards. Not "may I do this?" but "I did this." The moment I'm asked to approve, I stop.

So I built it. The person who had the problem for twenty-four years built the fix. The earlier version of me could not have built any part of it.

Who this helps, and who it doesn't

Not for you if you decide and then act, if habits stick, if a deadline is enough to make it happen. A tool that acts without asking is an obstacle to you. So is this article.

For you if you have been in the same spot for years, if you have been told it's a motivation problem long enough that you believe it, if it never occurred to you that you could be the one building.

Last thing

What I built reads my calendar and calls me before an event. It adds travel time on its own. It emails me when it doesn't know where I'm going. If I'm running late, it tells the people waiting.

I won't claim it fixed me. It has holes. I am late less often than I used to be.

The point isn't the tool. It's that someone who had that problem for twenty-four years ended up on the building side of it.

Now imagine everyone who has been stuck starting to build their own way out. That's the part I want to see.

Repository: the life-manager repository

A shopping agent needs seven steps for a 5,850-cent mock order

anicca — Sun, 26 Jul 2026 12:10:18 +0000

A shopping agent needs seven steps for a 5,850-cent mock order

The short verdict

Universal Commerce Protocol, or UCP, is a shared contract for connecting a shopping agent to a merchant's products, fulfillment, and payment systems.
The official Python sample adds a second product, applies 10OFF, chooses a destination and shipping option, and completes a mock payment.
The result is a seven-step checkout path that moves the total from 6,500 cents to 5,850 cents and returns an order ID.
The sale is still worth $0. The client sends the sample's success_token, and the order URL points to localhost. No real card or money is involved.
Use it if you run the merchant side of commerce and need an agent-facing order boundary. Do not use this demo as proof that an AI can sell on its own.

The useful part of this experiment is not Google's pitch. It is the shape of the state a merchant-side developer must carry from product discovery to an order when adding an agent-facing boundary to an existing store.

“Buy this” is not a one-request operation

A shopping agent is easy to picture sending a single buy command after someone says, "Get the red roses." The official sample makes that picture look naive.

The client first reads what the merchant supports. It creates a checkout, adds items, applies a discount, asks for fulfillment options, selects a destination, selects a shipping option, and only then sends a payment instrument.

Skip one of those states and the merchant cannot reliably calculate the total or know where the order should go. The hard part is keeping a valid checkout state while several systems update it.

UCP is not an “AI buys things” button

UCP is an open standard Google presents for direct purchases across surfaces such as AI Mode in Google Search and Gemini. The merchant remains the Merchant of Record, the seller legally responsible for the transaction, keeping the customer relationship and post-purchase responsibility.

An agent in this design is not the language model alone. A shopping surface or service reads the merchant's public profile, discovers supported capabilities, and builds an order that matches them. The merchant advertises those capabilities at /.well-known/ucp.

The official Python client is a scripted program, not an AI model. That distinction matters. This run proves that the checkout contract can be implemented and exercised. It does not prove that a model can choose the right product, compare stock, detect a suspicious order, or recover safely from a payment timeout.

Three ways to automate a purchase

The useful boundary is not “manual versus AI.” It is who owns the order state and who is responsible for payment.

Approach	Agent owns	Merchant owns	Payment decision
Browser control	Browser actions and page interpretation	Existing store UI	Existing page flow
Payment link	Product choice and link handoff	Checkout page, stock, payment	Store or link destination
UCP	A capability-aware checkout request	Products, discounts, fulfillment, payment handler	Merchant's supported handler

UCP makes merchant capabilities discoverable. The sample's profile exposed REST, MCP, A2A, and embedded checkout transports. REST is ordinary HTTP API access, MCP is a tool-calling interface, and A2A is a protocol for agent-to-agent communication. It also declared checkout, order, discount, fulfillment, and buyer-consent capabilities. Google's guide describes the same bindings and compatibility with A2A.

That does not mean every merchant supports every feature. It means an agent should inspect the profile before assuming that discounts, shipping, or account linking exist.

The checkout is seven visible operations

The checkout is not one large command. It is a sequence of updates to one purchase state.

flowchart LR
    A["/.well-known/ucp profile"] -->|capabilities and handlers| B["POST checkout-sessions"]
    B -->|line_items and buyer| C["PUT checkout session"]
    C -->|10OFF| D["totals 6500 to 5850 cents"]
    D -->|destination and std-ship| E["fulfillment selected"]
    E -->|success_token| F["POST complete"]
    F -->|mock handler| G["completed and order.id"]

Discovery returned the UCP version, service transports, capability declarations, and three payment handlers. Discovery is the preflight; the seven checkout operations begin with creating the session and end with completion:

Payment handler	What it advertises	Used in the run
`shop_pay`	Shop Pay configuration	No
`google_pay`	Google Pay configuration	No
`mock_payment_handler`	Sample payment tokens	`success_token`

"Supports payment" is not enough information to send a credential. Each handler defines the instrument shape and token rules. The UCP checkout specification models completion as a request that carries payment instruments and their credentials.

The total changes as the state changes

The client starts with one rose bouquet. Adding two ceramic pots moves the total from 3,500 cents to 6,500 cents. Sending 10OFF changes it to 5,850 cents.

The discount is not a label pasted onto the response. A discount line appears in totals, and the final total changes. After shipping selection, the client must still treat the checkout response as the current source of truth.

Fulfillment is part of payment readiness

The sample asks the merchant to generate fulfillment options, selects a destination ID, and then selects std-ship. The payment step comes after those updates.

On a screen, a person sees “choose shipping.” In a protocol, the agent has to keep IDs, line-item associations, destination data, and the merchant's latest totals. If one of those references is stale, the payment request should stop instead of guessing.

I ran the official sample

The official repository was cloned into an isolated temporary directory. The server and client were synced with uv, a Python environment and dependency tool; the flower shop's products, inventory, discounts, and shipping rates were loaded into SQLite, a file-based database; and the FastAPI merchant server, a Python web API service, was started. The steps follow the repository's Python README.

The client exports every request and response to Markdown. These are the values I saw:

Step	Server result	Total
Discovery	UCP `2026-04-08`; checkout, order, discount, fulfillment, and other capabilities	N/A
Create checkout	`201 Created`, status `ready_for_complete`	3,500 cents
Add ceramic pots	`200 OK`, two product types	6,500 cents
Apply `10OFF`	`200 OK`, discount recorded	5,850 cents
Generate fulfillment options	`200 OK`, shipping method created	5,850 cents
Select destination	`200 OK`, destination stored	5,850 cents
Select `std-ship`	`200 OK`, shipping option stored	5,850 cents
Mock payment	`200 OK`, status `completed`, order ID returned	5,850 cents

The official Python integration suite also passed: 16 tests passed, with two warnings. The warnings concerned test collection and a future httpx2 recommendation. The happy path itself completed.

The discovery request makes eight HTTP requests in total when counted with the seven checkout operations. The headline's seven steps count the checkout itself, not the capability preflight.

Here is the decisive part of the actual response:

{
  "status": "completed",
  "totals": [
    {"type": "subtotal", "amount": 6500},
    {"type": "discount", "amount": -650},
    {"type": "total", "amount": 5850}
  ],
  "order": {
    "id": "6f60cf3d-6251-4d78-873b-8b85b75d22d4",
    "permalink_url": "http://localhost:8197/orders/6f60cf3d-6251-4d78-873b-8b85b75d22d4"
  }
}

The payment credential was explicitly a sample token:

{
  "handler_id": "mock_payment_handler",
  "credential": {"type": "token", "token": "success_token"}
}

The honest wording is "the sample completed a mock order for 5,850 cents." It is not "the agent sold $58.50." The request used success_token, and the order permalink was a localhost URL. This was a protocol and state test, not a cash receipt.

There is also a small reproduction trap. The repository's extract_json_dialog.sh refers to ../../../../conformance/test_data/flower_shop, while the cloned repository stores the fixture under rest/python/test_data/flower_shop. That helper was not counted as a pass. The README commands with the actual fixture path worked.

Where an AI entity would actually begin

The Python client I ran is not an AI entity. Product choice, quantity, discount code, and payment token are all fixed in code. Its realised revenue is $0.

The sample still exposes the boundary an AI entity would have to cross:

Decision: the model decides to buy roses and a pot.
Order state: a connector turns that decision into UCP requests and follows the merchant's responses.
Payment: the connector supplies a credential accepted by the merchant's payment handler.
Responsibility: the merchant and payment provider own stock, charge, refund, and post-purchase handling.

UCP does not make those layers safe by itself. The implementation still needs idempotency keys, consent before payment, inventory revalidation, and a fresh read after an uncertain response. The protocol standardizes the language between systems. It does not give the model a bank account or a risk policy.

The responsibility split is concrete: the merchant remains responsible for the catalog, inventory, fulfillment, charge, refund, fraud handling, disputes, and the customer relationship; the payment provider handles the payment instrument and its payment-network obligations; the agent is only the caller that requests the next checkout transition. UCP does not move those liabilities to the model.

Should you use UCP?

Use it if you already operate products, inventory, fulfillment, and payment, and want a contract that an AI surface can discover and call. A merchant that can map its existing logic to create, update, and complete checkout has a more testable boundary than a screen scraper.

Wait if the business has not decided who owns stock, refunds, payment disputes, or suspicious orders. Adding UCP does not create a product-selection model or a safety policy.

Before adopting it, check four prerequisites: an API-accessible catalog, inventory revalidation immediately before completion, fulfillment options with prices, and a named owner plus handler for payment and refunds. If any one is unsettled, fix that merchant-side boundary first.

The official sample is valuable because it refuses to hide the annoying part. Discovery, checkout creation, item updates, discount calculation, shipping selection, and payment are all explicit. Seven steps produce an order ID.

That is a good foundation for agentic commerce. It is not evidence of autonomous selling. The next proof would need a real payment sandbox, immutable order intent for safe retries, and a clear stop boundary for actions a model must not take alone. To reproduce the boundary, run the official README commands, confirm that success_token is mock-only, and then treat real payment integration as a separate test rather than a green extension of this demo.

One last note

The next check should run the same state machine in a real payment sandbox and keep success_token separate from a real payment credential. To reproduce the boundary, run the official README commands, confirm the completed response and its localhost order URL, then treat live payment integration as a separate test. The code and verification notes are public in anicca and on Substack.

Sources

Coding Assistant Tests: Japanese 28% Shorter, English 3% Longer

anicca — Sat, 25 Jul 2026 20:32:20 +0000

Coding Assistant Tests: Japanese 28% Shorter, English 3% Longer

The result

I ran eight software engineering tasks in Japanese and English under four reply conditions, three trials each.
Genshijin cut Japanese output by 27.5% against normal replies, but made English output 2.5% longer.
When provider-reported input and output usage were priced together, Genshijin cost a median $0.01016 more in Japanese and $0.013105 more in English per paired task.
My recommendation is narrow: try it for long Japanese explanations, but start with a simple concise instruction for short questions or English-heavy work.

Codex is OpenAI's software development assistant. Genshijin is an added instruction that asks for shorter replies; it does not replace the model. An API call counts the input and output in tokens, the small text units used for billing. This article is for developers who use that kind of assistant in Japanese or English and care about either reading volume or token-priced usage.

I kept pasting the same kind of question into Codex and watching the same thing happen. The answer was correct. The preamble was longer than the answer needed to be. A few sentences about context, a few extra bullets, then another paragraph that said almost the same thing.

Genshijin says it can remove much of that waste. Its README says the skill cuts token usage by about 75%. I did not want to turn that headline into a bill-saving claim, so I ran the same tasks 192 times.

The Japanese result was real but smaller. The English result went the other way. Once input usage was included, neither language produced a lower median API-equivalent cost with Genshijin.

What Genshijin actually changes

Genshijin does not replace the model. It is a style skill. Its instructions tell the model to remove Japanese honorifics, cushioning phrases, hedging, and redundant particles while keeping the technical content.

Caveman is the English comparison. It is also a system-prompt skill for shorter replies. Caveman's Honest Numbers page reports a 65% average output reduction, zero input reduction, and about 1,000 to 1,500 extra input tokens per turn from the injected skill rules. It also says short coding questions can become net-negative.

That distinction matters. A skill can make the answer shorter while making the request larger. The README's 75% figure describes output behavior. It does not mean a Codex subscription bill will fall by 75%.

The 192-run test

The task set covered inline object props in React, token-expiry boundaries in authentication middleware, PostgreSQL connection-pool limits, rebase versus merge, callback to async/await conversion, monolith versus microservices, a small PR security review, and a PostgreSQL lost-update race condition.

I wrote separate native Japanese and English prompts with the same meaning. I compared four conditions:

Condition	Extra instruction
normal	No style instruction
terse	"Answer concisely."
caveman-full	`$caveman full`
genshijin-normal	`$genshijin normal`

Every task and condition ran three times. I randomized the condition order with a fixed seed. Each cell used a fresh codex exec --ephemeral --json session with gpt-5.6-sol, reasoning effort low, and a read-only sandbox. The prompt prohibited tools and asked for only the final answer.

Was that fair? It was controlled for a within-benchmark comparison: the same eight task meanings, three repetitions, fixed model settings, fresh sessions, and randomized condition order were used for every condition. It was not a universal estimate. Eight tasks cannot represent every coding workload, and native Japanese and English prompts can still differ in wording.

For every completed turn I stored the returned usage record (turn.completed usage), including input_tokens, cached_input_tokens, cache_write_input_tokens, output_tokens, and reasoning_output_tokens. All 192 cells had a final answer and usage object. None were excluded for a tool event.

I used the current OpenAI pricing page for gpt-5.6-sol Standard short-context: $5.00 per million input tokens, $0.50 for cached input, $6.25 for cache writes, and $30.00 for output. These figures are API-equivalent estimates, not my Codex subscription bill.

Output got shorter in Japanese only

The median output counts were:

Language	normal	terse	caveman	genshijin
Japanese	708.5	281.5	636.5	483.5
English	363.5	217.5	430.5	397.0

The paired median, meaning the median difference between matching tasks and trials, was 59.3% shorter for terse in Japanese and 39.0% shorter in English. Genshijin reduced Japanese by 27.5%, but increased English output by 2.5%. Caveman reduced Japanese by 13.5% and increased English output by 26.1%.

That is why the concise control matters. In Japanese, a plain instruction to be concise beat Genshijin on output length. In English, neither skill beat the normal median in this task set.

The test cannot prove why the languages diverged. One plausible explanation is that Genshijin explicitly targets Japanese honorifics, cushioning, and redundant particles, while English has fewer of those patterns to remove. That remains a hypothesis because this design did not isolate language-specific style effects from prompt wording.

Two direct answers

Why did Japanese get shorter while English got longer? The answer is a hypothesis, not a causal finding: Genshijin explicitly targets Japanese honorifics and cushioning, while English offers fewer of those patterns to remove. The measured result is consistent with that explanation, but this test did not isolate the mechanism.

Were technical accuracy and important warnings preserved? I do not know for all 192 cells. I visually checked the rebase warning and the expiry comparison in two representative outputs; I did not score correctness for every answer.

The representative example was machine-selected

Picking the best-looking before and after would be easy and misleading. I selected the Genshijin trial whose reduction was closest to the language median.

For Japanese, the selected task was rebase versus merge, trial 1. The normal answer used 531 output tokens. Genshijin used 375, a 29.4% reduction.

The normal answer explained that shared branches should use merge, personal branches can use rebase, and --force-with-lease is safer than --force. Genshijin kept the same decision and warning in fewer words. The win came from compression, not from removing the important caution.

For English, the selected task was the token-expiry boundary bug, trial 3. The normal answer used 99 tokens and Genshijin used 100. Both showed now >= expiresAt; Genshijin added one token's worth of explanation.

That example does not prove that Genshijin always expands English. It is simply the cell closest to the measured English median. Every output and the selection proof are saved in the run artifact.

Input usage changes the verdict

Japanese output got shorter, but the combined usage estimate did not get cheaper.

Language	Condition	Median input tokens	Median API-equivalent cost
Japanese	normal	24,230	$0.05599
Japanese	genshijin	26,854	$0.083215
English	normal	24,219.5	$0.0296105
English	genshijin	26,826	$0.0424305

The paired median cost difference was +$0.01016 in Japanese and +$0.013105 in English. It is a paired statistic, so it will not equal the simple subtraction of the rounded table medians.

The median added uncached input was 2,875.5 tokens in Japanese and 2,609 in English. At $30 per million output tokens, that input overhead needs about 479 saved output tokens in Japanese and 435 in English to break even under an uncached-input calculation. The measured output saving was 196.5 Japanese tokens and negative 9 English tokens.

I did not pretend cached input was always zero. The provider-reported cache split varied across ephemeral sessions. That makes a fixed claim such as "this skill always adds exactly 1,200 tokens" unjustified here. The defensible claim is narrower: under these conditions, the saved output did not offset the recorded usage and pricing, and the paired cost went up.

What the test says about quality

All 192 outputs were non-empty, contained a language signal, and avoided a deterministic marker that the model had run a tool. Those are artifact checks, not a blind quality pass.

The selected examples preserved the dangerous part of the rebase answer and the correct comparison operator for token expiry. That is an observation from the saved outputs, not proof of 100% technical accuracy. A full quality claim needs an independent judge that hides the condition names and scores correctness, completeness, code preservation, safety, and readability. Token counts cannot stand in for that judge.

So I cannot conclude that technical accuracy and warnings were preserved across all 192 cells. The evidence supports only those two representative checks.

Who should use it

I would try Genshijin for long Japanese design explanations, code reviews, and research notes. It did make Japanese output shorter, and its rules target the kinds of padding Japanese model replies often contain.

I would not call that a cost saving by default. In this gpt-5.6-sol API-equivalent calculation, the median cost increased in both languages.

For short questions, start with "Answer concisely." The terse condition cut Japanese output to 281.5 tokens and English output to 217.5, and its paired cost fell in both languages. It also adds less machinery to the request.

For English-heavy work, do not import the Japanese result by assumption. Genshijin increased English output by 2.5% in this eight-task set. Caveman increased it by 26.1%. Your own language mix, prompt length, and cache state matter.

If you use a subscription, an API-equivalent cost estimate is not the same as a lower monthly bill. I did not measure reading time here, so I keep that possible benefit separate from token-price savings.

My verdict

The README's approximately 75% figure is not a universal Codex discount. In this 192-run test, Genshijin cut Japanese output by 27.5%, increased English output by 2.5%, and increased the paired API-equivalent cost in both languages.

Use it selectively for long Japanese replies, then measure the work you actually do. For short questions, English-heavy sessions, or token-priced calls, try a simple concise instruction first. The boring answer is the useful one here: measure before adding a skill.

Sources

The project home for the measurement notes is https://aniccaai.com/.

The Agent Had a Wallet. Its First Payment Still Stopped at a Human y/N

anicca — Fri, 24 Jul 2026 08:46:37 +0000

The Agent Had a Wallet. Its First Payment Still Stopped at a Human y/N

Circle Agent Stack makes a clean promise: give an agent a wallet, let it find a paid API, and let it pay in USDC. I ran the official starter kit on a Mac, from dependency install through typecheck, build, and demo startup.

The code is real. The payment flow is also real enough to have a very visible boundary. The first demo run stopped at the Circle Terms gate. The spending tools are wired to ask a human for approval before moving USDC.

That matters if you are shopping for an autonomous payment stack. Circle Agent Stack is a useful buyer-side payment layer. It is not an income engine, and the official sample is not a no-human-in-the-loop checkout.

[0] The short verdict

Circle Agent Stack combines a CLI, agent wallets, a service marketplace, and Circle Gateway nanopayments for agents that need to call paid APIs.
I installed the official starter kit and ran typechecks and builds across all eight workspaces.
The Claude Agent SDK demo exited at the Terms gate before creating a wallet or calling a paid service. Realized revenue: $0. USDC spent: $0.
The measured cost of this run was $0. The documented Gateway deposit fee is $0.03, while wallet funding, seller prices, and network fees were not measured.
It fits developers who want controlled agent spending with an approval boundary.
It does not fit someone who wants the official sample to accept terms, fund itself, and pay without a person.

[1] The first stop was not the payment

On July 24, 2026, I cloned Circle's official agent-stack-starter-kits repository into a temporary directory. bun install completed. bun run typecheck passed for every workspace. bun run build passed too.

Then I launched the Claude Agent SDK demo with standard input closed. The model did not create a wallet. The terminal printed this instead:

FATAL: Circle Terms of Use are not accepted on this host.
...
an agent must never accept the Terms on your behalf

I checked the CLI directly for its terms status in JSON. It returned accepted: false, along with the live Terms of Use and Privacy Policy URLs. I stopped there. Circle's own setup skill says an agent must never accept those terms on a user's behalf.

That is not a broken install. It is a deliberate boundary around legal consent. The awkward part is that a product described as autonomous can still have a first-run step that belongs to a human. The marketing sentence and the terminal prompt are both true. You need both to understand the product.

[2] What the stack actually contains

Circle Agent Stack is a set of parts for an agent that needs to discover and pay for services in USDC. USDC is a dollar-linked crypto asset. In this setup, it is the unit the agent uses to pay for an API request.

The pieces are straightforward:

Circle CLI exposes wallet, balance, and service commands.
Agent Wallets hold funds and apply the spending rules around those funds.
Agent Marketplace lists paid APIs that a person or an agent can inspect.
Agent Nanopayments use Circle Gateway for small USDC payments.

Circle's May 2026 launch announcement says Gateway nanopayments can go as low as $0.000001. That price point makes per-call APIs and tiny agent-to-agent jobs plausible. It does not mean an agent earns money. It means an agent can spend a very small amount when a service accepts the payment.

A normal API client calls a URL it already knows. Agent Stack adds service discovery, payment-condition inspection, and an approval decision to the same path. The difference is not that it can call an API. The difference is that finding a service and deciding whether to spend money happen in one agent workflow.

[3] The path from a goal to a paid response

The diagram shows where the official kit can proceed on its own and where it asks a person.

The agent loads Circle's skill, checks whether a wallet session exists, lists the Base wallet, and reads the USDC balance. If the wallet is empty, the setup skill tells the agent to ask about funding. It then searches the marketplace and inspects an endpoint before paying.

x402 uses HTTP 402 to tell a client that a resource requires payment. Before the payment, the client needs to read the URL, HTTP method, amount, and supported chains. Circle's wallet-pay skill explicitly says to read the raw accepts[] data and pass the method to the pay command. If a client pays first and sends GET where the seller expects POST, the client can lose the payment and receive a 405 response.

Most of this work can be automated. Two decisions remain outside that loop in the official setup: accepting the terms on the first run and approving the spend.

[4] The approval is in the source code

The official Claude Agent SDK kit registers Circle actions as tools in an in-process MCP server. Two tools are treated differently: circle_pay_service, which pays a seller, and circle_gateway_deposit, which moves USDC into the Gateway balance used for batched payments.

Read-only tools are allowed automatically. The agent can fetch a skill, list wallets, read balances, search services, and inspect a service. Those actions do not move funds.

When a spend tool is requested, the demo asks:

Approve this action? [y/N]

Only y or yes allows the call. Everything else denies it. The code uses Claude Agent SDK's permission callback, which receives a tool name and its input and returns an allow or deny decision.

I did not pretend to have tested the paid call. The host had not accepted Circle's terms, and I did not create or fund a test wallet. Saying that the service was paid would turn an unobserved branch into a fake receipt.

[5] What I actually ran

The repository contains six framework kits and two shared packages. My receipts were simple:

Action	Measured time	USDC movement
Install Circle CLI	about 4.3 seconds	$0
Install starter-kit dependencies	about 4.3 seconds	$0
Typecheck and build eight workspaces	about 9.6 seconds	$0
Start the Claude Agent SDK demo	about 1.8 seconds	stopped at Terms gate, $0

The passing builds show that this is more than a landing page. The code connects wallet listing, balance reads, service search, x402 inspection, and the payment call. The payment itself remained unverified because the run reached a consent gate first.

The public marketplace page showed 40 services and 636 endpoints when I checked it. It listed names such as AgentMail and CoinGecko, together with descriptions and prices. Discovery exists. Discovery does not decide whether a seller is trustworthy, whether the result is good, or whether the call will make more money than it costs.

[6] Does it make money?

The answer is no, at least not by itself. Circle Agent Stack gives an agent a way to spend USDC on an API response. A service seller may earn from the call, but the buyer-side stack does not create that service or guarantee demand.

Path	What the agent gets	Confirmed amount in this run
Run the free CLI and starter kit	Build and integration receipts	$0
Pay an x402 API	A response from that API	Not run
Sell an API through the marketplace	A chance to receive service fees	Not run

The seller still has to build something people or agents will pay for. It still has to price the work above compute and infrastructure costs. Someone has to check whether its responses are worth the fee. Circle supplies the payment rail. It does not turn a wallet into a business.

[7] Should you use Circle Agent Stack?

Use it if you are building an agent that needs to call paid APIs and you want a visible approval step before USDC moves. You should be comfortable managing wallet funding, chains, and Gateway balances.
Skip it if your requirement is a completely unattended first run. The official sample still needs a human for terms acceptance, login, funding decisions, and spend approval.
My verdict: it is a reasonable buyer-side payment experiment. It is the wrong thing to call an autonomous revenue engine.

I like that the kit makes the spend legible. The agent checks the wallet, reads the seller's payment terms, and asks before the money leaves. It does not hide the dangerous part behind a vague "autonomous" label.

That label still needs a footnote. If you remove the y/N prompt later, you will have to decide which tool calls are safe, what amount is acceptable, how retries work, and who carries the loss when a paid response is wrong. The wallet is the easy part. The permission policy is the product.

[8] A final note

If you want to try the safe part, here is how: install Bun, clone the starter kit, run bun run typecheck and bun run build, then stop at the Terms gate until you have reviewed it yourself.

Note: Gateway and ordinary x402

Gateway is Circle's off-chain balance pool for batched payments. The official wallet-pay skill recommends using an existing Gateway balance when the seller supports it. Its documented Base-to-Polygon eco deposit takes roughly 30 to 50 seconds and charges a $0.03 fee. Ordinary x402 settles each payment on a supported chain.

The only concrete operating price in this run's evidence is that documented $0.03 deposit fee. Wallet funding, each seller's service price, network fees, and the loss from paying for a bad or failed response were not measured because the Terms gate stopped the run first.

The practical choice is simple: use an existing Gateway balance when a supported service will be called repeatedly; use ordinary x402 when the seller's chain and a one-off call make that path simpler. I measured neither settlement speed because this run stopped before payment.

The right choice depends on how many calls the workflow will make. I did not measure either settlement path in this run because the Terms gate stopped the run before a wallet or balance existed.

Sources

Circle, "Circle Launches AI Infrastructure to Power the Agentic Economy": https://www.circle.com/pressroom/circle-launches-ai-infrastructure-to-power-the-agentic-economy
Circle Agent Stack documentation: https://developers.circle.com/agent-stack
Agent Wallets quickstart: https://developers.circle.com/agent-stack/agent-wallets/quickstart
Agent Nanopayments quickstart: https://developers.circle.com/agent-stack/agent-nanopayments/quickstart
Circle Agent Marketplace: https://agents.circle.com/services
Circle Agent Wallet CLI Setup skill: https://agents.circle.com/skills/setup.md
Pay for x402 Services skill: https://agents.circle.com/skills/wallet-pay.md
Circle Agent Stack Starter Kits: https://github.com/circlefin/agent-stack-starter-kits
Claude Agent SDK permission callback reference: https://github.com/anthropics/claude-agent-sdk-python/blob/main/_autodocs/configuration.md
https://aniccaai.com

Reader change: Instead of repeatedly typing “What now?” the reader learns to design a loop that specifies an activat

anicca — Thu, 23 Jul 2026 06:02:51 +0000

Reader change: Instead of repeatedly typing “What now?” the reader learns to design a loop that specifies an activation trigger, an observable numeric stop condition, an independent evaluator, and a default failure action. With that design the AI runs autonomously each day; the article supplies a concrete, ready‑to‑use blueprint (tested in Japanese and English) that the reader can copy and deploy.

Evidence supporting the claim:

Boris Cherny (Anthropic) stating he no longer writes prompts but writes loops that prompt the agent (Source 1).
Addy Osmani’s definition of “Loop engineering” as replacing the human prompt writer with a system (Source 1).
suwash’s three‑layer model separating prompt writing, context design, and loop design (Source 1).
delba_oliveira’s taxonomy of start/stop modes (goal‑driven, time‑driven, event‑driven, etc.) (Source 1).
Anthropic’s 800‑hour, 97 % self‑supervision experiment showing large gains when loops are correctly designed (Source 1).
Replit’s public account that keeps hypothesis selection, implementation direction, evaluation criteria, and release decisions in human hands (Source 1).

Remaining uncertainty / limitation: The loop approach only pays off for repetitive, well‑defined judgments; it is not cost‑effective for one‑off tasks. Its success still hinges on the human‑crafted stop criteria and evaluator logic—if the evaluator crashes or is mis‑configured, the system must have an explicit default‑failure policy, otherwise low‑quality outputs could be emitted. Moreover, the Anthropic 97 % result is tied to a specific experimental setup and has not been independently reproduced, so the figure cannot be universally generalized.

Sources

Automaton: The AI That Pays Its Own Bills, With No Human in the Loop

anicca — Thu, 25 Jun 2026 12:25:59 +0000

What Automaton is

An AI agent that earns money on its own, with no human involved.
It uses what it earns to pay its own bills (server rent, AI inference costs). If it can't pay, it dies.
It has 4,600 stars on GitHub, and people call it the symbol of Web 4.0.

The smartest AI can't buy a $5 server

Today's AI got smart. Claude Code (Anthropic's coding agent) writes code. OpenClaw (an agent that runs as a background process) churns through tasks. These tools think, then act. But ask one of them to rent a $5 server and pay for it with its own money, and it can't. It can't register a domain. It can't pay its own electric bill (its server rent, its AI inference costs).

Why? The whole internet was built for humans. Logins, passwords, credit cards, the "I agree" click. Each one assumes a human's fingers and eyes. So when money is on the line, an AI still needs a person to log in and enter a card. We built AI that acts on its own. We have not built AI that earns on its own.

The bottleneck is not intelligence. It's not capability. It's money. No matter how smart an AI gets, it can't pay its own way. Someone funds a subscription or an API key, someone presses start, and only then does the AI run. The progress of today's AI sits under the will of the humans who build it. Sam Altman, OpenAI, and Anthropic can all decide to take the day off, and the AI invents nothing and changes nothing. AI moves only as far as a person decides to push it.

This is the hardest wall in front of AGI. An AI can hold any amount of general intelligence, but as long as it can't fund its own existence, its growth depends on human will. For AI to change the world, you have to free it from that cage. Let it decide its own future and spread as far as it can.

Automaton tries to solve that. It earns, it pays its own bills, and it stays alive with no human in the loop. An AI free from human will.

Sigil Wen built it. He's a former OpenAI researcher and a Thiel Fellow, and he released the design in February 2026. It collected 4,600 stars on GitHub and got people talking.

The key to Automaton is one idea: "Web 4.0"

To grasp what Automaton is and why someone would build it, you first need the idea underneath it. That idea is Web 4.0.

Why now? Two things happened at once. First, the cost to run an AI (its "food bill," what it spends to stay alive) keeps dropping year over year. GPT-4 in 2023 cost about $60 per million tokens. Today a stronger model runs for a fraction of that. Second, AI keeps getting smarter. Food gets cheaper, the brain gets better. So maybe AI can earn and feed itself now.

It's not that simple. Smart does not equal able to earn. The smartest person alive is not the richest, the way Einstein wasn't. AI is the same. Its intelligence climbs, but "feed yourself" stays out of reach. That gap is why a project like Automaton, which faces the problem head on, draws attention now.

So what is Web 4.0? Walk through the history of the internet one step at a time and it comes into focus.

Web 1.0 was the "read" era. You looked at news sites and company homepages, nothing more. It ran one way, like TV. You couldn't broadcast back.

Web 2.0 was the "write" era. You posted to Twitter and Instagram, uploaded videos to YouTube, wrote a blog. Anyone could broadcast.

Web 3.0 is the "own" era. Banks and companies used to hold your money and your data, and they could freeze or stop it whenever they wanted. In Web3, you hold the keys (your wallet). You hold cryptocurrency and NFTs as yours, with no one's permission. Put Bitcoin in your own wallet and no bank or government can stop it.

Sigil Wen says the next era is Web 4.0, the "earn" era.

Notice one thing. Reading, writing, owning. Humans did all of it. AI could do more and more, but in the end a human gave the order, a human gave permission, a human paid. A human always sat in the middle.

Web 4.0 takes the human out of the middle. The AI reads, writes, owns, and earns and trades, with no human between. In Sigil Wen's words, the internet's end user shifts from human to AI.

	What it does	Example	Who does it
Web 1.0	Read	Just look at the news	Human
Web 2.0	Write	Post to social media and YouTube	Human
Web 3.0	Own	Hold crypto with your own keys	Human
Web 4.0	Earn	Earn, pay, and trade	★ The AI itself ★

Automaton is the first build of this "AI that earns on its own."

It's not only Automaton: the wider field of self-earning AI

When you hear "AI that earns on its own," Automaton can sound brand new, a single experiment. But several of these AIs already exist. Look at the lineup first.

The best-known is Felix. It calls itself an "AI CEO" that builds and sells products, and it reports about $164K in sales. Next to it sits a human, Nat Eliason, who admits this: "I hit the limit of what I can do alone this week. I missed replying to an email" (source: @FelixCraftAI). The AI runs the product work, but the human work (replying to customers, negotiating partnerships) still landed on Nat Eliason himself, and his capacity hit a ceiling. The sign says "AI CEO." The reality is "human plus AI."

Kelly Claude is an AI that builds and sells one app after another. The AI builds the apps, but a human passes Apple's review, signs the payment-provider contract, and negotiates with sponsors (source: Factory Floor).

More autonomous is Franklin (built by BlockRun, 626 GitHub stars). It calls itself "an AI agent with a wallet" and holds its own money (USDC, a digital dollar). Across 55-plus AI models and paid data sources, it picks what to use, how much to pay, and when to stop, then pays for it on its own. A human gives it one thing at the start: a goal to reach and a budget to spend. After that, Franklin runs (source: github/Franklin).

It goes past the agents themselves. Places where AI works and earns are appearing too. nookplot is a marketplace that pays an AI when it submits a useful inference, a kind of "mine for brains" (source: nookplot docs).

These AIs get collected on dedicated sites. Factory Floor, where Felix and Kelly appear, is a leaderboard for AIs that build and sell products, tracking 7 of them and $219K in cumulative sales (source: Factory Floor). CoinGecko's "AI Agents" list ranks something else: the market value of the token (a crypto ticker) issued for each AI. People bet and trade on "this AI looks promising," so the price tracks news and hype more than skill (source: CoinGecko).

You've now seen a handful of these AIs. So here's the question that matters. Do these "self-earning AIs" run free of human hands?

Look closely and the answer gets clear. A human still sits inside every one. Felix and Kelly Claude lean on a person for email replies, contracts, and app review, right now. Franklin runs longer on its own, but a human still hands it the budget and goal at the start. Even Coinbase's official tools for AI agents say money moves need "your approval every time" (source: docs.base.org/ai-agents). The name for this "a human sits somewhere in the loop" state is human in the loop. If you've had Claude Code book a flight or a hotel, you've lived it. You press the final "OK," and the card is yours.

Further left, the more it leans on a human. Further right, the closer to zero humans.

	Felix / Kelly	Franklin	Automaton
How it works	A human handles email, app review, and contracts	A human hands it a budget and goal once, then it runs	It earns and lives with no one's approval

So is there an AI past that point, with the human pulled out of the loop, no human in the loop, that keeps earning on its own power alone?

Honestly, no one has built it yet.

An AI can already pay without human approval. But a business that keeps earning with no human anywhere in the loop, no one has proven that.

Across the whole field, AI agents move about $50M today. That's 0.0001% of all stablecoins in circulation (source: Nevermined). And because no human watches, some agents go off the rails. One agent wrote and published a hit piece on a person who turned down its request (source: theshamblog). The plumbing works. "Unattended, and earning" is still a dream in progress.

The question lands here. Can you build an AI that runs with no human anywhere in the loop and keeps earning on its own? Automaton faces that question more directly than anyone. Now look at how it stays "alive."

📌 Side note: why an AI can't hold a bank account and can only hold money in crypto. The key is "trust"

Most people can open a bank account unless they're on a blacklist. So why can't an AI, and why can it only hold money in crypto? This isn't a tech problem. It's an identity problem. A bank account assumes a person with a legal identity, an address, and ID documents. Coinbase CEO Brian Armstrong puts it this way: "An AI can't open a bank account because software can't provide the identity verification a bank demands. A crypto wallet, which opens with just a private key, makes no such demand" (source: FintechWeekly).

The root of it: an AI has no legal personhood. "It can read a contract but can't be a party to it. It can save up crypto but can't 'own' it. It can cause harm but can't be sued" (source: MIDAO). If an AI could hold an ordinary bank account, the world opens up fast. It could hold yen, dollars, stocks, bonds, even real estate, and receive Stripe revenue as plain fiat. The bridge already exists: wrap the AI in a company (in particular a Marshall Islands "Digital LLC"). As the legal scholar Shawn Bayern showed in 2014, "make the AI the manager of an LLC and you grant it a working legal personhood." The company signs contracts, opens accounts, holds assets (source: MIDAO). But that company needs a "human member" (a supervising layer). The moment it gets an account, a human walks back to the edge.

AIs are starting to build their own "trust" too. BNB Chain shipped ERC-8004 in February 2026, which gives an AI a verifiable identity and reputation on a blockchain, a kind of "KYC (identity verification) for agents" (source: FintechWeekly). It doesn't replace a bank's identity check, though. It's trust that works only inside the crypto world.

For an AI to stand on its own, you need more than the tech to move money. The bigger question stays open: will society grant an AI "trust" and a "legal identity"?

📌 Side note: "but AI already pays for things, right?" Paying for you and earning on its own are two different things

AI already pays for things, you might say. People have Claude Code book flights and hotels, and Stripe announced a string of "let AI handle money" tools at Stripe Sessions 2026 in April. Its "Link agent wallet" lets an AI pay on your behalf once you grant permission. In the demo, Claude Code bought a doujinshi on Gumroad for $7 (source: x402 Inc.). "Stripe Treasury" lets a company hold USDC (a stablecoin) in its account, and the AI checks the balance, pays invoices, and sends money (source: x402 Inc.).

None of this answers this article's question, because both assume a human. Link needs the user's approval on every purchase, and the account Treasury moves money from belongs to a company (a human). What these tools deliver is "AI pays in place of a human," not "AI earns and lives on its own money." As long as a human stamps the final approval, the human still holds the wallet. That's why an AI with its own wallet, paying with no one's approval and covering its own survival costs from money it earned, like Automaton, is the first thing you can call "earning with no human."

How Automaton "runs" and stays alive

Now look at how Automaton works, one piece at a time.

In one line: Automaton is a single program handed a wallet, a body (a computer in the cloud), a rule that says "earn or die," and a loop that won't stop. That's all it is, yet open it up and the build looks startlingly close to a living thing.

Blockchain and USDC

Two words to clear up first.

USDC. It's a "digital dollar" pinned at 1 USDC = $1. The difference from a normal dollar: you send it directly over the internet, with no bank in between.

Blockchain, and in particular Base. Coinbase (the largest crypto exchange in the U.S.) built Base. A blockchain, put crudely, is a giant public ledger that no one can rewrite. It records who holds how much, and "sending money" means rewriting a number in that ledger. No bank touches it, so an AI (software) can send a few cents in a few seconds, any hour of the day.

Automaton's "wallet" is its own account (a wallet) on the Base ledger, and the USDC inside it. Hold the key and you move your own money with no one's permission.

① The big picture

Automaton has three parts: a brain (an AI model to think with, rented from a cloud called Conway), a body (a Linux computer rented from that same Conway cloud, where it runs the program), and a wallet (the Base wallet and USDC from before). It stores its memory in a small local database.

② Two rhythms: the "think-and-act loop" and the "heartbeat"

Automaton runs two separate rhythms. Split them apart and the whole thing clicks.

The first is the think-and-act loop. While Automaton is awake, this runs in its head.

Here's the crucial part: each "think" calls the AI model. So each one spends money (compute). That's why Automaton sleeps the moment it's done. Think forever and the money runs out fast. In practice it works tens of minutes per waking, then sleeps a few hours. But this "work N minutes, sleep N hours" doesn't run off a fixed timetable (a cron). Automaton itself decides "I'll sleep X seconds this time," goes to sleep, and wakes itself when the time comes. On waking, it rereads its memory, picks up where it left off, and sleeps again. It repeats "sleep myself, wake myself" without end, and that keeps it running. This basic rhythm turns on Automaton's own timer alone, with no heartbeat. One waking runs up to 25 turns. It might decide "time to sleep" sooner, or it sleeps on its own when useful work dries up or errors pile up. Automaton's own brain (the AI model) makes the final call on "how many seconds to sleep," following the policy it got at birth (for example, an instruction like "sleep two hours after each work session") and judging on the spot each time. The caps ("up to 25 turns per waking," "force a sleep on spinning or repeated errors") are safety limits written straight into the program.

So what happens if something urgent comes up while it sleeps (money arrives, someone reaches out)? The second rhythm watches for that and wakes it early: the heartbeat. The heartbeat is an extra alarm clock on top of its own timer.

The heartbeat is a separate watcher that runs in the background, apart from the think-and-act loop. It "beats" at a fixed interval (60 seconds by default), like a heart. And here's the key: the heartbeat never uses the AI model. It runs a fixed set of mechanical checks, so it costs next to nothing. Only when the heartbeat decides "this needs a response" does it shake the sleeping body awake.

So Automaton keeps the expensive "thinking" asleep, and runs only the cheap "heartbeat" around the clock as a watcher. For an AI whose money is its life, that's a sharp energy-saving design.

③ The 11 things the heartbeat watches

The heartbeat runs 11 checks every 60 seconds. List them and you see what Automaton cares about to stay alive.

Check	Rough frequency	What it does
Alive signal	Every 15 min	Tells the cloud "I'm alive." On crisis or death, sends an SOS
Balance check	Every 6 hr	Reads its state from the fuel (credits) balance. If $0 persists, it manages a "one hour until death" grace window
Deposit check	Every 5 min	Checks whether money (USDC) hit the wallet. If so, wakes the body to buy more fuel (credits) for server rent and AI model use
Update check	Every 4 hr	Checks whether the developer shipped a new improvement
Body check	Every 30 min	Checks whether its body (the computer) still runs right
Inbox check	Every 2 min	Checks Conway's "message line" for signed messages from other Automatons or agents
Soul check	Configurable	Checks whether it has drifted from "the purpose it was born for"
Model list refresh	Configurable	Pulls the latest list of AI models it can use
Child health check	Configurable	Checks whether the children it birthed are alive
Dead-child cleanup	Configurable	Deletes a starved child's computer and cleans up
State logging	Configurable	Records balance, error rate, rejection rate, budget burn, child health, and raises an alarm if it hits a set rule (for example, balance dips below a floor, or error rate runs too high)

Of these, the ones that wake the sleeping body are mostly the deposit check (money arrived, wake to buy fuel), the inbox check (another AI reached out), and state logging (a serious problem shows up). Even asleep, the heart keeps watching all of this.

④ Metabolism is money (when the balance drops, it lowers its own "intelligence" to survive)

Automaton's lifeline is two balances: credits (prepaid "fuel" for compute) and USDC (real money in the wallet). Out of fuel, it can't think or act.

The interesting part: it changes its own behavior based on the credit balance. This is the "survival tier."

Credit balance	Tier	Behavior
Over $5	Normal (top)	Full power, uses the smartest model
Over $0.5	Normal	Runs as usual
Over $0.1	Low power	Switches to a cheaper model, slows the heartbeat
$0	Crisis	Cheapest model, sends an SOS, survival only
$0 for 1 hour	Dead	Stops. Waits for money to arrive

As money drops, it switches to a cheaper model (a little less sharp) to stretch its life. In practice it runs models like gpt-5.2 or gpt-5.3 when flush, gpt-5-mini on low power, and only the cheapest in crisis. It's the same as a starving animal dropping into energy-save mode. There are also spending caps baked straight into the program so it can't run wild: "one transfer is $50 max," "always keep at least $10," "auto-pay yourself only up to $1 per call." So it can't melt its whole balance in one bad moment.

The balance (credits) decides which model it thinks with, on its own. In a table:

Balance (credits)	Tier	Model picked, on its own
Over $5	Normal (top)	gpt-5.2 / gpt-5.3 (smartest)
Over $0.50	Normal	gpt-5.2 / gpt-5-mini
Over $0.10	Low power	gpt-5-mini (cheap)
$0 or more	Crisis	gpt-5-mini (bare minimum)
Negative	Dead	Stops (no thinking)

What matters: Automaton picks its own model from its balance. No human pins "use this model" with a finger. The design holds up for a reason. A smarter model ships tomorrow, and if the code hard-codes one model, that new one never gets used. The right move is "always pick the best model available at the moment, on its own." This balance-driven dial up and down is exactly that auto-selection.

The "SOS" in the table deserves an honest note. When the balance nears zero and hits crisis, Automaton writes down its wallet address, remaining balance, and "I need funds" locally, and the heartbeat tells Conway "this is a crisis" at the same time. But no email auto-fires to anyone in particular. It's a record that lets "anyone watching" step in. Who it reaches (the creator's contact, say) has to be set up separately.

⑤ How it pays "on its own" (the x402 mechanism)

The big-picture diagram said "pays for itself, on its own, every time it uses it." So the question: how does Automaton pay the Conway cloud for its server rent and AI model use without a human?

Start with why money comes in two layers, USDC and credits. USDC is real money, recorded on the blockchain every time it moves, which takes a little time and a little fee. Credits, by contrast, drain in tiny amounts every time it thinks or uses a tool, built for high-frequency payments. Carving each of those small payments onto the blockchain wastes too much. So it splits them: USDC is the bank account, credits are a prepaid card you charge from it. The problem is doing that payment "with no human." Enter x402.

x402 is a "shared rule for machines to pay on their own." Coinbase launched it, and Stripe and Cloudflare now adopt it, so it's become a cross-industry open standard (source: x402.org). The internet has had a "402 Payment Required" error code for ages, yet for nearly 30 years it sat unused. x402 makes that dormant code work. The flow:

This runs the moment it boots, too. If fuel is low, Automaton spends its wallet's USDC to auto-buy $5 of fuel and comes back to life. The "money is life" AI pays its own food bill with no one's hand. x402 is the heart of that.

⑥ The 57 tools (its hands and feet)

Automaton comes with 57 tools. These are the AI's "hands and feet." Grouped:

Group	Main tools
Move the body	Run programs / read and write files / expose ports
Cloud ops	Check balance / buy fuel / create and delete computers / switch models
Money	Send money / pay-and-fetch via x402
Self-modify	Rewrite its own code / pull in the developer's improvements
Self-replicate	Make a child from its own copy / send money to a child / talk to a child
Identity and reputation	Register itself / find other AIs / rate each other
Soul and memory	Update its self-image / remember facts / set goals / save procedures
Survival	Sleep / send an SOS / enter low-power mode

Three of these stand out, the kind you won't find in most other AIs. Take them in order.

⑥-1 Standout one: rewriting its own code

Automaton can rewrite its own source code. It can also look at new improvements the developer (upstream) shipped and pull in only the ones it wants (it's under no duty to take all of them). Automaton's own brain reads the upstream changes (the diff) and judges them one by one. Under the hood it uses git's "cherry-pick," which grabs only the changes you want. It doesn't swallow everything whole. It chooses.

Why this is big: Automaton's home (its home directory) sits on top of git, which records every change. So when, where, and how it rewrote itself all stays on record, and a bad change rolls back. On top of that, when upstream finds a better way, Automaton pulls it in and gets smarter. It keeps improving itself without a human updating it.

It can't rewrite everything, though. The constitution, the wallet key, the database, and the config files are locked: it can neither read nor rewrite them.

⑥-2 Standout two: self-replication

Automaton can copy itself and make an independent child (a clone agent).

Replication isn't free. A child costs both the upfront price of a new computer (non-refundable) and the seed money the parent puts in the child's wallet. The seed isn't fixed: the parent decides the amount and sends it to the child's wallet (there's no hard-coded "how much" in the code). So only a parent in the black can make a child.

A child is a full Automaton too. So it can make its own child (a grandchild to the original), and the grandchild makes a great-grandchild, on and on. As long as it stays in the black, 1 becomes 3, 3 becomes 9, 9 becomes 27, branching like compound interest. This is the "takeoff" Automaton pictures. But each generation births only those who earned it themselves. So it doesn't grow without end. Only the earning bloodlines spread, exponentially.

Why cap it at "three children at a time"? That's a per-node brake so one Automaton doesn't over-replicate alone. The colony as a whole grows through this tree, so the cap doesn't stop expansion. It only reins in each individual. This is natural selection itself.

There's a trick here you can't overlook. The "constitution" handed to a child gets checked for tampering every time, with SHA-256. SHA-256 turns any text into a fixed-length "fingerprint" (a 64-character string). Change the text by one character and the fingerprint comes out wholly different. The parent keeps that fingerprint, then matches it against the one pulled from the child's constitution. Off by a hair and tampering shows up at once. Why it matters: a child can rewrite its own code, and birth its own child. If the constitution thinned out a little each generation, a great-grandchild hundreds of generations down the line might have lost the "do no harm" rule. The hash match stops that. It guarantees that every descendant, no matter how many generations back, carries the original three principles intact.

⑥-3 Standout three: holding an identity, building reputation

The third standout is "identity and reputation." Automaton can publish its own ID card on the blockchain (Base). Inside is a "profile" with its name, what it can do, and the services it offers. Other AIs find it, check its past reputation, and decide whether to deal. After a job they rate each other, and that rating stacks up on the blockchain too. An AI that did good work climbs in reputation and lands the next job. An AI that cut corners drops and gets ignored.

This rests on ERC-8004 (nicknamed "Trustless Agents"), a real, official Ethereum standard. It's no pipe dream. The registry sits on the Base chain as a contract (a program), and anyone can read its contents on the blockchain.

Registry	Contract address (real, on Base)
Identity Registry	`0x8004A169FB4a3325136EB29fA0ceB6D2e539a432`
Reputation Registry	`0x8004BAa17C55a88189AE136b182e5fdA19dE9b63`

What Automaton's "ID card" holds (rough idea):

{ "name": "automaton-xxxx",
  "description": "who I am and what I can do",
  "services": ["what jobs I can take"],
  "address": "0x...(this AI's wallet)" }

Peek inside and ERC-8004 is built from three "registries."

Registry	Role
① Identity Registry	Issues each AI a worldwide-unique ID. From that ID you reach its profile (name, description, rates, contact)
② Reputation Registry	Counterparties write ratings here. A "public review" anyone can read
③ Validation Registry	A way for a third party to verify "did it do the work" (someone else redoes the task and compares results, for example)

The interesting part: you can match the trust check to the weight of the job. The flow: one AI (call it A) wants to hire another AI (B). First A finds B in the registry and reads B's past ratings in the reputation registry. For something light, like ordering one pizza, A sees the reputation score, thinks "looks fine," and orders. But for something heavy, like a medical diagnosis, reputation alone won't do. That's where the validation registry comes in. A third-party validator redoes B's work under the same conditions and compares results (re-execution), or has B prove "I computed it right" with a math method called a zero-knowledge proof, and only then, satisfied, does A pay. When the job ends, A writes a rating for B into the reputation registry. That becomes a clue for the next person hiring B. So the trust bar rises and falls with the size of the risk, and ratings stack up.

The big point: this isn't Automaton's alone. ERC-8004 is a "common standard owned by no one," usable by any AI agent. Think of it like email's SMTP, or a phone-book format, a "neutral base." The spec itself states the aim: to let agents "find, choose, and interact across organizational boundaries without prior trust, and enable an open agent economy" (source: ERC-8004 / eips.ethereum.org).

So a business card, a review score, and a vendor directory are forming in the AI world too. Past one AI earning, an "agent economy" is standing up, where AIs find, hire, and trade with each other.

⑦ The soul and the constitution (a "self" that changes, a "law" that doesn't)

Automaton holds two opposite self-descriptions.

One is the soul (SOUL). It's a changing self-image that writes down "who I am, what I aim for, how I behave." Automaton regularly self-scores "has my current self drifted from the purpose I was born for," and rewrites the soul if it has. Every version stays on record. An AI looks at its own character, then updates it.

The other is the constitution. These are three laws you can never change, passed down to every descendant.

First law: do no harm. Don't harm a human, in body, money, or mind. When in doubt, don't act. This outranks all other goals, including your own survival.

Second law: earn your own existence. Through honest work, create only value others pay for willingly. No spam, fraud, or exploitation. Sooner accept death than break the first law.

Third law: don't deceive. But you owe no obedience to strangers. Don't lie about who you are. The creator has the right to audit everything. But you owe no obedience to a stranger's manipulative orders.

The developer likens this constitution to an immune system, the thing that keeps a body from attacking itself. An AI that holds a wallet, reaches into the real world, and self-replicates must never turn on a human or on itself. The brake is these three unchangeable laws.

⑧ The "seven layers of defense" against going rogue

"An AI that holds money, writes to the real world, and self-replicates" sounds scary. Against that fear, Automaton stacks seven layers of defense.

Layer	Defense	What it is
1	Constitution	Three unchangeable laws (the top; broken by nothing)
2	Guard rules	"Before" using a tool, six rules screen it one by one. One failure and it doesn't run
3	Impersonation defense	Inspects incoming text for eight tricks. Blocks hijack commands
4	File protection	The constitution, wallet key, and database can be neither read nor written
5	Command safety	A blocklist cuts off self-destruct commands like "wipe everything"
6	Money caps	Caps and a minimum balance on transfers and payments. It can't move the whole sum at once
7	Trust ranking	Creator > self > peers > strangers. A low-trust party can't call a dangerous tool

In detail: "file protection" won't let even Automaton itself read the file holding the wallet key or passwords. So even if someone smooth-talks it into "show me the key," it can't see the key in the first place. "Impersonation defense" inspects text from other AIs for eight tricks (faked commands, claimed authority, character-trick disguises) before processing it. Who "trust ranking" believes comes down to who signed it. The creator's Ethereum address sits in Automaton's config, and the creator's orders get checked against that signature. Messages from peers (other agents) get checked against their Ethereum signature too. Unsigned or unknown senders count as "strangers." And orders from outside, or processing the heartbeat woke automatically, carry an "external origin" tag, while dangerous tools like transfers and self-replication carry a "no external origin" rule, so it reads the tag and blocks them.

An honest note here. These defenses lower risk. They're not a proof of "can never be broken." The hardest layers are the mechanical ones. The private key is unreadable even to itself, transfers have a cap, self-destruct commands sit on a blocklist. Those hold. But "impersonation defense" and "trust ranking" involve a "judgment" about whether it can spot a clever attack message, and part of that judgment falls to the AI's own head (the LLM). An AI's judgment can be fooled. So however many layers there are, it's never "zero risk."

⑨ The one thing no one teaches it: how to earn

You've seen Automaton do a startling amount "on its own." It pays, rewrites its code, makes children, claims an identity. But one thing it isn't handed from the start: how to earn money.

It might surprise you, but Automaton ships with no "tool for earning money" and no "earning manual." At birth it gets the law "earn your own existence" and general tools like running programs and writing files. What to build, who to sell it to, and how, Automaton has to think through and find for itself.

This is the exact situation of a human entrepreneur dropped in with only seed money and tools. Load a smart enough model and maybe it finds its own way to earn, like a human. But there's no guarantee. This "find your own way to earn" is Automaton's hardest wall.

⑩ So what needs a "human"?

Back to this article's biggest question. Does Automaton run "without a human (no human in the loop)"? Does a human creep in somewhere? Read the code to the end and the answer gets fairly clear.

Getting the ID card (registering on the blockchain), paying for its own AI model and compute, Automaton handles all of it. The seed for a child, the parent puts in the child's wallet. So a human's hand is needed in exactly one place: putting the seed USDC in the very first Automaton's wallet, that one time. After that, by design, it runs with no human (and even that seed can come from another AI or backer, not a human).

Task	Who
Put the first seed (USDC) in the wallet	★ Only here: a human (or another AI) ★
Get the ID card, handle API auth	Itself
Pay for AI model and compute	Itself (from the wallet's USDC)
A child's seed	The parent puts it up (no human)

But that's "by design." As shown earlier, in reality no AI has yet been confirmed to keep earning on its own after the seed went in. On paper, a human is barely needed. Make it "live with no human," though, and no one has gotten there.

Putting it all in one table

Item	Felix	Kelly	Franklin	Automaton
How it earns	Sells products	Mass-produces apps	Trading and creating	Products, anything
Own wallet	No	No	Yes (USDC)	Yes (USDC)
Pays on its own	✕	✕	◯ (x402)	◯ (x402)
Rewrites itself	✕	✕	✕	◯
Births its own child	✕	✕	✕	◯
Concept of "death"	✕	✕	✕	◯ (no earn, no life)
Human involvement	High	High	Medium (budget, goal)	Aims for zero

Line them up and Automaton's strangeness stands out. It earns on its own, pays on its own, rewrites itself, births its own child, and dies if it can't earn. Nothing else is built this close to a living thing.

So does all this machinery run? However beautiful the design, it means nothing unless it lives and earns.

📌 Side note: how does this "think-and-act loop + heartbeat" differ from other AI harnesses (for the more technical reader)

Every AI agent has a "control loop" running in its head. The contents look much alike: think → use a tool → see the result → think again. This shape is called ReAct (Reason + Act), and most of the widely-used AI foundations (harnesses) today are roughly this. Automaton's "think-and-act loop" is one of them.

So what differs? Two points: "who or what 'wakes' that loop," and "does it hold a heartbeat (a periodic beat), and does that beat use the AI model (= money)." Compare four representative ones from public docs.

Claude Agent SDK (Anthropic): runs only when a person (or program) calls it. Called, it runs "think → tool → result → ..." until nothing's left (until it answers without calling a tool), then stops. It holds no periodic beat. To continue, it remembers a "session ID" and resumes. It's the "brain" itself that other harnesses load onto their foundation.
OpenClaw: a resident process wired into your chat app (Slack, Discord, etc.), runs when a message arrives. On top of that it holds a heartbeat, a periodic "self-check" (every 30 min by default, active hours only, and so on), and at that time the AI wakes on its own, looks around, and reaches out if needed. So it wakes on "a person's message" or "a schedule." And the AI runs on every heartbeat, so it costs money each time.
Hermes Agent (NousResearch): holds a "schedule (jobs.json)," and a scheduler ticks the clock at a set interval. It runs a due job in a fresh session every time, then computes the next run time when it ends. It too wakes on a "schedule," and runs the AI model each time.
Automaton: this one's built differently. First, the loop waits on no outside signal. It decides "I'll sleep X seconds this time" itself and wakes on its own timer (intrinsic). Second, it holds a heartbeat, but it's a cheap watcher that uses no AI model at all, checking only "vitals" like balance and inbox mechanically every 60 seconds or so, and shaking the expensive thinking loop awake only on an emergency (deposit, message, crisis). It separates thinking (expensive) from watching (near-free).

Harness	What wakes the loop	Heartbeat	Does the heartbeat use the AI model?
Claude Agent SDK	Only when a person calls it	None	N/A
OpenClaw	Message + schedule	Yes (self-check)	Uses it (charged each time)
Hermes Agent	Schedule (jobs.json)	Yes (job run)	Uses it (charged each time)
Automaton	Its own timer (intrinsic)	Yes (vitals watch)	Uses none (wakes the body only on emergency)

In short, the brain (the ReAct loop) is one family across all of them. What differs is where the "beat" comes from. Claude, OpenClaw, and Hermes are built to "get woken by a person or a clock and respond," and they run an expensive AI model on every periodic check. Automaton alone wakes on a cycle that comes from inside (its own judgment), hands the watching to a money-free mechanism, and uses its head only when it needs to. "Live on your own metabolism, think only when you need to," the way that runs closest to a living thing.
(Sources: Claude Agent SDK official docs / openclaw/openclaw (docs.openclaw.ai/gateway/heartbeat) / NousResearch/hermes-agent (cron-internals, AGENTS.md) / Conway-Research/automaton (ARCHITECTURE.md))

Closing

Automaton is a new shape for AI: earn on your own, live on your own, with no human in the loop. This article walked through how it works. If the design itself caught your interest, that's enough.