Forge

Forge has a built-in openai_compatible provider slot. The easiest path is the interactive menu:

forge provider login
# choose "openai_compatible", then enter your base URL and API key when prompted

This writes an entry to ~/.forge/.credentials.json shaped like this (confirmed from a real, already-configured Forge installation pointed at DodoRouter):

{
  "id": "openai_compatible",
  "auth_details": { "api_key": "sk-dodo-YOUR_KEY" },
  "url_params": { "OPENAI_URL": "{base_url}/r/{router}/v1" }
}

and sets in ~/.forge/.forge.toml:

[session]
provider_id = "openai_compatible"
model_id = "default"

Then run forge as usual, or non-interactively with forge -p "your prompt".

Verified with a caveat

We pointed a real Forge installation at a live DodoRouter router using exactly this config and it connected, authenticated, and completed several successful tool-calling turns (each logged by DodoRouter as HTTP 200 with the correct content). During one longer automated run, Forge's own client logged "Empty completion received" and retried repeatedly on a turn where DodoRouter's logs show it actually returned a perfectly valid response (right content, finish_reason: "stop"). That looks like an intermittent client-side parsing hiccup in Forge rather than anything DodoRouter did wrong, and it's exactly the config the project's own maintainers run day-to-day against the hosted service — but if you hit a similar stall, check the request in DodoRouter's Logs before assuming the request failed.