Decoding Zalando's risk-based PR auto-approval and LiteLLM proxy setup

How Zalando auto-approves low-risk PRs using rules built from its incident history, and what a smaller team running coding agents can reuse.

Picture a six-person product team at a mid-size online retailer. Since everyone started using coding agents, PR volume has gone up and so has PR size. Every change still needs a second approval, so a README fix, a config tweak and a schema migration all wait in the same queue. Someone working on an internal tool has to interrupt a colleague to rubber-stamp a docs change. Meanwhile the change that actually caused last quarter's outage, a typo in a deployment config, got the same thirty-second glance as everything else.

Zalando's engineering team described how it handles this in an August 14, 2026 post on agentic engineering, which @bibryam highlighted on X on October 29. A bot scores every new PR as low, medium or high rollout risk using rules drawn from Zalando's own production incidents, and auto-approves the low-risk ones. The same post covers a LiteLLM proxy with cost and version hooks.

What it is

This is not a product you can install. It is a write-up of internal practice. Two parts matter most for builders.

Risk-based PR approval. According to Zalando's post, the tool runs when a PR is created and rates its rollout risk as low, medium or high. Zalando says 33% of its PRs are low risk and get auto-approved, after which the author can choose to merge. Zalando reports this cut PR lead time by 20–40% "when compared with all PRs." The rules come from analysis of Zalando's production incidents and the usual causes of outages, and Zalando says they are "highly specific" to its tech stack, deployment manifests and configuration files. The post gives three examples:

This maps directly to the lede's pain. The docs fix merges without interrupting anyone, and the config change gets the scrutiny. Zalando also reports, as anecdotal evidence, a side effect: engineers began splitting work into a quick low-risk PR with backwards-compatible changes and a separate medium-risk PR, for example one that drops unused fields. Before, those changes were mixed together.

An LLM proxy with hooks. Since January 2024, Zalando's ML platform team has run a LiteLLM-based proxy in front of OpenAI, AWS Bedrock and Google Vertex. The post says it uses post-call hooks for anonymized cost tracking, pre-call hooks that block outdated clients based on the User-Agent header, and auto-injected prompt caching checkpoints. Zalando's own LLM tools, such as custom code review agents, include a name, originating repository and version in the User-Agent. To deal with LiteLLM stability and memory-leak issues, Zalando forces restarts after 20k requests using --max_requests_before_restart. With that setting, it runs the proxy for 2k monthly active users on six small pods with 2 CPU cores and 4 GB of memory each.

Alternatives for the gateway layer, from the comparison sources:

For the approval bot itself, our sources name no off-the-shelf equivalent. The nearest pattern is the Claude Code team's process at Anthropic, which, as summarized by Flavio Copes, combines agent review, tests and human approvals based on risk tiers and protected paths.

Who it's for

Pick this up if you have a track record of incidents you can actually categorize, a stack where risk shows up in file types (manifests, config, schemas, docs), and review latency you can measure.

Skip it if you have no incident history to learn from, since without it you are guessing at rules. Skip it too if you are a solo maintainer hoping a bot will be your second key. As Stéphane Robert's CODEOWNERS guide notes, on GitHub you cannot approve your own PR, and requiring code owner review on a single-maintainer repo makes merging impossible unless you add a second reviewer, a bypass list or path-limited rules. Skip the proxy half if you use one provider and one tool. Zalando's case for it rests on vendor independence and on measuring many tools across 2k users.

Before and after

Before:

  1. An agent opens a PR, often a large one. Zalando reports growth in its 500–1k and 1k–2k line PR buckets since Sonnet 4's release in Q2 2025.
  2. Every PR waits for a human approver, whatever its content.
  3. Low-stakes changes interrupt colleagues, and high-stakes changes get the same attention as everything else.
  4. LLM spend and client versions are invisible, or tracked per tool.

After, based on Zalando's description:

  1. When a PR is created, the bot scores it against rules derived from past incidents.
  2. Low-risk PRs, such as docs-only changes, are auto-approved, and the author decides whether to merge.
  3. Medium-risk PRs, such as backwards-compatibility breaks, go to a human to check the business reason. The post doesn't say what happens to high-risk PRs.
  4. Authors split mixed changes so the safe part ships first.
  5. All model traffic goes through one proxy. That proxy logs anonymized cost, rejects outdated clients by User-Agent and injects caching checkpoints.

Try it

Zalando has not published the bot, its rules or its hook code, so there is nothing to clone. The smallest real steps use tools the sources do document.

1. Write your risk rules on paper first. List your last several incidents and the files each one touched. That list is your rule set, and it is exactly what Zalando says its rules are built from.

2. Enforce the high-risk paths with GitHub settings you already have. Per Robert's guide, a CODEOWNERS file only notifies reviewers. It blocks nothing until require_code_owner_review is on in the ruleset or branch protection. You can limit it to sensitive paths such as .github/workflows/, the Dockerfile and dependency files, so other code follows the normal route. This is not auto-approval. It is the inverse: the strictest review is kept for high-risk paths only.

3. Keep agent work flowing through PRs. The DEV Community post on Copilot approvals suggests pushing local agent branches instead of merging them locally:

git push -u origin agent/fix-login
# --fill uses the commit messages as the PR title and body
gh pr create --base main --fill

4. Stand up a proxy if you need cost and version visibility. The LiteLLM docs offer a quickstart script for the gateway:

curl -fsSL https://raw.githubusercontent.com/BerriAI/litellm/main/scripts/quickstart.sh | sh

or the SDK via uv add litellm. The docs list virtual keys, cost tracking and an admin UI. Pin a version. The v1.107.0rc1 release notes (October 18, 2026) list behavior changes from v1.106.0. For example, token-count routes now return an error instead of a local estimate when the provider can't count, and the notes warn that Claude Code uses /v1/messages/count_tokens through the proxy, so test that route before upgrading.

Where it breaks

Sources