Al 29 de abril de 2026, una OpenAI Platform API key puede crearse sin pagar en el momento de creación. Eso no significa que el uso oficial del backend API sea gratis e ilimitado. Cada request queda controlada por organization, project, billing state, credits, model access, usage limits y rate limits detrás de esa key.
| Route | Owner | Payer | Safe use | Check first |
|---|---|---|---|---|
| OpenAI Platform API | Your OpenAI org and project | Your API billing account, credits, or prepaid balance | Production API and controlled tests | Billing, model access, usage limit, rate limit |
| ChatGPT app access | Consumer app account | plan gratuito, Plus, Pro o workspace quota | Manual app work, not backend calls | App plans do not become API billing |
| Trial credit | Specific Platform account | Credit first, paid balance later if enabled | Short official test | Balance, expiry, allowed models |
| Provider route | Third-party provider | Provider credit, plan, or your provider bill | Non-sensitive evaluation | Owner, price unit, data terms, support |
| User-pays route | SDK/platform plus end user | End user at runtime | Bring-your-own account or session apps | Consent, privacy, abuse controls |
| Open-weight model route | Host, community, or self infrastructure | Host, community, or you | No-cost experiments | Model identity and host limits |
| Copied key or generator | Unknown or exposed owner | Unknown, often someone else's account | Reject | Key ownership, logs, malware, billing risk |
La regla de parada es sencilla: si una ruta no muestra quién posee la key, quién paga después de la acción gratis, qué límites aplican, qué términos cubren prompts y outputs y quién atiende fallos, no la uses con datos reales ni código de producción.

Una API key es una credencial, no una quota
Una OpenAI Platform API key autentica una request dentro de un project. No crea una cuota gratis separada, ni un presupuesto oculto, ni acceso independiente a modelos. El resultado lo deciden project, organization, role, billing, credits, model access, usage limit y rate limit.
Por eso una key recién creada puede devolver un error de quota o billing. El secret puede ser válido, pero el project puede no tener usable credit, el modelo pedido puede no estar habilitado, el spend cap puede estar agotado o una dimensión de rate limit puede estar llena. Rotar la key mejora seguridad; no multiplica uso.
Mantén el secret en el servidor. Usa una variable de entorno como OPENAI_API_KEY o un secret manager. No lo pongas en un repositorio público, front-end bundle, screenshot, notebook compartido ni browser extension. Si staging y production usan projects distintos, etiqueta las keys para que usage y billing sigan siendo trazables.
Los roles del equipo también importan. Un developer puede crear keys en un project y no tener acceso a otro. Las service-account keys deben estar limitadas y revisarse. Si el código local funciona y production falla, mira primero el owning project, role, billing y limits antes de reescribir la integración.
Qué es gratis y qué se paga
Lo gratis es la creación de la key. El API usage es una decisión de billing y limits. La página actual de pricing de OpenAI es el lugar oficial para verificar precios de modelos, y prepaid billing es la vía para comprar API credits por adelantado. OpenAI Help describe actualmente una compra mínima de 5 dólares para prepaid API credits. Eso hace que el inicio oficial sea de bajo coste, no ilimitado.
Los trial o promotional credits son account-specific. No asumas que cada cuenta recibe el mismo saldo, caducidad o cobertura de modelos. Revisa la Platform billing page del propietario del project y fecha la afirmación antes de usarla en planificación.
Rate limits y usage limits son cosas separadas. Rate limits controlan throughput de requests y tokens; usage limits controlan spend. Una request puede fallar por cualquiera de esas capas. Crear otra key dentro del mismo project suele mantener el mismo owner y los mismos limits.
El acceso a la app de ChatGPT no es API credit
Los planes de la app de ChatGPT y OpenAI Platform billing son superficies separadas. Una persona puede usar un modelo manualmente en la app y aun así no tener balance usable para backend API. Un plan Plus o Pro mejora la experiencia de la app; no paga automáticamente server calls.
Usa la app cuando una persona trabaja dentro de ChatGPT. Usa Platform API cuando una aplicación envía requests, maneja errors, guarda outputs, registra usage y paga mediante un API project. Si un workflow usa ambos, controla dos presupuestos y dos conjuntos de limits.
Esta separación explica muchas preguntas de quota. La suscripción de la app no se transforma en financiación del API. El API project tiene su propio estado de credit, billing y limits. Diagnostica ese estado directamente.
Clasifica cada alternativa que parece gratis

Una provider route puede ofrecer trial credit, endpoint compatible o free model. Puede ser útil para evaluación, pero es la ruta del provider. El provider posee price unit, mapping, logs, failure behavior y support. Llámalo provider evaluation, no official OpenAI free usage.
Una user-pays route puede tener sentido cuando cada end user trae de forma intencional una session, account o relación de pago. No es gratis para todo el sistema; solo mueve el payer. El producto debe explicar consent, privacy, abuse handling y qué ocurre cuando se agota la quota del usuario.
Los free open-weight models resuelven otro problema. Ayudan cuando el objetivo es experimentación sin coste o self-hosting, no cuando el requisito es comportamiento de OpenAI Platform API. Model identity, context window, data policy y host limits aún deben verificarse.
Las copied keys y páginas de generator deben rechazarse. Una respuesta que funciona no prueba permission, safe logging, durable access ni billing ownership. Puede probar solamente que una credential expuesta todavía no fue revoked.
El test oficial seguro más pequeño

La ruta oficial segura es pequeña: crea tu propia Platform key, guárdala como secret, verifica billing o credit, define un project usage limit bajo, llama un modelo habilitado de bajo coste con un prompt mínimo y luego abre la usage page para confirmar que la request se cargó donde esperabas.
Si la request falla, lee el owner del error. Billing, quota, model access, permission y rate-limit errors tienen arreglos distintos. No sigas generando keys salvo que la key esté leaked o mal scoped.
Antes de producción, agrega server-side secret storage, budget alerts, low caps, logging y un fallback visible para quota o billing failures. Mantén los primeros tests sin datos sensibles hasta entender data handling y retention.
Regla de decisión
Elige OpenAI Platform API cuando necesitas first-party API behavior, project controls, official docs y production ownership. Elige ChatGPT app access para trabajo manual. Elige provider route solo cuando owner, payer, limits, terms y support son suficientemente claros para el riesgo. Elige user-pays solo cuando el producto está diseñado explícitamente alrededor de user consent y user billing. Elige open-weight free models para experimentos sin coste, no como entitlement de OpenAI.
Rechaza copied keys y generators. Convierten una pregunta de coste en un incidente de security, privacy, billing y reliability.
FAQ
¿Puedo crear una OpenAI API key gratis?
Sí, la creación de la key puede ser gratis. El uso sigue dependiendo de billing, credits, model access, project permissions, usage limits y rate limits.
¿Un plan pagado de ChatGPT incluye API credit?
No. Los planes de la app de ChatGPT y Platform API billing son separados. El acceso a la app no financia automáticamente backend API calls.
¿Los trial credits de OpenAI son universales?
No. Trata los credits como account-specific y volátiles. Revisa Platform billing page para balance, expiry, allowed models y paid fallback.
¿Un endpoint gratis de provider es uso oficial gratis de OpenAI?
No. Es un provider contract separado con su propio price unit, limits, data terms y support.
¿Son seguras las keys públicas de GitHub?
No. Public keys y generators no prueban ownership, permission, billing control ni data safety.
¿Qué revisar después de un quota error?
Revisa project billing state, credit balance, model access, usage limit y rate limits antes de crear otra key.



