Build1 distinct publisher3 min readUpdated
A 2.5-year retrospective spanning more than 250 engineering teams credits a LiteLLM-based API proxy, stood up in January 2024, for metering adoption and forcing client upgrades.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Zalando's engineering blog has published a look back at 2.5 years of LLM work across more than 250 engineering teams, and the thing it credits first is not a model or a coding agent [1][2]. It is a LiteLLM-based API proxy that the company's ML platform team deployed in January 2024 to give engineers API access to models from multiple providers, now OpenAI, AWS Bedrock and Google Vertex [3].
The stated payoff is unglamorous and compounding: one team got a single point at which to measure adoption by monthly and weekly active users, by model, and by User-Agent [4]. Everything else in the post hangs off that. Post-call hooks do anonymized cost tracking [5]. Pre-call hooks enforce client version upgrades by restricting proxy access based on the User-Agent header [5]. The post is blunt about why that mechanism exists: for self-managed client installations, blocking access is the only effective measure, and the same applies to retiring models, because there is always a long-tail group of users who do not adjust local configurations or follow new model releases [6]. A proxy is not just a router. It is the only place where refusal is possible.
The same chokepoint absorbs mistakes made by users. Zalando enabled auto-injection of prompt caching checkpoints, which the team says reduced costs for custom agents while their authors were still learning about prompt caching [7]. The operational numbers are modest. To work around LiteLLM stability and memory leak issues, the team forces restarts after 20,000 requests via `--max_requests_before_restart`, and says this lets it serve 2,000 monthly active users on six small pods specced at 2k CPU and 4 GB [8][9]. That is roughly 333 monthly active users per pod [10]. The team says it is looking forward to LiteLLM's expected Rust rewrite for performance and stability [11].
Zalando has been a GitHub Copilot user since the days when it offered IDE autocomplete, and describes the proxy as complementary to that [12]. The in-house surface area on top is deliberately cheap: a chat UI forked from a now-unmaintained open source codebase, and a CLI built with pydantic-ai [13]. The chat UI still sees high adoption, which the authors call a surprise given how many more capable IDE plugins and CLIs now exist [14]. The CLI began at an August 2024 hackathon, before coding agents existed, which puts it about seven months after the proxy went live [15][16]. It has since accumulated agent mode with MCP support and automatic Bearer token injection for internally hosted MCP servers, an HTTP-to-stdio MCP proxy, and a command that installs safe configurations for Claude Code, opencode and pi [17]. The point of the token injection and MCP proxy, per the post, is that no secrets need to be hardcoded in configuration files, which matters as the user base spreads beyond engineering to people with varying intuition for security [18].
Two frictions are worth tracking, because they are industry-wide rather than local. Tools too often send a generic User-Agent, which defeats client identification at the proxy; Zalando's own agents carry a name, repository and version, and for third-party tools the team requests or contributes upstream changes [19]. And tools lack support for custom auth commands for token generation, supporting only static credentials [20]. Until vendors fix both, the metering and enforcement story above stays partly blind.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Zalando's engineering blog published a retrospective looking back at the company's progress over the past 2.5 years and sharing approaches that worked well.
Zalando has more than 250 engineering teams innovating across its business lines, and observes value and impact of LLMs in different forms and at different paces.
Zalando's ML platform team deployed in January 2024 a LiteLLM-based API proxy with access to models from different providers (now OpenAI, AWS Bedrock and Google Vertex), making it easy for engineers to experiment with different tools and models.
The platform team got a single point to measure adoption via MAU, WAU, model and User-Agent.
Zalando uses LiteLLM post-call hooks for anonymized cost tracking and pre-call hooks for enforcing client version upgrades by restricting access to the proxy based on the User-Agent header.
For self-managed client installations, blocking access is the only effective measure, and the same goes for retiring models, because there is always a long-tail group of users who do not adjust their local configurations and do not follow new model releases.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-source and unverified
The account is unusually specific for a company blog -- named flag and threshold, pod count and shape, MAU, deployment months, named tools -- which raises evidentiary quality above a typical vendor narrative. But every figure comes from one first-party retrospective with no logs, benchmarks, dashboards or third-party corroboration, and the qualitative claims (cost reduction from prompt caching, high chat UI adoption) carry no numbers at all.
Real internal production use at mid-thousands scale
This is not a pilot: the proxy has run since January 2024, meters 2k MAU across an organization of 250+ engineering teams, has grown three surfaces (API, chat UI, CLI) plus MCP tooling, and the user base is spreading beyond engineering. Adoption is nonetheless confined to one enterprise's internal platform, self-reported, with no external users, revenue or third-party deployments, so it is real but bounded.
Source is more restrained than the framing
The underlying post understates rather than oversells: it volunteers LiteLLM memory leaks patched by forced restarts, admits blocking is the only lever against stale self-managed clients, and names two unresolved tooling gaps (generic User-Agent headers, static-credential-only auth). The only forward-leaning element is the unverified expectation that a Rust rewrite will improve performance and stability, and the unquantified chat UI and prompt-caching cost claims. Net slightly negative: the concrete operating evidence is stronger than the modest language around it.
First-party employer-brand publication, no product to sell
The sole source is the subject's own engineering blog, so selection of what worked is inherently self-favorable and serves recruiting and reputational goals. Offsetting this, Zalando sells no LLM gateway product, credits third-party open source (LiteLLM, pydantic-ai) rather than its own, states it never centrally mandated a tool, and discloses failures -- which limits, though does not remove, the incentive to shade the account.
Coherent and internally consistent, but wholly unverified
Confidence is moderate: the technical narrative is internally consistent, dated, specific enough to be checked by anyone running LiteLLM, and includes self-critical detail that a purely promotional account would omit. It is capped by having exactly one publisher, no independent measurement, and several load-bearing statements (cost savings, chat UI adoption) left qualitative.
build
Claude Code now outruns Copilot roughly two to one in JetBrains' survey of 15,000 developers1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
build
Waku 0.1.0 bets the product is the control plane, not another coding agent1 distinct publisher
science
OX Security says MCP command execution is a design choice, so server owners own the risk1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 17, 2026