Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[DEL-B3] Adaptive deliberation budgets, selective activation and provider usage accounting

Open
  • Is something wrong?
#321 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
ai, backend

Research direction

Start from EPIC #315 and hard dependencies #316, #318, #319 to ground the baseline. Locate the controller and LLM Manager modules owning done acceptance and provider routing, and review ADR 0004 for effect ownership. Use deterministic fake provider with existing CLI integration tests to validate per-round and per-run bounds, keeping opt-in config backward compatible.

Written by the indexing model from the issue text.

Description

enhancement

Parent: EPIC #315 · Wave B · Size M · Planning baseline f4fd5ef (2026-10-25 UTC). Research: GVS5H, not an implementation dependency.

Objective / deliverable

Implement feature-off-by-default admission for low/medium/high complexity or explicit operator opt-in. Cap manager/worker/verification rounds, total cost/token/time, request count and storage; derive trusted usage from normalized summaries where available (#154), distinguish cumulative vs delta, unknown cost and subscription plans. No unsupported assumptions about dollar cost or unlimited subscriptions; no silent API/provider fallback. Kill or pause with preserved state/candidate on exhaustion. Route optional roles only among configured Claude/OpenCode/Pi adapters after capability probe; heterogeneous model routing remains experiment not default.

Dependencies

  • Hard: #316 (DEL-A1)
  • Hard: #318 (DEL-A3)
  • Hard: #319 (DEL-B1)
  • Coordination only: #147 SDK providers / #126 interactions, #154 usage, #176 scheduler and #266 sandbox. Do not add blanket cross-EPIC hard blockers without evidence.

Acceptance criteria

  • Default one-agent behavior and existing config remain unchanged, strict config validation for opt-in options
  • Deterministic stop on per-round and per-run bounds, including crash resume and unknown usage
  • No unapproved provider change, no rate-card hallucination, no bypass of step/review budgets
  • Metrics include overhead and cost-per-validated-success with explicit unknown/estimated provenance
  • Token-cost/success tradeoff thresholds and activation policy tied to baseline evidence from #318 (DEL-A3)
  • Regression tests preserve original single-agent path, ADR 0004 controller-owned effects, exact candidate validation, ReviewCertificate and merge safety; provider credentials remain isolated.
  • Docs/doctor/config compatibility updated where behavior changes; skipped real-runtime evidence never reported as pass.

Invariants / exclusions

The LLM Manager is advisory. Controller exclusively owns done acceptance, typed GitHub effects, state transitions, candidate identities and merge. Inner tasks are not GitHub native sub-issues and do not modify EPIC graph. Neither Agent nor verifier may execute repository-controlled commands outside the existing sandbox. No unbounded raw transcript/reasoning recording or ambient credentials. Feature remains opt-in; no Public Alpha #255 gate. Coordinate persisted schema on #23 before migration. Do not copy GVS5H's arbitrary subprocess verifier or its text-hash scratchpad and call it production recovery.

Verification hints

Use deterministic fake provider plus real existing CLI integration where available; include redacted bounded evidence, attack cases, failure/cancel/resume, explicit run/issue/candidate SHA. No new orchestration daemon or scheduler.

Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 51m
Merged PRs (30d)
66

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from iceboundrock/AutoForge

All issues in iceboundrock/AutoForge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.