Skip to content

Add reset evidence states for quota windows and meters #9

Description

@TheKrush

Summary

Replace ambiguous reset countdown states with explicit reset evidence states for quota windows and provider meters.

This will make PromptFuel clearer when a provider reports usage without reset timing, when an expected reset has passed but the source has not refreshed, or when reset timing is inferred rather than measured.

Current behavior

Missing or passed reset times can appear as a bare ?, which makes several different cases look the same:

  • provider did not return reset timing
  • expected reset has passed but fresh source data has not arrived
  • reset timing is unknown
  • usage percent is measured but reset timing is not

Desired behavior

PromptFuel should represent reset timing with explicit evidence states and user-facing wording that distinguishes measured usage from unknown reset timing.

Suggested reset evidence states:

  • measured
  • provider-implied
  • schedule-inferred
  • reset-due-unconfirmed
  • unknown

Requirements

  • Add reset evidence state fields for quota windows and provider meters where applicable.
  • Replace bare ambiguous ? reset output with clearer wording.
  • Treat expected reset passed but not yet confirmed by fresh provider data as reset-due-unconfirmed.
  • Treat measured usage without provider reset timing as measured usage with reset evidence unknown.
  • Allow schedule-inferred reset timing only when explicitly configured or clearly marked as inferred.
  • Update UI formatting for reset evidence states.
  • Add tests for reset formatting and evidence-state behavior.
  • Document the reset evidence states.

Non-goals / constraints

  • Do not claim reset timing is measured unless the provider returns it.
  • Do not hardcode provider-specific reset schedules without provider evidence or explicit configuration.
  • Do not change provider credential/auth handling.
  • Do not introduce a background service solely for reset confirmation.
  • Do not present inferred reset timing as provider-confirmed.

Suggested implementation

Extend reset metadata and formatting so the UI can render clear phrases such as:

  • resets in 2h 14m
  • reset due — awaiting provider confirmation
  • no reset time from provider
  • reset schedule inferred

Acceptance criteria

  • Missing reset timing no longer renders only as a bare ambiguous ?.
  • Passed expected resets render with an unconfirmed/reset-due state.
  • Measured usage can be displayed independently from reset timing certainty.
  • Schedule-inferred reset timing is clearly labeled as inferred.
  • Reset evidence state tests pass.
  • Documentation explains each reset evidence state.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions