Anthropic afirma que su monorepositorio interno pasó de unos 2.500 cambios fusionados al día en mayo a más de 30.000 al día en septiembre de 2026. Su relato de ingeniería del 13 de octubre describe Scion, un sistema de control de versiones creado para los agentes y trabajos automatizados que impulsan buena parte de ese crecimiento. La pregunta de ingeniería relevante es qué trabajo sigue teniendo que hacer un cliente cuando puede confiar en un servicio central para el historial, los commits y las fusiones.
El gran cambio
- Qué cambió: Anthropic trasladó su monorepositorio de Git a Scion en cinco meses. Los clientes de Scion obtienen solo los objetos que necesitan y dejan los commits, las fusiones, los rebases y las consultas de historial en manos de un servidor. Anthropic lo creó para una carga de trabajo dominada por agentes y trabajos que ya están conectados.
- Por qué importa: Un trabajo de CI puede solicitar una diferencia o una base de fusión mediante una API sin mantener un repositorio local. Cuando necesita archivos, una copia dispersa o virtualizada limita lo que llega al disco. Eso traslada los costes y la responsabilidad operativa al servicio central.
- Qué conviene observar: Anthropic informa de copias más rápidas y menor uso de infraestructura en su propia flota, sin una validación independiente aquí. La empresa afirma que Scion es un sistema interno a medida y que la migración también exigió cambios en la revisión de código, la búsqueda y CI.
Por qué Git se volvió costoso en este monorepositorio
El diseño distribuido de Git hace que cada clon completo tenga el historial y los objetos necesarios para trabajar sin conexión. Anthropic afirma que el historial de la rama principal de su monorepositorio roza los 100 GB, mientras que una copia de trabajo comprimida supera los 25 GB. Su flota de CI realiza unos 25 millones de copias de código al día, antes de contar los entornos de desarrollo, los entornos aislados de agentes y los trabajos de investigación. Son cifras de la carga de trabajo de Anthropic, no un umbral general a partir del cual Git deje de funcionar.
La empresa ya había usado clones superficiales, copias dispersas, réplicas internas e instantáneas de repositorios. Afirma que varios cientos de réplicas acabaron siendo difíciles de operar a medida que crecían el repositorio y el ritmo de fusiones. El diagnóstico de Anthropic fue concreto: la mayoría de sus clientes ya eran agentes o trabajos conectados, pero las herramientas seguían pagando gran parte del coste de mantener un repositorio local.
Scion convierte esa conexión en línea en una premisa de diseño. El relato de ingeniería dice que el servidor responde a consultas de historial y blame, crea commits y realiza fusiones y rebases. El cliente conserva una caché acotada de objetos, coloca en el disco los archivos de trabajo solicitados y vigila los cambios locales. Renunciar a poder realizar esas operaciones de forma independiente es una decisión deliberada para enviar menos datos a cada cliente.
Una copia de trabajo puede ser más pequeña o innecesaria
Scion expone mediante API las consultas de control de versiones que usa su cliente. Anthropic afirma que un trabajo de CI que necesita una diferencia desde una base de fusión puede preguntar directamente al servidor. Sus procesos automatizados de búsqueda binaria y reversión usan la misma vía programática. Para esas tareas, puede que el trabajo nunca necesite materializar una copia de trabajo.
Cuando sí necesita archivos, Scion admite copias dispersas con los directorios solicitados y copias virtualizadas que materializan archivos al leerlos. El cliente pide de forma recursiva árboles y blobs concretos que faltan, en lugar de negociar un gran packfile. Cada objeto solicitado tiene una identidad inmutable direccionada por contenido, por lo que la caché puede devolverlo sin comprobar si su contenido cambió. Anthropic describe un demonio a nivel de nodo y cachés regionales entre los clientes y los servidores autoritativos; todos los niveles usan el mismo protocolo de solicitud de objetos.
Este diseño tiene límites de fallo y mantenimiento distintos de los de un clon local completo. El cliente depende del servicio para operaciones que Git puede realizar sin conexión, y el servicio debe suministrar consultas de objetos e historial al ritmo de toda la flota. Anthropic afirma que impone niveles de caché, en parte, para evitar que el fallo de una caché regional sobrecargue los servidores de origen. El artículo no aporta mediciones de disponibilidad de esa arquitectura.
Qué almacena y calcula el servidor
La unidad de trabajo de Scion es un changeset en un registro de escritura anticipada. Anthropic afirma que registra los archivos modificados respecto del primer padre, con punteros al contenido comprimido de los archivos en el almacenamiento de blobs. El servidor crea changesets sin mover un puntero de rama compartida con cada escritura. Estructuras derivadas separadas permiten consultas como blame de archivos, historial de rutas y ascendencia de commits; Anthropic calcula algunas de inmediato y aplaza otras.
Esa separación importa para el diseño de la API. Los trabajos pueden pedir una base de fusión o el historial de un archivo sin llevar todas las estructuras necesarias para calcular la respuesta localmente. También traslada al servicio de Anthropic el coste de mantener esas estructuras. La empresa afirma que distribuye los datos del repositorio y escala los componentes por separado, y que ni siquiera en el servidor existe una copia del repositorio materializada por completo.
Anthropic afirma que la infraestructura de Scion usa 200 veces menos CPU y memoria que su anterior sistema de réplica de Git, y que las copias de CI e investigación ahora tardan segundos en vez de minutos. Atribuye a este cambio un aumento del 25% en la capacidad de CPU de CI. Las comparaciones se hacen con el anterior sistema interno de Anthropic bajo su propia carga de trabajo; BIG CHANGE no ha reproducido las mediciones ni examinado la telemetría subyacente.
El coste de la migración también forma parte del resultado
Anthropic afirma que siete ingenieros construyeron Scion, la herramienta de revisión de código complementaria Antique y sistemas relacionados, y migraron el monorepositorio en cinco meses. Ese relato también describe nuevas búsquedas de código, controles de acceso y cambios en la forma de revisar e integrar el código. Una organización que evalúe el diseño debe tener en cuenta esos flujos de trabajo adyacentes, además del propio servicio de control de versiones.
Anthropic dice explícitamente que Scion no es adecuado como sustituto general de Git. Sus componentes internos de revisión, búsqueda y CI son específicos, y abandonar Git exigiría cambios en todo el ciclo de desarrollo. La lección más acotada de su relato es arquitectónica: un servicio en línea puede responder más preguntas de control de versiones para clientes automatizados, mientras estos conservan solo los archivos que usan. Anthropic sugiere que algunas ideas, como API de servidor más completas y una mejor combinación de las funciones dispersas y superficiales de Git, podrían aplicarse sin adoptar Scion.
Fuentes y lecturas adicionales
- Anthropic Engineering, Redesigning source control at Anthropic (13 de octubre de 2026). Relato de primera mano de Anthropic sobre la arquitectura de Scion, su migración y las cifras internas de carga de trabajo y rendimiento. BIG CHANGE no ha verificado de forma independiente las mediciones ni los resultados operativos comunicados; no se probó ningún sistema Scion para este artículo.



