Paperclip proposes UTC-day budgets, but daily setup still lacks a UI path

Paperclip's September 24 daily-budget proposal would add a native UTC-day window alongside monthly and lifetime policies. It also revisits a recurring-budget problem: a scope paused for yesterday's spending should not necessarily stay paused after the relevant window resets. The inspected implementation evaluates active company and agent hard-stop policies when checking whether work may start. The product gap is equally important: displaying a daily label is not the same as offering a complete interface for creating that daily policy.

The facts

- PR #13950 adds calendar_day_utc while leaving calendar_month_utc as the default policy window. - Its day calculation runs from midnight UTC to the following midnight, not a rolling 24-hour interval. - Observed spend for calendar policies is filtered to timestamps at or after the start and before the end. - The company and agent invocation checks inspect all active billed-cents policies with applicable hard stops, not only one daily policy. - A budget-owned pause can clear when no applicable hard-stop policy is exceeded; a manual company pause remains a separate block. - A review comment identifies missing daily-window selection in creation forms; the API and display labels alone do not complete setup.

Why it matters

A monthly allowance and a daily ceiling answer different operational questions. One limits a longer accounting period; the other can constrain how much observed work accumulates in a particular day. The proposal also shows why reset behavior needs explicit ownership. Releasing a pause because yesterday ended must not override a still-exceeded monthly policy or an operator's intentional stop. The inspected code checks the reason for the pause and reevaluates relevant policies, which is more precise than a timer that blindly resumes everything at midnight.

Current

The request is open, based on the inspected 5a356054fc revision, with v2026.916.1 remaining the stable release baseline. Resume logic is in the invocation-block check; this does not establish an independent midnight scheduler that restarts canceled work. The condition is also broader than time rollover: clearing a policy can make the budget-owned pause eligible to clear. The reviewed UI gap remains part of the feature's availability boundary.

Evidence

Primary: paperclipai/paperclip PR #13950 (https://github.com/paperclipai/paperclip/pull/13950). Supporting context: paperclipai/paperclip PR #13950 — implementation diff (https://github.com/paperclipai/paperclip/pull/13950/files); paperclipai — budgets.ts (https://raw.githubusercontent.com/paperclipai/paperclip/5a356054fc306455adc9eaa47984901eac727c33/server/src/services/budgets.ts). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.

Operator take

Before relying on a future daily policy, verify creation, enforcement and recovery as three separate journeys. Test a UTC boundary, simultaneous daily and monthly ceilings, a deliberately manual pause and a budget pause whose policy was removed. Use recorded cost events to check the actual accounting window rather than inferring enforcement from a rolling-spend chart. Finally, confirm the interaction between a resumed scope and work canceled by the earlier hard stop; permission to start new work is not proof that an interrupted task has been reconstructed or safely replayed.

Caveat

This is a proposed software control, not a recommendation about a spending amount or a guarantee against billing overshoot. Daily UI selection is not complete in the inspected change. Source and test inspection do not establish live provider-billing enforcement, and project-scope policy handling should not be generalized from the company/agent loops.