Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés

Uso de memoria

Estado: Actual

Alcance: estado actual

Última revisión: 2026-09-13

Responsable: entorno de ejecución de ax-code

AX Code comparte la máquina con servidores de lenguaje, compilaciones del repositorio, navegadores y cualquier entorno de ejecución de modelo local. Un servidor de TypeScript o un analizador de Rust puede usar más memoria que el propio backend de AX Code. Esos procesos aportan análisis de código; no son servicios de voz. Sumar el RSS de los procesos puede contar páginas compartidas más de una vez.

Perfiles

AX_CODE_MEMORY_PROFILE acepta auto (predeterminado), low o normal. En auto, un host que informa como máximo 8 GiB de RAM física selecciona low; los demás hosts seleccionan normal. Los valores no válidos usan la detección automática. La detección usa la RAM física del host, no la RAM libre ni un límite de memoria de contenedor; selecciona low de forma explícita en una máquina virtual o un contenedor restringido cuando haga falta. Establece la variable antes de iniciar AX Code; no reconfigura un backend que ya está en marcha.

AX_CODE_MEMORY_PROFILE=low ax-code

PowerShell:

$env:AX_CODE_MEMORY_PROFILE = "low"
ax-code

Los servidores de lenguaje arrancan bajo demanda de forma predeterminada en ambos perfiles. El arranque y las lecturas ordinarias de archivos no disparan el precalentamiento semántico especulativo. La navegación semántica explícita, los diagnósticos y la indexación siguen iniciando el análisis necesario, así que la primera solicitud semántica puede tardar más. Para restaurar el arranque especulativo y el precalentamiento de lectura en un host con margen suficiente, establece ambas variables antes de iniciar:

AX_CODE_MEMORY_PROFILE=normal AX_CODE_LSP_PREWARM=1 ax-code

Solo el valor exacto 1 activa el precalentamiento especulativo; low lo suprime siempre. Este ajuste no termina los servidores existentes, y no es una prohibición global del arranque LSP: las ediciones que exigen diagnósticos y las operaciones semánticas o de indexación explícitas siguen usando servidores de lenguaje. La recuperación por inactividad del modo bajo permanece aparte.

La caché de código fuente también tiene un límite de 1.000 entradas. Su contabilidad incluye un margen conservador de cadena y clave; no es un límite del montón de V8 ni de RSS. Un archivo que no cabe igual sincroniza su contenido actual completo con el servidor de lenguaje. El desalojo de la caché no cierra un documento mientras una solicitud pueda necesitarlo.

El modo bajo encola el trabajo en lugar de omitir el análisis. El primer uso, o el uso después de un apagado por inactividad, puede tardar más. Los clientes seleccionados o en cola, las RPC subyacentes pendientes y las esperas de diagnóstico están protegidos del apagado por inactividad. Una solicitud que agota el tiempo puede dejar trabajo en ejecución en el servidor: dos operaciones en espera no garantizan solo dos cálculos dentro de los servidores de lenguaje. El inventario de diagnósticos se marca degradado después de la recuperación por inactividad porque reiniciar un archivo no puede probar la cobertura completa del espacio de trabajo anterior.

Estos límites se aplican dentro de cada proceso de AX Code. No limitan la RAM total, no coordinan instancias separadas de AX Code, no topean los montones de los servidores de lenguaje ni controlan un compilador, un navegador o un modelo local. La selección de modelo, el contexto de prompt exigido y los comandos de verificación permanecen sin cambios.

Retención de sesión y de evidencia

La TUI conserva los eventos pesados de la transcripción de la sesión que se está viendo. Las sesiones inactivas retienen resúmenes, estado y aprobaciones o preguntas pendientes; abrirlas recarga el historial guardado desde SQLite. La ventana de visualización normal es de 100 mensajes con un presupuesto de carga serializada de 16 MiB. Los mensajes completos antiguos se liberan primero. El mensaje indivisible más reciente y el historial recuperado de Deshacer y Restaurar pueden superar el presupuesto blando; la TUI muestra un indicador. Son límites de proyección, no límites del historial durable de la sesión ni del contexto del modelo.

Cuando el montón de V8 se acerca a su límite duro, el presupuesto de la transcripción se estrecha de forma automática (hasta un suelo de 2 MiB al 90 % de uso del montón) para que el conjunto retenido se desprenda antes de que el proceso alcance FatalProcessOutOfMemory; por encima del 80 % la TUI también muestra un aviso que sugiere /compact o un reinicio. La presión se recupera después de una recolección de basura completa, pero el historial ya desalojado sigue ausente hasta que se recarga.

Las partes que llegan antes que su mensaje padre usan un área pendiente acotada (128 ID de mensaje / 1 MiB). Si hay que liberar contenido pendiente, la TUI ofrece una recarga desde el historial guardado. Los eventos tardíos de mensajes desalojados no pueden recrear de forma permanente partes huérfanas.

La caché de evidencia usa de forma predeterminada memoria acotada (128 entradas / 4 MiB de valores serializados por instancia). RocksDB sigue siendo optativo; cambiar solo el backend de la caché no reduce las llamadas a herramientas del modelo. Consulta Caché de evidencia.

Salida de comandos en segundo plano

La salida de segundo plano no leída usa archivos transitorios privados en lugar de retener cadenas de JavaScript de varios megabytes para cada shell terminado. Cada archivo es un anillo UTF-8 de 2 MiB; la salida no leída más antigua que supera ese límite se descarta y se etiqueta. Hasta 32 archivos de anillo reservan como máximo 64 MiB por proceso. Cuando los huecos de disco están llenos, el spool terminado más antiguo puede caducar; la propiedad de un shell activo no se desaloja. Las lecturas devuelven de forma incremental la salida no leída retenida y liberan su hueco de disco.

El registro permite 16 shells activos por sesión y 32 por proceso, y retiene como máximo 16 registros terminados por sesión y 64 por proceso. La salida terminada caduca a los 30 minutos (se comprueba al acceder y aproximadamente una vez por minuto). Los listados de comando y descripción son vistas previas limitadas a 8 KiB / 1 KiB; el comando ejecutado no cambia. La reproducción del observador tiene límites aparte de 64 KiB y 128 registros por shell, con un presupuesto de bytes de 2 MiB para todo el proceso; la reproducción incompleta se etiqueta.

bash_output informa la integridad de la salida aparte del estado real de salida del proceso. La salida descartada, caducada o ilegible es evidencia de verificación incompleta incluso cuando el comando salió con código cero. Estos avisos siguen visibles cuando se usa un filtro de salida. Un registro ausente puede significar que ya se consumió o se desalojó; una salida no disponible no prueba que una comprobación haya aprobado.

Los archivos usan un directorio temporal privado propiedad del proceso (0700) y archivos 0600 en POSIX. Las lecturas, la eliminación de sesión, la limpieza de retención y la salida normal del proceso liberan los archivos propios. El spool no es almacenamiento de sesión durable ante caídas. Una terminación forzada o una caída puede dejar atrás un directorio temporal privado; no hay barrido automático entre procesos, así que el límite de 64 MiB describe el proceso actual, no restos acumulados de caídas. Los errores de limpieza del sistema de archivos se informan y no liberan la reserva de cuota del archivo fallido. La E/S de archivos síncrona y acotada evita colas de escritura sin límite, pero puede añadir latencia en un sistema de archivos temporal lento.

Elegir una carga de trabajo

En hosts restringidos, usa primero un proveedor en la nube, una sesión de programación activa y un repositorio pequeño. Ejecuta compilaciones grandes y sesiones de agente adicionales solo cuando la máquina tenga margen. La inferencia local necesita un presupuesto aparte para pesos, caché KV y contexto, y sobrecarga del entorno de ejecución; la orientación de hardware de un proveedor en la nube no se le aplica.

Usa la CLI empaquetada para el uso ordinario; pnpm run dev es un flujo de código fuente para colaboradores, con un coste distinto de arranque y de carga de módulos. Inspecciona AX Code junto con sus hijos de servidor de lenguaje y de compilación en Activity Monitor o en el monitor de procesos de la plataforma. Un límite de caché reducido no establece una reducción fija de la memoria física.

Los cambios de memoria tienen pruebas deterministas de retención y de equivalencia semántica. No se han cualificado con una prueba de carga en un Mac físico de 8 GB. El modo bajo no garantiza que un proyecto arbitrario quepa en una máquina de 8 GB.