Claude Opus 5.5, 40% 싸지고 더 빨라졌다

Claude Opus 5.5, 40% 싸지고 더 빨라졌다

Medium Effort·Token·Cache·Agent 비용까지 달라진 이유

2026년 9월 22일 Anthropic이 Claude Opus 5.5를 공개했습니다.

새 모델이 나오면 보통 Benchmark 점수부터 확인하게 됩니다.

그런데 이번 Opus 5.5는 성능 숫자보다 다른 변화가 더 눈에 들어옵니다.

같은 일을 처리하는 데 드는 비용과 시간이 크게 줄었습니다.

성능 ↑

Input / Output 가격 ↓

Cache 가격 ↓↓↓

기본 Effort
High → Medium

불필요한 Thinking ↓

작업에 필요한 Turn ↓

출력 속도 ↑

Anthropic이 공식 발표에서 강조한 숫자도 강합니다.

Opus 5와 비교해 일반적인 작업 비용을 약 40% 낮췄습니다.

단순히 토큰 가격만 낮춘 결과는 아닙니다.

모델이 일을 처리하는 방식 자체가 더 효율적으로 바뀌었습니다.

---

1. 먼저 숫자부터 보면 변화가 꽤 크다

Opus 5.5의 주요 사양은 다음과 같습니다.

항목	Claude Opus 5.5
Context	1M tokens
일반 최대 Output	128K
Batch 최대 Output	300K Beta
Input	$4 / MTok
Output	$20 / MTok
5분 Cache Write	$5 / MTok
Cache Read	$0.20 / MTok
기본 Effort	Medium
Thinking	Adaptive Thinking
출력 속도	Opus 5 대비 30% 이상 향상
Fast Mode	최대 2.5x OTPS

Opus 5의 Input과 Output 가격은 각각:

Input
$5 / MTok

Output
$25 / MTok

이었습니다.

Opus 5.5에서는:

Input
$4 / MTok

Output
$20 / MTok

으로 내려갔습니다.

기본 토큰 가격부터 20% 인하된 셈입니다.

---

2. Cache Read 가격은 더 크게 내려갔다

Prompt Cache 쪽 변화는 더 큽니다.

Opus 5:

Cache Read
$0.50 / MTok

Opus 5.5:

Cache Read
$0.20 / MTok

입니다.

60% 인하입니다.

그리고 Fresh Input 가격과 비교하면 Cache Read는 5% 수준입니다.

Fresh Input
$4

Cache Read
$0.20

Claude Code처럼 같은 프로젝트 Context를 계속 읽는 환경에서는 꽤 중요한 차이입니다.

---

3. 그래서 20% 가격 인하가 40% 작업비용 절감으로 커진다

가격표만 보면 이렇게 생각하기 쉽습니다.

토큰 가격이 20% 싸졌네.

그런데 Anthropic은 Opus 5.5가 일반적인 작업을 Opus 5보다 약 40% 낮은 비용으로 처리한다고 설명합니다.

이유는 Agent의 비용이 단순히 토큰 단가만으로 결정되지 않기 때문입니다.

예를 들어 기존 Agent가:

코드 읽기
 ↓
수정
 ↓
Test 실패
 ↓
다시 읽기
 ↓
다시 수정
 ↓
다른 문제 발견
 ↓
또 수정

했다면,

더 효율적인 Agent는:

관련 코드 확인
 ↓
영향 범위 파악
 ↓
수정
 ↓
Test
 ↓
완료

로 끝낼 수 있습니다.

실제 작업비용은 결국:

토큰 가격
×
사용한 Token
×
Turn 수
×
Retry 수

에 가깝습니다.

Opus 5.5는 이 여러 요소를 동시에 줄였습니다.

---

4. 이번 변화에서 가장 중요한 건 기본 Effort가 Medium이라는 점이다

Opus 5의 기본 Effort는:

High

였습니다.

Opus 5.5는:

Medium

입니다.

이 변화가 꽤 중요합니다.

Effort가 높아지면 모델은 더 많이 생각합니다.

그만큼:

Thinking Token ↑

처리시간 ↑

비용 ↑

도 따라옵니다.

예전에는 높은 품질을 얻으려면 High를 기본처럼 사용하는 경우가 많았습니다.

Opus 5.5는 상당수 Coding 작업을 Medium에서도 높은 품질로 처리하는 것을 목표로 합니다.

---

5. Effort가 높다고 무조건 좋은 것은 아니다

Effort는 성능 등급이라기보다:

이 작업에 얼마나 많은 계산을 쓸 것인가

에 가깝습니다.

Low

이름 변경

반복적인 코드 수정

정해진 Pattern 적용

간단한 파일 정리

Medium

Feature 구현

일반 Bug Fix

Refactoring

일반적인 Code Review

High

복잡한 Debugging

Concurrency 문제

여러 Module에 걸친 수정

Architecture 영향 분석

XHigh / Max

대규모 분석

정말 어려운 문제

장시간 자율 작업

정도로 생각하면 쉽습니다.

평소 개발까지 무조건 High나 Max를 사용하는 것은 필요 없는 Thinking 비용을 추가하는 것일 수 있습니다.

---

6. Medium으로 충분한 작업이라면 High는 그냥 더 비싸다

Medium에서도 한 번에 끝나는 기능을 High로 실행했다고 해보겠습니다.

결과가 같다면 High에서는:

Thinking이 더 길고

Token을 더 사용하고

응답이 늦고

사용 한도도 더 빨리 소모

됩니다.

아무런 이득이 없습니다.

그래서 Opus 5.5에서는:

일단 Medium

으로 시작하는 전략이 훨씬 자연스러워졌습니다.

---

7. 반대로 어려운 문제에서는 High가 더 싸게 끝날 수도 있다

High가 항상 낭비라는 뜻은 아닙니다.

Medium이 어려운 문제에서:

수정
 ↓
실패

다시 분석
 ↓
수정

또 실패
 ↓
다시 수정

한다면 Turn이 계속 늘어납니다.

반대로 High가 처음부터:

문제 분석
 ↓
관련 호출부 확인
 ↓
영향 범위 파악
 ↓
수정
 ↓
Test 통과

로 끝낸다면 Thinking Token을 조금 더 써도 전체 비용은 더 낮아질 수 있습니다.

그래서 Effort를 고를 때 중요한 건:

얼마나 오래 생각했나?

보다

몇 번 만에 일을 끝냈나?

입니다.

---

8. Opus 5.5는 같은 일을 더 적은 Token으로 끝내는 방향도 개선됐다

Opus 5.5의 장점은 단순 가격 인하가 아닙니다.

Agent가 작업을 끝내기 위해 사용하는:

Thinking

Tool Call

Output

Retry

Turn

자체도 줄이는 방향으로 개선됐습니다.

Coding Agent는 한 번 답하고 끝나지 않습니다.

코드 검색
 ↓
파일 읽기
 ↓
수정
 ↓
Build
 ↓
Test
 ↓
Log 확인
 ↓
재수정

을 반복합니다.

각 단계에서 조금씩 효율이 좋아지면 긴 작업에서는 차이가 꽤 크게 벌어집니다.

---

9. 출력 속도도 빨라졌다

Opus 5.5는 Opus 5보다 Output Token 생성 속도가 30% 이상 빨라졌습니다.

Agent에서는 단순 답변 한 번의 속도보다 의미가 큽니다.

Reasoning
 ↓
Tool Call
 ↓
Result
 ↓
Reasoning
 ↓
Tool Call

을 여러 번 반복하기 때문입니다.

각 단계가 조금씩 빨라지면 전체 작업시간에서는 체감 차이가 더 커집니다.

---

10. Opus 5.5 비용에서 정말 중요한 건 Prompt Cache다

Claude Code를 오래 사용하면 Session 안에 이런 내용이 계속 쌓입니다.

System Prompt

CLAUDE.md

Skills

Tool Definitions

읽었던 Source Code

Conversation

Build Log

Test Result

Context가 100K 이상 커지는 것도 어렵지 않습니다.

다음 요청에서도 이 내용을 계속 사용합니다.

매번 전부 Fresh Input으로 다시 처리하면 비쌉니다.

그래서 Prompt Cache가 중요합니다.

---

11. 이미 읽은 Context는 훨씬 싸게 다시 읽는다

Opus 5.5 기준으로:

Fresh Input
$4 / MTok

Cache Read
$0.20 / MTok

입니다.

같은 Context를 다시 읽을 때 비용 차이가 20배입니다.

예를 들어 120K 정도의 Context가 이미 Cache에 있다면 다음 Turn에서는 대부분을 매우 저렴하게 다시 활용할 수 있습니다.

긴 Agent 작업에서는:

Token을 조금 줄이는 것

만큼이나

이미 만든 Cache를 유지하는 것

이 중요합니다.

---

12. 그래서 긴 Claude Code Session에서는 Cache를 깨지 않는 게 중요하다

이미 150K Context가 쌓여 있다고 해보겠습니다.

이 상태에서:

구현

Build

Test

Review

를 이어가면 앞의 Context 대부분은 계속 재사용됩니다.

그런데 설정을 바꿔 Cache가 깨지면:

150K Context
→ 다시 Cache Write

가 필요합니다.

Session이 길수록 이 비용은 커집니다.

---

13. Claude Code에서 Effort를 바꾸면 Cache가 다시 만들어질 수 있다

Claude Code에서:

/effort high

처럼 Effort를 바꿀 수 있습니다.

문제는 Effort나 Thinking 설정이 Prompt Cache 조건에 영향을 준다는 점입니다.

그래서:

Medium
 ↓
High
 ↓
Medium
 ↓
High

처럼 계속 변경하면 긴 Session에서는 Cache 효율이 떨어질 수 있습니다.

Effort는 필요할 때만 바꾸는 게 좋습니다.

---

14. Effort 변경은 작업 경계에서 하는 게 낫다

예를 들어:

Feature 구현
Medium

──── 구현 완료 ────

복잡한 Architecture Review
High

──── Review 완료 ────

다음 일반 작업
Medium

처럼 쓰는 편이 낫습니다.

작업 중간에 계속 Low, Medium, High를 오가는 것보다 자연스럽습니다.

---

15. API에서는 Cache를 유지하면서 Effort를 바꿀 수도 있다

Claude API에는 Per-message Effort라는 Beta 기능이 있습니다.

예를 들어:

Turn 1
Medium

Turn 2
Medium

Turn 3
이번 문제만 High

Turn 4
다시 Medium

처럼 특정 Turn만 Effort를 높일 수 있습니다.

이 방식은 기존 Prompt Cache를 유지하면서 사용할 수 있습니다.

그래서 구분하면:

Claude Code 일반 Effort 변경
→ Cache 재작성 가능

API Per-message Effort
→ Cache 유지 가능

입니다.

---

16. Per-message Effort 자체가 Opus 5.5에서 처음 나온 기능은 아니다

이 기능은 Opus 5.5만의 전용 기능은 아닙니다.

일부 이전 Claude 모델에서도 지원됩니다.

다만 Opus 5.5에서는:

기본 Medium

+

낮아진 Cache Read 가격

+

향상된 Token 효율

이 같이 들어오면서 훨씬 활용하기 좋아졌습니다.

---

17. Adaptive Thinking은 항상 켜져 있다

Opus 5.5에서는 Thinking을 단순히:

ON
OFF

하는 방식보다 Effort로 조절하는 방식이 중심입니다.

즉:

Thinking을 할까?

보다

얼마나 깊게 생각할까?

를 정하는 방식입니다.

다만 Adaptive Thinking이 켜져 있다고 모든 요청에서 길게 생각하는 것은 아닙니다.

간단한 문제라면 낮은 Effort에서 거의 바로 처리할 수 있습니다.

---

18. Context는 1M, 일반 Output은 128K다

Opus 5.5는:

Context
1,000,000 tokens

일반 Output
128K tokens

을 지원합니다.

Batch API Beta에서는 최대 300K Output도 지원합니다.

대규모 Repository 분석이나 Migration에는 꽤 넉넉합니다.

하지만 1M Context가 있다고 무조건 다 채우는 건 좋은 전략이 아닙니다.

---

19. Context가 크다고 다 넣으면 오히려 비싸다

예를 들어:

Repository 전체

오래된 Build Log

이미 끝난 Debugging 내용

필요 없는 Test 결과

까지 계속 Session에 들고 다닐 필요는 없습니다.

Cache Read가 싸다고 해도 무료는 아닙니다.

Context가 커지면 모델이 중요한 정보를 찾기도 어려워집니다.

그래서:

필요한 Context는 오래 유지하고

끝난 Context는 정리한다

가 중요합니다.

---

20. 그래서 /compact와 /clear가 중요하다

같은 업무를 계속하지만 Session이 너무 커졌다면:

/compact

를 사용할 수 있습니다.

완전히 다른 업무로 넘어간다면:

/clear

가 더 적합합니다.

예를 들어:

/compact
실패한 테스트와 API schema 변경 내용은 유지해줘

처럼 중요한 내용을 남길 수도 있습니다.

중요한 건 아무 때나 Compact하지 않는 것입니다.

Debugging 한가운데서 Context를 줄였다가 필요한 Log까지 사라지면 오히려 다시 읽어야 합니다.

---

21. Prompt도 Opus 5.5에 맞게 다시 볼 필요가 있다

이전 모델을 움직이기 위해 이런 규칙을 만들어둔 경우가 있습니다.

항상 6단계로 작업해라.

모든 변경 전에 긴 Plan을 작성해라.

항상 두 번 검증해라.

모든 내용을 자세하게 설명해라.

예전에는 도움이 됐을 수 있습니다.

하지만 Opus 5.5에서는 이런 규칙이:

불필요한 Output

추가 Tool Call

Turn 증가

를 만들 수도 있습니다.

모델이 바뀌었다면:

CLAUDE.md

Skills

Agent Rules

Prompt

도 한 번 정리하는 게 좋습니다.

---

22. 테스트가 잘 되어 있으면 High Effort를 쓸 일도 줄어든다

Medium에서 코드 하나를 놓쳤다고 바로:

Medium
→ High

로 올릴 필요는 없습니다.

Agent가 스스로 결과를 확인할 수 있다면 상황이 달라집니다.

Build

Unit Test

Integration Test

Lint

Static Analysis

를 실행할 수 있으면 Medium에서도 실수를 발견하고 다시 고칠 수 있습니다.

Agent 개발에서는:

더 많이 생각하게 하기

보다

틀렸는지 바로 확인할 수 있게 하기

가 더 중요한 경우가 많습니다.

---

23. Task Budget도 Agent 개발에서는 재미있는 기능이다

API 기반 Agent를 직접 만든다면 Task Budget도 사용할 수 있습니다.

Effort와 역할이 다릅니다.

Effort
→ 한 단계에서 얼마나 깊게 생각할까

Task Budget
→ 전체 작업에 얼마를 쓸까

입니다.

예를 들어:

Search

파일 읽기

Tool Call

수정

Test

전체에 일정한 Token Budget을 주는 식입니다.

현재 Beta 기능이며 일반 Claude Code 기능과는 구분해서 봐야 합니다.

---

24. Fast Mode는 비용 절감 기능이 아니다

Opus 5.5에는 Fast Mode도 있습니다.

같은 Opus 5.5를 더 빠른 Inference 환경에서 실행합니다.

일반 가격:

Input
$4

Output
$20

Fast Mode:

Input
$8

Output
$40

수준입니다.

즉 Fast Mode는:

비용을 줄이는 기능

이 아니라

돈을 더 내고 응답시간을 줄이는 기능

입니다.

실시간 Agent나 긴 Streaming Output에서 속도가 중요한 경우에 맞습니다.

---

25. Tool Calling도 확인해야 한다

API Agent를 직접 만들고 있다면 Model ID만 바꿔서는 안 됩니다.

Opus 5.5에서는 기존 Tool 강제 선택 방식 일부가 달라졌고:

Strict Tool Use

Structured Output

쪽을 다시 확인해야 합니다.

Computer Use도 새로운 Toolset 구조를 사용합니다.

기존 Agent Framework를 운영한다면 Migration 전에:

Tool Choice

Thinking

Effort

Computer Use

max_tokens

를 같이 점검하는 게 좋습니다.

---

26. Opus 5.5가 일상용 Opus가 된 이유

기존 Opus는 성격이 명확했습니다.

정말 어려운 문제
→ Opus

였습니다.

성능은 좋았지만 모든 Coding Task에 쓰기에는 부담이 있었습니다.

Opus 5.5에서는:

Input / Output 20% 인하

Cache Read 60% 인하

기본 Medium

적은 Turn

적은 Retry

빠른 Output

이 같이 들어왔습니다.

그래서 최고급 모델인데도 일상적인 Coding에 쓰기 훨씬 쉬워졌습니다.

---

27. Claude Code에서는 이렇게 시작하면 된다

복잡하게 생각할 필요 없습니다.

단순 반복 작업

Low

일반 개발

Medium

복잡한 Debugging

High

정말 어려운 문제

XHigh / Max

그리고 Medium이 한 번 틀렸다고 바로 High로 올리지 않습니다.

먼저:

Test가 있나?

Build를 돌릴 수 있나?

Agent가 자기 결과를 검증할 수 있나?

를 확인하는 편이 좋습니다.

---

28. 같은 작업에서 사용 한도 소모도 줄었다

Opus 5.5의 낮아진 가격은 Claude 구독 사용 한도에도 반영됩니다.

Anthropic 설명에 따르면 가격 차이만 놓고도 Opus 5보다 사용 한도가 약 25% 더 오래 갑니다.

여기에:

적은 Turn

적은 Retry

적은 Output

저렴한 Cache

가 같이 적용됩니다.

그래서 실제 사용자는 같은 시간 동안 더 많은 작업을 처리할 수 있습니다.

표현도:

사용량이 덜 줄어든다

보다는:

같은 작업에서 사용 한도 소모가 줄었다

가 정확합니다.

---

29. 그런데 이번에 더 중요한 숫자는 40%다

Opus 5.5에서 가장 눈에 들어오는 공식 수치는:

약 40% 낮아진 작업비용

입니다.

이건:

토큰을 40% 적게 쓴다

는 뜻이 아닙니다.

더 정확한 의미는:

가격 인하

+

Cache 비용 감소

+

필요한 Token 감소

+

Turn 감소

+

Retry 감소

를 합쳤을 때 같은 일을 완료하는 총비용이 약 40% 낮아졌다는 것입니다.

이쪽이 훨씬 중요한 변화입니다.

---

30. Opus 5에서 넘어간다면 High부터 다시 볼 필요가 있다

기존 설정이:

Opus 5
High

였다고 해서 5.5에서도 그대로 High를 유지할 필요는 없습니다.

먼저:

Opus 5.5
Medium

으로 같은 작업을 돌려보는 게 좋습니다.

충분하면 그대로 씁니다.

부족한 작업만 High로 올립니다.

이것만으로도:

Thinking

Latency

Token

사용 한도

를 꽤 줄일 수 있습니다.

---

31. Opus 5 → 5.5 Migration Checklist

API를 직접 쓰고 있다면 이 정도는 확인하는 게 좋습니다.

1. Model ID 변경

2. Thinking 설정 확인

3. 기본 Effort 다시 측정
   High부터 쓰지 말고
   Medium부터 시작

4. Tool Choice 변경사항 확인

5. Structured Output / Strict Tool Use 확인

6. Computer Use Toolset 확인

7. max_tokens 확인

8. Prompt Cache 동작 확인

9. CLAUDE.md / Skill 정리

10. 실제 Repository Task로
    Opus 5와 비용 비교

Benchmark보다 자기 프로젝트에서 Feature 하나, Bug 하나를 실제로 해결해보는 게 훨씬 정확합니다.

---

마치며

Claude Opus 5.5를 단순히:

Opus 5보다 더 좋은 모델

이라고 설명하면 이번 변화의 핵심을 놓치게 됩니다.

이번에는:

성능 ↑

가격 ↓

Cache 가격 ↓↓↓

기본 Effort
High → Medium

Thinking 효율 ↑

Turn ↓

Retry ↓

출력 속도 ↑

가 같이 움직였습니다.

그래서 가장 눈에 들어오는 숫자가:

Opus 5 대비 약 40% 낮아진 작업비용

입니다.

최고급 Opus를 쓰면서도 이전보다 부담이 크게 줄었습니다.

그리고 개발자에게는 숫자보다 더 중요한 변화가 있습니다.

예전에는:

좋은 품질이 필요하다
→ High

더 어려운 문제다
→ 더 오래 Thinking

에 가까웠다면,

이제는:

평소 개발
→ Medium

단순 작업
→ Low

정말 어려운 문제
→ High

정도로 시작할 수 있습니다.

더 오래 생각하게 만드는 것보다 필요한 만큼만 생각하게 하는 게 중요해졌습니다.

긴 Claude Code 세션에서는 여기에 Prompt Cache까지 잘 유지하면 비용 차이는 더 커집니다.

Opus 5.5를 한 문장으로 정리하면 이렇습니다.

성능 좋은 Opus가 하나 더 나온 게 아니라, 매일 써도 될 만큼 효율 좋은 Opus가 나왔습니다.

---

참고자료

Anthropic — Introducing Claude Opus 5.5
Opus 5.5의 성능 향상, Agentic Coding, Early Tester 사례와 비용 효율에 대한 공식 발표입니다.
Claude Opus 5.5 공식 발표

Claude — What a task costs on Opus 5.5
Token 단가만이 아니라 Turn, Retry, Thinking, Prompt Cache를 포함해 실제 Claude Code Task 하나의 비용이 어떻게 결정되는지 설명합니다. Claude Code에서 Effort 변경 시 Cache가 다시 작성될 수 있다는 부분도 확인할 수 있습니다.
Opus 5.5 작업 비용 분석

Claude Platform — Opus 5.5 Model Overview
1M Context, 128K Output, 300K Batch Output, 가격과 Prompt Cache 사양을 확인할 수 있습니다.
Opus 5.5 모델 사양

Claude Platform — Effort
Low·Medium·High·XHigh·Max의 역할과 Effort가 Thinking·Latency·비용에 미치는 영향, API의 Per-message Effort와 Cache 유지 방식을 설명합니다.
Claude Effort 공식 문서

Claude Platform — Prompting Claude Opus 5.5
Opus 5보다 30% 이상 빨라진 Output 생성과 Effort Calibration, Opus 5.5에 맞는 Prompt/Harness 작성 방법을 설명합니다.
Opus 5.5 Prompting Guide

Claude Platform — What's new in Opus 5.5
Inline Tool Addition, Compaction, Prompt Cache, Task Budget 등 Opus 5.5에서 지원하는 최신 Agent 기능을 정리한 공식 문서입니다.
Opus 5.5 새로운 기능

Claude Platform — Migration Guide
Opus 5에서 5.5로 변경할 때 Thinking 설정, Tool Choice, Computer Use Toolset 등 실제 코드에서 수정해야 하는 Breaking Change를 정리합니다.
Opus 5.5 Migration Guide

Claude Platform — Task Budgets
Effort가 각 단계의 추론 깊이를 조절한다면 Task Budget은 전체 Agent Loop가 소비할 작업량을 조절한다는 차이를 확인할 수 있습니다.
Task Budgets 공식 문서

Claude Platform — Fast Mode
동일 Opus 모델에서 최대 2.5배 높은 Output Token 속도를 제공하는 Research Preview 기능과 별도의 Premium 가격을 설명합니다.
Fast Mode 공식 문서