AI providers
Bidderops’s AI features are powered by a pluggable provider layer. You bring your own model access, configure it per feature, and Bidderops routes each request to the provider you chose.
Supported providers
| Provider | Models | Notes |
|---|---|---|
| OpenAI | GPT-4o, GPT-4o Mini | Direct API. |
| Anthropic | Claude Opus 4, Claude Sonnet 4, Claude Haiku 4 | Direct API; native web search. |
| Gemini 1.5 Pro, Gemini 1.5 Flash | Direct API. | |
| OpenRouter | Any model in the OpenRouter catalog | A gateway to many providers; the live catalog is fetched and cached. |
| Local | Any model on an OpenAI-compatible endpoint | Runs on your hardware. See Local LLM. |
A model is identified by a provider:model string — for example openai:gpt-4o,
anthropic:claude-sonnet-4-6, or local:mistral.
The AI features
Each of these features can be pointed at a different model, with its own editable instructions, in Settings → AI:
| Feature | Purpose |
|---|---|
| Go/No-Go Advisor | Recommends whether to pursue an opportunity. |
| RFx Analyzer | Extracts scope, criteria, milestones, dates, and submission documents from tender text. |
| Discovery Boost | Scores how well sourced tenders fit your bid profile. |
| Portfolio Insights | Summarizes win/loss patterns across your portfolio. |
| Bid Intelligence Agent | Researches a single opportunity into a dossier. |
| Bid Intelligence Deep Dive | Expands one section of a dossier in depth. |
| Pipeline Report | Produces an executive briefing on the active pipeline. |
| Experience Import | Extracts references and CVs from documents. |
Where keys live
API keys and your local endpoint settings are stored per organization, server-side. They are never shipped to the browser — the AI calls are made from the server, so your credentials stay on the server. You can configure keys for several providers at once and switch between them per feature.
Your keys are encrypted at rest with AES-256-GCM; the encryption key is held in the application environment, never in the database, so a database dump yields ciphertext rather than your keys. They are also masked and write-only in Settings — a configured key shows only as dots and a “Configured” badge, and only owners and admins can set, replace, remove, or read them. For the full data-flow and privacy details of the local option, see Local LLM.
Web-search grounding
Two features — Bid Intelligence and its Deep Dive — are far more useful when the model can search the live web. Grounding support depends on the provider:
| Provider | Grounding | How |
|---|---|---|
| Anthropic | Yes (native) | web_search tool |
| OpenRouter | Yes | the :online model suffix |
| OpenAI | Best-effort | Responses API web_search_preview |
| Best-effort | Google Search grounding | |
| Local | No | falls back to ungrounded generation |
When a provider cannot ground, the report is still produced — it is simply marked
grounded: false. This matters most when running a local model.
Customizing instructions
Every feature ships with sensible default instructions describing the model’s role. You can override them per organization in Settings → AI. A fixed output contract (the required JSON shape) is always appended in code so responses stay machine-readable — that part is not editable.