Claude vs GPT-4 vs modelos open-source para atención al cliente: cuándo usar cada uno

“¿Con qué modelo hacemos el agente?” es la pregunta incorrecta. La correcta es “¿qué restricciones tengo y qué experiencia quiero entregar?“. Con eso en mano, el modelo casi se elige solo.

Este post es cómo lo pensamos en Dynecron cuando nos toca elegir stack de IA para proyectos de customer support.

Las dimensiones que sí importan

1. Costo por request

Para un agente de soporte con RAG (entre 1.500 y 4.000 tokens por turno, incluyendo contexto recuperado):

Claude 3.5 Sonnet: ~US$0.005–0.015 por turno. Razonamiento fuerte y buen tool use.
GPT-4o: ~US$0.010–0.020 por turno. Latencia menor en streams cortos, con output un poco más “chatty”.
Claude Haiku 3.5: ~US$0.001–0.003 por turno. Excelente para clasificación e intent, menos robusto en generación de respuestas matizadas.
Llama 3.1 70B self-hosted: costo fijo de infra (GPU) + operación. Rentable a partir de ~20K requests/mes si ya tienes plataforma.

2. Tool use y structured output

Para un agente que llama a APIs internas (consultar orden, consultar stock, escalar a humano), la calidad de tool use importa más que la calidad del prompt.

Nuestro ranking empírico en 2026, de más robusto a menos:

Claude 3.5 Sonnet — no inventa herramientas, respeta schemas, maneja bien ambiguación.
GPT-4o — muy bueno, pero más propenso a “llamar algo por si acaso”.
Llama 3.1 — viable con prompt engineering serio, sensible a cambios de versión.

3. Latencia

Para UX tipo chat en web, lo que pide el usuario es primer token <1 segundo. En ese eje:

GPT-4o y Claude Sonnet están en el orden de 300–700 ms primer token con API streaming.
Modelos open-source hosteados dependen de tu infra: con vLLM en GPU decente, 400–900 ms.
Modelos pequeños en edge (Llama 3.1 8B o Mistral 7B) pueden dar 100–300 ms pero con calidad menor en reasoning.

4. Soporte multilingual

Para clientes LATAM con operaciones en español y portugués, Claude y GPT son ambos fuertes. En quechua, kichwa y otras lenguas regionales el panorama es más pobre; ahí evaluamos traducción intermedia + modelo grande.

5. Cumplimiento / residencia de datos

Si los logs no pueden salir del país o de la red del cliente, los modelos propietarios vía API quedan fuera a menos que tengan deployment regional (AWS Bedrock tiene Claude en varias regiones). Con datos altamente sensibles (historias clínicas, PCI), la respuesta suele ser Llama o Mistral self-hosted.

Cómo los combinamos

El error común es elegir un único modelo para toda la operación. Nosotros mezclamos:

Router con Haiku o un clasificador pequeño para decidir intent y rutear.
Generación con Sonnet o GPT-4o para el turno del usuario.
Validación con un modelo pequeño que revisa outputs antes de escalar a humano o tomar acciones destructivas.

Esto abarata costo y hace más auditable el sistema.

Lo que no cambió

Elegir el modelo sigue siendo 20% de la solución. Los otros 80% son: qué contexto pasas, cómo cortas tu documentación, qué herramientas expones y cómo evaluás continuamente los outputs. Un agente con Llama bien armado gana por paliza a un GPT-4o conectado a documentación sucia.

Si estás arrancando en 2026 y no tienes fuerte opinión previa, nuestro default es Claude 3.5 Sonnet como generador y Haiku como clasificador. Con ese combo se construye un MVP convincente en semanas.