IAVENGERS
en / fr
Join the beta
Private beta — by La Petite Agora

A teammate who scopes before he codes.

IAvengers lives in your GitHub issues. It talks the problem through, writes the spec, implements in TDD, opens the Pull Request — then works through your review. You merge. Always.

Install the app · mention @iavengers · no per-repo config

  1. paul opened the issue

    @iavengers we need a rate limit per API key, 100 req/min. How would you go about it?

  2. IAvengers

    Proposal: a Redis token-bucket middleware, keyed on the API key, 60 s sliding window. Returns 429 with a Retry-After header. Two open questions: what happens to keys with no quota set, and do we count rejected calls? Want me to write the spec?

  3. paul

    @iavengers go-spec

  4. IAvengers

    Spec and plan pushed to feat/issue-142-rate-limit. Label spec-ready.

  5. paul

    added the label iavengers:go

  6. IAvengers

    Implemented in TDD — 14 tests, suite green. Pull Request #143 is open, ready for your review.

the flow

From issue to Pull Request, in the conversation

Four steps. All of it happens in GitHub comments — there is no second tool to learn, and no context to re-explain.

01

Scope

You mention IAvengers on an issue. It asks the questions a senior dev would ask, proposes an approach, and settles the need with you before a single line is written.

@iavengers <message>
02

Spec & plan

It writes a spec and an implementation plan, commits them to a dedicated branch, and labels the issue spec-ready. You read them before anything is built.

@iavengers go-spec
03

Implement

It works the plan in TDD — failing test, minimal code, green, commit — pushes the branch and opens the Pull Request. If it gets stuck, it says so and labels the issue blocked.

label iavengers:go
04

Iterate

You review as you would review anyone. It answers each point on the PR branch — inline comments included. Then you merge.

@iavengers <feedback>

why iavengers

A careful teammate, not a code vending machine

It scopes first

Brainstorm, then spec, then plan, then code. Most of what goes wrong with generated code goes wrong before the first line — in what was understood. IAvengers spends its time there.

Your code stays yours

Self-host the daemon, bring your own Claude key. Every outgoing comment is scanned for secrets before it leaves. Nothing is committed that shouldn't be.

You stay in control

IAvengers cannot merge. Not by policy — by permission. Who may trigger it follows your GitHub roles, and one job runs at a time on a repo, so two agents never fight over the same branch.

vs copilot coding agent

Copilot codes a ticket. IAvengers behaves like a teammate.

Copilot's coding agent is good, bundled and backed by GitHub. We are not trying to beat it at turning an issue into a diff. Here is where the two actually differ.

What differs Copilot coding agent IAvengers
Before writing codeGoes from the issue to a diffAsks, proposes, commits a spec and a plan you read first
Where it runsGitHub's infrastructureYours, if you want it there
Whose model, whose billGitHub's, in the bundleYour own Claude account, if you prefer
What it leaves behindA Pull RequestA Pull Request, plus the spec and plan that justify it

for teams careful about ip

Your code never has to leave your infrastructure

Self-hosted

One daemon on your own machine serves every repo you install it on. Your code is cloned there, and nowhere else.

Bring your own Claude

Your account, your key, your usage policy. We are not in the middle of that conversation.

Secrets never travel

Every comment, PR title and PR body is scanned and redacted before it leaves the daemon. The git token is never written to disk.

Human merge, by construction

IAvengers opens Pull Requests. It has no merge permission at all — so there is no configuration to get wrong, and no green CI that could ever be mistaken for approval.

pricing

Priced on real compute, not on promises

Final numbers land with the public launch — we would rather set them on what the beta actually measures than guess now. The model itself is already settled:

Free to start

Enough to take one real issue all the way to a merged Pull Request, on a repo of your choosing. No card.

Then, on usage

Billed on compute consumed, not on a made-up count of "tasks" — a big implementation and a one-line fix are not the same work. Hard cap per job and per month, visible in the thread.

Or self-hosted

Run it yourself with your own Claude account: unlimited work, and we only ever bill the platform. This is the tier for teams who cannot send their code anywhere.

questions

The things people actually ask

Will it merge something on its own?

No — and not because we told it not to. The app holds no merge permission. A green CI, a clean review, a last PR in a series: none of it changes anything. Merging stays a decision, and it stays yours.

What if it gets it wrong?

Then you get a Pull Request you close, which costs you a read. IAvengers retries a failed implementation a bounded number of times, then labels the issue blocked and says what stopped it — rather than pushing something that compiles and calling it done.

Which languages and stacks?

Whatever your repo already uses. IAvengers reads your conventions file and your test command, and works through your own suite — it does not bring a stack of its own.

Who on my team can trigger it?

Whoever your GitHub roles already trust. IAvengers reads the repository permission of the person commenting — a drive-by comment from outside the team triggers nothing.

Is it open source?

The core is headed that way — it is what makes self-hosting a real promise rather than a slogan. The beta is where we settle what belongs in the open and what belongs in the hosted service.

Give it an issue. Get back a Pull Request.

The private beta opens to a small number of teams at a time, so that each one gets a first Pull Request that actually lands. Leave your email and we will come to you.

One email address, kept on our own server. No tracking, no list resale, one message when your slot opens.