API Gateway Prompt Collection: Turn Real LLM Usage Data Into Better Onboarding, Quotas, and Model Selection

Running an API gateway to many AI models sounds like a clean developer pitch: one endpoint, many models, instant choice. But real usage often tells a sharper story. In the reported gateway experiment, 15 Chinese AI models were available, yet 62% of playground calls went to one model: Kimi K3. A generous 500K free-token monthly tier looked like a growth lever, then doubled as an unplanned load test. Meanwhile, 68% of registered users never made a single API call after getting a key.

That is the useful part. The problem is not simply model routing or token pricing. It is developer activation, trust, default model selection, quota enforcement, and product clarity.

This curated prompt collection is built for API gateway operators, developer tooling teams, and founders managing multi-model AI platforms. Use these prompts with your own usage logs, onboarding copy, quota rules, and API documentation to turn raw behavior into practical changes.

Concept & Theory

A multi-model AI gateway usually fails in boring places before it fails in sophisticated ones.

Developers do not care about 15 models until the first request works. They care about a clean API key flow, a copy-pasteable curl command, a default model that succeeds, clear errors, predictable quotas, and documentation that matches reality. Model diversity matters later, when users start comparing latency, context length, output quality, cost, and domain performance.

The context here points to three core lessons:

Default experience beats model count. If most users choose Kimi K3 in the playground, the gateway needs to treat that as a product signal, not an embarrassment. The first visible working path matters more than a broad catalog.
Free tiers are operational tests. A 500K token monthly allowance can reveal quota races, retry storms, abuse patterns, and unexpected infrastructure costs. It is not just marketing.
API key creation is not activation. If 68% of users never make an API call, the onboarding funnel has a serious drop-off between registration and first successful request.

The prompts below help you investigate those realities. They are intentionally specific, because vague product prompts produce vague advice. Paste real logs, metrics, docs, and user messages where the variables indicate.

The Prompts

Prompt 1: First Successful API Call Funnel Audit

Use this when many users register, create an API key, and disappear before sending their first request.

You are a senior developer experience analyst reviewing an AI API gateway onboarding funnel.

Context:
We run a single API endpoint that provides access to multiple Chinese AI models, including DeepSeek and Kimi K3. In our first month, a large share of registered users created an API key but never made a successful API call. The product originally emphasized model count, but real usage suggests users care more about seeing one model work quickly.

Your task:
Audit the onboarding path from registration to first successful API call. Identify friction, missing trust signals, unclear instructions, and likely reasons a developer would stop after key creation.

Input data:
- Registration-to-key-created conversion: {{registration_to_key_rate}}
- Key-created-to-first-call conversion: {{key_to_first_call_rate}}
- First-call success rate: {{first_call_success_rate}}
- Median time from registration to first call: {{median_time_to_first_call}}
- Top API errors for first-time callers: {{first_time_error_logs}}
- Current onboarding page copy: {{onboarding_copy}}
- Current quickstart docs: {{quickstart_docs}}
- Current playground UI text: {{playground_text}}
- Current default model: {{default_model}}
- Most-used playground model: {{most_used_playground_model}}
- SDKs or examples available: {{available_examples}}

Analyze the funnel in this order:
1. Diagnose the biggest activation bottlenecks.
2. Explain which bottlenecks are copy problems, product flow problems, API design problems, or trust problems.
3. Identify what should be visible immediately after a user creates an API key.
4. Rewrite the first-run experience as a concise developer journey.
5. Produce a replacement quickstart that gets a user to a successful request in under five minutes.
6. Suggest instrumentation events we should add to confirm whether the fixes work.

Constraints:
- Do not recommend adding more models as the primary fix.
- Assume developers want a working request before reading a model catalog.
- Keep recommendations practical for a small engineering team.
- Use plain language suitable for a developer tools product.

Output format:
## Diagnosis
## Highest-Impact Fixes
## Revised First-Run Journey
## Five-Minute Quickstart
## Instrumentation Plan
## Risks and Tradeoffs

Prompt 2: Multi-Model Gateway Usage Pattern Analysis

Use this to understand why one model dominates usage and whether your catalog is helping or confusing users.

You are an AI product analyst specializing in multi-model API gateways and developer platforms.

Context:
Our gateway offers access to 15 Chinese AI models through one endpoint. We launched with model variety as the headline. After one month, usage data showed that 62% of playground calls went to a single model: {{dominant_model}}, currently Kimi K3 in our observed data. We need to understand whether this concentration is healthy default behavior, weak model discovery, poor documentation, or a sign that the remaining models are not clearly positioned.

Input data:
- Model list and descriptions: {{model_catalog}}
- Playground call distribution by model: {{playground_distribution}}
- API call distribution by model: {{api_distribution}}
- Median latency by model: {{latency_by_model}}
- Error rate by model: {{error_rate_by_model}}
- Cost or internal token expense by model: {{cost_by_model}}
- User-selected task categories, if available: {{task_categories}}
- Example prompts submitted in playground: {{sample_playground_prompts}}
- Current model picker UI text: {{model_picker_copy}}
- Current default model logic: {{default_model_logic}}

Your task:
Analyze the model usage pattern and recommend a clearer model selection experience.

Important distinction:
Do not assume concentration on one model is bad. A strong default model can be good if it helps new users succeed. The goal is to determine when users need choice, how to explain that choice, and how to avoid making the first experience feel like homework.

Please provide:
1. A diagnosis of why {{dominant_model}} receives most calls.
2. A model positioning matrix using real available information from the input only.
3. A recommendation for the default model experience.
4. A simplified model picker structure for developers.
5. Suggested labels that explain models by use case, not vendor hype.
6. Experiments to test whether model discovery improves.
7. Metrics that separate healthy default usage from harmful model lock-in.

Constraints:
- Do not invent benchmark scores.
- Do not invent capabilities not present in the input.
- Avoid generic claims like 'best for reasoning' unless supported by data.
- Focus on practical gateway UX, documentation, and API defaults.

Output format:
## Executive Summary
## What the Usage Pattern Probably Means
## Model Positioning Matrix
## Recommended Default Behavior
## Model Picker Redesign
## Experiment Backlog
## Metrics to Watch

Prompt 3: Free Tier Quota and Abuse Review

Use this when a free-token allowance is causing surprising load, quota races, or edge-case overages.

You are a backend reliability and abuse-prevention reviewer for an AI API gateway.

Context:
We offer a free tier of {{monthly_free_tokens}} tokens per month with no credit card required. We expected this to reduce signup friction. In practice, the free tier also became a live load test. A small number of users exceeded the intended quota because the quota check had a race condition. Some accounts reached {{highest_observed_usage}} tokens before enforcement caught up.

Your task:
Review the free tier design from an engineering, product, and abuse-prevention perspective. Recommend changes that preserve developer friendliness while making quota enforcement reliable.

Input data:
- Monthly free-token quota: {{monthly_free_tokens}}
- Number of users above quota: {{users_above_quota}}
- Highest observed usage: {{highest_observed_usage}}
- Current quota enforcement design: {{quota_enforcement_design}}
- Current request flow: {{request_flow}}
- Current database or cache used for counters: {{quota_counter_storage}}
- Concurrency model: {{concurrency_model}}
- Retry behavior: {{retry_behavior}}
- Rate limits, if any: {{rate_limits}}
- Abuse signals observed: {{abuse_signals}}
- Current error response for quota exceeded: {{quota_error_response}}
- Current free tier messaging: {{free_tier_copy}}

Analyze the system in this order:
1. Identify the likely race condition failure modes.
2. Explain where quota should be checked, reserved, finalized, and refunded if needed.
3. Recommend a safer quota accounting strategy.
4. Recommend rate limits that reduce abuse without blocking normal evaluation.
5. Rewrite quota-exceeded errors so developers know what happened.
6. Suggest operational dashboards and alerts.
7. Suggest a migration plan that does not surprise legitimate users.

Constraints:
- Do not suggest requiring a credit card as the only solution.
- Keep the free tier usable for real evaluation.
- Do not recommend vague 'AI abuse detection' without concrete signals.
- Prefer simple, auditable quota logic over complex black-box systems.

Output format:
## Failure Mode Analysis
## Safer Quota Accounting Design
## Rate Limit Recommendations
## Developer-Facing Error Copy
## Monitoring and Alerts
## Migration Plan
## Open Questions

Prompt 4: Developer-Facing Positioning Rewrite

Use this when your landing page says “15 models, one endpoint” but users need a clearer reason to make their first request.

You are a senior developer marketing strategist for an AI API gateway.

Context:
Our current headline emphasizes access to many Chinese AI models through one endpoint. Real usage shows that developers do not initially explore all models. Most playground usage goes to one model, {{dominant_model}}, and many registered users never make an API call. We need positioning that still communicates breadth, but leads with immediate developer success.

Input materials:
- Current homepage hero copy: {{homepage_copy}}
- Current docs intro: {{docs_intro}}
- Current playground empty state: {{playground_empty_state}}
- Current API quickstart: {{api_quickstart}}
- Actual usage insight: {{usage_insight}}
- Free tier details: {{free_tier_details}}
- Supported models: {{supported_models}}
- Main target users: {{target_users}}
- Primary use cases: {{primary_use_cases}}

Your task:
Rewrite the developer-facing positioning so it improves first-call activation while staying truthful about model variety.

Please produce:
1. Three alternative homepage headlines.
2. Three short subhead options.
3. A revised docs introduction.
4. A playground empty state that encourages one immediate test.
5. A post-key-creation screen with a copy-pasteable API request.
6. A short model catalog intro that does not overwhelm new users.
7. A free tier explanation that sets expectations without sounding defensive.

Constraints:
- Do not use exaggerated claims such as 'best', 'unlimited', or 'production-ready' unless the input proves them.
- Do not hide the fact that there are multiple models.
- Prioritize the first successful API call over broad feature explanation.
- Keep the tone direct, technical, and credible.

Output format:
## Positioning Strategy
## Homepage Copy Options
## Docs Introduction
## Playground Empty State
## Post-Key Creation Screen
## Model Catalog Intro
## Free Tier Copy

Variables

Use these variables to adapt the prompts to your own gateway data:

{{dominant_model}}: The model receiving the largest share of calls, such as Kimi K3 if your logs confirm it.
{{monthly_free_tokens}}: Your stated monthly free-token allowance.
{{first_time_error_logs}}: The most common errors from new users, including authentication, model name, quota, timeout, and request schema errors.
{{quota_enforcement_design}}: A plain-English or technical explanation of how your current quota checks work.
{{model_catalog}}: Your real model list and any verified descriptions.
{{playground_distribution}}: Model usage share in the playground.
{{api_distribution}}: Model usage share in production API calls.
{{onboarding_copy}}: Text shown after registration or API key creation.
{{api_quickstart}}: The current first request example from your docs.
{{target_users}}: Your actual audience, such as indie developers, AI app teams, researchers, or internal platform teams.

The most important rule is simple: paste real data. If you only provide broad statements, the model will give broad advice. If you provide actual funnel numbers, error messages, copy, and request traces, you will get a much more useful audit.

Expected Output

After running these prompts, you should have four practical assets.

First, you should get a clear explanation of why users fail to make their first API call. That might expose missing curl examples, confusing API key placement, unclear model names, broken SDK assumptions, or an empty playground state that asks users to choose too much too soon.

Second, you should get a cleaner model selection strategy. For a multi-model Chinese AI gateway, the default should probably be opinionated. Let the first request work with a strong default, then introduce model comparison once the user has a reason to care.

Third, you should get a safer free tier design. A 500K monthly token allowance can be attractive, but quota checks need reliable accounting under concurrency. The useful output should include concrete advice around reservation, finalization, rate limits, alerts, and developer-facing quota messages.

Fourth, you should get better positioning. “15 models, one endpoint” is clear, but it may not be the best first sentence. A stronger developer-facing message is closer to: create a key, run one request, then choose the Chinese model that fits your workload.

That is the real lesson from the usage data. Developers do not evaluate a gateway by counting logos. They evaluate it by whether the first request works, whether the default model feels competent, whether errors are understandable, and whether the free tier behaves predictably under real load.