Claude Fable 5 Second Brain: Más Allá de un Gráfico Bonito

La captura de pantalla que me hizo cerrar la pestaña era un grafo: la idea que alguien tenía de un segundo cerebro con Claude Fable 5.

Cientos de nodos brillantes, codificados por colores, conectados por mil hilos tenues, flotando sobre un fondo oscuro como una galaxia de mis propias notas. Era precioso. También era, me di cuenta después de mirarlo fijamente durante un minuto entero, completamente inútil. No podía hacer nada con él. No podía hacerle una pregunta. No podía abrir un archivo desde él. No podía saber si alguna de esas bonitas conexiones significaba algo en absoluto. Era un mood board disfrazado de segundo cerebro.

Esa es la trampa en la que cae de lleno casi todo tutorial de segundo cerebro con Claude Fable 5. Construyen el grafo de Obsidian, capturan la constelación, lo llaman segundo cerebro y lo publican. Y lo entiendo: el grafo fotografía de maravilla y se siente como inteligencia. Pero una imagen de tu conocimiento no es lo mismo que un sistema que lo recupera más rápido y más barato que las herramientas que ya tienes. La construcción que desgrano aquí acierta en esa distinción, y es la razón por la que dejé de hacer scroll y empecé a reconstruir mi propio setup.

He pasado meses metiendo mi conocimiento empresarial y personal en sistemas que Claude Code puede leer, mantener y sobre los que puede actuar. Así que cuando un tutorial afirma que su segundo cerebro mapea 35.466 archivos, reemplaza a Finder por completo y reduce el uso de tokens en aproximadamente un 40% en consultas reales, no me tomo las cifras al pie de la letra: voy a buscar el mecanismo que hay debajo. Este post es ese desmontaje: qué te dicen realmente las cuatro capas de visualización, el pequeño archivo personalizado que hace el trabajo pesado, y por qué la luna de miel en el precio de Fable convierte este momento en el momento de construir.

Por qué el grafo de tu segundo cerebro es sobre todo decoración

Déjame decir primero la parte incómoda, porque reencuadra todo lo que sigue.

La visualización — el grafo, los nodos, la red brillante — es quizá el 30% del valor de un segundo cerebro. Posiblemente menos. El presentador de la construcción que estoy diseccionando lo dice sin rodeos: si el grafo ralentiza la velocidad con la que encuentras un documento, o encarece lo que pagas por recuperarlo, el valor no solo se encoge. Se derrumba. Un segundo cerebro más bonito y más lento que tu explorador de archivos es un retroceso con mejor iluminación.

A Obsidian se le presenta aquí como el estándar de oro, y su vista de grafo es genuinamente lo que la gente captura en pantalla. Pero mira lo que ese grafo hace en realidad: muestra conexiones. No las usa. No puedes profundizar desde un nodo hasta el archivo y abrirlo. No puedes preguntarle al grafo "cuál de estos documentos responde mi pregunta" y que te lleve hasta él. Es un mapa que miras, no un mapa por el que viajas. Ya lo dije cuando comparé Obsidian y Claude Code como capa de memoria persistente: el grafo es la parte menos útil de una herramienta por lo demás excelente.

Así que el primer cambio mental para construir un segundo cerebro real con Claude Fable 5 es este: deja de optimizar lo que capturas en pantalla y empieza a optimizar lo que usas. El grafo debería ganarse su lugar haciendo la recuperación más rápida y más barata, o no debería existir. Todo lo bueno de esta construcción se deriva de tomarse eso en serio.

Bien hecho, eso sí, el grafo deja de ser decoración y se convierte en una vista en vivo de un sistema operativo.

Las cuatro capas que un segundo cerebro con Claude Fable 5 debería mapear

La construcción organiza el espacio de trabajo como una empresa se organiza a sí misma: por departamentos. El negocio por aquí, el contenido por allá, el trabajo personal y de comunidad en sus propias zonas. No porque sea ordenado, sino porque una estructura clara es algo que tanto tú como el modelo podéis navegar sin adivinar. Cuando puedes ver de un vistazo que tu departamento de "contenido" tiene 400 archivos y tu departamento de "negocio" tiene 40, ese desequilibrio te dice algo real sobre dónde se ha ido tu atención.

Pero la vista departamental es solo la superficie. Por debajo, el grafo mapea cuatro capas que juntas forman lo que yo llamaría un sistema operativo agéntico — la misma idea que llevo rondando en mis textos sobre la capa de inteligencia visual de un OS agéntico. Sigue de cerca estas cuatro y ya estarás operando por delante de casi cualquiera que toque estas herramientas.

Aplicaciones (la capa de conectividad). Es cada herramienta de terceros cableada al sistema mediante un conector MCP, una API o una CLI — Google Calendar, Google Drive, tu CRM, lo que hayas enchufado. Verlas como nodos hace dos cosas a la vez. Expone los huecos: una app que pensabas conectar y nunca conectaste es un agujero de productividad que ahora puedes ver. Y expone la densidad: más apps conectadas significa más potencial de automatización, pero también más superficie que defender.

Esa segunda parte importa más de lo que los tutoriales admiten. Dale a Claude el control de tu HubSpot y puede ejecutar tus campañas de email — lo cual es potente justo hasta que una instrucción mal interpretada dispara la secuencia equivocada a una lista real. La capa de aplicaciones no es solo un mapa de conectividad; es un mapa de confianza y riesgo. Cada conexión que puedes ver es una conexión que puedes cuestionar, y las que no usas se convierten en candidatas obvias a recortar, encogiendo tu superficie de ataque y tu complejidad de un solo movimiento. Ya he defendido antes que los permisos van en la clave de API, no en un prompt — la capa de aplicaciones es donde por fin ves qué claves has repartido.

Rutinas (la capa de automatización). Son las tareas programadas en segundo plano — las cosas que se disparan solas mientras duermes. Más rutinas generalmente significa más tiempo ahorrado, pero el verdadero trabajo de esta capa es el mantenimiento. Las automatizaciones se pudren. Una rutina que configuraste en marzo para un proyecto que terminó en abril sigue corriendo, sigue consumiendo, sigue siendo una pequeña responsabilidad que nadie vigila. Ver las rutinas como nodos convierte "auditar mis automatizaciones" de una tarea que nunca harás en un vistazo. En esta construcción, las rutinas corren sobre un agente dedicado — el presentador llama al suyo "Hermes" — con cosas como una skill de registro diario accesible directamente desde la interfaz.

Memoria (la capa de conocimiento). Es el contexto acumulado — cada archivo, nota, decisión y archivo histórico que has guardado con el tiempo. También es donde aparece el número que me hizo incorporarme: 35.466 archivos, mapeados, con relaciones establecidas automáticamente. Seré honesto con esa cifra: es el espacio de trabajo del propio presentador, no una promesa sobre el tuyo, y el valor no está en el recuento. Está en lo que el recuento habilita. A esa escala, la capa de memoria puede reemplazar tu explorador de archivos por completo. Buscar un archivo, encontrar una foto, abrirla — todo desde dentro de la interfaz del segundo cerebro, sin tocar nunca Finder ni el Explorador de Windows. Ese es el momento en que una visualización deja de ser un póster y se convierte en una herramienta que echarías de menos de verdad si desapareciera.

Skills (la capa de capacidades). Esta es la que más importa, y la que nadie enseña. Es una vista transparente de cada skill del sistema y de cómo cada una se conecta con los archivos que lee y las rutinas que impulsa. ¿Por qué importa esa transparencia? Porque es la diferencia entre tener un sistema agéntico y poder explicarlo. Cuando quiero mostrarle a un cliente cómo funciona realmente su operación, un árbol de carpetas pelado no sirve de nada — son solo nombres. Un grafo de skills con navegación en vivo hacia los archivos y carpetas reales me permite recorrer con ellos toda la máquina en tiempo real. Es la forma más honesta que he encontrado de demostrar un segundo cerebro a alguien que no estaba allí cuando lo construiste.

Cuatro capas: a qué estás conectado, qué corre por su cuenta, qué sabes y qué puedes hacer. Mapea esas y habrás construido algo estructuralmente distinto de una pila de notas. Pero — y este es el giro al que la multitud del grafo bonito nunca llega — nada de eso explica el ahorro de tokens. Para eso, tienes que mirar más allá de la visualización, al pequeño archivo que hace el trabajo de verdad.

brain.js: el motor de recuperación que hace el trabajo real

¿Recuerdas la cifra del 30%? Aquí está el otro 70%.

La visualización es lo que ves. brain.js es lo que no ves — un archivo JavaScript personalizado que se sitúa entre tu pregunta y el modelo, y es donde un segundo cerebro con Claude Fable 5 realmente se gana el sueldo. Cada vez que le preguntas algo al sistema, la consulta no va directa a Fable. Va primero a brain.js, que hace una cantidad sorprendente de razonamiento sin invocar el modelo en absoluto.

Recorramos lo que ocurre en una sola consulta:

1. Extrae las palabras clave y descarta el relleno. "¿Dónde está la factura que le envié al cliente Ramlit allá por mayo?" se convierte en algo más cercano a factura, Ramlit, mayo. Las stop words — dónde, la, que, le, por — se descartan. Sin llamada al modelo. Solo procesamiento de texto determinista.
2. Puntúa la relevancia de forma determinista. Contra tu índice de archivos, brain.js calcula qué documentos tienen más probabilidades de importar — usando lógica simple y coincidencia de palabras clave, no una búsqueda de embeddings ni una pregunta a la IA por cada archivo. Esta es la parte que ahorra el dinero. Comprobar la relevancia de 35.466 archivos preguntándole al modelo por cada uno sería absurdamente caro. Hacerlo con puntuación determinista cuesta prácticamente nada.
3. Lee solo lo relevante — y solo las partes relevantes. Una vez que tiene los mejores candidatos, no vuelca archivos enteros al contexto. Extrae las secciones concretas que coinciden, siguiendo "punteros" que mantiene hacia documentos relacionados mediante su propia lógica personalizada.
4. Entonces, y solo entonces, le entrega el resultado filtrado a Claude. Fable recibe un paquete compacto y preverificado con exactamente la información correcta y produce una respuesta precisa — en lugar de ahogarse en todo tu espacio de trabajo y cobrarte por el chapuzón.

La astucia aquí lo es todo. El recurso caro es el modelo. El razonamiento de frontera a las tarifas de Fable es algo que racionas, no algo que rocías sobre cada búsqueda. Así que la arquitectura empuja todo el trabajo posible hacia abajo, a la capa que es gratis — el código determinista — y reserva el modelo para lo único que solo él puede hacer: entender y responder. Es el mismo instinto que hay detrás de una buena optimización de tokens en Claude Code, escalado hasta convertirse en un motor de recuperación completo. No haces el modelo más barato. Haces que haga menos.

Por eso el enfoque por capas también supera a una base de datos vectorial ingenua para un cerebro a escala personal. Un almacén vectorial tiene fortalezas reales, pero oculta su razonamiento tras embeddings que no puedes leer y añade una dependencia que tienes que ejecutar y en la que tienes que confiar. brain.js es legible: puedes abrirlo, ver exactamente cómo decide qué es relevante y ajustar la lógica cuando se equivoca. Para un sistema al que vas a confiar tu negocio, poder leer la lógica de recuperación vale más que una caja negra marginalmente más lista.

Si montar una capa de recuperación determinista sobre tu propia base de conocimiento te suena exactamente al tipo de fontanería poco glamurosa que preferirías no construir en solitario, este es el tipo de sistema que asumo para clientes — puedes ver lo que construyo aquí. Pero el diseño de arriba es genuinamente suficiente para empezar por tu cuenta, y la siguiente sección muestra la recompensa que hace que el esfuerzo valga la pena.

¿Un segundo cerebro realmente recorta tokens? La prueba lado a lado

Aquí está la prueba que separa un segundo cerebro real de una captura de pantalla: ejecuta la misma pregunta dos veces.

La construcción hace exactamente eso — dos sesiones de Claude Code, lado a lado. Una tiene el segundo cerebro y brain.js por delante. La otra es Claude Code por defecto, yendo directo al modelo sin prefiltrado. La misma consulta, el mismo espacio de trabajo, una comparación honesta.

La sesión con segundo cerebro respondió más rápido. Esa es la mitad cualitativa, y es la mitad que se siente. Pero el número que importa es el recuento de tokens. En las ejecuciones del presentador, la consulta con segundo cerebro quedó en torno a los 30.000 tokens. La sesión por defecto, haciendo el mismo trabajo alimentando al modelo con más material en bruto, se acercó a los 50.000 tokens. Llámalo una reducción de ~40%, que el presentador informa que se mantuvo a lo largo de múltiples pruebas.

Quiero ser cuidadoso con esos números, porque este es exactamente el punto donde el contenido sobre segundos cerebros suele empezar a mentir. Son los resultados de una persona en un espacio de trabajo, no una garantía de que los vayas a clonar. Tu mezcla de archivos, tus patrones de consulta y tus hábitos de contexto mueven la línea. Así que no trates el "40%" como una ficha técnica.

Trátalo como algo direccionalmente obvio, que lo es. Cuando filtras de forma determinista antes de que el modelo lea nada, el modelo lee menos. Menos entrada son menos tokens de entrada, y un prompt más ajustado tiende a producir una respuesta más ajustada y más barata. El mecanismo garantiza la dirección aunque no pueda garantizar tu porcentaje exacto. Y en Fable en concreto — donde la salida cuesta 50 $ por millón de tokens — una capa de recuperación que recorta de forma consistente entre un tercio y la mitad de tu factura de tokens no es un extra agradable. Es la diferencia entre un sistema que ejecutas a diario y uno que apagas en silencio después de la primera factura. Analicé esas cuentas por separado en mi desglose de cómo recortar los costos de uso de Fable 5, y la disciplina de recuperación es la palanca más grande de todas.

Esa es la recompensa. Entonces, ¿cómo consigues construir uno sin escribir brain.js a mano desde cero? Haces que el modelo más inteligente del momento lo haga por ti.

¿Cómo consigues que Claude Fable 5 construya el tuyo?

La construcción no se codificó a mano línea a línea. Fue dirigida — y el enfoque de prompting es la parte que puedes copiar hoy mismo.

El movimiento central es negarte a que Fable diseñe tu segundo cerebro solo con sus datos de entrenamiento. Su conocimiento tiene una fecha de corte; las herramientas de segundo cerebro se mueven más rápido que eso. Así que le instruyes explícitamente para que vaya a buscar las mejores prácticas de los últimos ~30 días allí donde ocurre la conversación real — Reddit, X, YouTube, Hacker News — y que incorpore al diseño lo que está vigente. No le estás preguntando qué sabe sobre segundos cerebros. Le estás pidiendo que investigue qué funciona ahora mismo y construya a partir de eso.

Luego le das trabajo previo. La construcción hace referencia a un puñado de proyectos de memoria open source como inspiración estructural — piensa en ellos como ejemplos ilustrativos y no como palabra sagrada:

• QMD (Query My Docs) — un enfoque de búsqueda semántica sobre documentos, útil para pensar cómo debería sentirse la recuperación.
• Un proyecto personal de segundo cerebro ("Gbrain") — un ejemplo resuelto del sistema de conocimiento vital completo de una persona.
• Graphify — un proyecto centrado en fortalecer las conexiones entre archivos y carpetas, que merece estudiarse por sí solo; escribí sobre Graphify como grafo de conocimiento para una base de código y el patrón se generaliza limpiamente a un cerebro personal.

Soltar capturas o resúmenes de proyectos como estos en tu prompt le da a Fable estructuras concretas que adaptar en lugar de inventar desde la nada. Le estás dando los hombros sobre los que apoyarse.

Hay un patrón de prompt más que rinde muy por encima de su peso: los objetivos de autooptimización automatizada. Configuras un comando permanente — /go o /goal — que instruye al sistema a comprobar la capacidad de respuesta de su propia interfaz. ¿Hay lag cuando los nodos se mueven? ¿El layout se traba? ¿El grafo entero carga completamente en, digamos, 10 segundos tras un refresco? Si falla esas comprobaciones, se optimiza a sí mismo y lo intenta de nuevo. En lugar de que tú presentes quejas de UX contra tu propia herramienta, la herramienta se exige a sí misma un listón de rendimiento y cierra la brecha con el tiempo. Es una idea pequeña con un gran efecto compuesto — el mismo instinto de automejora al que vuelvo una y otra vez en los sistemas automejorables de Claude Code.

Apunta a Fable hacia las mejores prácticas actuales, dale estructuras open source reales de las que aprender y ponle un objetivo de autooptimización para sostener el listón de rendimiento. Esa es la receta. No será perfecto a la primera — y las formas en que se queda corto merecen conocerse antes de empezar.

Lo que esto no hará (y por qué aun así lo construiría esta semana)

Te haría un flaco favor si dejara que el número del 40% cargara con todo este post. Así que aquí está el balance honesto.

El grafo te seducirá para sobreinvertir en el 30% equivocado. Me he visto hacerlo. Dejar la visualización preciosa es profundamente satisfactorio y mayormente un desperdicio. Si tus nodos son hermosos pero tu recuperación es lenta, construiste un salvapantallas. Juzga cada hora que inviertas con una sola pregunta: ¿esto hace que encontrar y usar información sea más rápido o más barato? Si no, el grafo no lo necesita.

La recuperación determinista tiene un techo. La puntuación por palabras clave es rápida, gratuita y legible — y de vez en cuando pasará por alto un documento que es relevante pero no comparte tus palabras exactas. Un sistema puramente semántico podría captar lo que brain.js se salta. La apuesta de esta construcción es que la legibilidad y el costo casi nulo superan las ganancias marginales de recall para un cerebro personal, y creo que esa apuesta es correcta a esta escala. Pero es un compromiso, no un almuerzo gratis, y si tu conocimiento se inclina fuertemente hacia lo conceptual en lugar de lo indexable por palabras clave, notarás los bordes.

Las conexiones son una responsabilidad permanente, no una configuración de una sola vez. Cada app que cableas es una puerta. La capa de aplicaciones te ayuda a ver las puertas, pero verlas no las cierra con llave. El ejemplo de HubSpot no es hipotético — dale a un agente la capacidad de enviar, y una instrucción mal leída se convierte en un mensaje real a personas reales. La visualización solo es una herramienta de seguridad si actúas sobre lo que muestra y recortas lo que no usas.

El mantenimiento es el costo real, y nunca aparece en la factura. Las APIs cambian. Las skills derivan. Las rutinas sobreviven a su propósito. Un segundo cerebro así de capaz es un jardín, no un monumento — necesita cuidados, y el día que dejas de cuidarlo es el día en que empieza a mentirte en silencio.

Entonces, ¿por qué construir ahora, sabiendo todo eso? Por el momento. Claude Fable 5 se lanzó el 9 de junio de 2026, y su ventana gratuita inicial en Pro y Max se cortó de golpe cuando una directiva de control de exportaciones del gobierno de EE. UU. suspendió el acceso al modelo el 12 de junio. Se volvió a desplegar el 1 de julio — ahora a tarifas de API de 10 $ por millón de tokens de entrada y 50 $ por millón de salida, el modelo generalmente disponible más caro que Anthropic ofrece. La lectura estratégica es sencilla: el contexto, la memoria y la potencia de automatización del modelo son extraordinarios ahora mismo, y el trabajo complejo y de una sola vez de construir el sistema es exactamente lo que quieres delegar en un cerebro de frontera mientras está a tu alcance. Construyes el andamiaje caro durante la ventana capaz, y una vez que brain.js hace el filtrado, la operación del día a día cuesta una fracción de lo que costaría el uso ingenuo. Construye inteligente ahora; opera barato después.

Construye el motor de recuperación, no el salvapantallas

Vuelve a esa galaxia de nodos brillantes con la que cerré la pestaña. No estaba mal construir un grafo. Estaba mal detenerse en el grafo — confundir la imagen del conocimiento con la máquina que lo usa.

Un segundo cerebro real con Claude Fable 5 se define por las partes que no lucen en una captura: las cuatro capas que te dicen a qué estás conectado y qué corre sin ti, y el pequeño archivo determinista que decide qué lee el modelo antes de que lea nada. Ahí es donde vive la velocidad. De ahí sale el ahorro de ~40% en tokens. Ese es el 70% que nadie pone en la miniatura.

Aquí va tu único movimiento de esta semana. No construyas el grafo. Abre una terminal, apunta a Claude hacia tus archivos existentes y escribe la versión más rudimentaria posible de brain.js — un script que toma una pregunta, elimina las palabras de relleno, puntúa tus archivos por solapamiento de palabras clave y devuelve los tres mejores. Eso es todo. Será feo y será suficiente para demostrar el mecanismo en tu propio espacio de trabajo. Una vez que lo veas entregarle al modelo tres archivos correctos en lugar de treinta, no volverás jamás a dejar que Fable nade entre todo.

El grafo bonito es un póster de tu conocimiento. El motor de recuperación es el segundo cerebro. Construye el que te cuesta menos cada vez que lo usas — y deja que la galaxia venga después, si es que llega a venir.

Preguntas frecuentes

¿Qué es un segundo cerebro con Claude Fable 5?

Un segundo cerebro con Claude Fable 5 es un sistema de conocimiento personal que mapea todo tu espacio de trabajo y usa una capa de recuperación determinista para alimentar a Claude Fable 5 solo con los archivos relevantes para cada consulta. Combina una visualización de cuatro capas — Aplicaciones, Rutinas, Memoria y Skills — con un motor de filtrado que recorta el costo en tokens, en lugar de ser solo un grafo que miras.

¿Cuánto puede reducir un segundo cerebro el uso de tokens de Claude Fable 5?

En la construcción examinada aquí, una consulta con segundo cerebro usó aproximadamente 30.000 tokens frente a unos 50.000 de una sesión por defecto con la misma pregunta — alrededor de un 40% de reducción que el presentador informa a lo largo de múltiples pruebas. Son los resultados de una persona, no una garantía, pero la dirección se sostiene: el prefiltrado determinista significa que el modelo lee menos. Consulta la sección de la prueba lado a lado más arriba.

¿Es un segundo cerebro con Claude Fable 5 mejor que la vista de grafo de Obsidian?

Para recuperar información de verdad, sí — porque el grafo de Obsidian muestra conexiones sin dejarte usarlas, mientras que un segundo cerebro construido a propósito profundiza desde un nodo hasta el archivo real y enruta las consultas a través de un motor de recuperación. Obsidian sigue siendo un excelente almacén de markdown; su grafo es la parte decorativa, no la funcional.

¿Qué hace brain.js en un sistema de segundo cerebro?

brain.js es un archivo JavaScript personalizado que intercepta una consulta antes de que llegue a Claude Fable 5, extrae palabras clave, descarta palabras de relleno, puntúa la relevancia de los archivos de forma determinista sin llamar al modelo, y luego pasa a Claude solo las secciones concretas. Esto mantiene las invocaciones caras del modelo limitadas al contenido genuinamente necesario. El mecanismo completo se desglosa en la sección de brain.js más arriba.

¿Por qué construir un segundo cerebro durante la ventana de precios de Claude Fable 5?

Porque el contexto, la memoria y la potencia de automatización de Fable 5 lo hacen excepcionalmente bueno en el trabajo de una sola vez de diseñar y construir el sistema, y quieres que ese trabajo pesado esté hecho mientras el modelo está a tu alcance. Fable se lanzó el 9 de junio de 2026 y ahora factura a 10 $/50 $ por millón de tokens — así que construir inteligente ahora, y luego operar sobre una capa de recuperación barata, es la jugada rentable.

¿Quieres un segundo cerebro que realmente recupere?

Si prefieres no escribir brain.js a mano ni cablear las cuatro capas tú mismo, esta es exactamente el tipo de fontanería de recuperación determinista que construyo para clientes — legible, ajustada a tu propia mezcla de archivos, para que el modelo lea menos y cueste menos en cada consulta. Cuéntame cómo es tu base de conocimiento y te ayudo a dimensionarla.