Know what a run costs before you approve it

Bumping a dependency and refactoring across three repositories are not the same job, and paying the same rate for both is waste. CodeLynq can pick the model per task, starting from what it knows before the run: task type, effort estimate, how many repositories are involved, whether a bug arrived with a stack trace.

Then it learns. Per project, it records how often each model got each kind of work right first time. A model that keeps failing on refactors in your codebase stops being sent them. One that handles your chores cleanly gets more of them. Below ten runs in a category nothing changes, because two unlucky runs should not rewrite your routing.

Every choice carries a reason you can read on the run, such as “feature, medium, three repositories”. A router that cannot explain a bill is one nobody trusts with the budget.

Approving work without knowing whether it costs fifty cents or twelve euros is uncomfortable. Next to the run button you see what runs of this kind have actually cost in this project. Where there is no history it says so rather than inventing a number.

A delivered-work view lists what shipped, by name, with the pull request and what each task cost. Alongside it: success rate, how often work landed without needing a second pass, median run time, and the spend per shipped task.

Every figure is a count of something that happened. Where there is no basis for a ratio yet, it shows nothing instead of a flattering zero.

Plans carry a monthly run allowance and a concurrency cap, and nothing is charged beyond them automatically. Runs stop until the next cycle or until you upgrade, so there is no surprise invoice.