Token Usage by Output Format Prompt

This prompt is for infrastructure engineers, FinOps analysts, and prompt engineers who need to compare the token efficiency of different output formats for the same task. The job-to-be-done is a side-by-side cost analysis: given a fixed input and task description, the prompt generates equivalent outputs in JSON, markdown, plain text, and a structured format, then calculates the token consumption for each. The primary reader is someone optimizing a production pipeline where output format choice has a direct, measurable impact on per-request cost and latency at scale.

Use this prompt when you are making an intentional trade-off between output structure and token cost. For example, you might be deciding whether a summarization endpoint should return markdown with headings and bullet points or a flat JSON object for downstream parsing. The prompt requires a stable task definition and a representative input sample. It is not designed for evaluating output quality—it measures token counts, not accuracy, completeness, or adherence to a schema. If you need to assess whether the JSON output contains the correct fields, use a structured output evaluation prompt instead.

Do not use this prompt when the output format is non-negotiable due to downstream system contracts. If your API consumer requires a specific JSON schema, the cost of that format is a fixed constraint, not a variable to optimize. This prompt is also inappropriate for tasks where the output length varies dramatically by format in ways that distort the comparison—for instance, a task that produces a one-word answer in plain text but a full sentence in markdown. In those cases, normalize for information content before comparing token counts. Finally, this prompt is a diagnostic tool, not a runtime optimizer. It should be used during prompt engineering and cost modeling, not as a production middleware step that adds latency to every request.

This template is designed to analyze a production trace or a representative task and produce a side-by-side token consumption report for different output schemas. The goal is to identify the most cost-effective format—JSON, markdown, plain text, or a structured alternative—for a given task before you commit to a schema in your system prompt. Use this when you are optimizing per-request costs, selecting an output format for a new feature, or diagnosing why a particular prompt version is consuming more tokens than expected. Do not use this prompt for tasks where the output format is non-negotiable due to downstream parsing requirements; in those cases, use the [OUTPUT_SCHEMA] constraint directly and skip the comparison.

textCopy
You are a token-efficiency analyst. Your job is to compare the token consumption of different output formats for the same task.

## INPUT
[TASK_DESCRIPTION]

[SAMPLE_INPUT_DATA]

## OUTPUT FORMATS TO COMPARE
[OUTPUT_FORMATS]

## INSTRUCTIONS
1. For each output format listed in [OUTPUT_FORMATS], generate a complete response to [TASK_DESCRIPTION] using [SAMPLE_INPUT_DATA].
2. After generating all responses, produce a comparison report with the following structure:
   - **Format Name**
   - **Estimated Output Tokens**: The approximate token count for the generated response.
   - **Schema Overhead Tokens**: Tokens consumed by structural characters (braces, brackets, markdown syntax, etc.) that are not part of the content.
   - **Content Density Score**: A subjective 1-10 rating of how much useful information is conveyed per token.
   - **Parse Reliability**: High / Medium / Low assessment of how reliably this format can be parsed by downstream systems.
   - **Recommendation**: A brief note on when this format is the right choice.
3. End with a **Cost-Efficiency Leaderboard** ranking the formats from most to least token-efficient for this specific task.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## OUTPUT_SCHEMA
[OUTPUT_SCHEMA]

To adapt this template, start by populating [TASK_DESCRIPTION] with a concrete, repeatable task—such as 'summarize a customer support ticket' or 'extract entities from a contract clause.' Provide [SAMPLE_INPUT_DATA] that is representative of your production workload; avoid toy examples that won't surface real token differences. The [OUTPUT_FORMATS] placeholder should list the formats you want to compare, such as JSON with strict schema, Markdown with headings, Plain text paragraph, and YAML. If you have a fixed [OUTPUT_SCHEMA] that one of the formats must conform to, include it there. Use [CONSTRAINTS] to enforce rules like 'do not exceed 500 words' or 'preserve all numerical values exactly.' The [EXAMPLES] placeholder is optional but recommended for few-shot guidance if the model struggles with consistent formatting across the comparison report.

Before wiring this into an automated pipeline, validate that the model reliably produces the comparison report structure. A common failure mode is the model generating the per-format responses but omitting the leaderboard or schema overhead calculation. Add a post-processing validator that checks for the presence of all required report fields. For high-stakes cost decisions—such as selecting an output format that will be used across millions of requests—run this prompt against a golden dataset of at least 20 representative inputs and review the leaderboard consistency manually before committing to a format change. Do not rely on a single run to make a cost decision.

This prompt is designed to be called programmatically as part of a cost-optimization or prompt engineering workflow, not as a one-off manual query. The primary integration point is a script or microservice that iterates over a set of target prompts, generates equivalent outputs in multiple formats (JSON, Markdown, plain text, etc.), and then feeds those outputs into this analysis prompt. The harness must capture the token counts from the provider's API response (usage.prompt_tokens, usage.completion_tokens) for each format variant and pass them as structured input to this prompt, ensuring the analysis is grounded in real, measured consumption rather than estimates.

To implement this, build a runner function that accepts a target prompt template and a list of output format instructions. For each format, execute the target prompt against a consistent model (e.g., gpt-4o or claude-3-5-sonnet) with temperature=0 to minimize output variance, and log the full response object including token usage. Aggregate these results into a JSON object matching the prompt's expected [INPUT] schema: an array of objects with format_name, prompt_tokens, completion_tokens, total_tokens, and output_preview fields. Pass this aggregated object to the analysis prompt. Validate the analysis output against a defined [OUTPUT_SCHEMA]—a JSON object containing a ranked_formats array and a recommendation object—and retry once if parsing fails. For high-volume or production pipelines, log the analysis result alongside the raw token data to a cost-observability store (e.g., a database table or a tool like Langfuse) for trend tracking over time.

Avoid wiring this prompt directly into a user-facing feature without caching or rate-limiting. The analysis itself consumes tokens, so running it on every request defeats the purpose. Instead, use it as a periodic batch job—triggered by a CI/CD pipeline on prompt version changes or on a weekly schedule—to re-evaluate format efficiency as models and prompt content evolve. If the analysis identifies a clear cost leader, the harness can automatically update a configuration flag that switches the production prompt's output format, but only after a human reviews the output_preview samples to confirm that the cheaper format does not degrade task quality. The final safeguard is an eval step: run the recommended format against a golden test set and assert that accuracy or task-completion metrics remain within acceptable thresholds before deploying the change.