AI-Git-Bot — News

One key, many models: OpenRouter in AI-Git-Bot

2026-11-11T00:00:00.000Z

AI-Git-Bot supports several AI providers, and OpenRouter is the one that is a router rather than a model vendor. A single inference key opens a catalog of model families, and the request carries policy with it: which region may process it, whether the endpoint is allowed to retain it, and which parameters the endpoint has to support.

The dedicated OpenRouter provider type is not the same thing as pointing the generic OpenAI integration at openrouter.ai. The generic path speaks plain OpenAI and hopes the gateway behaves; the dedicated one speaks OpenRouter’s own dialect, sends a routing policy on every call, and validates the key before it saves anything. This article covers that integration: the setup, the routing and privacy section, what automatic model routing can and cannot do inside the bot, and where to watch the spend. The reference documentation: USER_GUIDE.

Why put a router in front of a review bot

The reason is not “more models”. It is that the same account serves every bot:

One key, several families. A review bot on a frontier model, a triage bot on a cheap one and a coding agent on whatever is strongest for tool calls can all point at one integration — or at several integrations with the same key and different model IDs.
Model choice is a text field. Switching the model of a bot is an edit to the integration, not a new vendor contract, and the suggested IDs in the dropdown are examples rather than a catalog. Type any author/model ID.
Spend in one place. OpenRouter credits pay for everything, and the per-integration token log in AI-Git-Bot lines up with the activity view on the OpenRouter side.
Data policy as configuration. Region and retention are properties of the request, so a bot reviewing a customer repository can be stricter than the bot reviewing your own.

That last point is the part that matters in regulated repositories, and it is the part the bot actually enforces instead of passing along.

Setting up the integration

AI Integrations → New. Set Provider Type to OpenRouter.
API Key — an inference key. On save the server calls /v1/key on the selected official host, rejects management and provisioning keys, and checks that the key is allowed in the selected region. A key that fails the check is not stored.
Routing and privacy — region, data collection and ZDR, described below.
Model — a concrete ID such as deepseek/deepseek-v4.1-flash, or one of the routers.
Max Tokens and Context Window — the response limit and the model’s real window. OpenRouter passes both through to whichever endpoint serves the request, so a wrong context window is compounded by a router you did not pick.
Enable native tool calling — on for models that call tools reliably. With it off, the bot describes the tools in the prompt and parses a JSON answer.

The OpenRouter provider type with the Routing and privacy section: region, provider data collection and the ZDR checkbox.

The API URL field is not editable for this provider — it is derived from the region and shown as plain text, so the host and the policy cannot drift apart. A gateway of your own in front of OpenRouter is a different situation: use the generic OpenAI provider for that, because a custom root would break the region check.

Automatic model routing

OpenRouter’s routers are model IDs. openrouter/auto rates each request and picks both a model and a reasoning effort for it; openrouter/auto-code runs on the same engine with a policy tuned for coding agents and harnesses. Enter either in the Model field like any other ID and the bot sends it unchanged.

flowchart LR A[Request] --> B[Rate task] B --> C[Narrow pool] C --> D[Pick model] D --> E[Endpoint]

The pool in step two is where the bot’s settings become visible. The router only considers models that the account’s guardrails, the ZDR requirement, provider restrictions and your BYOK keys allow — so turning ZDR on narrows the router as much as it narrows a pinned model. What the router cannot read is per-request router settings: allowed_models, excluded_models and cost_tier travel in a plugin block, and the bot disables plugin overrides on every request. Sets that have to be request-specific belong on the account or in a guardrail.

There is a trade-off worth naming. Routing makes the model a variable in a pipeline whose output you review as if it were deterministic: two rounds of the same agent run can be served by different models, and a review that looked thorough yesterday looks hurried today because the router picked cheaper. For production reviews, pin a concrete ID and use a router for experiments, for triage, or where the traffic mix is genuinely unknown. OpenRouter’s response tells you which model actually served the call, and the bot records the integration and the token counts, so a surprising diff is traceable rather than mysterious.

The model field of an OpenRouter integration with the automatic router entered as the model ID.

Region choice

Three options, each with a fixed API root:

Region	API root	What it means
Global (default)	`https://openrouter.ai/api`	No regional restriction; any eligible endpoint may serve the request.
EU	`https://eu.openrouter.ai/api`	Prompt and completion are processed in the EU/EEA, the UK or Switzerland.
US	`https://us.openrouter.ai/api`	Prompt and completion are processed in the US.

In-region routing is a paid OpenRouter account tier, not a free toggle, and it fails closed: if no endpoint in that region can serve the model, the request errors instead of quietly leaving the region. That is the behaviour you want in a review pipeline, and it is also the reason a model that works on Global can be unavailable under EU — the endpoint has to be onboarded for the region.

The bot does not take your word for the entitlement. On save it reads the key’s allowed_data_regions and rejects a region the key does not list; an omitted list is accepted only for Global. Changing the region later re-checks the retained key, so a plan downgrade surfaces on the next edit rather than on the next review.

flowchart LR A[Request] --> B[Region host] B --> C[Key check] C --> D[Data policy] D --> E[Parameters] E --> F[Endpoint]

ZDR and data collection

Two settings, two independent filters, both on the integration:

Provider data collection — Deny (default) or Allow. Sent as data_collection in the routing policy.
Require zero data retention (ZDR) — off by default. When on, only endpoints with a zero-retention policy are eligible.

The ordering matters and the bot does not soften it: ZDR wins over Allow. With ZDR enabled and data collection set to Allow, retention-free endpoints are still the only ones considered — Allow does not override ZDR, it only stops being the constraint that binds. Both values are stored as selected rather than normalised into something contradictory, and if no endpoint satisfies the combination the request fails explicitly instead of falling back to a weaker policy.

Two details that make this hold up rather than just look good:

No plugins. The bot disables OpenRouter’s plugins on every request — web, file parser, response healing, context compression and the Pareto router. Those run outside the inference path and carry their own retention, and context compression in particular rewrites the prompt in ways a tool-calling agent did not plan for. Account-level Prevent overrides settings can force plugins back on; keep the OpenRouter account free of forced plugins if the policy is the point.
No retained payloads by default. The optional raw-payload audit (AI_USAGE_RAW_PAYLOADS_ENABLED) is off, so enabling ZDR does not leave a copy of the prompt in your own database.

One honest limitation belongs here: OpenRouter’s own retention documentation describes a content-screening exception that applies to ZDR traffic as well. If your requirement is a signed data-processing agreement rather than a routing flag, read their ZDR page and their terms before you treat the checkbox as the whole answer.

What the bot pins on every request

The routing policy is not the only thing that is fixed. Each OpenRouter call from AI-Git-Bot sends:

require_parameters: true — the endpoint must support the parameters the bot sends, which for an agent run means tool calling and the token limits. An endpoint that would silently ignore tools is not eligible.
allow_fallbacks: false — no provider fallback. A request that no eligible endpoint can serve fails. For a review this is the right trade: a fallback to a provider with a different retention policy or a weaker parameter set is worse than a red build.
max_tokens, not max_completion_tokens — OpenRouter’s token-cap dialect. The generic OpenAI integration keeps using the OpenAI field name.
The plugin opt-outs above.
App attribution headers, so the traffic shows up under the AI Git Bot entry in OpenRouter’s app directory and rankings.

Reasoning details from models that emit them are preserved across tool continuations in memory, separately from the visible answer and the session history — the same mechanism that keeps a native tool-calling loop consistent on the other providers.

Watching the spend

The AI usage page logs every interaction with input, output, cache-write and cache-read tokens per integration. The cache columns are the ones to look at first with OpenRouter: an agentic review re-sends the same prefix every round, provider prompt caching passes through, and a run whose cache-read count stays at zero is paying full input price on every round. That is usually a model without caching on the serving endpoint, not a bot misconfiguration.

The AI usage page filtered to an OpenRouter integration, with input, output and cache-read token counts.

Reconcile against OpenRouter’s activity view when the numbers look off: the bot counts what the provider reported, and OpenRouter is the side that knows the price of the model that actually served the call.

Errors and what they mean

HTTP 401 on save — the key was rejected. The response body is not surfaced or logged; provider error bodies can contain account details.
HTTP 402 / 429 during inference — credits exhausted or rate limited. Check the OpenRouter account, not the bot.
HTTP 404 during inference — the model is unavailable, or no route satisfies the region and ZDR policy. With EU selected this is the common shape of “works on Global”.
“Provider overloaded” — 503/529 from the upstream endpoint. The retry decorator backs off and retries, and posts a comment on the pull request or issue saying when the next attempt happens. Authentication, prompt-too-long and malformed responses are not retried; they are handled or reported.

When not to use it

If the requirement is a provider contract with the model vendor directly — a specific data-processing agreement, a dedicated deployment, a fixed price — the router sits in the way, and the bot’s Anthropic or OpenAI integration is the shorter path. OpenRouter earns its place where you want several model families, one bill, and a policy you can set per request. Within the bot, that is the difference between “this integration reviews with this model” and “this integration reviews with this model, in this region, without retention”.

Feedback is welcome — use the contact form, send an email, or open an issue on GitHub.

From issue to pull request: running the coding agent

2026-11-06T00:00:00.000Z

The coding agent — the implementation agent in the workflow list — is the part of AI-Git-Bot that ends with a pull request instead of a comment. Assign a bot to an issue and it clones the repository, works out which files are involved, edits them, runs your build, and opens the PR for review. It never merges — the last step stays human.

What follows is the practical side of that workflow: the four objects that have to exist before the first run, the settings that decide whether a small model produces something usable, how to plug in your own validation command, and what to do when the repository or the issue is bigger than one run. The reference documentation lives in the repository: Coding Agent, Issue Agents, Tool Calling.

Two kinds of rounds

flowchart LR A[Issue assigned] --> B[Clone] B --> C[Explore] C --> D[Edit] D --> E[Validate] E -->|fails| D E -->|passes| F[Pull request]

A run is a loop, and the loop has two flavours of round. Read-only rounds (rg, tree, ctags-signatures, cat) fetch context without spending an edit attempt. Rounds that write or validate do spend one. The two budgets are separate, and reads stop being free once the read budget is used up: further reads are charged to the write budget instead. That is why a run can stop for lack of rounds having never reached the change — it read too much.

Setting it up

Four objects in the admin UI, in this order:

AI Integration — provider, model, key, and Enable native tool calling (on for frontier models). For Anthropic, leave prompt caching on; an agentic loop re-sends the whole prefix every round and cache reads are roughly a tenth of the input price.
Git Integration — a token with repository write access (branches, pushes, pull requests) and issue write access (progress comments).
System prompts (under System settings) — the prompt sets a bot can use. Clone the default set for your bot instead of editing the default, and edit its Issue-Agent System-Prompt; that is what the coding agent runs with.
Bot — bot type Coding bot, Issue-Assigned Workflow Configuration: Issue: Coding Agent, plus the prompt set and a Tool Configuration.

The bot form: coding bot type, issue-assigned workflow, prompt set and tool configuration.

Then point the repository webhook at the URL shown on the bot page and enable the Issues event, and make sure whoever triggers the bot can be trusted with your AI budget — the bot form’s user whitelist is the cheapest guard there is.

The one setting people get wrong is the Tool Configuration. It is not a permission list in the narrow sense: it is the entire tool surface the model sees, and it is re-sent on every round. Leave out dotnet or mvn and the agent is told in its own prompt that validation is mandatory, cannot comply, and loops until the retry budget is gone. Tick the toolchains the image actually contains, and nothing else.

A tool configuration with the file tools, the read-only context tools and one validator selected.

Branches follow {prefix}issue-{number} — ai-agent/issue-42 with the default prefix. AGENT_ALLOWED_REPOS limits the whole feature to a list of repositories, which is worth setting before you let anyone assign the bot.

What a run looks like on the issue

The bot confirms that it picked the issue up, then posts a short plan for each round, the validation output when something fails, and finally the pull request. For a run on a repository you have not tried yet, watch the timeline rather than the result: the rounds tell you whether the model understood the codebase or is guessing at paths.

One reading tip: the plan comment is posted before the tool call runs. It says what the model is about to do, not what happened next. The evidence is the comment that follows — or the diff.

If a session gets stuck, comment try again, please retry or redo on the issue. The agent sees the previous conversation and usually corrects itself.

When the model is small

Frontier models call tools reliably; small and local ones often do not. The first lever is the transport, not the prompt: turn Enable native tool calling off for that integration. The bot then describes the tools in the prompt and parses a JSON answer instead of using the provider’s tool API. It costs more tokens, and it is the path that has seen the most model/provider combinations.

The tool-calling section of an AI integration, with native tool calling switched off for a local model.

What does not help is tightening the budgets. The coding agent is not told how many rounds it has left, so it cannot plan around a cap — lowering AGENT_BUDGET_MAX_ROUNDS or AGENT_BUDGET_MAX_CONTENT_ROUNDS does not make a small model work more efficiently, it only stops the run sooner, and the issue ends up with a failure comment instead of a branch. AGENT_BUDGET_MAX_TOKENS_PER_CALL is the output budget of a single call: halve it and a long patch plan is cut in half, which is a failed run, not a cheaper one. Leave all three at their defaults; if runs keep ending for lack of rounds, raise them.

What helps is giving the model less to hold at once:

Fewer tools. Every tool descriptor is re-sent on every round, and every one of them is a choice the model can get wrong. The tool configuration from the setup is the cheapest lever there is.
A smaller tree on the first run. AGENT_CONTEXT_MAX_TREE_FILES puts up to 500 paths into the opening prompt; 120 is plenty and leaves less to sift.
A starting point. One or two file paths in the issue body are worth several exploration rounds, and they cost a sentence.
A smaller change. One issue, one change, a handful of files. A small model asked for a refactor will produce something plausible and wrong, and the review will cost more than writing it yourself.

Two settings belong to this list as well. Set the integration’s context window to the model’s real window; it is what decides when the runtime starts dropping history mid-run, and a wrong value either fires too late or too early.

For thinking-style local models served through an OpenAI-compatible API, OPENAI_CHAT_TEMPLATE_KWARGS (for example {"enable_thinking": false}) is often the difference between a tool call and a paragraph of reasoning about one.

Finally, the prompt. The coding agent runs on the Issue-Agent System-Prompt of the prompt set selected in the bot form (System settings → System prompts). A small model follows the rule it read last far better than the tenth one, so shorten it there: name the validator it should run, say that a change is not done until it has been verified, and drop the rest.

Custom validation with `execute`

Validation is what turns “the agent says it changed something” into “the change compiles”, and it needs a command. Repositories with a conventional build have one. Documentation sites, infrastructure repositories and anything driven by a script do not — for those there is the execute tool.

Enable it in the bot’s tool configuration like any other validator, commit the script with its executable bit, and the agent calls it by repository-relative path:

execute scripts/validate.sh

#!/usr/bin/env bash
set -euo pipefail

dotnet build projects/hub/Hub.sln -c Release --nologo
dotnet test projects/hub/tests/web-ui/Hub.WebUi.Tests.csproj \
  --no-build --nologo

git update-index --chmod=+x scripts/validate.sh

The contract is deliberately narrow:

Exit code 0 means validation passed. Anything else fails the round, and the captured stdout/stderr goes back to the model and onto the issue — exactly like a failing mvn test.
The script runs directly, never through a shell, with the workspace as its working directory. Arguments after the path are passed through verbatim.
It must match the committed version. execute refuses a script the run has modified, staged or added, so the agent cannot make validation pass by editing the validator.
It is bounded by AGENT_VALIDATION_TOOL_TIMEOUT_SECONDS (300 by default).

That last point shapes the script: keep it under the timeout, make it print the failing command’s output rather than a summary, and avoid network calls. A validator that takes four minutes on a good day will time out on a bad one, and a timeout looks to the model like a broken change.

The execute validator enabled in a tool configuration, next to the language toolchains.

execute is additive — it never replaces mvn or npm. Repositories with a real build command should keep using it, and use execute only for the extra checks the build does not cover.

Pitfalls worth knowing

Validation off means a green comment and no build. With AGENT_VALIDATION_ENABLED=false the run finishes as soon as the workspace has a diff, and the success comment says nothing about whether the code compiles.
Tool output is capped. A single tool result is truncated at 10,000 characters. cat with line ranges is how the agent reads a large file, which also means it can patch a line range it has only partly seen.
A search that finds nothing is a failed tool. rg exits non-zero when there is no match, and in a round that also writes, that counts against the attempt budget. It is not a bug you can configure away; expect the occasional “asking the model to correct” after a legitimate empty search.
Follow-ups remember the conversation, not the issue. A follow-up prompt carries the new comment and the discussion, not the issue description, and the session history is bounded. After a long thread the agent may genuinely no longer know what the original issue asked for. Start a new issue for a new topic instead of reusing the PR.
The comment thread is filled oldest-first. The per-comment and total budgets stop at the character limit, and the oldest comments get there first. Put the specification in the issue body; the last comment is the worst place for it.
Hitting a budget looks like a failed implementation. A run that runs out of rounds reports “I was unable to produce a valid implementation” on the first run, or “validation failed and I couldn’t fix the issues” on a follow-up — neither is necessarily true; it may simply have stopped. Read the last rounds of the timeline before you go looking at the build.
One branch per issue. Follow-ups push to the same branch as the PR. Two features in one issue means two features in one diff.
Polyglot repositories need the validator named. The model picks the build command; in a repository with a JVM service and an npm frontend it will sometimes pick the wrong one. Say which one counts in the prompt.
The agent can edit dependency files but cannot install from a registry you have not made reachable. A change that needs a new package is a change your image has to support.

Big repository, big issue

A repository is large when the clone is slow and the tree is unhelpful; an issue is large when it describes more than one change. Both are manageable, but not with the same knobs.

For the repository:

Raise GITEABOT_WORKSPACES_CLONE_TIMEOUT_SECONDS (300 by default) — the clone is shallow, but a monorepo tip still takes time — and put GITEABOT_WORKSPACES_DIR on fast local disk rather than on a network mount.
Keep the exploration tools that do not read whole files: rg, tree, ctags-signatures, ctags-deps, git-log, git-blame. They are what makes a large tree navigable in ten rounds.
Let execute-code do the filtering. A small Python program can call the same tools and print only the matches that matter, so a fifty-file sweep costs one tool result instead of fifty.
AGENT_MAX_FILES (20 by default) is a blast-radius limit, not a target. On a monorepo, name the package in the issue so the agent does not have to discover the boundary.
Keep the tool configuration minimal. Every tool descriptor is paid for on every round of every run.

For the issue: split it. A run that has to hold three acceptance criteria and two subsystems will satisfy one of them and claim all three. If the issue is vague, let the writer agent turn it into a specification first; if it is simply large, cut it into issues that can each be reviewed in one sitting. And give the agent a starting point — one or two file paths in the issue body are worth several exploration rounds.

Start small

The honest summary: the coding agent is reliable on focused issues in repositories with a working build command and a validator in the tool configuration, and it is a coin flip anywhere else. Set it up on one repository, assign it a small issue, and read the timeline before you trust the result. The settings above are the ones that decide whether the second run is better than the first.

Feedback is welcome — use the contact form, send an email, or open an issue on GitHub.

AI-Git-Bot 1.30.0 released

2026-11-05T00:00:00.000Z

We released AI-Git-Bot 1.30.0 today. The complete list of changes is in the release notes on GitHub. Here are the ones worth a closer look.

Progress comments on Azure

When the progress comment is enabled for agentic reviews, it now also appears in Azure repositories.

The setting that enables the review progress comment.

That matters most for reviews you expect to run long: it tells the user that a review is still running instead of leaving them guessing, and afterwards it makes it easy to see how long reviews actually take — which is the starting point for tuning them, for example by keeping a changeset small.

The progress comment in a Gitea pull request.

Initializing all data from a file-based configuration

If your job is to provision AI-Git-Bot automatically in its final configuration, the Docker start routine now accepts a configuration document with the required settings. Every value that can be set in the admin UI can also be supplied through that file. Details, a generator and an example docker-compose are linked in DEPLOYMENT.md.

An example docker-compose that ships a configuration document.

The reverse direction works as well: the complete configuration of a running instance can be exported, to back it up or to use it as the base for further automated installations.

Downloading the running configuration from the system settings.

Throw-away instance for testing

gitbot.eu/trial now generates a disposable instance, so you can try AI-Git-Bot in your own environment without risk. The instance is reset to its original settings on every restart — anything you configured in the UI is gone afterwards, which is exactly the point.

Many small improvements

Beyond the three features above, this release includes small refactorings, performance optimisations and a number of bug fixes.

Feedback welcome

We would like to hear from you: use the contact form, send an email, or open an issue on GitHub.

AI-Git-Bot — News

One key, many models: OpenRouter in AI-Git-Bot

Why put a router in front of a review bot #

Setting up the integration #

Automatic model routing #

Region choice #

ZDR and data collection #

What the bot pins on every request #

Watching the spend #

Errors and what they mean #

When not to use it #

From issue to pull request: running the coding agent

Two kinds of rounds #

Setting it up #

What a run looks like on the issue #

When the model is small #

Custom validation with execute #

Pitfalls worth knowing #

Big repository, big issue #

Start small #