[GSoC 2026] OpenHands + OVMS Integration — first contactt

[devesh-047]

Hello Michal and Milosz,

I’ve been working on the “OpenHands + OpenVINO Model Server” project idea and built an initial prototype to understand the scope before drafting a formal proposal.

OVMS is running (Docker, CPU-only) serving a quantized TinyLlama model via the MediaPipe LLM pipeline. I’ve validated /v3/chat/completions, streaming behavior, and documented observed OpenAI-compatibility gaps.

Full details, gap notes, and my tentative 90-hour execution plan are here: https://github.com/devesh-047/openhands-openvino-integration/blob/master/docs/gsoc/gsoc_first_contact.md

Before proceeding to full OpenHands integration, I’d appreciate your feedback on whether this direction aligns with expectations — especially regarding model size and how to handle strict OpenAI schema gaps.

Thank you for your time.

[devesh-047]

@adrianboguszewski and @mlukasze can you help me connect with the mentors. I am unable to tag them here. Thanks.

[adrianboguszewski]

Please tag the mentors. All mentors are listed for each project.

[devesh-047]

@michalkulakowski @mzegla

[michalkulakowski]

Hi @devesh-047,
we looked at the document you provided. When it comes to the gaps you mention, OVMS supports:

• object, created, model response fields for chat completion
• function calling
• usage with streaming
• v1 api (just requires adding v3/ in endpoint url before v1)

In fact only gap is "id" field which OVMS in fact omits in responses. But i wonder if that's an blocker for integration? We uses Openai python client an that have never been a problem.

[devesh-047]

@michalkulakowski,

Thank you for the clarification — that’s very helpful.

Regarding the id field, my earlier note was based on testing with the openai Python client where the response model defines id as a required field in the schema. I observed a validation issue in one of my local tests, but I haven’t yet verified this against the exact client version and configuration used by OpenHands.

I’ll re-test using the same dependency stack as OpenHands to confirm whether the missing id is actually a practical integration blocker or just a schema-level difference. If it turns out not to affect real usage, I’ll update the gap classification accordingly.

Thanks again for pointing this out.

Devesh

[devesh-047]

@michalkulakowski @mzegla,

I’ve completed the end-to-end OpenHands + OVMS integration and documented the results and y observations. The github url is :https://github.com/devesh-047/openhands-openvino-integration

What works:
-OVMS serves /v3/chat/completions (non-streaming + SSE) correctly
-OpenHands connects over Docker network and sends full agent prompts
-End-to-end request/response loop functions locally (CPU-only)
-Direct inference via curl/Python behaves as expected

What is not working (WSL2, 8 GB limit):
-TinyLlama (2K context) → system prompt exceeds context window
-Phi-3.5-mini (3.8B) → loads but crashes on inference (OOM, exit code 137)
-Qwen2.5-0.5B (32K context) → runs reliably, but cannot follow CodeActAgent’s structured tool format; responses are hallucinated and slow due to large prompt prefill

So far, the integration is architecturally sound. The limiting factor appears to be model capacity and memory constraints rather than API compatibility.

Detailed observations and memory breakdowns are in:
-docs/observations.md
-docs/troubleshooting_history.md
-README

I’d appreciate guidance on whether the 90-hour scope should focus on architectural validation + hardware sizing guidance, or target demonstration with a 7B-class model on ≥16GB RAM.

This image shows the working , But the answer is a visible hallucination. Also it take a long time for response generation. The above response was received after around 10 minutes .

Do let me know your thoughts and suggestions on the demo.

[devesh-047]

@michalkulakowski , @mzegla,

Just a quick follow up on the integration update I shared earlier.
I’ve continued testing and refining the repository
(benchmarking models and documenting hardware constraints).

any feedback on the direction of work would be appreciated

[michalkulakowski]

@devesh-047
appreciate that you are so eager to work on our project, but i think that you should focus right now on submitting your proposal through GSOC webapp, This would give us chance to review and evaluate it.

[devesh-047]

@michalkulakowski ,
I am working on some final changes to my proposal...will be submitting it in the next 24 hrs.

Thanks for you guidance

[devesh-047]

@michalkulakowski, @mzegla
I have submitted my proposal on the gsoc web app . Please review it and let me know your thoughts.

Thanks for your guidance.

[devesh-047]

@michalkulakowski ,

Since the application period for GSoC 2026 is nearing its deadline,I would appreciate some feedback on the proposal I have submitted on the GSoC portal. Thank you for your guidance throughout this period.