Modelo de datos y evidencia
Unas cuantas convenciones recorren todos los endpoints. Compréndelas una vez y toda la API se leerá con claridad.
Entidades
| Entidad | Qué es |
|---|---|
| Modelo | Una identidad canónica de modelo (p. ej. gpt-oss-120b), normalizada entre el dialecto de cada proveedor. |
| Proveedor | Quién sirve realmente la inferencia (Fireworks, Together, una nube). Se clasifica en el tablero de confianza de proveedores. |
| Agregador / Enrutador | Un mercado que enruta entre proveedores (OpenRouter, HuggingFace, 0G, Novita, Requesty). Se clasifica en el tablero de agregadores. |
| Oferta | Un punto de precio (modelo × proveedor × enrutador), con precios, ventana de contexto y una etiqueta de evidencia. |
Etiquetas de evidencia
Cada oferta indica cómo conocemos sus cifras. Esta es la columna vertebral de la credibilidad de TKX.
| Etiqueta | Significado |
|---|---|
| official | Precio de lista publicado por el proveedor (tarjeta de tarifas). |
| api | Leído desde la API pública en vivo del proveedor. |
| probe | Medido por un sondeo de TKX (TTFT / TPS / disponibilidad reales). |
| self | Autoinformado — siempre posicionado más abajo, nunca tratado como verdad. |
IDs canónicos de modelo
Los proveedores nombran el mismo modelo de una docena de formas. TKX los normaliza a un único id canónico para que una sola fila de modelo agregue a todos los proveedores que lo sirven. Usa el id canónico como parámetro de ruta para el detalle del modelo.
Precio blended
Para clasificar un modelo con un único número usamos un precio blended ponderado hacia la salida, que domina el costo real:
blended = (3 × input_per_1M + output_per_1M) / 4Niveles: live vs listed
Los agregadores llevan un tier: live significa que TKX ingiere sus datos reales ahora; listed significa que se rastrea pero aún no está integrado (se muestra, pero nunca se puntúa con cifras fabricadas).