xxwzkdwz/astra-cost-preview-skill

Task Cost Preview · Cotización previa

El usuario describe lo que quiere hacer → Astra evalúa el alcance y la carga de trabajo → se presentan cotizaciones Estándar y Fast simultáneamente → el usuario elige antes de comenzar. El núcleo es una cotización previa, no una auditoría posterior, ejecución automática o un artículo extenso sobre costos.

Al usar esta Skill para cotizar, solo se cotiza por defecto. Incluso si el usuario dice "Crea un juego, primero haz una estimación", se debe dar la cotización primero y esperar a que elija; solo si dice explícitamente "cotiza y hazlo directamente" se continúa dentro de la autorización original. La cotización en sí misma consume una pequeña cantidad de uso del modelo, no se garantiza que sea de costo cero.

"Preguntar a Astra" significa que la instancia real de Astra evalúa según la información disponible, no que exista una interfaz interna de cotización del modelo. Cuando el modelo actual no es Astra o la identidad es desconocida, no se finja que ya se ha preguntado a Astra; se puede indicar claramente como "estimación según tarifas de Astra". Esta Skill no cambia de modelo, crea asistentes ni inicia otra solicitud de modelo paga por sí misma.

Definir el alcance

• Priorizar el modelo, canal de facturación, nivel de velocidad y alcance de la tarea proporcionados explícitamente por la herramienta actual; no adivinar a partir de que el usuario diga "tú eres Astra" o del estilo de escritura del modelo. Marcar como desconocido cuando falte, o enumerar escenarios con nombres explícitos para la estimación.
• Distinguir entre montos de API, créditos de Codex, cuotas incluidas en la suscripción y costos internos del proveedor. El monto equivalente de API no es el cobro real al usuario; los créditos no son el porcentaje de cuota restante; los costos internos del proveedor no se pueden deducir del precio de venta público.
• Consultar las tarifas oficiales actualmente aplicables, registrar la URL, la fecha de verificación, el modelo, el canal y la unidad de facturación. Reutilizar la información ya verificada en esta ronda, no buscar de nuevo extensamente para cada cotización. Si no hay tarifas disponibles, escribir "desconocido"; no memorizar precios fijos ni asumir que es gratuito.
• Priorizar la documentación oficial y las herramientas directas. Referencias de OpenAI: página de modelos https://developers.openai.com/api/docs/models/gpt-6-astra, precios de API https://developers.openai.com/api/docs/pricing, precios de Codex https://developers.openai.com/codex/pricing, uso de razonamiento https://developers.openai.com/api/docs/guides/reasoning. Las tarifas cambian, los enlaces no son prueba de verificación.

Estimar el uso de la tarea

Primero, definir el alcance de la entrega en una oración, por ejemplo: "Un juego de plataformas web horizontal jugable de un nivel, con monedas, enemigos, reinicio y pruebas básicas, sin incluir publicación". Evitar mezclar prototipos simples con productos comerciales completos dentro del mismo rango de cotización. Realizar solo comprobaciones de solo lectura mínimas; no ejecutar la tarea completa, hacer llamadas de prueba pagas ni iniciar un nuevo asistente para estimar.

Combinando el contexto visible, el tamaño de los archivos, los viajes de ida y vuelta de la herramienta, la longitud de la entrega, las iteraciones planificadas y los registros de tareas similares realmente disponibles, predecir los usos más probable, más bajo y más alto respectivamente. El usuario verá primero el valor estimado más probable, acompañado de un rango de variación razonable, no solo un rango enorme desde el precio mínimo al máximo.

La forma de reducir el rango es aumentar la evidencia, no comprimir mecánicamente: priorizar la coincidencia del uso real de tareas similares, ajustar la longitud del contexto actual, la capacidad de la herramienta, la disponibilidad de caché y los requisitos de entrega; cuando no haya registros, hacer una estimación de carga de trabajo por fases. Un solo caso histórico puede servir como analogía, pero no representa una precisión verificada; no se puede disfrazar el costo medido de una tarea recién completada como un resultado predicho anteriormente. El valor más probable debe provenir de un escenario de carga de trabajo claro, no puede ser automáticamente el promedio de los límites superior e inferior.

Si el rango sigue siendo amplio, identificar la ambigüedad que más afecta el resultado y hacer una pregunta breve para acotarla, o dar explícitamente dos cotizaciones: una para la versión pequeña y otra para la versión completa. Si aún faltan datos clave, admitir que la estimación es aproximada y no inventar certeza solo para que el "rango sea pequeño". Sin respaldo de datos, no afirmar "error inferior al 20%" ni dar niveles de confianza estadísticos.

Tener en cuenta al facturar:

• Las solicitudes múltiples repiten el historial, los resultados de herramientas y las nuevas entradas; no se puede contar solo la oración del usuario.
• Distinguir entre entrada no almacenada en caché y almacenada en caché; cuando se desconoce la tasa de acierto, usar el escenario sin caché o calcular por separado, no garantizar el acierto.
• La salida debe cubrir los tokens de razonamiento facturables y otros tokens de generación facturables, no solo el texto visible final. Si usage.output_tokens ya incluye reasoning_tokens, no se pueden sumar estos últimos nuevamente.
• Los umbrales de contexto largo, velocidad, nivel de servicio, escritura de caché, etc., se verifican por solicitud según el canal y luego se resumen; no se pueden acumular tokens de toda la tarea y aplicar incorrectamente el umbral de una sola solicitud, ni mezclar las tasas de API y Codex.
• Enumerar por separado el uso adicional de generación de imágenes, video, voz, búsqueda, contenedores, otras herramientas del proveedor y asistentes autorizados. Los elementos no cotizados escriben "desconocido"; no se puede usar un subtotal de partes conocidas para hacerse pasar por el costo total.
• Solo se pueden usar datos de uso dentro del alcance de la tarea y accesibles para el usuario. No leer credenciales, escanear chats irrelevantes ni inferir el costo de esta tarea a partir de cambios en la cuota compartida de la cuenta; otras tareas y restablecimientos de cuota pueden interferir.

Cotización y continuación

Por defecto, generar una pequeña tabla de cotización, manteniendo el idioma actual del usuario:

Tarea: una oración clara con versión y alcance de entrega.

| Nivel | Estimación principal | Rango estimado | | Estándar | Aprox. X créditos | L–H créditos | | Fast | Aprox. Y créditos | A–B créditos |

Base: una o dos suposiciones de carga de trabajo/caché más importantes; elementos no incluidos o riesgos especiales. En la primera vez o cuando falten datos, indicar "Estimación no calibrada, no es un cobro real".

Elige Estándar o Fast para comenzar.

X/Y son marcadores de posición de formato; deben reemplazarse con números calculados según la tarea y las tarifas verificadas, no copiarse. Por defecto, redondear razonablemente; no usar decimales para fingir precisión de predicción. Si no se puede calcular un nivel, mantener esa fila y explicar "desconocido"; no omitir silenciosamente Fast.

Al comparar los dos niveles, usar el mismo alcance de entrega y las mismas suposiciones de carga de trabajo; solo comparar las tarifas aplicables; a menos que haya evidencia, no asumir que Fast es más potente, tiene menos tokens o tiene un tiempo de finalización determinado. La tasa Fast para créditos de Codex y montos de API puede ser diferente; verificar por separado. Aplicar la tasa solo a los costos del modelo aplicable; imágenes, herramientas de terceros, etc., se cobran según sus propias tarifas; no multiplicar el precio total por la tasa Fast.

Por defecto, esperar a que el usuario elija o confirme; si el anfitrión no puede cambiar de nivel a través de las herramientas disponibles, indicar que el usuario debe cambiar; no fingir que Fast ya está activado. La confirmación relacionada con costos no reemplaza los requisitos de permisos de la tarea en sí. No reducir los estándares de aceptación, agregar interfaces de pago nuevas ni delegar tareas.

Cuando el usuario establezca un presupuesto, primero confirmar la unidad y el alcance incluido. Si la estimación supera el presupuesto o el costo clave es desconocido, preguntar antes de la siguiente operación paga controlable. Una Skill por sí sola no puede detener forzosamente una solicitud de modelo en ejecución, una tarea de generación externa o un asistente concurrente; no se puede garantizar que no se exceda. Un presupuesto estricto requiere medición e interceptación en la capa de ejecución real; no se falsifica en esta Skill.

El recálculo posterior solo se realiza cuando el usuario lo solicita, no debe adelantarse al flujo principal de cotización previa. Cuando haya un uso confiable a nivel de tarea, informar "uso medido"; el monto calculado según las tarifas sigue siendo "estimación de tarifa"; el cobro formal se basa en la factura. Sin datos, escribir "no obtenido". Solo persistir registros de calibración anonimizados cuando el usuario lo solicite.

Calculadora local opcional

Para sumar múltiples elementos, usar python3 scripts/calculate.py quote.json. Es puramente offline, no llama al modelo, no lee la cuenta, no recolecta tokens ni verifica si las tarifas están actualizadas.

Campos de entrada JSON:

• unit: USD, CNY o credits, uniforme en toda la tabla; diferentes monedas se calculan por separado, sin conversión implícita.
• items: cada elemento incluye name, quantity: [low, high], expected_quantity, rate, basis, source, as_of. expected_quantity es la cantidad más probable con evidencia, debe estar dentro del rango; si se desconoce o se omite, no tomar automáticamente el punto medio.
• quantity es el rango de cantidad de la unidad de facturación explícita; rate es la tarifa aplicable por unidad (ya verificada y procesada por canal/tasa); basis explica la unidad, modelo, canal y base de la cantidad; source es el enlace oficial o la fuente de tarifa indicada explícitamente por el usuario; as_of es la fecha de verificación de la tarifa en formato YYYY-MM-DD.
• Si la cantidad o la tarifa son desconocidas, usar null, no 0. Admite múltiples escenarios, modelos o herramientas, pero no duplicar la facturación.
• Para cotizar dos niveles simultáneamente, establecer compare_fast: true en el nivel superior, y dar fast_rate adicional para cada elemento; la tasa aplicada es verificada por el llamante según el canal actual. Para tarifas de herramientas fijas, fast_rate es igual a rate; si falta la tasa Fast, se trata como desconocida. Ambos niveles usan el mismo conjunto de escenarios de cantidad.

La salida distingue subtotal de elementos conocidos, rango total estimado y valor más probable; mientras haya elementos desconocidos, el total estimado estará vacío. La integridad aún depende de si has enumerado todos los elementos; que el cálculo pase no significa que la predicción sea precisa. Prueba: python3 -m unittest discover -s scripts -p 'test_*.py'.