OpenAI, 공식 CLI 공개…터미널에서 API를 그대로 다룬다
OpenAI CLI
OpenAI가 REST API를 명령줄에서 바로 쓸 수 있는 공식 CLI를 내놨다. Homebrew나 Go로 설치하고, API 키만 넣으면 responses, files, images 같은 명령으로 API를 호출한다. JSON 응답은 기본적으로 읽기 좋은 텍스트로 출력되고, --format json으로 스크립트에 맞출 수 있다. 업데이트 확인은 일주일에 한 번 조용히 돌고, 자동 설치는 하지 않는다.
The CLI never installs updates automatically.
HN 토론
109- nater5000
기술 사용자들을 대상으로 하는 사이트인데, 이 스레드의 많은 사람들이 하나의 서비스가 특정 사용 사례에 특화된 여러 소프트웨어를 제공할 수 있다는 개념 자체를 완전히 이해하지 못하는 것 같다.
codex: OpenAI의 에이전트 하네스. OpenAI 모델로 구동되는 에이전트가 네 머신에서 뭔가를 하도록 하고 싶을 때 일반적으로 상호작용하게 되는 물건. API의 저수준 기능을 추상화해서 신경 쓸 필요 없게 해준다.
openai-cli: OpenAI의 REST API에 대한 저수준 작업을 노출하는 단순한 CLI. completions API를 직접 호출하는 저수준 스크립트를 만들거나 계정을 관리하는 등의 용도로 쓰는 물건.
솔직히 말해서, 이름만 봐도 명백하다. 이게 명확하지 않다면, 이건 너를 위한 게 아니다. 네가 타깃이 아닌 소프트웨어를 OpenAI가 출시한다고 해서 흥분할 필요는 없다.
- kristopolous
나는 약 1년 동안 llcat이라는, 비슷한 부류의 무언가를 작업해 왔다.
cURL, awk, sed처럼 작동하는 LLM 네이티브 유닉스 친화적 도구가 부족해서 태어났다.
아무것도 찾을 수 없어서 직접 하나 작성했다.
나는 상태가 없고, 명시적이며, 저수준이고, 모달 설정 없이 조합 가능한 레퍼런스를 원한다는 것을 알고 있었다.
예를 들어, 설정 파일 대신 llcat은 내장 jq 문법과 줄 번호로 파일을 인덱싱할 수 있다. 그런 다음 호출을 나중을 위해 저장할 수 있다:
llcat --save invocation.json \
-k "@~/credentials.txt:12" \
-u "@settings.json:.[3].host" \
-s "@system_prompts:8" \
-m "@settings.json:.[3].model" \
"@query.txt:12" > output.txt
그리고 나서
llcat --load invocation.json { ... 덮어쓰고 싶은 매개변수 ... }
채팅으로 동료에게 보내거나 공유 네트워크 폴더에 호출을 보관하기 쉽다.
대화도 그냥 JSON 파일이다. 입력과 출력을 다르게 할 수 있다. 이는 다음과 같은 것을 할 수 있다는 뜻이다
for i in *; do
# 변경 불가능한 대화 사용
# 표준 유닉스 파이프로 파일 그룹에 적용
cat "$i" | llcat --load settings.json -cr context.json > ../results/"${i}.output"
# 또는 첨부 파일 사용
llcat --load settings.json -a "$i" -cr context.json > ../results/"${i}.output"
# 또는 전체 컨텍스트 저장
llcat --load settings.json -a "$i" -cr context.json -c ../results/"${i}.output" > /dev/null
done
내가 가장 좋아하는 패턴 중 하나는 이것이다: […]
- isodev
잠깐, codex가 "openai cli" 아니었나?
제품 이름이 너무 혼란스럽다 (chat, vs. work ?!).. 거의 전체가 vibecoded된 것 같다.
- techgnosis
아이러니하게도 나는 Codex로 이걸 5분 만에 만들어 줄 수 있었다. 공개된 API가 있다면, CLI는 항상 손 닿는 곳에 있다.
- mi_lk
언제 Codex 대신 이걸 써야 하나? 이건 다른 도구/에이전트가 호출하도록 만들어진 건가?
- guyuedumingx
이름만으로 도구를 설명한다는 주장은 약하다: CLI 래퍼라도 어떤 문제를 해결하고 누가 써야 하는지 한 줄은 필요하다.
- albert_e
이건 월정액 구독 쿼터를 소모하나, 아니면 API 크레딧을 소모하나.
Anthropic에도 비슷한 게 있나.
"claude -p"는 구독 쿼터와 함께 쓰기 불안정했고 종종 "추가 사용" 크레딧이 필요했다고 이해하고 있다.
- hahahacorn
내 생각에 전략은 모델이 가장 효율적으로 사용할 줄 아는 자체 도구로 문제를 해결하도록 RL을 돌려서, 결국 관리형 에이전트 같은 서비스를 기본으로 사용하게 만드는 것 같다.
솔직히 이게 더 일찍 나오지 않았다는 게 놀랍다.