feat(acp): add Venice AI as a provider#105
Conversation
Venice (https://venice.ai) offers an OpenAI-compatible chat completions endpoint at https://api.venice.ai/api/v1. This adds it as a first-class provider so users can write `venice:<model-id>` in their agent_key, mirroring the existing `openrouter:*` pattern. Changes: - Add "venice" to PYDANTIC_AI_PREFIXES - Add Venice's base URL to DEFAULT_BASE_URLS - Add the venice branch in _build_model (requires VENICE_API_KEY env) - Document VENICE_API_KEY (and the other AI keys) in .env.example
There was a problem hiding this comment.
Pull request overview
Adds Venice AI as a first-class provider option for PydanticAIClient by introducing a venice:<model> agent key prefix and routing it through Venice’s OpenAI-compatible API base URL using VENICE_API_KEY.
Changes:
- Add
veniceto the recognized pydantic-ai model prefixes and default base URL mapping. - Add a dedicated
_build_modelbranch forvenice:*that enforces an explicit model id and requiresVENICE_API_KEY. - Document
OPENAI_API_KEY,OPENROUTER_API_KEY, andVENICE_API_KEYin.env.example.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
condor/acp/pydantic_ai_client.py |
Adds venice:* model resolution and default base URL wiring for Venice’s OpenAI-compatible endpoint. |
.env.example |
Documents optional environment variables for common OpenAI-compatible provider API keys. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Hi @gordonkoehn, is this PR complete or have you already tested if it works? Venice is not showing in the list of LLMs in the bot UI. |
- Add "venice:" to the cloud-provider list in `_infer_tool_filter_mode()` so Venice models get tool_filter_mode=full (same as openai/openrouter/etc). - Document the venice:model resolution path in the `_build_model()` docstring "Resolution:" section. Refs Copilot comments on the two code locations.
Addresses @david-hummingbot's feedback: Venice now appears in the /agent LLM picker. The shape mirrors the existing OpenRouter picker exactly: - `"venice:"` sentinel in AGENT_OPTIONS opens a paginated picker. - `handlers/agents/venice_models.py` fetches GET /v1/models with VENICE_API_KEY, filters to entries where `model_spec.capabilities.supportsFunctionCalling == true` AND `type == "text"`. Tool-calling is required by Condor's architecture so non-tool models are hidden. Cached 1h. - `_venice_picker_keyboard` (menu.py) paginates 8/page with vc_page / vc_pick / vc_type / vc_type_confirm / vc_type_cancel / vc_noop callbacks — same prefix-shortening as OpenRouter to stay under Telegram's 64-byte callback_data cap. - `_settings_keyboard` shows the currently-selected venice:<slug> with a bullet, parallel to the openrouter:<slug> case. - Text-message handler routes typed slugs to `_resolve_venice_typed_slug` with the same UX as OpenRouter's manual-entry flow. Smoke-tested on a live Condor: picker loads (75 Venice models filtered down to ~N with tool support), selection sets agent_llm to "venice:<slug>", the `_build_model()` path then routes prompts through Venice and returns clean completions. No new dependencies — reuses aiohttp already in the project.
|
Updated with the UI picker — mirrored the OpenRouter pattern. |
seems to work
|
|
Hi @gordonkoehn, I ran into some issues when testing Venice. I selected the 
I couldn't stop it via the /agent command and CTRL + C in the terminal didn't stop it - had to kill the actual terminal window for it to stop. Another issue is when using the 
I'm just picking random models but at this point it looks like the quality of the models that Venice provides might not be that great if it can't even fetch just the portfolio balance - it'll for sure fail when using the agent trading. |
|
Hi @david-hummingbot, thank you for testing this throughly – seems I opened this PR proposal prematurely, and didn't test throughly enough. Perhaps, a dynamic shortlist of models in needed. That indeed does not look satisfactory. Let me latently investigate. I will reset this PR to be a DRAFT; may resubmit if I get it all ironed out. |
|
@gordonkoehn No worries, let us know once the PR is ready for testing again. |
What
Adds Venice AI as a first-class provider in
PydanticAIClient, mirroring the existingopenrouter:*pattern. Venice exposes an OpenAI-compatible chat completions endpoint athttps://api.venice.ai/api/v1.After this, users can write agent keys like:
and Condor's agent features will route through Venice using
VENICE_API_KEYfrom the environment.Why
Venice is a privacy-focused inference provider (no logging, no training on prompts) that's particularly relevant for trading-context agents where prompt contents may include strategy / position data. Some users prefer it for that reason; this PR removes the need to write a custom wrapper.
Changes
"venice"toPYDANTIC_AI_PREFIXES"venice": "https://api.venice.ai/api/v1"toDEFAULT_BASE_URLSvenicebranch in_build_model(requiresVENICE_API_KEYenv, modeled directly on theopenrouterbranch above it)VENICE_API_KEY(and the previously-undocumentedOPENROUTER_API_KEYandOPENAI_API_KEY) in.env.exampleTest plan
VENICE_API_KEYset,venice:<model>returns anOpenAIModelconfigured against Venice's base URLVENICE_API_KEY, raises a clearRuntimeErrorwith remediation hintvenice:), raises a clearRuntimeErrorpointing to Venice's model docsopenai:*,openrouter:*,ollama:*, etc.) unaffected — only adds a branch above the genericDEFAULT_BASE_URLSfall-through, same shape asopenrouterNo tests added — the affected file doesn't have unit tests today; happy to add a small parametrize over providers if maintainers want it.