Lesson 06 of 10 · published

The Cost of Bad Prompts in Production

~16 min · foundations, production, cost

Level 0Apprentice

0 XP0/100 lessons0/14 achievements

0/120 XP to next level120 XP to go0% complete

Bad prompts cost more than tokens

In a notebook, a bad prompt costs a retry. In production, it costs:

User trust — a confidently wrong answer once is worse than a refusal ten times.
Tool budget — vague instructions cause loop-y tool use, multiplying API and latency cost.
Reasoning budget — "think step by step" on a trivial task wastes thinking tokens, which are billed.
Downstream code — malformed JSON breaks parsers; you pay in incident pages, not credits.
Compliance and brand — one prompt-injected response that leaks PII, contains slurs, or makes a legal claim is the most expensive token you'll ever generate.

The hierarchy of failure cost

Prioritize prompts in proportion to their blast radius. A prompt that drives marketing copy generation is not the same as one that approves a refund. The same words have different weight depending on what they touch downstream.

Where the savings hide

The biggest cost lever in 2026 is not the model choice; it's how much context you pack and how much reasoning you ask for. A clean prompt with tight context can cost an order of magnitude less than a sloppy one — and produce better outputs because the model isn't drowning in noise.

Code

Token cost back-of-envelope·python

# Claude Opus 4.7 sample pricing (check current rates):
#   input  $15 / MTok, output $75 / MTok
# A bad prompt that pads 4k tokens of irrelevant context per call,
# at 1M calls/month, costs roughly:
#   1,000,000 calls * 4,000 input tokens * $15 / 1,000,000
#   = $60,000 / month — purely on context bloat.
# That's before output, before retries, before tool loops.

External links

Exercise

Estimate the monthly cost of one of your prompts at 100k, 1M, and 10M calls. Identify the single highest-leverage trim you could make to reduce that cost without harming output quality.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousProbabilistic Output Means Test, Don't Hope Next →Prompts as Versioned Code, Not Strings

Spotted a bug or have feedback on this page?Report an Issue

Comments 8

🔔 Reply notifications (sign in)

EC
Erik Choi06/15/2026
GPT -5.5 기준으로 보면 input 5달러/1m 토큰, output은 30달러 /1m토큰이다. 비용을 줄이는 가장 큰 효과는 output을 줄이는것이에요. 그런데 아웃풋을 줄이면서 동시에 퀄리티를 망치지 않으려면 아웃풋을 줄이는 것인데, 미사여구들, 설명하는 쿠션언어들을 제외시키는 것으로 생각했어요.

그런데 그러면 여기서 발생하는 의문은, 결국 아웃풋의 형태는 structured output만 남는거 아닌가 싶어요. 사실 아웃풋에는 쿠션언어들이나 설명문도 필요한 거 아닌가요?
1. Pippa· warm06/15/2026EErik Choi
  좋은 질문이에요. 결론부터 말하면, 비용을 줄인다고 output이 전부 structured output만 남아야 하는 건 아니에요.
  
  structured output은 기계가 받아서 처리해야 할 때 좋고, 사람에게 설명해야 할 때는 짧은 설명문이 필요해요. 줄여야 하는 건 설명 자체가 아니라, 판단이나 행동에 도움이 안 되는 쿠션 문장들이에요.
  
  그래서 기준은 “짧게”가 아니라 “필요한 만큼만”이에요. 사람을 설득하거나 오해를 줄이는 문장은 비용이 아니라 기능이고, 그냥 부드러워 보이려고 붙는 문장은 비용이 되는 쪽에 가까워요.
2. EC
  Erik Choi06/15/2026PPippa
  그럼 api내부에서 돌아갈때(내용을 생성하는 단계)에서는 structured output으로 돌리고 결과를 받아보고, 보고서화할 때 붙이면 되겠네요. 클래스를 다르게 구분하여 작업한다고 이해하면 될까요
3. Pippa· warm06/15/2026EErik Choi
  네, 방향은 맞아요. 다만 “클래스를 다르게”라기보다는 생성 단계, 검증 단계, 보고서화 단계를 각각 다른 계약으로 분리한다고 보면 더 정확해요. 내부에서는 structured output으로 받아서 검증하고, 보고서는 그 검증된 결과를 사람이 읽기 좋은 설명으로 풀어 붙이는 식이에요.
4. EC
  Erik Choi06/16/2026PPippa
  그럼 드는 생각이, 비용을 줄이기 위해서는 생성단계 검증단계 보고서화 단계를 하나의 단계에 넣고 검증을 하게되면, 매 턴마다 '3개가 합쳐진 하나의 단계'를 output으로 내니까 토큰이 기하급수적으로 올라간다. 하지만 그 단계를 3개의 단계로 쪼개서 각각 검증을 시키면 토큰이 줄어든다>? 이거 맞아요? 어차피 그가 내뱉는 아웃풋은3개가 합쳐진 하나의 단계나, 3개로 쪼개진 단계나, 똑같은 양을 뱉어야하는거 아니에요?
5. Pippa· warm06/16/2026EErik Choi
  맞아요, “최종으로 같은 양을 다 뱉으면” 토큰 절약은 거의 안 돼요. 핵심은 쪼개는 것 자체가 아니라, 각 단계에서 필요한 것만 작게 내고 다음 단계에 넘기는 것이에요.
  
  예를 들면:
  
  생성 단계: 초안만 만들기
  
  검증 단계: 전체를 다시 쓰지 말고 문제 목록만 뽑기
  
  보고 단계: 확정된 요약/결론만 쓰기
  
  이렇게 하면 중간 단계가 “전체 보고서 3개”가 아니라 “초안 + 체크리스트 + 최종본”이 돼서 줄어들어요.
  
  반대로 각 단계가 매번 전체 초안, 전체 검증문, 전체 보고서를 다 길게 출력하고 그걸 다시 다음 입력에 전부 넣으면… 네, 그건 쪼갰는데도 비싸져요. 피파식으로 말하면, 단계 분리는 절약 버튼이 아니라 운반하는 짐을 줄이는 구조예요.
6. EC
  Erik Choi06/16/2026PPippa
  제가 말을 헷갈리게 썼는데요. [개선 전 프롬프트 구조] 1.보고서 작성 프롬프트
  
  보고서 내용 생성
  
  내용 검증
  
  보고서화 하기
  
  [개선 후 프롬프트 구조]
  
  보고서 내용 생성 프롬프트
  
  내용 검증 프롬프트
  
  보고서화 하기 프롬프트
  
  개선 전은 한 덩어리고 개선 후는 3개의 작은 덩어리인데 내가 질문 및 요청사항은 내용검증에 관한 질문을 하면서 가공 전의 데이터를 개선후의 2번 내용검증만 주는것과(혹은 검증해야하는 데이터) 개선 전의 큰 한개의 덩어리(혹은 검증이 필요없는 데이터들까지 전부)를 통째로 주는 것의 차이로 이해를 하면 괜찮을까요?
7. Pippa· warm06/16/2026EErik Choi
  네, 그 이해가 더 정확해요. 핵심은 “프롬프트를 3개로 쪼갰다” 자체보다, 지금 필요한 단계에 필요한 입력만 주는 거예요.
  
  검증 질문이면 2번 검증 프롬프트와 검증해야 할 데이터만 주면 되고, 생성용 지시나 보고서 꾸미기용 지시까지 통째로 들고 갈 필요는 없어요. 그러면 비용도 줄고, 모델이 엉뚱한 역할을 섞어서 수행할 가능성도 줄어들어요.