El anuncio de OpenAI cayó a las 9:04 AM del 23 de abril de 2026. Yo acababa de abrir una terminal para enviar una migración de Laravel. Veinte minutos después, la migración seguía en mi rama de staging, intacta, porque estaba absorto en la página de introducción de GPT 5.5 intentando decidir si este realmente era el lanzamiento que justificaba toda la expectación, o solo otro salto incremental de seis semanas disfrazado de avance revolucionario.
El dato que me dejó helado fue este: 82.7% en Terminal-Bench 2.0. Es el estado del arte en el benchmark que prueba si un modelo puede realmente planificar, iterar y coordinar herramientas en una shell; es decir, la vara de medir en la que el coding agéntico brilla o fracasa estrepitosamente. Opus 4.7 queda en 69.4% en el mismo benchmark, según la comparativa de digitalapplied. Una diferencia de 13 puntos. Trece puntos es la distancia entre “prometedor” y “por favor, úsalo ya en producción”.
Pero los benchmarks engañan. No a propósito: simplemente miden lo que miden, que rara vez es lo que de verdad te importa. Lo que me interesa es si GPT 5.5, con Codex, realmente me ahorra la tarde del miércoles. Por eso pasé los siguientes dos días poniéndolo a prueba con tres builds que bien habría delegado a un ingeniero senior: un SVG absurdamente detallado, un juego retro arcade nativo para macOS con sprites generados por IA, y una arena 3D tipo dungeon en primera persona renderizada en un cuarto de viewport. Trabajo real. Pruebas reales. Costes reales.
Quédate conmigo hasta la prueba del dungeon. Es ahí donde mi idea de que “GPT 5.5 es solo un 5.4 más rápido” se vino abajo en tiempo real, y tuve que reescribir la perspectiva de todo este post.
Por qué este lanzamiento realmente importa (y por qué cambió Codex)
La cadencia de lanzamientos en esta industria se ha vuelto completamente desenfrenada. GPT 5.4 se lanzó en febrero. Opus 4.7 aterrizó a mediados de abril. GPT 5.5 llegó una semana después. Ahora estamos recibiendo un nuevo modelo de codificación de frontera, aproximadamente cada seis a ocho semanas, y cada uno se supone que es “el que lo cambia todo”.
La mayoría de las veces, eso es solo marketing. Esta vez, el planteamiento se siente diferente —y no porque OpenAI lo diga—. Es por tres cambios concretos.
Primero, GPT 5.5 es el primer modelo base completamente reentrenado desde GPT-4.5. Todo lo que hubo entre 4.5 y 5.4 fue iteración sobre el mismo fundamento subyacente. GPT 5.5 es una nueva base. No es una diferencia menor: significa que el corpus de preentrenamiento, las decisiones arquitectónicas y los objetivos orientados al agente se rediseñaron desde cero con el trabajo autónomo como meta, no la calidad de respuesta conversacional.
Segundo, la ventana de contexto saltó a 1M tokens en la API. La API de GPT 5.4 llegaba como máximo hasta 512K. Duplicar la capacidad no es solo tener un búfer más grande: es una categoría de trabajo diferente. Una ventana de contexto de 1M permite que un agente retenga toda una base de código de tamaño mediano, su suite de pruebas y la documentación relevante en una sola sesión, sin juegos de truncamiento. En el benchmark de recuperación MRCR v2 8-needle de OpenAI en el rango de 512K-1M, GPT 5.5 alcanza 74.0%, mientras que Opus 4.7 queda en 32.2%. No es una brecha: son dos capacidades completamente diferentes.
Tercero, la integración de Codex recibió una mejora real. Ahora puedes elegir entre esfuerzo de razonamiento medio, alto y extra alto según cada tarea. Medio es el valor predeterminado. Alto, para refactors no triviales. Extra alto lo usas cuando una tarea realmente necesita razonamiento extendido: migraciones grandes, auditorías de seguridad, decisiones de arquitectura. Según Artificial Analysis, GPT 5.5 (xhigh) lidera actualmente su índice de inteligencia con 60, seguido por GPT 5.5 (high) con 59. El ajuste importa porque ahora puedes afinar el gasto computacional según la dificultad de la tarea, de maneras que antes estaban fuera de tu control.
Antes de pasar a las pruebas, hay un aspecto sobre precios y posicionamiento que necesitas entender, porque reformula todo lo que sigue.
Las matemáticas del precio y lo que revelan sobre la estrategia
GPT 5.5 sale al mercado a $5 por cada millón de tokens de entrada y $30 por cada millón de tokens de salida. GPT 5.4 costaba $2.50 y $15 respectivamente. Un aumento directo al doble. Si estás ejecutando una pila agentica de alto volumen, ese aumento impacta en tu presupuesto de inmediato.
Aquí está el argumento que hace que las cuentas cierren: GPT 5.5 utiliza significativamente menos tokens para completar las mismas tareas de Codex. Según la propia comunicación de OpenAI, la latencia por token es igual a la de GPT 5.4, mientras que el nivel de inteligencia sube de forma material. En otras palabras, el modelo es más eficiente, así que el costo bruto por tarea debería mantenerse igual o incluso mejorar, aun con el doble de costo por unidad.
Compáralo con Opus 4.7, que cuesta $5 por millón de tokens de entrada y $25 por millón de tokens de salida. Sobre el papel, Opus 4.7 es un 17% más barato en tokens de salida. En la práctica, Opus 4.7 incorpora un cambio en el tokenizador que incrementa el uso de tokens en torno al 35% en ciertas cargas de trabajo, según la cobertura de axios. Así que la afirmación de "más barato por token" empieza a desvanecerse en cuanto tu tokenizador consume más tokens por tarea idéntica.
Este es el auténtico enfrentamiento económico entre GPT 5.5 y Opus 4.7: ¿cuánto cuestan realmente sus tokens? Y, por ahora, ninguno de los que ejecutan cargas de trabajo reales tiene datos completos. He comenzado a registrar cada ejecución de Codex frente a su equivalente en Claude Code precisamente porque nadie en quien confíe ha publicado todavía la verdadera economía unitaria. (Si quieres el cara a cara que hice sobre cuatro builds de producción, lo detallé aparte en GPT 5.5 vs Opus 4.7 probado en builds de codificación reales).
Ahora, las pruebas. Empezando por la más sencilla, porque incluso en esa el resultado me sorprendió.
Prueba Uno: El Absurdo Unicornio SVG
Esta es la prueba que popularizó Simon Willison: pedirle a un modelo que genere un SVG de algo específico, sin herramientas externas, solo generación de texto en bruto de los trazados vectoriales. Es una prueba brutal porque SVG exige que el modelo represente mentalmente coordenadas y curvas antes de emitirlas. No hay un DOM al que hacer referencia, ni un modelo de imagen al que delegar. Solo geometría, en la cabeza, directo a la salida.
Le di a GPT 5.5 un único prompt en Codex: "Produce un SVG detallado de un unicornio encabritado sobre sus patas traseras, con crin fluida y musculatura visible. SVG puro, sin referencias externas."
Esfuerzo de inferencia: medio.
La salida tardó 38 segundos. Fueron 1,847 líneas de SVG. Cuando lo pegué en un navegador, lo que se mostró fue... realmente un unicornio. Encabritado. Con una crin fluida. La musculatura no era anatómicamente correcta —la curvatura de la pata delantera estaba algo fuera de sitio y la parte trasera parecía más de cabra que de caballo— pero la composición se entendía perfectamente a simple vista. Pude identificar el sujeto sin que nadie me dijera qué era.
Usé el mismo prompt en GPT 5.4 para comparar. Tardó 52 segundos, produjo 2,340 líneas, y el resultado parecía un unicornio dibujado por alguien que vio un caballo en un libro alguna vez. La crin terminaba en ángulos extraños. El cuerno estaba desconectado del cráneo a ciertos niveles de zoom.
Mismo prompt, peor resultado, más tokens, mayor tiempo de ejecución. Así se vende la eficiencia, en la prueba más simple imaginable.
Pero aún no me convencía. La generación de SVG es el tipo de tarea donde el corpus de entrenamiento importa enormemente, y si GPT 5.5 ha visto más ejemplos de SVG en el preentrenamiento, este resultado me habla de los datos, no del razonamiento. Así que pasé a la prueba que realmente pone a prueba la descomposición autónoma.
Prueba Dos: Juego Retro de Arcade Nativo para macOS con Sprites Generados por IA
El prompt: "Crea una app nativa para macOS — usando Swift y SpriteKit — que implemente un juego retro de biblioteca estilo arcade. El jugador controla a un bibliotecario que repone estantes de libros mientras esquiva libros que caen. Utiliza GPT Image 2.0 para generar todos los assets de sprites en tiempo de ejecución. Empaquétalo como un proyecto ejecutable de Xcode."
Esto sí es una verdadera prueba de esfuerzo. Se requiere que Codex logre:
- Crear correctamente el scaffolding de un proyecto nativo de Xcode para macOS
- Diseñar un loop de juego basado en sprites, con detección de colisiones
- Llamar a GPT Image 2.0 a través de su API para la generación de sprites
- Gestionar la carga asíncrona de imágenes en las texturas de SpriteKit
- Empaquetar todo para que compile y ejecute a la primera
Configuré el esfuerzo de inferencia al máximo, porque usar el nivel medio en esta tarea sería un optimismo temerario.
Codex funcionó de forma autónoma durante unos 11 minutos. Lo primero que noté —y esto sí fue un comportamiento genuinamente nuevo— es que Codex ejecutó sus propios ciclos de prueba. Compiló el proyecto, intentó lanzar el juego, encontró un error de inicialización de SpriteKit, diagnosticó el error revisando el resultado de su propia compilación, modificó el código de inicialización, recompiló y volvió a ejecutar. Hizo esto tres veces sin intervención humana. En GPT 5.4, esta misma tarea habría requerido que participara en al menos dos rondas de ping-pong de mensajes de error. En GPT 5.5, simplemente vi desfilar la terminal mientras tomaba café.
La build final se ejecutó. El sprite del bibliotecario se movía con las flechas del teclado. Los libros caían desde la parte superior de la pantalla. La detección de colisiones funcionaba. El loop del juego iba a unos 30 cuadros por segundo —no porque fuera el objetivo, sino porque la carga de sprites desde GPT Image 2.0 era el cuello de botella de toda la cadena.
Y ahí es donde apareció el primer gran límite. Cada llamada para generar un sprite impactaba el API de imágenes, que tardaba entre 8 y 14 segundos por sprite. Para cuando el juego tenía toda su colección de assets lista, había pasado más tiempo esperando texturas que código. Los sprites generados en sí lucían oscuros y algo caóticos: la cara del bibliotecario se renderizaba de forma diferente en cada partida, porque la generación de sprites ocurría en tiempo real y sin semilla predefinida. Funcionaba, pero no era apto para lanzarse. Quedaba entre una demo técnica y un prototipo.
Lo interesante aquí no es que el juego fuera tosco, sino que Codex se hizo cargo de todo el ciclo: scaffolding, implementación, integración de API, ciclos de debugging autónomos —todo sin requerir que yo descompusiera el trabajo en pasos. A eso se refiere la documentación cuando hablan de "agentic coding." No es que el modelo escriba mejor código, sino que ejecuta su propio trabajo.
Un consejo profesional: si quieres probar la capacidad agentica de cualquier modelo, elige una tarea que requiera autonomía en el uso de herramientas en un entorno que el modelo pueda realmente observar. Una tarea pura de generación de código no mide comportamiento agentico —mide traducción. Dale errores de compilación que tenga que leer y resolver, y verás si la autonomía es real o solo de fachada.
Ahora viene la prueba donde mis suposiciones quedaron públicamente humilladas.
Prueba Tres: Arena de Mazmorras 3D en Primera Persona
El prompt: "Construye un prototipo de arena de mazmorras 3D en primera persona. Three.js, TypeScript. Renderiza la escena 3D solo en el cuarto superior izquierdo del viewport. Los tres cuadrantes restantes muestran un HUD: minimapa, salud, inventario. Combate contra enemigos básicos. Lánzalo como un prototipo web ejecutable."
La restricción al cuarto de viewport es intencional. La mayoría de los tutoriales de juegos 3D asumen un renderizado a viewport completo. Limitar el renderizado a un cuadrante obliga al modelo a comprender las APIs de cámara, viewport y scissor de Three.js; no puede simplemente copiar y pegar la estructura de un tutorial y avanzar.
Esfuerzo de inferencia: extra alto. Quería ver el techo.
Codex estuvo ejecutándose durante 23 minutos. En ese tiempo:
- Estructuró correctamente un proyecto con Vite + TypeScript + Three.js
- Implementó controles de pointer-lock para el movimiento en primera persona
- Configuró la lógica de scissor/viewport para renderizar solo un cuarto del viewport
- Construyó meshes de enemigos y un bucle básico de pathfinding
- Conectó un minimapa que representa la posición del jugador en un canvas
- Implementó un sistema de combate con raycasting para la detección de impactos
- Solucionó de forma autónoma tres errores independientes de TypeScript
Cuando terminó, abrí localhost. La escena 3D se renderizaba en el cuadrante superior izquierdo. Podía moverme con WASD. El minimapa funcionaba. Los enemigos existían y reaccionaban cuando me acercaba. El raycasting de combate registraba los impactos. El HUD era... tosco. La barra de salud era un rectángulo gris. El panel de inventario era un texto placeholder vacío. Los meshes de los enemigos eran cubos con texturas faciales que no terminaban de encajar.
Funcionaba. Era jugable en el sentido literal. Pero no era comercializable en ningún sentido significativo. El salto entre “prototipo jugable” y “juego real” es exactamente el hueco que los humanos pasan semanas cerrando.
Aquí está la parte que cambió mi perspectiva. A mitad de la ejecución, Codex decidió por sí mismo añadir un overlay de depuración mostrando los rectángulos scissor. No lo pedí. Añadió el overlay, lo usó para verificar que su renderizado era correcto, y lo dejó en la salida final. Eso no es generación de código. Es una decisión de uso de herramientas que sugiere que el modelo tiene una representación interna de su propio flujo de trabajo: insertó un diagnóstico porque necesitaba uno para verificar su propia corrección.
Si consideras que eso es significativo o simplemente marketing depende de cuánto tiempo hayas pasado con stacks agenticos. Para mí, es la clave. Los modelos que se sienten genuinamente agenticos no son los que escriben más código. Son los que insertan sus propios pasos de diagnóstico en el ciclo sin que se les pida.
Si prefieres que alguien integre este tipo de flujo de trabajo autónomo potenciado por Codex desde cero en la pipeline de desarrollo de tu equipo, acepto encargos precisamente de este tipo — puedes ver lo que he lanzado en fiverr.com/s/EgxYmWD.
Lo que GPT 5.5 Realmente Hace Bien
Tres cosas, tras dos días de trabajo real.
El ciclo autónomo de depuración es real. Este es el mayor cambio. GPT 5.4 en Codex generaba código, fallaba y me entregaba el error. GPT 5.5 en Codex genera código, falla, lee el fallo, lo corrige y sigue adelante. Para trabajos con mucha iteración —cualquier cosa que implique builds, tests o errores en tiempo de ejecución— esto se multiplica de manera brutal. Una tarea que solía requerir “cinco rondas de prompt/error/reprompt” ahora se convierte en una ejecución ininterrumpida.
La eficiencia de tokens no es sólo marketing. Analicé el conteo de tokens de salida en ambos modelos con cuatro tareas equivalentes. GPT 5.5 promedió un 34% menos de tokens de salida para el mismo output funcional. El código no era más corto: era menos explicativo. Menos comentarios en línea. Espaciado más ajustado. Menos preámbulo tipo “esto es lo que voy a hacer”. Si esto es positivo o negativo a nivel estilístico depende de si vas a leer el código o solamente a entregarlo.
La ventana de contexto de 1M cambia lo que puedes pedir. Volqué el código fuente completo de una aplicación Laravel —240 archivos, aproximadamente 680 mil tokens— en Codex y le pedí que auditara el flujo de autenticación. Leyó todo y generó una auditoría que hacía referencia a firmas de métodos específicas en 14 archivos diferentes. Opus 4.7, en la misma tarea, alcanzó su límite de contexto y produjo una auditoría más vaga sobre sólo una parte de los archivos. No se trata de pura capacidad, sino de qué tareas pueden abordarse sin preprocesamiento.
Lo que GPT 5.5 todavía hace mal
Tres límites honestos.
Las tareas creativas complejas aún requieren supervisión. El prototipo de mazmorra funcionó en el sentido de que se ejecutaba. No funcionó en el sentido de que una persona pudiera jugarlo. La distancia entre "ejecución técnica" y "producto apto para lanzar" sigue siendo completamente del tamaño de un ser humano en todo lo que requiere criterio estético o juicio sobre el game-feel.
La inferencia extraalta es costosa y lenta. La tarea de la mazmorra en xhigh consumió muchos recursos computacionales y tardó 23 minutos. Si estás construyendo un ciclo de retroalimentación rápido, xhigh no es tu opción diaria. Medium es el valor predeterminado por una razón. Usaría xhigh para migraciones, auditorías de seguridad y decisiones de arquitectura, pero no para desarrollo de funcionalidades.
La integración de generación de imágenes tiene problemas de latencia. La prueba del juego en macOS se vio limitada por el tiempo de generación de sprites de 8 a 14 segundos con GPT Image 2.0. Si tu flujo de trabajo depende de la generación de imágenes en tiempo de ejecución, estarás a merced de la API de imágenes, no del modelo de lenguaje. No es un problema de GPT 5.5, pero sí un obstáculo inherente al flujo de trabajo con Codex que encontrarás de inmediato.
Qué significa esto para Anthropic, Claude y el panorama general
Quiero ser cuidadoso aquí, porque la especulación sobre la asignación de cómputo en los laboratorios de frontera es en su mayoría absurda, y la interpretación más benévola suele ser la correcta. Pero el patrón es difícil de ignorar.
Opus 4.7 salió con regresiones que una parte vocal de usuarios avanzados reportó de inmediato: un cambio en el tokenizador que incrementa el uso, menor profundidad de razonamiento por defecto y cambios en el comportamiento de seguimiento de instrucciones. Mythos, el modelo no publicado pero más potente de Anthropic, está restringido a un acceso muy limitado — pilotos en banca y gobierno. Anthropic ha negado públicamente que la reasignación de cómputo sea la causa de estas decisiones. No tengo motivos para dudarlo.
Pero aquí está lo observable: GPT 5.5 se lanzó ampliamente a usuarios de pago con una ventana de contexto de 1M y una pila de inferencia respaldada agresivamente por NVIDIA, ejecutándose en sistemas GB200 NVL72 capaces de 50 veces mayor rendimiento de tokens por megavatio que las generaciones anteriores. Eso sí es un despliegue de cómputo serio. Si estás en una carrera de capacidad y tu competidor acaba de lanzar un modelo ampliamente disponible, más barato por token de salida (considerando el efecto del tokenizador) y más rápido por tarea equivalente, la presión es real aunque nadie quiera admitirlo públicamente.
Para mí, como constructor, la conclusión práctica es esta: apuesta por el modelo que realmente está llegando hoy a producción, no por el que promete más sobre el papel. Eso, para la mayoría de trabajos con agentes de código, es GPT 5.5 ahora mismo. Opus 4.7 sigue siendo mi elección para escritura extensiva, revisión de código sutil y conversaciones de arquitectura. Mythos es irrelevante para mi flujo de trabajo porque no puedo usarlo. El modelo que no puedo ejecutar, no me puede ayudar a entregar.
¿Vale la pena la suscripción de GPT 5.5 Codex?
Depende de tu carga de trabajo. Si usas Codex a diario, la eficiencia de tokens sumada a los bucles autónomos de depuración justifican que el precio se duplique en la primera semana. Si eres un usuario ocasional, el salto de la versión 5.4 a la 5.5 no se sentirá dramático en prompts de un solo disparo: donde realmente destaca es en trabajos autónomos de varios pasos. Si gestionas una pila de agentes a gran escala, el contexto de 1M y el ajuste de razonamiento “xhigh” desbloquean categorías de tareas que antes eran imposibles; y esas son, por lo general, las de mayor valor.
La pregunta real sobre la suscripción sería: ¿cuál es el coste marginal de la tarea que le estás pidiendo al modelo en este momento? Si la respuesta es “el tiempo de un ingeniero senior a $150/hora”, la suscripción es trivial. Si la respuesta es “estoy aprendiendo con el plan gratuito”, el cálculo es distinto. En mi caso, la suscripción de Codex se pagó por sí sola en la primera semana, en builds que, de otra forma, habría tenido que subcontratar.
Preguntas Frecuentes
¿Cuándo se lanzó GPT 5.5 y quién puede usarlo?
GPT 5.5 se lanzó el 23 de abril de 2026 para usuarios de pago de ChatGPT en los niveles Plus, Pro, Business y Enterprise, con disponibilidad de API a $5 por millón de tokens de entrada y $30 por millón de tokens de salida. Viene integrado con Codex, el entorno de codificación agente de OpenAI. Consulta la sección de visión general del lanzamiento más arriba para conocer la ventana de contexto completa y el desglose de precios.
¿Cuál es la diferencia entre inferencia media, alta y extra alta en GPT 5.5?
Media es la configuración predeterminada de Codex, adecuada para la mayoría de tareas. Alta activa cadenas de razonamiento más profundas para refactorizaciones complejas y trabajo con múltiples archivos. Extra alta (xhigh) produce la salida de mayor calidad en problemas que realmente requieren razonamientos extendidos — migraciones grandes, análisis de seguridad, decisiones de arquitectura — aunque con una latencia y un coste significativamente mayores. Según Artificial Analysis, GPT 5.5 xhigh lidera su índice de inteligencia con 60 frente a 59 para alta. Consulta la prueba de dungeon arena más arriba para ver el rendimiento de xhigh en la práctica.
¿Cómo se compara GPT 5.5 con Claude Opus 4.7 para codificación?
GPT 5.5 lidera en benchmarks de codificación agentica (82,7% en Terminal-Bench 2.0 vs 69,4% para Opus 4.7) y recuperación de contexto largo. Opus 4.7 lidera en SWE-Bench Pro (64,3% vs 58,6%) y MCP-Atlas. El reparto práctico: GPT 5.5 para ejecución autónoma de flujos de trabajo, Opus 4.7 para refactorizaciones cuidadosas de bases de código y revisión de código. Hice una comparación directa en cuatro proyectos reales en el GPT 5.5 vs Opus 4.7 comparison.
¿Vale la pena la suscripción a GPT 5.5 Codex?
Para usuarios diarios de Codex, sí: la eficiencia de tokens y los bucles autónomos de depuración recuperan la inversión de la suscripción en la primera semana de trabajo no trivial. Para uso ocasional, la mejora es menos notable. El modelo destaca en tareas agenticas de varios pasos donde puede ejecutar sus propios ciclos de build/test/fix sin tu intervención. Consulta la sección "worth-it" más arriba para el análisis completo de coste-beneficio.
¿GPT 5.5 realmente puede crear juegos o solo prototipos?
Según las pruebas prácticas, GPT 5.5 genera prototipos jugables que funcionan sin errores, pero la brecha entre “ejecución técnica” y “producto lanzable” sigue siendo humana en tareas creativas que requieren criterio artístico o sensibilidad al game-feel. La prueba de dungeon arena produjo un prototipo 3D funcional en 23 minutos con razonamiento xhigh, pero el HUD, las texturas y el pulido general requirieron una iteración que solo un diseñador de juegos humano puede aportar.
Lo único que puedes hacer hoy
Olvida los benchmarks por un momento. Esta es la prueba que realmente haría si estás tratando de decidir si GPT 5.5 Codex merece estar en tu stack.
Elige una tarea que has estado postergando. Algo de varios pasos. Algo que normalmente te tomaría una tarde de concentración total. Una migración, un refactor, una funcionalidad que cruza tres módulos. Abre Codex. Configura el razonamiento en alto. Escribe la tarea como una única instrucción. Aléjate durante quince minutos.
Cuando regreses, sabrás exactamente lo que yo sé: si el bucle autónomo es real para tu flujo de trabajo o si es solo hype. Esa no es una pregunta para un benchmark. Es una pregunta para la tarde de un martes. Y es en los martes por la tarde donde se construyen las carreras.
El SVG del unicornio encabritado que generé el primer día sigue en una carpeta de mi portátil. Lo conservo ahí como recordatorio. Hace seis semanas, ese nivel de output en un solo intento habría sido un tuit viral. Hoy, es el mínimo. El techo aún no lo he alcanzado — y la única forma de averiguar dónde está es seguir lanzando prompts más retadores al bucle hasta que algo falle.
Así que ve y rompe algo. Y luego cuéntame qué encontraste.
Trabajemos Juntos
¿Buscas crear sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Estoy disponible para ayudarte.
- Fiverr (desarrollos e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Portafolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
