kinderp / kinderp/durex

Enforce resource, concurrency, and provider budgets

Open
#48 0 comments 0 reactions 0 assignees View on GitHub
area:security kind:design
Dominant language
Python
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

## Parent and milestone

- Parent issue: #43
- Milestone: not scheduled; implementation remains gated by #15.

## Problem

Provider quotas, token observations, wall time, compute, and concurrency differ
across runtimes. Without explicit budgets, failed loops can consume excessive
resources or switch providers in ways that violate operator expectations.

## Outcome

Define enforceable task, project, runtime, plugin, and node budgets with
measured-versus-estimated provenance and conservative stop behavior.

## Scope

- Define wall-time, attempt, concurrency, CPU, memory, disk, network, token,
request, and monetary budget dimensions.
- Distinguish provider-measured, runtime-reported, host-measured, and estimated
usage.
- Define warning, suspend, stop, and explicit fallback behavior.
- Require privacy, capability, and authorization compatibility before runtime
fallback.
- Expose budgets and consumption through audit and client view models.

## Non-goals

- Pretending provider subscription limits or token counters are equivalent.
- Automatically routing around provider restrictions or terms.
- Guaranteeing monetary cost when the provider exposes no reliable metric.

## Acceptance criteria

- [ ] Every enforced value records source, unit, confidence, and scope.
- [ ] Hard limits stop or suspend owner-scoped work conservatively.
- [ ] Fallback cannot weaken capability, privacy, or approval requirements.
- [ ] Restart and multi-host behavior preserve budget accounting idempotently.
- [ ] Limit races, missing metrics, retries, and stale reports are tested.

## Validation

- Deterministic fixtures for exact, delayed, estimated, missing, duplicated,
and conflicting usage observations.

## Dependencies

- #26 usage contract, #31 routing, #41 control API, and #44 resource isolation.

Contributor guide

No contributing guide indexed for this repository

Research direction

No implementation files or entry points are named. Start by reading dependencies #26, #31, #41, and #44, then use the acceptance criteria and validation requirements to define the budget model, fallback rules, accounting behavior, and deterministic fixtures that would constitute completion.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.