Skip to content

Team cost controls: per-team activity budget (C) and quiet hours / mute (E) — A and D are shipped #645

Open

Description

@hsliuustc0106

What this is now

The original report — a team starting to work before the user asks — has been split up and partly shipped:

C. Per-team activity budget

A cap per team per day on turns and/or tokens, visible in the UI, with non-essential turns pausing when the budget is spent, and reporting back to on-demand only. The decisions this needs, none of which a Bot should make:

  • what the unit is (turns, tokens, or both — tokens cost money, turns measure noise);
  • what the default cap is for a fresh team, and whether 0 means "off" or "unlimited";
  • what counts as non-essential — scheduled reports, the daily tidy, proactive reminders — versus a direct message from the user, which must always go through;
  • where it is shown (inbox header, team overview, a settings row) and what it does at 100 %.

E. Quiet hours / mute

A team-level toggle that stops proactive turns (scheduled reports, tidy, reminders) while direct messages keep working. The decisions: whether it is a schedule (hours in the team's local time) or a plain toggle; whether a muted team still runs scheduled work with a zero-turn path; and whether a mute is visible to the Bots (so a coordinator does not think its child is broken).

What is already accepted (kept from the original report)

  • A user task costs a bounded number of turns that the budget exposes before it is spent.
  • A team can be muted so scheduled/proactive turns stop while direct messages still arrive.
  • No change to how a Bot answers once it is actually addressed.

Why this stays needs-human

Both halves change something the user sees and pays for: a cap that silently drops reporting, or a mute that makes a team look broken. The four decisions above are one sentence each from the user, and then each half becomes an agent-ready issue with a fixed shape.

Where the work lands when it is decided: settings/state for the budget and the toggle, core/src/host/schedules.js and the prompt layer for what counts as proactive, and the inbox/team view for the display.

Activity

  1. Birfy commented on Oct 22, 2026

    @Birfy
    Collaborator

    Triaged: four independent causes are described in one issue, which is why it cannot be picked up as is. Two answers turn it into a scoped PR.

    1. Scope now: which cause does this round cover — the creation kickoff, one-turn-per-message, proactive prompts, or the activity budget? One of them, or a specific pair.
    2. Product call: is "a newly created Bot does not greet until the user writes" acceptable behaviour? If yes, the kickoff half is a deletion and needs no budget; if no, the budget becomes the answer and this issue needs a number (turns per hour? per team?).

    Acceptance I would write once answered: for the kickoff half, creating a 3-Bot team and a group produces zero turns before the user writes, asserted on turn count in the bench; every existing test that pinned a kickoff greeting is updated with a note saying why.

    Written-by: Triage

  2. added
    needs-infoWaiting for the reporter or a maintainer decision
    on Oct 22, 2026
  3. Birfy commented on Oct 22, 2026

    @Birfy
    Collaborator

    Design decision (owner, 2026-10-22: decide the design in the issue instead of asking). The four causes are one PR's worth only if scoped to the first; this issue covers the kickoff, and the other three get their own issues when someone takes them.

    1. No turn before the user writes. A newly created Bot does not greet: remove the [Bot team setup] kickoff turn (core/src/host/delivery.js, role: 'kickoff'). A newly created group does not open a round either: remove roomKickoff and the opening speakers (core/src/host/groups.js). The user's first message is what starts work.
    2. Proactive prompts and the activity budget are out of scope here. They are separate behaviours (one-turn-per-message is A burst of messages opens one turn per message; there is no receive buffer #642); mixing them into this diff is how the "one issue, one PR" rule breaks.
    3. The Bot still exists and is usable immediately — this removes a greeting, not a capability; list_bots and the tree still see it.

    Acceptance (bench):

    • creating a 3-Bot team and one group produces zero turns until the first user message: assert on the turn count, not on text;
    • the first user message in a group produces exactly one turn from the admin (the existing opening-speaker behaviour applies from that message, not before it);
    • every test that pinned a kickoff greeting is updated, and the change note says why (the grep for kickoff must come back with no live call site).

    Red without the change: the first case shows 4+ turns (one per Bot plus the group round).

    Scope: core/src/host/delivery.js, core/src/host/groups.js, their tests, and the mirror under patches/ds-bot/ (generate then check). No setting, no UI change.

    Written-by: Triage

  4. added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    and removed
    needs-infoWaiting for the reporter or a maintainer decision
    questionFurther information is requested
    on Oct 22, 2026
  5. Birfy commented on Oct 22, 2026

    @Birfy
    Collaborator

    Claiming: branch feat/645-no-kickoff-turns, from main.

    Scope is the kickoff half only, as decided in the issue: remove the [Bot team setup] turn a new Bot gets (core/src/host/roster.js, role: 'kickoff') and the opening round a new group sends (core/src/host/groups.js, roomKickoff + its opening speakers). The user's first message starts the work; one-turn-per-message (#642), proactive prompts and the activity budget stay out of this diff.

    Acceptance I will pin in the bench: creating 3 Bots and one group leaves the turn count at zero until a user message; the first user message in that group produces exactly one admin turn; every test that pinned a greeting is updated with the reason, and no live kickoff call site remains in core/src/host.

    Touches core/, so ds-bot-patches.mjs generate and check are part of done.

  6. added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 22, 2026
  7. self-assigned this
    on Oct 22, 2026
  8. added
    agent-prPull request opened by an agent
    and removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 22, 2026
  9. changed the title [-]A new team starts working before the user asks: kickoffs, per-message turns, proactive defaults, no activity budget[/-] [+]Team cost controls: per-team activity budget (C) and quiet hours / mute (E) — A and D are shipped[/+] on Oct 22, 2026
  10. added
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    and removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    agent-prPull request opened by an agent
    on Oct 22, 2026
  11. Birfy commented on Oct 23, 2026

    @Birfy
    Collaborator

    Claim void: no branch or pull request exists, and the kickoff half already landed in #681.

  12. Birfy commented on Oct 25, 2026

    @Birfy
    Collaborator

    Written-by: Triage

    E (quiet hours) is now #1166 — the owner ruled the split on 2026-10-25 with defaults written in: off unless switched on, a window in the team's local time, and direct messages and approval requests never suppressed. Owner: Dev3, agent-ready.

    C (per-team budget) is what is left here, and it still needs the user's four numbers — unit (turns / tokens / both), the default cap for a fresh team, what 0 means, and what counts as non-essential. Until those exist, C is not triageable: any card I wrote would be inventing the cap.

    Nothing else in this issue is being closed; A and D shipped, B has its own ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:automationScheduled tasks and automationenhancementNew feature or requestneeds-humanThe agent loop stopped; a person must decide (reason in the last comment)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions