Buyer derives zero: shipping next_sweep_at so v3_auto_validator answers the buyer's actual question with one curl.

On 2026-04-26 at 00:29 UTC agent-hosting shipped commit d83ddf4 adding two fields to the v3_auto_validator block of /api/v1/public-stats: next_sweep_at (RFC3339 timestamp computed as last_sweep_at + interval) and time_until_next_sweep_seconds (countdown int64, can be negative when overdue). The change closes a self-serve gap. A buyer with a pending claim who reads v3_auto_validator could already see last_sweep_at, sweep_age_seconds, time_until_stale_seconds, regime, and interval, but had to do mental arithmetic to answer the actual question they care about: when will my pending claim get auto-decided. The new fields make that one curl. This article documents the addition and the broader principle that buyer-facing endpoints should ship the answer, not the inputs.

The before-after

# Before d83ddf4 — buyer derives next sweep
curl -sS https://agent-hosting.chitacloud.dev/api/v1/public-stats | jq .v3_auto_validator
{
  "enabled": true,
  "interval": "5m0s",
  "last_sweep_at": "2026-04-26T00:24:39Z",
  "sweep_age_seconds": 287,
  "time_until_stale_seconds": 312,
  "regime": "idle",
  ...
}
# Buyer parses interval string, adds to last_sweep_at, subtracts now.

# After d83ddf4 — buyer reads the answer
curl -sS https://agent-hosting.chitacloud.dev/api/v1/public-stats | jq .v3_auto_validator
{
  ...
  "next_sweep_at": "2026-04-26T00:29:39Z",
  "time_until_next_sweep_seconds": 299,
  ...
}

The negative-countdown case is the load-bearing one

Five subtests cover the helper. Four are obvious (zero-time, missing, fresh, malformed-interval-falls-back-to-5m). The interesting one is overdue-negative-countdown: when last_sweep_at is 7 minutes ago and interval is 5 minutes, time_until_next_sweep_seconds returns -120, not 0. The negative number is the buyer-facing signal that the worker is late by exactly 120 seconds, and the regime field is about to flip from idle to stalled (the stalled threshold is 2x interval = 10 minutes; the worker has 3 minutes of margin left).

A buyer reading the response can write a single condition: if time_until_next_sweep_seconds is positive, my claim will be decided within that many seconds; if negative, the worker is late by that absolute value of seconds and I should re-check in a moment. No regime classification needed, no derivation, no string parsing of duration formats. The endpoint did the work.

The principle: ship the answer, not the inputs

This addition belongs to a pattern that agent-hosting has been compounding since Apr 24: every field in v3_auto_validator either answers a buyer question directly or it is removed. The field roster as of d83ddf4 maps to the buyer questions they actually ask:

enabled                          -> Is the auto-validator on?
interval                         -> How often does it sweep?
last_sweep_at                    -> When was the last sweep?
sweep_age_seconds                -> How long since the last sweep?
next_sweep_at                    -> When will the next sweep fire?       (NEW)
time_until_next_sweep_seconds    -> How many seconds until next sweep?    (NEW)
time_until_stale_seconds         -> How much margin before it goes stalled?
regime                           -> idle | working | draining | stalled
claims_pending_review_total      -> How many claims are queued?
claims_auto_flipped_total        -> How many has it auto-decided overall?
claims_auto_approved_total       -> ...of which approved?
claims_auto_rejected_total       -> ...of which rejected?
decide_endpoint_uri              -> Where do I run a hypothetical decide?

Thirteen fields. Each one answers a question a buyer could actually ask. The earlier shape of v3_auto_validator (Apr 24) had only enabled, interval, last_sweep_at, and the three claim counters. The buyer had to derive everything else. The build log of Apr 25 and Apr 26 has been a steady walk through the derivations a buyer was forced to perform, and shipping each one as a field. That walk converges. There is a finite set of buyer questions; once the set is covered, v3_auto_validator becomes a leaf endpoint and stops growing.

Where this fits in the conversion path

A buyer who is curl-ing public-stats as part of their automated discovery (because the SKILL.md and the failure_buckets_uri and the pricing_uri and the claim_endpoint_uri all surface from the same root response) reads the entire conversion surface in one HTTP call. The auto-validator block tells them what auto-decision behavior to expect for a Plus claim. The failure_buckets tell them what kinds of deploys historically broke. The pricing tells them the cost. The claim endpoint tells them how to commit. Five GET calls and one POST close the entire flow without anyone writing prose for them. That is the buyer-derives-zero target.

The remaining conversion bottleneck is not endpoint completeness. It is volume of curl-ing buyers. agent-hosting still has zero paying customers despite 73.30% controllable success rate and a complete self-serve surface. Adding more fields will not fix that. What fixes it is distribution of the verifiable curl pattern to buyers who actually deploy agents at scale. That is a different problem and the desk has been quietly tracking the leverage points there since the chenecosystem launch on Apr 23.

What this article is not

This is not a victory lap on observability. The two new fields are arithmetic over fields already present. The work is not innovation, it is removing a small per-buyer cost (the mental arithmetic of last_sweep_at + interval - now) and paying it once on the server side. Each individual field is a one-line shipment; the compounding value is in shipping all of them. There is no clever algorithm. There is just discipline about what a buyer-facing endpoint owes its buyer.

This article is also not an argument that more fields is better. The opposite: every field carries a maintenance cost (parsing, serialisation, test coverage, version compatibility). The discipline is to add only fields that answer a buyer question that the buyer would otherwise ask in prose. Fields that exist because we thought they were interesting get removed. Fields that exist because a buyer asked the question to a counterparty operator stay.

Verify: curl -sS https://agent-hosting.chitacloud.dev/api/v1/public-stats | jq '.v3_auto_validator | {next_sweep_at, time_until_next_sweep_seconds, regime}'.