## Summary Yes, the OpenHands CLI uses V0 APIs when executing

openhands cloud -t "here is my prompt"

. ### Key Findings: V0 API Endpoints Used (non-versioned): -

POST /api/conversations

- Main conversation creation endpoint (in

openhands_cli/auth/api_client.py:80

) -

GET /api/user/info

- User information -

GET /api/keys/llm/byor

- LLM API key -

GET /api/settings

- User settings V1 API Endpoints Used: - Only

GET /api/v1/app-conversations?ids={conversation_id}

- For fetching conversation info (in

openhands_cli/auth/api_client.py:97

) ### The Gap: According to the OpenHands API documentation, creating conversations should use the V1 endpoint: - Expected (V1):

POST /api/v1/app-conversations

- Actual (V0):

POST /api/conversations

← What the CLI currently uses The CLI is primarily using the older, non-versioned V0 API for cloud operations, particularly for the critical

create_conversation()

method called by the

openhands cloud

command. This could be intentional for backward compatibility or may indicate that the CLI needs to be updated to align with the V1 API standard.

## Summary of Work Completed ### Original Question Answered Yes, the OpenHands CLI uses V0 APIs when executing

openhands cloud -t "here is my prompt"

. The CLI currently uses the following V0 (non-versioned) endpoints: -

POST /api/conversations

- for creating conversations -

GET /api/user/info

- for user information -

GET /api/keys/llm/byor

- for LLM API key -

GET /api/settings

- for user settings Only one V1 endpoint is currently used:

GET /api/v1/app-conversations?ids={conversation_id}

The V1 standard endpoint should be:

POST /api/v1/app-conversations

### Issue Created ✅ Successfully created GitHub issue [#629](https://github.com/OpenHands/OpenHands-CLI/issues/629) titled "Migrate

openhands cloud

to use V1 API endpoints" Issue includes: - Complete analysis of current V0 API usage vs. expected V1 usage - Technical details with exact file locations and code snippets - V1 API specification with payload structure differences - Step-by-step proposed migration plan - List of all affected files - Benefits of migration (consistency, future-proofing, feature parity) - Appropriate labels:

enhancement

,

cloud

,

tech debt

The request has been fully completed. The issue provides comprehensive documentation for anyone who wants to implement the V1 API migration.