Using OpenWebUI as model provider (custom provider in Goose)

[hdd]

Why ? The reason behind it was the lack of tool calls from Goose and the good results I was getting in OWUI .
The other reason is that being able to use OWUI as model provider would allow me to use meta models where I can specify the context lenght , the temperature etc.... as well as define how tools should be called (default or native).

You can see in the following config, the mrdev model, which is a metamodel with qwen3-vl:4b-instruct-q8_0 as base model.

results, tbh are now much better , hence sharing it here.

How though ?

create a folder called : custom_providers uinder the goose config folder
create a file in it with name: custom_open_web_ui.json

fill up this file with the following (adapt to your server address)

{ "name": "custom_open_web_ui", "engine": "openai", "display_name": "Open Web UI", "description": "Custom Open Web UI provider", "api_key_env": "CUSTOM_OPEN_WEB_UI_API_KEY", "base_url": "https://my.openwebui.server/api/chat/completions", "models": [ { "name": "qwen3-vl:4b-instruct-q8_0", "context_limit": 128000, "input_token_cost": null, "output_token_cost": null, "currency": null, "supports_cache_control": null }, { "name": "mrdev", "context_limit": 128000, "input_token_cost": null, "output_token_cost": null, "currency": null, "supports_cache_control": null } ], "headers": null, "timeout_seconds": 1800, "supports_streaming": false, "requires_auth": true }

please note, you'll be in need of enabling the api keys in your OpenWebUI instance , following this guide:
https://docs.openwebui.com/getting-started/advanced-topics/monitoring/

Hope this helps !

ps.
Wondering how hard would be to have an official OpenWebUI model provider , so models and metamodels could be pulled from without having to write them in the config

[DOsinga]

makes sense to me. what do you want to do with this? add it to the documentation or to the canonical providers? either way, send us a PR!

[hdd]

Hi @DOsinga , wish Rust was something I knew to help out with.
Atm I'm happy to use the custom provider as it is , as it seems to be working kind of fine, while waiting for local model tools to properly work.

The post was mostly to share a temporarly solution I found, and possibly , allow others with local llm to get the best out of Goose.
If you think is valuable for the docs, that's something i'm happy to help with .

Cheers.

[DOsinga]

well, the good news is that we're building native model inference straight into goose which should mean no more mucking around with ports, context windows etc. keep an eye out for it, it should soon be in main and then released. we would be very much looking for people like you to figure out what works, what doesn't and what could work better if we had the right parameters

[hdd]

due to my laptop not having much of ram or gpu, I'm currently relying on an old rig with some ram and an old GPU, hence preferring remote providers, but I'll surely look into anything you are going to push out.

I'm loving this tool ;)

[mavpath]

I also want to use OpenWebUI as a provider because of the meta models and the customizations that can be made.
I added an openai compatible provider, but i get every token as new line.

Could somebody steer me in the right direction?

[Stitch10925]

This is already possible, I think.

OpenWebUI exposes OpenAPI-compatible endpoints. If you add an OpenAPI provider to Goose with the following:

OpenAI Host: http://{your OWUI url}/api
OpenAI Base Path: v1/chat/completions

And your OWUI api key, you should be able to select the models from the list. This includes workspaces, so you can configure your workspace and use it in Goose.

[richardchen874-sys]

This is a useful custom-provider thread because Goose-style agent runs need more than just a base URL. Context limits, token costs, cache support, and provider quirks all matter once the agent starts doing multi-step work.

A few fields I’d want to keep explicit per model:

• input/output token cost
• context limit and cache support
• streaming/tool-call reliability
• fallback provider or alternate model
• budget per session or task

I'm building a private-beta OpenAI-compatible API aggregation layer focused on Chinese models like DeepSeek / Qwen / GLM-style providers, using official-provider keys. If you want to test official-key Chinese model endpoints in a Goose custom-provider setup, I’d be happy to share some test credits.

Curious: is your main goal local OpenWebUI routing, cheaper hosted models, or better model metadata inside Goose?