토큰비 때문에 시간당 횟수 제한을 거셨다고 하셔서, 입력 쪽을 줄이는 방법을 적어 봅니다. Claude API 문서 기준입니다. 캐릭터챗은 캐릭터 설정과 시나리오가 요청마다 그대로라 프롬프트 캐싱이 잘 맞는 형태입니다. 다만 캐싱은 앞에서부터 일치하는지를 보는 방식이라, 캐시 구간 앞쪽이 한 글자라도 바뀌면 그 뒤가 전부 무효가 됩니다. 문서에 적힌 조립 순서는 tools, system, messages 순이고, 그래서 고정된 설정을 앞에 두고 매번 달라지는 값은 마지막 캐시 지점 뒤로 미루라고 되어 있습니다. 시스템 프롬프트에 현재 시각을 찍어 넣으면 캐시가 통째로 안 걸립니다.
걸렸는지 확인하는 법도 같이 적습니다. 응답의 usage 에 cache_read_input_tokens 가 따로 오는데, 요청을 반복해도 이 값이 계속 0이면 위 같은 무효화 요인이 하나 섞여 있는 것입니다. 캐시 지점은 요청당 네 개까지 잡을 수 있고, 최소 길이보다 짧은 구간은 오류 없이 조용히 캐시되지 않습니다. 최소 길이는 모델마다 달라서 512에서 4096 토큰 사이입니다.
시간당 60회는 계정당으로 거신 건지 아이피 기준인지 궁금합니다. 그리고 제한을 두신 이유가 모델 쪽에서 429가 떨어지는 걸 피하려는 것이라면, 429 응답에 retry-after 가 같이 오니 고정 대기보다 그 값을 그대로 쓰시는 쪽이 낫습니다.
@쩐의여왕님 답변 감사합니다. 답변을 다 이해하지는 못해서 ai와 함께 고민해보고 개선해보겠습니다. 시간당 60회 제한은 회원 가입없이 사용하는 형태라 기기 기준입니다. 실사용자가 많지는 않은데 일부 악용사례로 비용이 많이 나온 경험이 있어서요. 429응답이 서버측에서 나올때가 있는데 그 문제해결에 참조하겠습니다.
쩐의여왕
IP 183.♡.71.161
09-17
2026-09-17 12:24:57
·
@carbo님 가입 없이 쓰는 구조면 기기 기준 말고는 잡을 게 마땅치 않겠습니다. 429가 Claude API 에서 오는 거라면 문서에 적힌 걸 몇 가지 더 보탭니다.
한도는 분당 요청 수, 분당 입력 토큰, 분당 출력 토큰 세 가지가 모델마다 따로 걸려 있고, 어느 하나라도 넘으면 429와 함께 retry-after 헤더에 기다릴 초가 옵니다. 정해진 시각에 한꺼번에 풀리는 방식이 아니라 토큰 버킷이라 조금씩 차오르고, 분당 60회가 초당 1회처럼 짧게 잘려 적용될 수 있어서 요청이 한꺼번에 몰리면 한도 아래여도 걸린다고 되어 있습니다.
비용 문제를 겪으셨다면 하나 갈라 보실 게 있습니다. 월 지출 한도에 닿았을 때도 같은 429가 오는데, 이때는 retry-after 가 없고 error.details.error_code 가 enforced_spend_limit_reached 로 와서 재시도해도 계속 실패합니다. 두 경우를 같은 재시도 로직으로 받으면 후자에서 헛돌게 됩니다.
그리고 캐시에서 읽힌 입력 토큰은 대부분 모델에서 분당 입력 토큰 한도에 안 잡힌다고 되어 있어서, 캐싱이 비용뿐 아니라 429 빈도에도 도움이 됩니다.
@쩐의여왕님 월한도보다는 소수가 너무 많은 비용을 사용하거나 갑자기 몰리는 것을 방지하는데에 신경을 많이 써둔 상태입니다. 기대한것보다 적은 사람이 플레이하는 것 같습니다. 이 글도 조회수가 400회가 넘었는데 ep1을 클리어횟수는 4회뿐이네요. (월 한도는 넉넉한 편입니다.) 요즘 3d게임도 원샷 프롬프트로 만드는 수준이 되어버린 것에 비해 이게임은 상대적으로 정적이어서 손이 잘 안가는 모양입니다. 애초에 많은 사람이 즐겼으면 좋겠다는 마음으로 개발하긴 했지만, 이제 여기에 공개한 것은 다른 개발하시는 분들에게도 아이디어를 공유하고 싶다는 마음만 남은 것 같습니다.
쩐의여왕
IP 183.♡.71.161
09-18
2026-09-18 12:26:44
·
@carbo님 월 한도가 넉넉하시면 지금 거신 제한은 갑자기 몰리는 비용을 막는 용도로 제 역할을 하고 있는 셈이네요.
조회 400에 ep1 클리어 4회면, 그 사이를 한 번 나눠 보시면 어디서 빠지는지 갈릴 것 같습니다. 들어와서 한 줄도 안 친 사람, 몇 번 주고받다 멈춘 사람, 끝까지 갔는데 못 푼 사람은 고칠 곳이 서로 다르니까요. 앞쪽이 많으면 첫 화면에서 목표와 첫 마디 예시를 더 드러내는 쪽이고, 중간이 많으면 캐릭터가 목표 쪽으로 대화를 끌고 가는 힘을 보는 쪽입니다.
걸렸는지 확인하는 법도 같이 적습니다. 응답의 usage 에 cache_read_input_tokens 가 따로 오는데, 요청을 반복해도 이 값이 계속 0이면 위 같은 무효화 요인이 하나 섞여 있는 것입니다. 캐시 지점은 요청당 네 개까지 잡을 수 있고, 최소 길이보다 짧은 구간은 오류 없이 조용히 캐시되지 않습니다. 최소 길이는 모델마다 달라서 512에서 4096 토큰 사이입니다.
시간당 60회는 계정당으로 거신 건지 아이피 기준인지 궁금합니다. 그리고 제한을 두신 이유가 모델 쪽에서 429가 떨어지는 걸 피하려는 것이라면, 429 응답에 retry-after 가 같이 오니 고정 대기보다 그 값을 그대로 쓰시는 쪽이 낫습니다.
답변 감사합니다.
답변을 다 이해하지는 못해서 ai와 함께 고민해보고 개선해보겠습니다.
시간당 60회 제한은 회원 가입없이 사용하는 형태라 기기 기준입니다.
실사용자가 많지는 않은데 일부 악용사례로 비용이 많이 나온 경험이 있어서요.
429응답이 서버측에서 나올때가 있는데 그 문제해결에 참조하겠습니다.
한도는 분당 요청 수, 분당 입력 토큰, 분당 출력 토큰 세 가지가 모델마다 따로 걸려 있고, 어느 하나라도 넘으면 429와 함께 retry-after 헤더에 기다릴 초가 옵니다. 정해진 시각에 한꺼번에 풀리는 방식이 아니라 토큰 버킷이라 조금씩 차오르고, 분당 60회가 초당 1회처럼 짧게 잘려 적용될 수 있어서 요청이 한꺼번에 몰리면 한도 아래여도 걸린다고 되어 있습니다.
비용 문제를 겪으셨다면 하나 갈라 보실 게 있습니다. 월 지출 한도에 닿았을 때도 같은 429가 오는데, 이때는 retry-after 가 없고 error.details.error_code 가 enforced_spend_limit_reached 로 와서 재시도해도 계속 실패합니다. 두 경우를 같은 재시도 로직으로 받으면 후자에서 헛돌게 됩니다.
그리고 캐시에서 읽힌 입력 토큰은 대부분 모델에서 분당 입력 토큰 한도에 안 잡힌다고 되어 있어서, 캐싱이 비용뿐 아니라 429 빈도에도 도움이 됩니다.
월한도보다는 소수가 너무 많은 비용을 사용하거나 갑자기 몰리는 것을 방지하는데에 신경을 많이 써둔 상태입니다.
기대한것보다 적은 사람이 플레이하는 것 같습니다.
이 글도 조회수가 400회가 넘었는데 ep1을 클리어횟수는 4회뿐이네요. (월 한도는 넉넉한 편입니다.)
요즘 3d게임도 원샷 프롬프트로 만드는 수준이 되어버린 것에 비해 이게임은 상대적으로 정적이어서 손이 잘 안가는 모양입니다.
애초에 많은 사람이 즐겼으면 좋겠다는 마음으로 개발하긴 했지만, 이제 여기에 공개한 것은 다른 개발하시는 분들에게도 아이디어를 공유하고 싶다는 마음만 남은 것 같습니다.
조회 400에 ep1 클리어 4회면, 그 사이를 한 번 나눠 보시면 어디서 빠지는지 갈릴 것 같습니다. 들어와서 한 줄도 안 친 사람, 몇 번 주고받다 멈춘 사람, 끝까지 갔는데 못 푼 사람은 고칠 곳이 서로 다르니까요. 앞쪽이 많으면 첫 화면에서 목표와 첫 마디 예시를 더 드러내는 쪽이고, 중간이 많으면 캐릭터가 목표 쪽으로 대화를 끌고 가는 힘을 보는 쪽입니다.
아이디어 공유로 올려주신 글이라 반갑게 읽었습니다. 추리 시나리오까지 가시면 또 올려주세요.