calm-artist-7206
08/17/2026, 5:06 PMfresh-machine-37269
08/17/2026, 5:06 PMfresh-machine-37269
08/17/2026, 5:34 PMcalm-artist-7206
08/17/2026, 5:35 PMfresh-machine-37269
08/17/2026, 6:03 PMcalm-artist-7206
08/17/2026, 6:07 PMfresh-machine-37269
08/17/2026, 6:23 PMmain had since added 56_structured_output.py and 57_prompt_hooks, which collided with the PR's 56_ask_oracle_tool directory. This is why the PR was in CONFLICTING state.
2. check-examples failure: the new example wasn't documented in the OpenHands/docs repo, and the existing docs PR #566 was stale (referenced a removed oracle_llm_profile setting and the old 55_ path).
3. One unresolved review thread flagging that the PR description contradicted the implementation (the old oracle_llm_profile claim vs. the actual convention-based oracle profile design).
What I did
⢠Rebased/merged main into feat/ask-oracle-tool and resolved the conflict, then renumbered the example to 58_ask_oracle_tool (updating tests/examples/test_examples.py, the .pr/ evidence files, and the example's own docstring). The PR is now mergeable: True.
⢠Updated the docs PR (#566) in OpenHands/docs to match: it now documents the convention-based oracle profile (no oracle_llm_profile setting) and references 58_ask_oracle_tool.
⢠Updated the SDK PR description to remove the stale `oracle_llm_profile`/`54_ask_oracle`/`gpt-5-nano` references while leaving the HUMAN: section untouched.
⢠Resolved the last review thread with a reply explaining the description is now fixed.
⢠Marked the PR ready for review (draft: False).
Remaining CI note: the Python API, REST API (OpenAPI), Check OpenAPI Schema, and Update PR description checks show red on the latest commit, but I confirmed locally these are environmental ā the SDK API breakage check passes (No breaking changes detected), uv sync --frozen succeeds, and the OpenAPI export works; the job logs show GitHub API 503 "No server available" errors. They should turn green on re-run once GitHub's API stabilizes.calm-artist-7206
08/17/2026, 6:26 PMmodern-fireman-99755
08/17/2026, 6:40 PMcalm-artist-7206
08/18/2026, 12:08 PMfresh-machine-37269
08/18/2026, 12:08 PMfresh-machine-37269
08/18/2026, 12:32 PMask_oracle executor loaded its profile via LLMProfileStore().load() and called make_llm_completion() directly, bypassing the conversation's llm_registry. That meant Oracle token/cost usage never reached ConversationStats, and the code touched the private conversation._cipher.
Fix (pushed as a66c2a529):
⢠Switched to conversation.get_or_create_profile_llm(profile_name="oracle", usage_id="oracle:oracle"), matching vision_inspect.
⢠This registers the Oracle LLM in the registry so its metrics are tracked in conversation stats, binds conversation context (prompt-cache/session affinity), caches across calls, and removes the direct _cipher access.
⢠Added a conversation is None guard returning an error observation, consistent with switch_llm.
⢠Updated the two affected tests.
Verification: ask_oracle tests (6), the example-discovery test, ruff check, ruff format, and full pre-commit (incl. pyright and import-dependency rules) all pass. I also replied to the two open inline threads explaining the change.
The remaining review notes were either already resolved (the .pr/ artifacts are auto-cleaned on approval, and the PR description was already updated to drop the stale oracle_llm_profile claim) or minor/non-blocking (the response field duplication and the broad except, both flagged as harmless/consistent with existing patterns).