Files
OpenHands/openhands
openhands 611f2f7662 refactor: single source of truth for verified models
Move all verified-model knowledge into the backend so the frontend no
longer duplicates it.

Backend (openhands/utils/llm.py):
- Add get_openhands_models() — returns OPENHANDS_MODELS (self-hosted)
  or the database list (SaaS) through a single entry point.
- Add _assign_provider() — prefixes bare LiteLLM names (gpt-5.2,
  claude-opus-4-6, …) with their canonical provider before sending
  to the frontend.  Tables moved from the frontend's
  verified-models.ts.
- get_supported_llm_models() now returns a ModelsResponse pydantic
  model containing: models (flat list, pre-prefixed), verified_models,
  verified_providers, default_model.

Frontend:
- verified-models.ts reduced to a single DEFAULT_OPENHANDS_MODEL
  constant.  All 6 exported arrays are deleted.
- extract-model-and-provider.ts no longer carries hardcoded provider
  lookup tables — pure parsing only.
- ModelSelector, SettingsForm, settings-modal now receive
  verifiedModels / verifiedProviders as props from the API response.
- useAIConfigOptions unpacks the structured ModelsResponse.

Co-authored-by: openhands <openhands@all-hands.dev>
2026-03-16 17:52:15 +00:00
..
2026-02-25 05:11:13 -07:00
2025-10-14 02:16:44 +00:00
2024-08-26 01:31:37 -06:00
2025-10-14 02:16:44 +00:00

OpenHands Architecture

This directory contains the core components of OpenHands.

For an overview of the system architecture, see the architecture documentation (v0 backend architecture).

Classes

The key classes in OpenHands are:

  • LLM: brokers all interactions with large language models. Works with any underlying completion model, thanks to LiteLLM.
  • Agent: responsible for looking at the current State, and producing an Action that moves one step closer toward the end-goal.
  • AgentController: initializes the Agent, manages State, and drive the main loop that pushes the Agent forward, step by step
  • State: represents the current state of the Agent's task. Includes things like the current step, a history of recent events, the Agent's long-term plan, etc
  • EventStream: a central hub for Events, where any component can publish Events, or listen for Events published by other components
    • Event: an Action or Observeration
      • Action: represents a request to e.g. edit a file, run a command, or send a message
      • Observation: represents information collected from the environment, e.g. file contents or command output
  • Runtime: responsible for performing Actions, and sending back Observations
    • Sandbox: the part of the runtime responsible for running commands, e.g. inside of Docker
  • Server: brokers OpenHands sessions over HTTP, e.g. to drive the frontend
    • Session: holds a single EventStream, a single AgentController, and a single Runtime. Generally represents a single task (but potentially including several user prompts)
    • ConversationManager: keeps a list of active sessions, and ensures requests are routed to the correct Session

Control Flow

Here's the basic loop (in pseudocode) that drives agents.

while True:
  prompt = agent.generate_prompt(state)
  response = llm.completion(prompt)
  action = agent.parse_response(response)
  observation = runtime.run(action)
  state = state.update(action, observation)

In reality, most of this is achieved through message passing, via the EventStream. The EventStream serves as the backbone for all communication in OpenHands.

flowchart LR
  Agent--Actions-->AgentController
  AgentController--State-->Agent
  AgentController--Actions-->EventStream
  EventStream--Observations-->AgentController
  Runtime--Observations-->EventStream
  EventStream--Actions-->Runtime
  Frontend--Actions-->EventStream

Runtime

Please refer to the documentation to learn more about Runtime.