Dikaya Pro 2: revisar un cambio con pruebas concretas

Ejemplo mínimo de API

Código Python ilustrativo, no una respuesta real del modelo. La clave procede del entorno y los reintentos automáticos están desactivados. Una desconexión puede dejar resultado y coste desconocidos: no reintentes a ciegas.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "Crea una lista de comprobación para mi tarea. Separa hechos y suposiciones."}],
)
print(response.choices[0].message.content)

Elegir un fallo observable y un contrato estable

Tomemos una función que calcula el total de una cesta y aplica un descuento solo a ciertos productos. Describe una entrada que produce un total incorrecto y el valor esperado, con unidades y reglas de redondeo. Incluye la función, los tipos relevantes y un llamador representativo. Sin la regla del descuento, una corrección aparentemente limpia puede cambiar un comportamiento comercial que en realidad era intencionado.

Define también lo que no quieres modificar: formato de respuesta, moneda, almacenamiento o tratamiento de productos no elegibles. Pide que las dependencias no incluidas se consideren desconocidas. Es preferible recibir una pregunta concreta sobre una función ausente que una implementación inventada de esa función. Este límite mantiene la revisión centrada en el comportamiento que puedes comprobar, en lugar de convertirla en una reescritura general del proyecto.

Solicitar una prueba que falle por el motivo correcto

La primera prueba debe ejercer el cálculo real y comparar el resultado esperado con el obtenido. No basta con comprobar que se llamó a un sustituto o que existe una propiedad. Pide una explicación de qué defecto detectaría cada aserción. Si el test pasa incluso cuando se elimina el descuento, no está reproduciendo el problema que motivó la consulta y debe replantearse antes de tocar la implementación.

Añade casos vecinos que protejan reglas importantes: cesta vacía, producto no elegible y cantidad fraccionaria si tu dominio la permite. No busques una lista enorme por apariencia de cobertura. Cada caso debe justificar una frontera concreta. Conserva el fallo real de tu entorno, incluidos errores de tipos o importación, porque el modelo puede usar una API de pruebas que no existe en la versión instalada.

Revisar la corrección mínima y sus supuestos

Pide un cambio pequeño que haga pasar el caso reproducible sin alterar contratos ajenos. En el cálculo de cesta, comprueba el orden de descuento, redondeo y suma. Mover un redondeo puede cambiar resultados aunque la fórmula parezca equivalente. Exige que la explicación señale qué rama se modifica y qué ocurre con los casos protegidos. La claridad del razonamiento escrito no sustituye esas comprobaciones numéricas.

Examina las líneas eliminadas y los nuevos supuestos. Una validación que parece redundante puede proteger una entrada antigua; una utilidad añadida puede duplicar otra existente. Si falta información, conserva el punto abierto en el informe. Este procedimiento no afirma que Pro 2 sea superior para programar ni presenta una respuesta ficticia del modelo: describe cómo evaluar una propuesta sobre tus propios archivos y criterios.

Ajustar el ejemplo a las condiciones de la demostración

La demostración actual usa Pro 2 como opción textual y concede hasta tres solicitudes a las nuevas cuentas que cumplan las condiciones. Los límites anteriores se conservan mediante el registro de condiciones de cada cuenta. El contexto de demostración es de 6000 bytes y la salida de Pro 2 llega a 8192 tokens, incluido el razonamiento. Prepara un ejemplo breve pero completo, no fragmentos cortados sin sus contratos.

La configuración reasoning_effort=none de la demostración no garantiza cero tokens de razonamiento ni una respuesta final no vacía. Las solicitudes históricas a Flash mantienen compatibilidad con su límite propio de 512, sin renovar intentos. El gran contexto anunciado de Pro 2 no elimina estas restricciones, y pagar no reescribe el consumo pasado. Los niveles low, high y max de otras identidades tampoco se trasladan automáticamente a Pro 2.

Ejecutar las comprobaciones fuera del chat

Aplica la propuesta en un espacio de trabajo controlado y lanza primero la prueba de reproducción. Después ejecuta las comprobaciones relevantes del proyecto y revisa el diff completo. El chat muestra código, pero no ejecuta comandos en tu equipo. Si utilizas un cliente de desarrollo con herramientas, sus permisos y acciones pertenecen a esa integración; no debes atribuirlos al modelo como ejecución nativa demostrada por esta página.

Para una llamada Python controlada, el SDK documenta max_retries=0, que evita sus reintentos automáticos. Define también un límite explícito de salida. La documentación de Fetch distingue rechazo HTTP conocido de error de red; no establece el coste de una generación. Si se pierde la conexión, no concluyas que nada se procesó y no inventes una garantía de idempotencia pública para repetir una llamada incierta.

Entregar un informe que distinga hechos y pendientes

Cierra la revisión con cuatro datos: caso reproducido, cambio aplicado, comandos ejecutados y puntos no verificados. Escribe «no ejecutado» donde corresponda. Si la prueba falla por otro motivo, conserva su salida y revisa la hipótesis antes de pedir una nueva corrección. Este registro evita que una recomendación bien redactada se convierta en una afirmación falsa de éxito y facilita continuar desde el estado real del proyecto.

El traslado desde la guía solo prepara un borrador y un borrador guardado puede tener prioridad. Comprueba seller-pro-2 en el selector antes del envío. La demostración es textual; las imágenes de pago pasan por un puente textual separado, no por visión nativa de Pro 2. Si necesitas documentación reciente, la búsqueda explícita del navegador de pago no equivale a una herramienta de Internet incorporada a la API pública.

Preguntas y respuestas

¿Pro 2 y GLM 5.3 son intercambiables en las solicitudes?

No. seller-pro-2 es la identidad de la versión modificada basada en GLM-5.3, mientras que seller-glm-5-3 es otra entrada pública. Verifica el identificador exacto, los permisos y sus parámetros. La base relacionada no demuestra igualdad de respuestas, ajustes, precios ni condiciones de demostración entre ambas identidades del catálogo.

¿Qué código conviene enviar en la primera consulta?

Una función pequeña, sus tipos necesarios, la regla de negocio y una entrada que reproduzca el fallo. Incluye el resultado esperado y los comportamientos que no deben cambiar. Ese conjunto permite juzgar una propuesta de forma concreta y cabe mejor en la demostración que un proyecto grande cortado sin contexto suficiente.

¿Un test escrito por el modelo confirma la corrección?

No hasta que lo revises y ejecutes en tu entorno. Comprueba que utiliza la función real, que falla por el defecto adecuado y que las aserciones protegen el contrato. Después prueba la corrección y las regresiones relevantes. El texto de una explicación o una lista de comandos no constituye evidencia de ejecución.

¿Puede interpretar una captura del error en la demostración?

La demostración sigue siendo textual. En el acceso de pago, una imagen para Pro 2 utiliza una etapa independiente de descripción textual y tiene coste separado; no es visión nativa. Para errores de compilación o pruebas, copiar el mensaje y la traza relevantes suele preservar mejor el contenido exacto que una captura.

Fuentes

Contenido preparado con ayuda de IA. Los ejemplos son ilustrativos, no respuestas reales ni pruebas comparativas. Las fuentes externas no sustituyen las condiciones del servicio.

• Documentación de Dikaya: solicitudes y límites
  dikaya.cc
• Catálogo de Dikaya: modelos y modalidades
  dikaya.cc
• Precios de Dikaya: condiciones del cálculo
  dikaya.cc
• SDK de Python de OpenAI: reintentos automáticos
  github.com
• MDN: Fetch, respuestas HTTP y errores de red
  developer.mozilla.org