Por qué existe el límite y por qué tener más entradas no es el objetivo
El límite es de entradas, no de bytes
Manus cuenta las entradas. Cien entradas largas y cien entradas de una sola línea chocan contra la misma pared, lo que lo convierte en un límite de curación en lugar de un límite de capacidad. También significa que la solución más sencilla suele ser fusionar: tres entradas que describen la misma convención deberían ser una sola.
El motivo indicado es la calidad de las respuestas
Esto es lo que lo diferencia de la mayoría de los límites con los que te has topado. La propia explicación de Manus es que "tener demasiadas entradas puede afectar la calidad de respuesta del sistema". Nada sobre costes de almacenamiento, nada sobre niveles más allá de la división Pro/Free.
Esta es una afirmación plausible en sus propios términos: cualquier cosa cargada como contexto siempre activo compite por la atención con todo lo demás cargado como contexto siempre activo, y un almacén de cien datos variados es un peor objetivo de recuperación que un almacén de treinta datos relevantes. También es el patrón en todos los demás lugares. Claude Code carga solo "las primeras 200 líneas de MEMORY.md, o los primeros 25 KB, lo que ocurra primero", y aconseja apuntar a "menos de 200 líneas" por archivo de instrucciones porque "los archivos más largos consumen más contexto y reducen la adherencia". La memoria de Kiro's Crew limita cada capa por separado en caracteres (las preferencias a 4.250, los proyectos a 6.400) en lugar de dejar que cualquiera de ellas crezca. Perplexity limita las instrucciones del proyecto a 8.000 caracteres.
Manus es inusual solo al expresar su límite en entradas, lo que lo hace visible. El comportamiento es el mismo en todas partes.
El almacén global está haciendo un trabajo para el que no fue diseñado
La base de conocimientos del usuario es un único almacén que se aplica de forma generalizada. Si usas Manus para cuatro tipos de trabajo no relacionados, todo lo que le enseñes sobre uno de ellos estará en el contexto de los otros tres.
Esa es la verdadera razón por la que la gente alcanza el límite. No porque tengan cien datos genuinamente globales, sino porque tienen veintidós datos globales y ochenta específicos del proyecto en un almacén que no tiene el concepto de proyecto.
Lo cual es curioso, porque Manus sí tiene ese concepto
Los Manus Projects se describen como "espacios de trabajo persistentes con instrucciones y archivos compartidos, de modo que cada nueva tarea comienza con el contexto adecuado". Un proyecto tiene dos cosas: una instrucción maestra y su propia base de conocimientos de archivos y documentos, y ambas "se aplican automáticamente a cada nueva tarea creada dentro de ese proyecto".
Dos propiedades hacen de esta la respuesta real. Los proyectos están "disponibles para todos los usuarios en todos los niveles de suscripción", por lo que esta no es una vía de actualización de pago. Y Manus no documenta ningún límite de entradas en la base de conocimientos de un proyecto: contiene archivos y documentos en lugar de entradas contadas.
Vale la pena tener en cuenta el enfoque de la propia documentación de Manus: "el trabajo en sí puede ser repetible, pero la configuración a menudo no lo es". Eso es precisamente en lo que una base de conocimientos global es mala y un proyecto es bueno.
Lo que la gente intenta
Eliminar las entradas más antiguas. El consejo documentado es "filtrar las entradas de su base de conocimientos en función de sus necesidades más importantes y recientes, y eliminar algunas entradas innecesarias", y funciona. Pero la antigüedad es un mal indicador del valor. La convención que configuraste hace dieciocho meses y que nunca volviste a revisar suele ser la que menos quieres perder.
Meter varios datos en una sola entrada. Esto te mantiene por debajo del límite, pero va en contra de la razón por la que existe el límite. Una sola entrada que contiene nueve reglas no relacionadas es más difícil de aplicar que nueve entradas, y ahora es imposible eliminar solo una de las nueve.
Actualizar a Pro para tener más margen. Duplica el límite de 50 a 100 y es algo razonable por otras razones. No cambia la dinámica de calidad, y el consejo de Manus de optimizar también se aplica a los usuarios Pro.
Mantener un documento maestro y pegarlo en las tareas. Una solución común, y realmente pone el contenido frente a Manus. El coste es que es un trabajo manual por tarea, y es exactamente la carga de configuración que los Projects existen para eliminar.
Esperar a que se aumente el límite. Manus dice: "En el futuro, continuaremos optimizando la funcionalidad de la base de conocimientos en función de las necesidades y los comentarios de los usuarios", por lo que esto bien podría cambiar. No es un plan para esta semana, y el argumento de la calidad sobreviviría a un número mayor de todos modos.
Tratarlo como un problema de búsqueda. Añadir más documentos para que se encuentre el correcto es el instinto que la recuperación de documentos entrena en las personas, y no se transfiere a un almacén pequeño que siempre se aplica; la distinción que se explica en por qué RAG no es memoria.
La solución: dar a cada tipo de trabajo su propio contexto y mantener una capa duradera debajo
El proceso es un triaje, y lleva unos veinte minutos.
Clasifica cada entrada en uno de tres grupos. Genuinamente global: aplicable a ti y a todo tu trabajo, como tus convenciones de escritura o tu rol. Específico del proyecto: aplicable a un flujo de trabajo recurrente. Obsoleto: fue cierto una vez, pero ya no.
Elimina el tercer grupo. Mueve el segundo a las bases de conocimientos de los proyectos. Lo que quede en el almacén global debería ser pequeño, y ser pequeño es precisamente el objetivo.
Luego, configura los proyectos correctamente. La guía de Manus sobre la instrucción maestra es la parte más influyente: "Escribe instrucciones maestras detalladas. Cuanto más específicas sean tus instrucciones, menos contexto necesitarás proporcionar en cada nueva tarea". También puedes mover tareas existentes a un proyecto a posteriori; la documentación describe que los proyectos funcionan como carpetas.
Dos reglas de propagación que debes conocer antes de confiar en ellas, porque no son intuitivas. "Actualizaciones de instrucciones: se aplican la próxima vez que envíes un mensaje en tu tarea actual". Pero "Actualizaciones de archivos: solo surten efecto en las nuevas tareas creadas después de la actualización". Y de manera más general: "Todas las tareas creadas anteriormente no se verán afectadas y continuarán utilizando la configuración que existía cuando se crearon". Una tarea está vinculada a la configuración con la que nació, por lo que corregir un archivo no soluciona una tarea en ejecución: inicia una nueva.
Una nota de colaboración si compartes proyectos: "Cuando invitas a un colega a un proyecto, obtiene acceso a la instrucción maestra y a la base de conocimientos compartidas. Sin embargo, solo puede ver las tareas que ha creado él mismo dentro de ese proyecto". El conocimiento se comparte; el trabajo no.
Eso soluciona la división. Lo que no soluciona es que ambos almacenes son de Manus, están limitados por las reglas de Manus y solo se pueden leer dentro de Manus. Ahí es donde ayuda una capa duradera debajo, y eso es lo que contiene MemoryLake: el conocimiento de tu proyecto en una capa que tus herramientas consultan, de modo que el límite de entradas rige lo que Manus mantiene cargado en lugar de lo que se te permite saber. La configuración consta de tres pasos.
Paso 1: Crea una clave API
Inicia sesión y crea una clave API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias
Entradas cortas, una afirmación cada una. El triaje anterior acaba de producir la lista de entrada ideal, así que trabaja a partir de ella:

Todo lo que esté en tu pila de "obsoletos" sobre lo que hayas dudado. Las entradas de las que no estabas seguro son las que vale la pena conservar en algún lugar que no tenga límite. Elimínalas de Manus, consérvalas aquí.
Decisiones con el motivo adjunto. "Informamos en un ciclo de 4 semanas, no mensual, porque el cierre financiero se mueve". Una entrada establece la regla; solo el motivo evita que se vuelva a cuestionar.
El detalle específico del proyecto que no encajaba en la instrucción maestra. Una instrucción maestra debe ser corta y directiva. El contexto detrás de ella no pertenece allí y no es necesario desecharlo.
Datos que abarcan varios proyectos. Cualquier cosa que sea cierta para dos flujos de trabajo pero no para todos ellos no tiene un buen lugar en ninguno de los dos almacenes.
Paso 3: Conecta tu IA y agentes
MemoryLake es accesible a través de MCP y de una API, y Manus admite conectores MCP y servidores MCP personalizados, por lo que Manus puede consultar la misma memoria que leen tus otros asistentes, y los agentes nativos de MCP como Claude, Codex y OpenClaw se conectan apuntando al servidor MCP. Lo que significa que la respuesta a "¿qué decidimos sobre esto?" deja de depender de cuál de tus cien entradas sobrevivió a la última limpieza.

Tres límites honestos. MemoryLake no puede leer, escribir ni contar tu base de conocimientos de Manus: el límite se aplica dentro de Manus y las únicas herramientas para esas entradas son las de Manus. Solo contiene lo que tú o tus agentes introducen en él, por lo que el Paso 2 es manual. Y no aumenta ningún límite: Manus sigue cargando lo que carga Manus, y una base de conocimientos más pequeña y mejor curada sigue siendo el objetivo.
Qué cambia esto en la práctica
Eliminar una entrada deja de parecer arriesgado. La estás moviendo, no perdiendo.
El almacén global se vuelve pequeño y sigue siendo útil. Veinte datos relevantes superan a cien variados, que es el propio argumento del proveedor.
La configuración del proyecto deja de repetirse. Una instrucción maestra más una base de conocimientos del proyecto se aplican a cada nueva tarea automáticamente.
"¿Para qué entrada es esto?" tiene respuesta. El contexto con alcance de proyecto pertenece a un proyecto.
Alcanzar el límite deja de ser un acontecimiento. Se convierte en un aviso para hacer un triaje, del cual te ibas a beneficiar de todos modos.
El conocimiento sobrevive a la herramienta. Útil si alguna vez te mudas; el enfoque que se explica en cómo migrar de Manus a Cursor.
Buenas prácticas para la base de conocimientos de Manus
Fusiona antes de eliminar. Las convenciones duplicadas en tres entradas es la reducción de conteo más fácil que existe.
Conserva el almacén global para lo que es global. Tu rol, tus convenciones, tus preferencias permanentes. Nada que nombre a un solo proyecto.
Coloca el contexto del proyecto en el proyecto. Está disponible en todos los planes y no tiene un límite de entradas documentado.
Escribe instrucciones maestras específicas. La guía de Manus es que la especificidad allí reduce lo que debes proporcionar por tarea.
Inicia una nueva tarea después de cambiar los archivos del proyecto. Las actualizaciones de archivos solo se aplican a las tareas creadas después del cambio.
Revisa de forma programada, no al llegar al límite. El propio consejo de Manus es "mantener actualizada su base de conocimientos". Una revisión trimestral supera a una limpieza de emergencia.
No apiles reglas no relacionadas en una sola entrada. Anula la razón por la que existe el límite y hace imposible la eliminación selectiva.
Conserva una copia de todo lo que elimines. El límite es una decisión de carga. No debería ser una decisión de olvido.
Conclusión
La base de conocimientos de Manus está limitada a 100 entradas para usuarios Pro y 50 para usuarios Free, y el motivo indicado por el proveedor es la calidad de la respuesta en lugar del almacenamiento: "tener demasiadas entradas puede afectar la calidad de respuesta del sistema". Leído de esa manera, el límite es un consejo sobre la curación, y la acción recomendada es realmente optimizar en lugar de expandir.
La solución práctica es que Manus tiene dos bases de conocimientos y la mayoría de la gente solo usa una. Los proyectos llevan su propia instrucción maestra y su propia base de conocimientos de archivos, se aplican automáticamente a cada nueva tarea creada en ellos y están disponibles en todos los niveles de suscripción. Clasificar tus entradas globales en globales, específicas del proyecto y obsoletas, y luego mover el grupo intermedio a los proyectos, generalmente resuelve el límite sin eliminar nada de lo que querías.
Solo debes conocer las reglas de propagación: las actualizaciones de instrucciones surten efecto en tu próximo mensaje, las actualizaciones de archivos solo llegan a las tareas recién creadas y las tareas existentes conservan la configuración con la que fueron creadas. Y conserva la mitad duradera (las decisiones, los motivos, las cosas que dudaste en eliminar) en una capa que no tenga conteo de entradas, de modo que curar lo que Manus carga nunca signifique perder lo que sabes.