← Blog

Best Prompt Engineering Frameworks for 2025

2026-09-20 · 5 min read · SubToAPI Team

"Best prompt engineering framework" isn't a single answer — it depends on whether you're writing one-off prompts by hand, building a repeatable process for a team, or programmatically optimizing prompts against a dataset. This article covers the frameworks that actually get used in production, what problem each one solves, and how to choose between them.

If you just want a quick answer: for structuring individual prompts, CO-STAR and RACE are the most widely adopted. For reasoning-heavy tasks, Chain-of-Thought and Tree of Thoughts win. For agents that call tools, ReAct is the standard pattern. For teams that want prompts optimized automatically instead of by hand, DSPy is the closest thing to a real engineering framework rather than a mnemonic.

Structural frameworks: turning a request into a well-formed prompt

These frameworks are essentially checklists — acronyms that remind you what a good prompt needs. They're not code, they're a writing discipline.

CO-STAR (Context, Objective, Style, Tone, Audience, Response format) is popular because it maps directly onto how LLMs actually respond to structure. Splitting a prompt into these six labeled sections consistently outperforms a single paragraph of instructions, especially for content generation and summarization tasks.

RACE (Role, Action, Context, Expectation) is a lighter version of the same idea — good for quick prompts where you don't need a full six-part breakdown.

RISEN (Role, Instructions, Steps, End goal, Narrowing) adds explicit step decomposition, which helps for multi-stage tasks like data transformation or report generation.

A minimal CO-STAR prompt looks like this:

Context: You are reviewing customer support transcripts for a SaaS product.
Objective: Identify the top 3 recurring complaints.
Style: Concise, bullet-point analysis.
Tone: Neutral, factual.
Audience: Product manager.
Response format: Markdown list with a one-line summary per complaint.

These frameworks are the right starting point if your team writes prompts manually and needs consistency across writers. They don't require any tooling — just a shared template.

Reasoning frameworks: getting the model to think before it answers

Chain-of-Thought (CoT) prompting — asking the model to reason step by step before giving a final answer — remains the single highest-leverage technique for math, logic, and multi-step analysis. Appending "think step by step" or providing a worked example with reasoning still measurably improves accuracy on complex tasks.

Tree of Thoughts (ToT) extends this by having the model generate multiple reasoning branches and evaluate which one to pursue, rather than committing to a single linear chain. It's more expensive (more tokens, more calls) but outperforms plain CoT on problems with multiple plausible solution paths, like planning or puzzle-solving.

Self-consistency is a cheap complement to both: sample the same CoT prompt several times, take the majority answer. Useful when you can afford the extra calls and need higher reliability without redesigning the prompt.

Agentic frameworks: prompts that take action

ReAct (Reason + Act) interleaves reasoning steps with tool calls — the model explains what it's doing, calls a tool, observes the result, and reasons again. This is the pattern behind most modern coding agents and research assistants, and it's the de facto standard when you're building anything that calls external APIs, searches, or runs code mid-conversation.

If you're implementing ReAct-style agents against Claude, you'll want native tool-use support rather than parsing free text for function calls. SubToAPI exposes this through the standard Messages format with a tools array, so you can define a JSON schema for each tool and let the model decide when to call it — see /docs/tools for the request shape and streaming behavior.

Optimization frameworks: treating prompts like code

The frameworks above are things a human writes and refines by hand. DSPy is different — it treats prompts as parameters to be optimized against a dataset and a metric, similar to how you'd tune a machine learning model. Instead of hand-tuning wording, you define the task, a scoring function, and let DSPy search for prompt variants (and few-shot examples) that maximize the score.

This matters once you have enough production traffic to measure prompt quality objectively — support deflection rate, extraction accuracy, whatever your metric is. For small teams or early-stage products, manual frameworks like CO-STAR are usually faster to iterate on. DSPy pays off once you have a labeled eval set and stable task definition worth automating.

Choosing a framework for your situation

In practice, most production systems combine two of these — a ReAct loop for tool orchestration with CoT reasoning inside each step, structured with a CO-STAR-style template for consistency.

From framework to production API

Whichever framework you use, the prompt eventually has to run against a real model endpoint with streaming, retries, and usage tracking — not just a playground. SubToAPI wraps your existing Claude access in a standard HTTPS API so you can call your engineered prompts programmatically:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Context: ... Objective: ... Response format: ..."}
    ]
  }'

You get an application API key (sub_live_...), streaming responses, tool use, and per-request usage metadata — useful if you're doing self-consistency sampling and need to track token cost across repeated calls. Check /docs/quickstart to get a key running, or /docs/messages for the full request/response schema. Plans start at €9/month with a free trial — see /pricing.

FAQ

Is CO-STAR better than Chain-of-Thought? They solve different problems. CO-STAR structures what you tell the model (context, format, tone); Chain-of-Thought changes how the model reasons before answering. Use both together — a CO-STAR-structured prompt that also asks for step-by-step reasoning.

Do I need a framework for simple prompts? No. Frameworks earn their keep when prompts get reused, when multiple people write them, or when output consistency matters. A one-off prompt in a script doesn't need CO-STAR or ReAct — plain instructions are fine.

Which framework works best for coding agents? ReAct is the standard for agents that need to call tools, run code, or search external sources, since it interleaves reasoning with actions and observations rather than trying to solve everything in one shot.

Turn your Claude access into an HTTPS API

SubToAPI gives you application API keys, streaming, tool use and usage insights on top of your existing Claude access — set up in minutes.

Start free  Read the quickstart →