Model Capability Boundary Check Prompt

This prompt is a middleware component for your model router. Its job is to act as a pre-flight check, analyzing a user's request to identify the required model capabilities—such as vision, long context, tool use, or code execution—before the request is dispatched. The ideal user is an infrastructure or platform engineer who operates a routing layer that distributes tasks across a heterogeneous fleet of models with different strengths and cost profiles. You need this when a single, cheap text-only model is your default entry point, but your system also has access to more powerful, specialized, or expensive models. Without this check, a request to 'describe the trends in this chart image' sent to a text-only model will result in a hallucinated answer or a confusing error, wasting compute and degrading user trust.

The core mechanism is a structured comparison. The prompt takes the user's request and a declared capability profile for the currently targeted model as inputs. It classifies the request's requirements and produces a gap report. This report explicitly lists any missing capabilities and, crucially, recommends a specific fallback model from your known fleet that can handle the task. This isn't a generic refusal; it's an actionable routing signal. For example, if a user asks a claude-haiku instance (no vision) to analyze a photo, the prompt's output should flag vision as a missing capability and recommend claude-sonnet or gpt-4o as the fallback. Your application code then catches this structured output and re-routes the request, rather than letting the initial model fail.

Do not use this prompt for content safety or policy violation checks. It is strictly for functional capability matching. Confusing these concerns will lead to a bloated, unfocused classifier that performs poorly at both tasks. Also, avoid using this for real-time latency-sensitive decisions where a simple, hardcoded check on the model_id would suffice. The value of this LLM-based check is in its nuanced understanding of complex, multi-step user requests. A request like 'read this 50-page PDF and run a python script on the extracted data' requires the model to infer the need for long-context, file parsing, and code execution capabilities, which a simple regex cannot do. Implement this as an asynchronous pre-flight step or with a tight timeout, and always have a safe default route if the check itself fails.

This prompt template is designed to be injected into your model routing middleware. It takes a user request and the current model's capability profile, then produces a structured capability gap report. The output is a machine-readable JSON object that your infrastructure can use to either proceed with the current model or route the request to a more capable fallback. The prompt uses square-bracket placeholders that your application must populate before sending the request to the model.

textCopy
You are a model capability boundary checker. Your job is to determine whether the current model can fulfill a user request given its known capabilities. You must be conservative: if a capability is not explicitly listed as supported, assume it is unsupported.

## CURRENT MODEL CAPABILITIES
[CAPABILITY_PROFILE]

## USER REQUEST
[USER_REQUEST]

## INSTRUCTIONS
1. Analyze the user request and identify every capability it requires.
2. Compare each required capability against the current model's capability profile.
3. For each capability gap, explain why the capability is needed and cite the specific part of the request that requires it.
4. If any required capability is missing, recommend the most appropriate fallback model from the available fallback list.
5. If all capabilities are present, confirm that the current model can proceed.

## AVAILABLE FALLBACK MODELS
[FALLBACK_MODELS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "can_fulfill": boolean,
  "required_capabilities": [
    {
      "capability": string,
      "supported": boolean,
      "evidence_from_request": string
    }
  ],
  "gap_summary": string | null,
  "recommended_fallback": string | null,
  "confidence": "high" | "medium" | "low"
}

## CONSTRAINTS
- Do not assume capabilities that are not listed in the profile.
- If the request is ambiguous about a capability requirement, flag it with medium or low confidence.
- Never recommend a fallback model that is not in the available fallback list.
- If no fallback model can fulfill the request, set recommended_fallback to null and explain in gap_summary.

To adapt this prompt for your system, replace [CAPABILITY_PROFILE] with a structured description of what your current model supports—include modalities (text, image, audio), context window size, tool-use availability, code execution, and any domain restrictions. [USER_REQUEST] should contain the raw user input. [FALLBACK_MODELS] should list your available alternative models with their capabilities. The output schema is designed for direct parsing by your routing logic; validate the JSON before acting on it. For high-risk domains, add a human-review step when confidence is low or when no fallback model can fulfill the request.

The Model Capability Boundary Check Prompt is designed to sit in the critical path of a model routing gateway. Before a user request reaches a generative model, this prompt classifies the required capabilities—vision, long context, tool use, code execution, structured output—and compares them against the capabilities of the currently selected model. The output is a structured capability gap report that downstream routing logic can act on: either proceed with the current model, switch to a fallback model that satisfies all requirements, or reject the request with a clear explanation of the unsupported capability. This is not a conversational prompt; it is a classification step that must return a deterministic, machine-readable schema every time.

Wire this prompt into your application as a pre-invocation middleware. The harness should inject the current model's capability profile as a structured [MODEL_CAPABILITIES] object—listing supported modalities, max context length, tool-use availability, and code execution permissions—alongside the user's [INPUT] and any [TOOLS] or [OUTPUT_SCHEMA] the downstream task requires. On the response side, validate the output against a strict JSON schema with required fields: capability_gaps (array of missing capabilities), recommended_fallback_model (string or null), and routing_decision (enum: proceed, fallback, reject). If validation fails, retry once with the validation error injected into the prompt as additional context. If the second attempt also fails, log the raw response and escalate to a human reviewer rather than silently routing with an unvalidated classification. For high-throughput systems, cache capability profiles and fallback model recommendations by request fingerprint to avoid redundant LLM calls for identical capability checks.

Observability is essential here because a misclassification—approving a vision task for a text-only model—produces either a silent failure or a hallucinated response. Log every routing decision with the input fingerprint, detected capabilities, model selected, and the final routing action. Set up eval checks that run weekly against a golden dataset of requests with known capability requirements, measuring precision and recall on each gap category. Monitor the rate of reject decisions; a sudden spike may indicate a model capability regression or a misconfigured capability profile. The most common production failure mode is a capability profile that drifts out of sync with the actual model's features after a model upgrade or API change, so treat the [MODEL_CAPABILITIES] injection as configuration that must be versioned and tested alongside the prompt itself.