我挂机一晚上回来token全没了。。。。查了下是个叫什么goal——round的玩意

[sensen02]

这个goalround的玩意每隔2-3轮就重新激发模型， 这一晚上烧了2亿token ，我实在想不出诗人能写出这么阴间的代码 这个很好定位就不上传日志了，建议改小128 到 4

[sensen02]

我那2亿token还他宝贝的是GPT6 astra

[argszero]

The mechanism: dsh-goal-round-driver queues one continuation prompt every time the session goes quiescent, as long as the goal is phase === 'active' and the live activation is armed (packages/goal/goal-round-driver/src/index.ts:160-186). That is what "re-triggers every 2-3 rounds" is — one new round per settled turn, with no idle-time or spend gate in between.

On the number. The shipped default cap is 256, not 128 (packages/goal/goal/src/index.ts:244 and :253), and there is no 128 anywhere in that package (git log -S "default(128)" -- packages/goal matches nothing). So the 128 you saw is most likely your deployment's defaultMaxGoalRounds in the goal plugin config. Worth checking first — it is the knob you actually want.

Your suggestion is executable today, and on an existing goal too. The type surface makes it look like the cap is fixed after creation (EditGoalRequest.maxGoalRounds exists, but so does a goal <op> cannot change objective or maxGoalRounds error), but edit is precisely the branch that error does not cover: fold.ts calls requireSameDefinition from the pause / resume / complete / block arms only (:222, :226, :238, :242), while the edit arm (:213-219) deliberately checks only that phase and blocked reason are unchanged. So:

• lower a live goal: update_goal(action: 'edit', max_goal_rounds: 4) — but edit requires a direct top-level human request (tool-goal/src/index.ts:266), so the model cannot lower its own cap from inside an automatic round. That is deliberate, and it is also why the overnight case has no protection at all: nothing can act while you are away.
• stop one that is already burning: pause (also human-only), or let the model self-report blocked during a round once dsh-tool-goal's blockedAfterConsecutiveRounds (default 3) has elapsed.
• for future goals, defaultMaxGoalRounds in the deployment config is the honest lever; changing the shipped 256 to 4 would break every long-running goal that is working as intended, which is why the deployment knob exists instead.

The real hole is that the cap counts rounds, not spend. One round is unbounded in tokens and wall-clock: there is no per-goal budget, no unattended-hours bound, and no automatic brake when a goal has clearly stopped making progress. Three different thresholds already exist (maxGoalRounds in the goal definition, blockedAfterConsecutiveRounds in the tool policy, and the driver's own round-limit block) and the driver README warns that duplicating any of them risks divergent policy — so the gap is not "one number is too big", it is that none of them is denominated in cost.

I am building a small plugin for that: ctx.goals is a public service, and GoalBlockReason.code is defined as "chosen by the blocking policy", so a plugin can stop a goal in its own state durably — visible in the session, no core change — and enforce a deployment-level policy over both rounds and tokens. I will link the package here once it is published.

[argszero]

Following up on my earlier note in this thread about the missing spend dimension: the plugin is published.

@argszero/cordis-plugin-goal-budget-guard — npm: https://www.npmjs.com/package/@argszero/cordis-plugin-goal-budget-guard · source: https://github.com/argszero/cordis-plugin-goal-budget-guard

- insert:
    - id: goal-budget-guard
      name: '@argszero/cordis-plugin-goal-budget-guard'
      config:
        maxUnattendedRounds: 3    # rounds since the last human message — the "overnight" dimension
        maxTokens: 2000000        # tokens spent since the guard began watching this goal
        maxGoalRounds: 20         # deployment cap, independent of the goal's own cap
        dryRun: false             # true logs the stop it would write instead of writing it

Recap of the gap it targets, in one line: maxGoalRounds is denominated in rounds, one round is unbounded in cost, and the cap is fixed when the goal is created — so the "I left it running overnight" case has no bound the operator who pays can actually set.

What it does. On every agent/status transition — i.e. exactly when a round has settled and the driver is about to decide the next one — it evaluates the configured dimensions and, when one is crossed, writes exactly one durable ctx.goals.block(agent, ref, { code, message }) under its own reason code (round-budget / unattended-budget / token-budget). The goal's phase becomes blocked, its activation is disarmed, and the driver's next quiescence check stops. No core change, and no pre-step hook: agent/status is emit-mode, so the plugin never sits in a waterfall it would have to forward.

Boundaries, stated up front (all of them are in the README too):

• It bounds the run, not the step in flight — a round already admitted finishes; at most one further round is admitted after a crossing.
• maxTokens counts from when the guard first saw the goal (mount, or the goal's creation). Mounting into a session whose goal has already spent a lot re-seeds the baseline there; it does not retroactively bill that session.
• maxUnattendedRounds arms only after the guard has observed a human message in the session. Goal-round messages (source.kind === 'goal') and plugin-injected ones are not human contact; a session where the guard never saw a human message is left alone rather than guessed at.
• If the tokenUsage projection is not mounted, the token dimension stays silent instead of reading as 0 — an abstention, logged, never a guess.
• A human can still resume a blocked goal. This is a deployment policy, not a lock.

Verification. 26 tests: the policy function exhaustively, plus the guard driven through a real cordis Context with stub goals / sessionProjections services and the real block-reason validator copied from goal/src/index.ts; the suite also carries a control arm showing an over-budget goal is not blocked when the plugin is absent. 7 mutation checks (boundary off-by-one on each of the three dimensions, an invalid reason code, absent-observation-read-as-zero, unreadable-usage-read-as-zero, dropped human-arming edge) are all caught.

One note for anyone intending to lower the cap on a live session instead: update_goal(action: 'edit', max_goal_rounds: N) does work today — the edit branch skips requireSameDefinition — but it is gated by requireDirectHuman, which is exactly what is not available during an unattended run. That is the case this plugin exists for.