# GPT-6 Astra · Fable 5.1: 오래 일하는 AI, 빠르게 쌓이는 실행 비용

Author: Jaeho Shin / 신재호
Date: 2026-09-08
Updated: 2026-09-09
Category: Models & Cost
Canonical: https://www.viberick.com/notes/astra-fable-practical-cost

입력 $10·출력 $50/백만 토큰. 고성능 모델을 긴 Agent 작업에 쓸 때 캐시, 추론, 재시도와 실행 예산이 중요한 이유.

## Workflow overview

1. 완료 기준
2. 실행 예산
3. 모델·도구
4. 검수·총비용

평가 설계이며 모델 성능 실측치가 아니다. 토큰 요율과 앱 구독 한도는 구분한다.


## 한 번 답하는 모델에서 오래 일하는 모델로

**Astra와 Fable 5.1을 도입할 때 달라지는 질문은 ‘답변 한 번에 얼마인가’가 아니라 ‘이 일을 어디까지 맡기고 언제 멈출 것인가’다.** 모델이 여러 파일과 도구를 오가며 오래 작업할수록 한 실행의 입력·출력과 재시도가 쌓인다.

이것을 새로운 작업 방식이라고 보는 것은 이 글의 해석이다. 두 모델을 VibeRick이 같은 조건에서 실측해 우열을 가렸다는 뜻은 아니다. “토큰이 녹는다”는 체감은 실행 단위의 사용량을 봐야 검증할 수 있다.

## 현재 확인한 기본 요율

2026년 9월 9일 표준 텍스트 API 기준으로 두 모델 모두 입력 $10, 출력 $50/백만 토큰이다. Astra의 캐시 읽기는 $1, 쓰기는 $12.50이다. 입력이 272K를 초과하면 요청 전체에 입력·캐시 2배, 출력 1.5배 요율이 적용된다. [Astra 공식 명세](https://developers.openai.com/api/docs/models/gpt-6-astra).

Fable 5.1은 캐시 읽기 $0.25, 5분 쓰기 $12.50, 1시간 쓰기 $20/백만 토큰이다. 공식 문서는 일반 작업에서 먼저 Opus 5를 검토하고, 더 어려운 장기 작업에 Fable을 고려하도록 안내한다. [Fable 5.1 공식 명세](https://platform.claude.com/docs/en/models/fable-5-1/overview).

API 요율과 앱 구독 한도는 같은 표가 아니다. 사용 환경, 처리 모드, 리전과 도구 요금을 확인하고 비교한다. 이 글의 금액은 사용자 계정의 실제 청구서나 구독 한도를 추정한 값이 아니다.

## 20번 반복하면 어떻게 되는가

단순 비교를 위해 캐시·장문 할증·도구 비용을 제외하고, 매 호출에 입력 100,000토큰과 청구 대상 출력 5,000토큰을 쓴다고 가정하자.

```text
호출당 입력   0.1M × $10    = $1.00
호출당 출력   0.005M × $50  = $0.25
20회 실행     20 × $1.25    = $25.00
```

이것은 예산 감각을 위한 계산이지 두 모델의 실제 평균 작업비가 아니다. 출력이 짧거나 캐시가 적중하면 줄고, 컨텍스트가 커지거나 재시도하면 늘어난다. 캐시 쓰기까지 계산하면 단순 입력 요율과도 달라진다.

중요한 것은 호출 한 번이 저렴해 보인다는 이유로 전체 실행을 무제한으로 두지 않는 것이다. 상세한 재사용 비용은 [프롬프트 캐싱 가이드](/notes/prompt-caching-in-production)에서 다룬다.

## 추론과 도구 결과도 예산의 일부

사용자에게 보이는 마지막 문장이 짧다고 전체 작업이 짧았던 것은 아니다. 모델의 추론 사용량, 검색 결과, 읽은 파일과 테스트 출력까지 실행 기록을 확인한다. 캐시가 있어도 새로 생긴 컨텍스트와 결과 생성은 공짜가 아니다.

도구가 큰 로그를 그대로 반환하면 다음 호출의 읽을 거리가 늘어난다. 같은 실패를 설명 없이 반복하면 출력과 도구 실행이 함께 낭비된다. 먼저 결과를 요약 가능한 구조로 만들고, 실패 원인별 재시도 상한을 둔다.

비용이 늘었다고 곧바로 모델 탓을 하기 전에 무엇을 반복해서 읽었는지 살펴보자. 긴 작업에서 도구와 컨텍스트 관리의 영향이 더 잘 드러난다.

## 고성능 모델을 쓸 구간을 정한다

내 추천은 간단한 분류·포맷 변환과 어려운 설계·검증을 구분하는 것이다. 모든 업무를 최고가 모델에 고정하지 않는다. 반대로 복잡한 문제에서 싼 모델의 실패를 여러 번 반복하는 것도 비용 절감이 아닐 수 있다.

모델 전환은 실제 평가를 통과해야 한다. 결과 형식과 도구 사용, 실패 처리 방식이 모델마다 같다고 가정하지 않는다. 재사용 가능한 캐시가 모델 전환 후에도 유지된다고 기대해서도 안 된다.

[Fable 5.1 문서](https://platform.claude.com/docs/en/models/fable-5-1/overview)는 강제 도구 사용과 이전 thinking block 호환성 등 마이그레이션 변화도 설명한다. 모델 ID만 바꿔 운영에 넣기 전에 해당 작업의 API 계약을 확인한다.

## 실행 전에 정할 네 가지

1. **완료 기준:** 어떤 파일, 테스트, 근거가 있어야 완료인가.
2. **비용 상한:** 한 작업과 하루 전체에 얼마까지 쓸 수 있는가.
3. **시간 상한:** 어디서 중간 결과를 저장하고 멈출 것인가.
4. **중단 기준:** 같은 실패, 권한 오류, 불필요한 반복을 어떻게 감지할 것인가.

“예산을 아껴”라는 프롬프트만으로 지출을 통제하지 않는다. 애플리케이션에서 사용량과 실행 횟수를 집계하고 중단 조건을 적용한다. 병렬 subagent는 각각의 비용을 부모 작업에 합산한다.

## Quality · Latency · Cost로 비교한다

실제 업무 몇 개를 고정해 검수 통과율, 전체 완료 시간, 총비용을 비교한다. 테스트가 통과했다는 주장만 받지 말고 산출물과 테스트 결과를 남긴다. 사람이 다시 고친 시간도 따로 기록한다.

고성능 모델이 가치 있는 곳은 비싼 토큰을 많이 쓰는 곳이 아니라, 이전에 해결하지 못한 업무를 검수 가능한 결과로 끝내는 곳이다. [좋은 Agent 설계](/notes/what-makes-a-good-agent)의 세 축이 그 판단 기준이다.