Bound the work. Keep the evidence.
Captor grew from AI budget controls into execution contracts for production jobs. The same question applies to a model call or a data repair: how far may this run go, and how will we know it worked?
The idea
Define the boundary before work starts. Verify the outcome when it finishes.
Production jobs already have runners. Captor adds limits, checkpoints, and outcome checks inside those jobs, where the application can reserve capacity before a side effect.
Local receipts preserve the accounted usage and completed progress. A resumed backfill starts from a durable checkpoint, with the application responsible for source ordering and idempotent writes.
The optional platform inspects manually imported receipts. Existing AI integrations remain available as a compatibility path.
Built by
Captor
Captor is developed in public. Follow the repository for implementation details, release notes, and opportunities to test it with real production jobs.
The road so far
AI runtime budgets
The project began with in-process budgets, provider wrapping, and trace inspection for AI applications.
A boundary for arbitrary resources
The runtime now supports named resource limits, reservations, checkpoints, and outcome metrics for jobs such as backfills and reconciliation.
Recovery that can be demonstrated
Local stores, CLI inspection, and a fresh-process demo make the recovery path testable. The next step is validating these boundaries on real workloads.
Production work should have explicit limits, recoverable progress, and outcomes you can verify.