-
다중 LLM 제공자 간 상호운용성을 목표로 하는 오픈소스 규격과 생태계로, OpenAI Responses API를 기반으로 공통 인터페이스를 정의
- 요청과 응답을 공유 스키마로 기술해, 최소한의 변환 작업만으로 여러 모델 제공자에서 동일한 방식으로 실행 가능
- 메시지, 툴 호출, 스트리밍, 멀티모달 입력 등 공통 구성 요소를 일관된 구조로 정리해 에이전트 워크플로우 구현에 적합
- 안정적인 코어 위에 제공자별 확장을 허용하는 구조로, 확장성과 비분절성을 동시에 추구
- OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLM 등 다수 빌더 참여 커뮤니티 기반으로 운영
개요
- Open Responses는 OpenAI Responses API를 기반으로 한 오픈소스 규격과 도구 생태계
- 언어 모델 호출, 스트리밍 결과 처리, 에이전트 구성 작업을 제공자 독립적으로 수행 가능하도록 설계됨
- 공통 스키마와 툴링 계층을 통해 단일 인터페이스 경험 제공
왜 Open Responses인가
- LLM API들이 메시지, 툴 호출, 스트리밍, 멀티모달 입력 등 유사한 구성 요소를 공유하지만 각기 다른 인코딩 방식을 사용 중임
- Open Responses는 이를 통합하는 공개된 공통 규격을 제공해 중복 구현 부담을 줄임
- 한 번 정의한 요청과 출력 구조를 여러 제공자에 재사용 가능
설계 원칙
-
멀티 제공자 기본 설계로 단일 스키마가 다양한 모델 제공자에 매핑 가능
- 스트리밍 이벤트, 툴 호출 패턴, 모델 출력의 최소 단위로서 items 개념을 사용해 에이전트 워크플로우 친화적 구조 제공
- 일반화되지 않은 기능은 제공자별 확장을 허용하되, 코어 안정성 유지를 우선함
커뮤니티와 생태계
- 다중 벤더 환경을 전제로 한 오픈 커뮤니티 프로젝트로 운영됨
- OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLM 등 다양한 조직이 로고로 참여 표시됨
- 이식성, 상호운용성, 공통 기반을 중시하는 개발자 중심 커뮤니티 형성
스펙의 특징
-
Items 중심 공통 스키마로 메시지/툴 호출/추론 상태를 같은 단위로 표현, 입력도 출력도 item으로 오가는 구조
- 응답과 item을 상태 머신으로 정의해
in_progress→completed/failed/incomplete 같은 라이프사이클을 명시적으로 관리
- 스트리밍을 텍스트 조각이 아니라 semantic events로 표준화,
response.output_item.added로 시작해 delta→done으로 닫는 패턴 고정
- 툴을 외부 실행(개발자/서드파티) 과 내부 실행(제공자 호스팅) 으로 구분하고,
tool_choice/allowed_tools로 호출 가능 범위를 강제하는 제어면 제공
-
previous_response_id로 이전 입력+출력을 서버가 컨텍스트로 재구성해 대화 이어가기/재전송 최소화 지원, truncation으로 “자르기 허용 vs 초과 시 실패” 선택 가능
- 표준 밖 확장은
provider_slug: 접두어로 분리, 커스텀 hosted tool은 대응 item 타입을 반드시 제공해 로그/라운드트립 가능한 “영수증”을 남김
- 오류는 구조화된 error object로 반환하고, 스트리밍 중 오류는
response.failed 이벤트로 종료