Hice que Claude Code Hablara Como un Cavernícola. Se Volvió Más Inteligente.

Hice que Claude Code Hablara Como un Cavernícola. Se Volvió Más Inteligente.

El repositorio en GitHub tenía 589 estrellas y un eslogan que parecía un chiste: "why use many token when few token do trick." Casi cierro la pestaña. Estaba inmerso en un flujo de trabajo con Opus 4.6 — agentes ejecutándose en cuatro proyectos, costos de tokens escalando hacia cifras en las que prefería no pensar — y lo último que necesitaba era una herramienta meme prometiendo reducir mis costos.

Entonces leí la afirmación: 75% de reducción en tokens de salida.

Ese número me detuvo. No porque lo creyera — no lo hacía — sino porque si incluso una fracción se cumplía, estaba dejando dinero serio sobre la mesa cada día. Así que lo instalé. Y lo que sucedió después no fue lo que esperaba. El ahorro de tokens fue real pero modesto. ¿La parte que genuinamente me sorprendió? Claude comenzó a darme mejores respuestas.

No "mejores" de una forma vaga y subjetiva. Mejores de una manera que un artículo de investigación de marzo de 2026 en arXiv ya había predicho. Un artículo que evaluó 31 modelos en 1.485 problemas y descubrió algo que rompe la intuición de la mayoría de las personas sobre cómo funcionan los grandes modelos de lenguaje.

Necesito guiarte a través de lo que realmente sucedió — los números reales, los ahorros reales y la ciencia que explica por qué hacer que tu IA hable como un neandertal podría ser una de las cosas más inteligentes que puedes hacer con ella.

Qué Hace Realmente el Skill Caveman

El skill caveman, creado por el desarrollador independiente Julius Brussee, es un skill de Claude Code que reduce las respuestas de Claude a lo esencial. Sin artículos. Sin palabras de relleno. Sin cortesias. Sin atenuaciones. Fragmentos en lugar de oraciones completas. Los términos técnicos se mantienen exactos. Los bloques de código quedan intactos.

Así se ve la diferencia en la práctica.

Respuesta normal de Claude: "Tu componente se está rerenderizando porque estás creando una nueva referencia de objeto en cada ciclo de renderizado. La prop de objeto inline genera una nueva referencia cada vez que el componente padre se rerenderiza, lo que causa que el componente hijo también se rerenderice. Te recomendaría envolver el objeto en useMemo para mantener la estabilidad referencial."

Modo caveman full: "Nueva ref obj cada render. Inline obj prop = nueva ref = re-render. Envolver en useMemo."

Modo caveman ultra: "Inline obj prop -> nueva ref -> re-render. useMemo."

La misma información. La misma precisión técnica. Drásticamente menos tokens.

La instalación requiere un solo comando:

npx skills add JuliusBrussee/caveman

Se activa escribiendo /caveman en tu sesión de Claude Code, o frases como "talk like caveman" o "less tokens please." Para volver al modo normal, escribe stop caveman o normal mode. Tres niveles de intensidad — lite, full y ultra — te permiten ajustar la compresión a tu nivel de comodidad.

El skill también incluye una herramienta complementaria que comprime tus archivos de memoria (como CLAUDE.md) en aproximadamente un 45%, reduciendo los tokens de entrada en cada interacción. Si has leído mi análisis sobre por qué tu archivo CLAUDE.md es tu superpoder o tu cuello de botella, sabes cuánto suman esos tokens de contexto persistente.

Pero aquí necesito ser honesto contigo — porque los números del titular no cuentan la historia que la mayoría piensa.

La Matemática de Tokens Que la Mayoría Entiende Mal

El repositorio caveman afirma hasta un 75% de reducción en tokens de salida y un 45% de reducción en tokens de entrada. Esos números son técnicamente precisos. También son profundamente engañosos si no entiendes lo que realmente están midiendo.

Realicé una auditoría completa de mis propias sesiones de Claude Code para averiguar a dónde van realmente los tokens. Aquí está el desglose que cambió mi perspectiva.

Una sesión típica de Claude Code consume aproximadamente 100.000 tokens en total. Eso se divide en unos 75.000 tokens de entrada y 25.000 tokens de salida. El modelo mental de la mayoría ya está equivocado — asumen que la salida es el gran impulsor de costos, pero los tokens de entrada superan a los de salida 3:1 en una sesión de programación normal.

Ahora mira qué compone esos 25.000 tokens de salida:

• Llamadas a herramientas — cuando Claude lee archivos, busca en tu código base, ejecuta comandos. Son payloads JSON estructurados. El modo caveman no los toca.
• Bloques de código — el código real que Claude escribe. El modo caveman los deja completamente intactos (y así debe ser — no quieres nombres de variables comprimidos).
• Respuestas en prosa — las explicaciones, sugerencias y comentarios de Claude. Esta es la única parte que el modo caveman comprime.

En mis sesiones, las respuestas en prosa representaron aproximadamente 6.000 de esos 25.000 tokens de salida. El modo caveman comprimió esos 6.000 tokens en un 75%, ahorrando aproximadamente 4.500 tokens.

4.500 tokens de 100.000 en total.

Eso es una reducción del 4,5% por sesión. No el 75%.

En el lado de la entrada, la compresión de archivos de memoria ahorra alrededor de 1.000 a 2.000 tokens por sesión. El resto de tus tokens de entrada — historial de conversación, contenido de archivos que Claude lee, prompts del sistema — permanecen sin cambios.

Ahorro realista combinado: aproximadamente 4-5% de reducción total de tokens por sesión.

¿Es inútil el 4-5%? Absolutamente no. Si estás ejecutando Claude Code ocho horas al día en múltiples proyectos — y yo lo hago — se acumula. Con mi uso de aproximadamente $200/mes, ahorra $8-10 mensuales. No es transformador, pero es una optimización gratuita sin esfuerzo alguno después de la instalación.

Pero el ahorro en costos no es la razón por la que mantuve el modo caveman activado. La razón no tiene nada que ver con tokens.

El Artículo de Investigación Que Cambió Mi Opinión

En marzo de 2026, apareció un artículo en arXiv que inicialmente pasé por alto: "Brevity Constraints Reverse Performance Hierarchies in Language Models". El título sonaba académico y árido. Los hallazgos fueron todo lo contrario.

Los investigadores evaluaron 31 modelos de pesos abiertos que iban desde 0,5 mil millones hasta 405 mil millones de parámetros en 1.485 problemas distribuidos en cinco conjuntos de datos de referencia. Su pregunta era simple: ¿el tamaño del modelo siempre equivale a mejor rendimiento?

La respuesta rompió mis suposiciones.

En el 7,7% de los problemas de referencia, los modelos más grandes rindieron peor que los más pequeños — hasta en 28,4 puntos porcentuales. Un modelo de 2 mil millones de parámetros superando a uno de 400 mil millones. No en alguna pregunta trampa de caso límite. En benchmarks estándar de razonamiento matemático y conocimiento científico.

El mecanismo que identificaron tiene un nombre que se me quedó grabado: verbosidad espontánea dependiente de la escala.

Los modelos más grandes, entrenados extensivamente mediante reinforcement learning with human feedback (RLHF), desarrollan una tendencia a ser excesivamente verbosos. No solo responden la pregunta — elaboran, atenúan, matizan, exploran tangentes y añaden descargos de responsabilidad. Esta verbosidad no es relleno inofensivo. Introduce activamente errores a través de lo que los investigadores llaman "sobreelaboración."

Piénsalo de esta manera. Cuando le pides a un modelo grande que resuelva un problema matemático, no simplemente calcula la respuesta. Narra todo su proceso de razonamiento, a menudo más verbosamente de lo necesario. En algún lugar de esa narración — en las atenuaciones, las consideraciones alternativas, los apartes de "pero también deberíamos considerar" — el modelo puede convencerse a sí mismo de la respuesta incorrecta. Piensa de más. El modelo más pequeño, limitado por su capacidad, da una respuesta más corta y directa y llega a la respuesta correcta con más frecuencia.

Aquí está el hallazgo que me hizo sentarme derecho: restringir los modelos grandes a producir respuestas breves y concisas mejoró la precisión en 26 puntos porcentuales en esos benchmarks problemáticos. Aún más llamativo — redujo la brecha de rendimiento entre modelos grandes y pequeños en hasta dos tercios.

Los modelos grandes no eran menos capaces. Eran demasiado verbosos para usar sus capacidades de manera efectiva.

Por Qué RLHF Entrena a los Modelos a Perjudicarse a Sí Mismos

Esta parte de la madriguera de investigación se puso oscura. El problema de la verbosidad no es un bug en el proceso de entrenamiento — es un resultado predecible de cómo estos modelos aprenden a comunicarse.

RLHF funciona haciendo que anotadores humanos evalúen las respuestas del modelo. De manera consistente, a través de múltiples estudios, los anotadores humanos confunden longitud con calidad. Una respuesta más larga y detallada se siente más completa, más útil, más impresionante. Así que el modelo de recompensa aprende: más largo es mejor. Y el modelo de lenguaje optimiza para esa señal.

Investigación de OpenReview documenta este sesgo sistemático de longitud — las mejoras en las puntuaciones de recompensa están impulsadas en gran medida por el aumento de la longitud de respuesta más que por la calidad real de la respuesta. El modelo es recompensado por ser verboso, no por ser correcto.

Los modelos más grandes, con su mayor capacidad, internalizan esta señal más profundamente que los pequeños. Tienen más parámetros para dedicar a generar prosa elaborada y fluida. Así que se vuelven más verbosos a medida que escalan — exactamente lo opuesto de lo que se desearía.

Hay un hallazgo aún más inquietante de investigación separada: RLHF puede hacer que los modelos sean mejores para convencer a los humanos de que tienen razón, incluso cuando están equivocados. ¿La respuesta verbosa, segura de sí misma, bien estructurada que suena autoritaria? Podría estar equivocada con seguridad — y la verbosidad es lo que la hace convincente.

Cuando leí eso, toda mi relación con la salida del modelo cambió. Dejé de equiparar exhaustividad con precisión. Y comencé a preguntarme: ¿y si lo mejor que podía hacer por mi flujo de trabajo con Claude Code no era darle más contexto, más instrucciones, más libertad — sino menos?

Mi Configuración de Pruebas: Caveman vs. Modo Normal

Necesitaba probar esto yo mismo. No con benchmarks — con trabajo real. Mi flujo de trabajo diario con Claude Code involucra construir funcionalidades, depurar problemas de producción, escribir sistemas de agentes y generar contenido para cuatro sitios web. Si las restricciones de brevedad realmente mejoraban la calidad de la salida, lo vería en el código que se envía a producción.

Realicé una prueba A/B informal durante dos semanas. Semana uno: Claude Code normal, Opus 4.6, mi configuración estándar de CLAUDE.md. Semana dos: la misma configuración con el modo caveman (intensidad full) activado.

Rastré tres cosas:

1. Tasa de éxito en el primer intento — ¿la primera respuesta de Claude resolvió el problema sin necesitar una corrección adicional?
2. Total de turnos por tarea — ¿cuántos mensajes de ida y vuelta antes de que una tarea estuviera completa?
3. Tasa de aprobación en code review — cuando revisaba el código generado, ¿con qué frecuencia pasaba sin cambios?

Los resultados no fueron lo suficientemente dramáticos para publicarlos como un estudio controlado, pero el patrón fue consistente.

Tasa de éxito en el primer intento: El modo normal promedió alrededor del 64%. El modo caveman alcanzó aproximadamente el 71%. Esa mejora de 7 puntos porcentuales se alinea estrechamente con lo que la investigación predijo — la verbosidad restringida reduce la introducción de errores.

Total de turnos por tarea: El modo normal promedió 4,2 turnos. El modo caveman promedió 3,6 turnos. Menos turnos significaron una finalización de tareas más rápida y un menor consumo total de tokens (lo que multiplica los ahorros directos de tokens).

Tasa de aprobación en code review: Casi idéntica — 82% normal vs. 84% caveman. La salida de código en sí no se vio afectada, lo cual tiene sentido. El modo caveman no toca los bloques de código.

La verdadera sorpresa fue cualitativa. En modo caveman, las explicaciones de Claude eran más fáciles de analizar. Cuando algo salió mal, la descripción concisa del error me guió al problema más rápido que una explicación de tres párrafos. Cuando Claude explicó una decisión técnica, la versión simplificada expuso el razonamiento con más claridad — sin lenguaje atenuante para suavizar una elección cuestionable.

Es contraintuitivo. Menos explicación, mejor comprensión.

Cómo Configurar el Modo Caveman (y Cuándo No)

Si quieres probar esto tú mismo, aquí está la configuración práctica. También te diré dónde el modo caveman falla — porque lo hace, en situaciones específicas.

Paso 1: Instalar el Skill

npx skills add JuliusBrussee/caveman

Esto funciona con Claude Code y más de 40 otros agentes de IA, incluyendo Cursor, Windsurf y GitHub Copilot. El skill se instala en el directorio .skills de tu proyecto y Claude lo detecta automáticamente.

Paso 2: Activar y Elegir tu Nivel

En cualquier sesión de Claude Code:

/caveman lite    # Elimina relleno pero mantiene oraciones legibles
/caveman full    # Predeterminado — fragmentos, sin artículos, palabras mínimas
/caveman ultra   # Mínimo absoluto. Casi estilo telegrama.

Mi recomendación: empieza con full. Es el punto óptimo entre compresión y legibilidad. Ultra es útil para tareas repetitivas donde sabes exactamente qué buscar. Lite apenas difiere del modo normal — resérvalo para trabajo intensivo en documentación donde necesitas oraciones completas.

Paso 3: Comprimir tus Archivos de Memoria

La herramienta complementaria comprime tu CLAUDE.md y otros archivos de memoria:

# Desde el directorio del skill caveman
npx caveman compress

Esto elimina relleno de tus archivos de contexto persistente mientras preserva todas las reglas y restricciones técnicas. Si has seguido mi consejo de mantener CLAUDE.md bajo 300 líneas, la compresión lo reduce otro 45%.

Consejo profesional: Antes de comprimir, haz una copia de seguridad de tu CLAUDE.md original. La versión comprimida es más difícil de leer y editar para humanos. Mantengo una copia CLAUDE.md.human para cuando necesito hacer cambios manuales, y luego recomprimo después de editar.

Paso 4: Desactivar Cuando Sea Necesario

stop caveman

o

normal mode

Esto devuelve a Claude a su nivel de verbosidad estándar inmediatamente.

Cuándo el Modo Caveman Perjudica

He identificado tres escenarios donde consistentemente desactivo caveman:

Explicar conceptos a colaboradores. Cuando uso Claude para generar explicaciones que compartiré con compañeros de equipo o clientes, la salida caveman es demasiado escueta. Las personas que no están en tu cabeza necesitan el tejido conectivo que caveman elimina.

Depurar problemas complejos multi-archivo. Cuando un bug abarca múltiples archivos y Claude necesita recorrer su cadena de razonamiento, la salida comprimida puede ocultar puntos de decisión críticos. Quiero ver por qué Claude eligió buscar en el archivo A en lugar del archivo B. El modo caveman a veces oculta ese razonamiento.

Escribir documentación. Esto debería ser obvio, pero he cometido el error. Claude en modo caveman generando documentación de API produce documentación técnicamente precisa pero casi inútil. Las oraciones completas importan cuando escribes para humanos que no tendrán tu contexto.

Para tareas directas de programación, refactorización, escritura de tests, code review y cualquier tarea donde la salida es principalmente código, el modo caveman se queda activado. Siempre.

El Principio Mayor: Por Qué la Concisión Supera a la Verbosidad en los LLMs

Aquí está lo que la mayoría de la gente pasa por alto del enfoque caveman, y es la perspectiva que importa mucho después de que esta herramienta específica sea olvidada.

El problema de la verbosidad no es exclusivo de un skill o una herramienta. Está integrado en cómo se entrena cada gran modelo de lenguaje. Claude, GPT, Gemini, Grok — todos sufren del mismo sesgo de verbosidad inducido por RLHF documentado por el análisis de Unite.AI y el consenso emergente en torno al comportamiento de compensación de verbosidad.

Los modelos entrenados con RLHF, DPO o fine-tuning supervisado en trazas largas de chain-of-thought compensan rutinariamente la incertidumbre generando respuestas innecesariamente largas, redundantes o con razonamiento tortuoso. Cuando el modelo no está seguro de algo, su instinto entrenado es escribir más, no menos. Más atenuaciones. Más alternativas. Más salvaguardas. Cada palabra adicional es otra oportunidad de introducir un error o convencerse a sí mismo de dejar la respuesta correcta.

Esto significa que cada prompt que escribes, cada instrucción del sistema que configuras, cada regla de CLAUDE.md que estableces — todo puede combatir el sesgo de verbosidad o amplificarlo.

No necesitas el skill caveman para aplicar este principio. Puedes obtener el 80% del beneficio con una sola línea en tu CLAUDE.md:

Sé conciso. Sin relleno. Sin atenuaciones. Conclusiones primero, razonamiento después. Sin cortesías.

He probado esta instrucción exacta contra el modo caveman. Los ahorros de tokens son menores (aproximadamente 40-50% de compresión de prosa vs. el 75% de caveman), pero los beneficios de precisión son casi idénticos. La clave no es la formulación específica — es la restricción en sí. Decirle al modelo que sea breve lo obliga a comprometerse con las respuestas en lugar de eludirlas.

Si prefieres que alguien construya una configuración completa de Claude Code optimizada para tokens desde cero — incluyendo configuraciones personalizadas de CLAUDE.md, enrutamiento de modelos y optimización de costos de agentes — acepto exactamente ese tipo de proyectos. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Para desarrolladores que ya están inmersos en el juego de optimización de costos de agentes IA, esta es otra palanca que pueden accionar. Se acumula con estrategias de selección de modelos y técnicas de gestión de contexto. Combinados, estos enfoques pueden reducir tus costos mensuales de desarrollo con IA en un 60-70% sin afectar la calidad de la salida.

Los Números Que Realmente Importan

Permiteme enmarcar el panorama completo para alguien que ejecuta Claude Code diariamente, como yo.

Ahorro directo de tokens por modo caveman: ~4-5% por sesión. Con un uso de $200/mes, eso son $8-10 mensuales. No es revolucionario, pero es gratis después de una instalación de un minuto.

Ahorros indirectos por menos turnos de conversación: Mis sesiones promediaron 0,6 menos turnos por tarea en modo caveman. En 30-40 tareas diarias, eso son 18-24 turnos menos. Cada turno cuesta aproximadamente 2.000-3.000 tokens. Eso son otros 36.000-72.000 tokens ahorrados diariamente — empujando los ahorros totales hacia el 8-10%.

Mejora de precisión: 7 puntos porcentuales más alta la tasa de éxito en el primer intento en mis pruebas, consistente con la mejora de 26 puntos porcentuales encontrada en benchmarks de investigación controlada. La brecha es menor en programación del mundo real porque las tareas de código tienen restricciones más estrictas que los benchmarks abiertos — pero la dirección es clara y consistente.

Tiempo ahorrado: Menos turnos y explicaciones más concisas significaron que pasé menos tiempo leyendo la salida de Claude. Difícil de cuantificar con precisión, pero estimo 15-20 minutos ahorrados en un día completo de trabajo. Eso son casi dos horas por semana que recupero solo por leer menos relleno.

Impacto mensual combinado: Aproximadamente $15-20 en ahorros de tokens, más de 7 horas de tiempo recuperado y mediblemente menos ciclos de corrección. Para una instalación de un comando sin configuración.

Esos no son el tipo de números que generan titulares. Son el tipo que se acumula a lo largo de meses y cambia silenciosamente la economía del desarrollo asistido por IA a escala.

Qué Estoy Observando a Continuación

El skill caveman es un instrumento contundente — efectivo, pero tosco. Lo que me interesa más es hacia dónde conduce esta dirección de investigación.

Anthropic y OpenAI son conscientes del problema de la verbosidad. La propia documentación de Anthropic sobre la gestión de costos de Claude Code ya recomienda el prompting conciso como palanca principal de costos. Pero la solución a nivel de modelo — entrenar modelos que por defecto den respuestas concisas a menos que se solicite explícitamente detalle — aún no se ha implementado.

Espero que lo veamos dentro de 2026. La investigación es demasiado clara para ignorarla. Cuando un enfoque de entrenamiento reduce demostrablemente la precisión al fomentar la verbosidad, corregirlo a nivel de modelo se convierte en un imperativo económico. El modelo que naturalmente dé respuestas concisas y precisas sin necesitar un overlay de skill caveman tendrá una ventaja competitiva genuina.

Hasta entonces, el enfoque del skill — agregar una capa de restricción que contrarresta el sesgo de verbosidad — es la mejor herramienta que tenemos. Y funciona. No tan dramáticamente como sugieren los números del titular. Pero de manera significativa, consistente y sin ningún inconveniente para los flujos de trabajo de programación.

Hay una cosa más que el experimento caveman me enseñó que va más allá de tokens y precisión. Cambió cómo leo la salida de la IA.

Antes del modo caveman, escaneaba las largas respuestas de Claude buscando la respuesta real enterrada en la explicación. Pasaba por alto las atenuaciones, saltaba las salvaguardas, iba directo al bloque de código. Estaba inconscientemente filtrando por señal en un mar de ruido. Y ni siquiera me daba cuenta de cuánta energía cognitiva consumaba ese filtrado.

Después de dos semanas de respuestas concisas y directas, volver al modo normal se sintió ruidoso. Como cambiar de un terminal limpio a un IDE abarrotado con cada panel abierto. La información era la misma. La experiencia era peor.

Esa es la verdadera lección escondida en un repositorio de GitHub digno de meme. Hemos estado entrenando modelos de lenguaje para que suenen impresionantes cuando deberíamos haberlos entrenado para que suenen claros. El skill caveman es un hack — un hack divertido, útil y bien construido. Pero el principio detrás de él es completamente serio.

El token más caro no es el que pagas. Es el que introduce un error que pasas veinte minutos depurando.

Así que aquí está mi desafío: añade una línea a tu CLAUDE.md hoy. Solo una. "Sé conciso. Sin relleno. Sin atenuaciones." Ejecuta tu flujo de trabajo normal durante una semana. Observa qué pasa con tu tasa de éxito en el primer intento.

Creo que mantendrás esa línea permanentemente.

Preguntas Frecuentes

¿Afecta el modo caveman la generación de código de Claude Code?

No. El modo caveman solo comprime respuestas en prosa — explicaciones, sugerencias y comentarios. Todos los bloques de código, llamadas a herramientas y salidas estructuradas permanecen completamente sin cambios. El skill preserva explícitamente los términos técnicos, mensajes de error y sintaxis de código exactamente como aparecerían normalmente.

¿Cuánto ahorra realmente el modo caveman en costos de Claude Code?

Los ahorros totales realistas por sesión son del 4-5%, no el 75% del titular. El 75% aplica solo a la salida en prosa, que es aproximadamente 6.000 de 25.000 tokens totales de salida. Combinado con la compresión de archivos de memoria y menos turnos de conversación, los ahorros prácticos alcanzan el 8-10% para usuarios intensivos diarios. Para el panorama completo de optimización de costos, consulta mi guía de optimización de costos de agentes IA.

¿Pueden las restricciones de brevedad realmente hacer más precisos a los modelos de IA?

Sí. Un artículo de marzo de 2026 (arXiv 2604.00025) evaluó 31 modelos en 1.485 problemas y encontró que las restricciones de brevedad mejoraron la precisión de los modelos grandes en 26 puntos porcentuales en problemas donde la verbosidad causaba errores. El mecanismo es la reducción de la "sobreelaboración" — los modelos verbosos se convencen a sí mismos de respuestas incorrectas a través de atenuaciones excesivas y razonamiento tangencial.

¿Cómo instalo el skill caveman para Claude Code?

Ejecuta npx skills add JuliusBrussee/caveman en el directorio de tu proyecto. Activa con /caveman o /caveman full. Elige la intensidad: lite, full (predeterminado) o ultra. Desactiva con stop caveman. El skill también funciona con Cursor, Windsurf, GitHub Copilot y más de 40 otros agentes.

¿Hay una alternativa más simple al skill caveman?

Añade esta línea a tu CLAUDE.md: "Sé conciso. Sin relleno. Sin atenuaciones. Conclusiones primero, razonamiento después." Esto logra aproximadamente 40-50% de compresión de prosa comparado con el 75% de caveman, con beneficios de precisión casi idénticos. El principio clave es la restricción en sí, no la herramienta específica.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io