7d57d9f4a1
Rebased onto the current release/v3.8.51 tip as part of a combined provider-retirement/provenance merge batch (Designer Web, Felo Web, Runtime, GPL-derived removal, Qwen Web already landed). Large conflict set (this is the biggest PR in the batch — the common ChatGPT Web provider touches chat, images, count-tokens, session leases, and combos). Conflicts resolved: - `open-sse/config/providers/registry/chatgpt-web/*`, `open-sse/executors/chatgpt-web*`, `open-sse/handlers/imageGeneration/providers/chatgptWeb.ts`, and their tests: kept deleted, matching the PR's stated scope. - `open-sse/config/providers/registry/minimax/web/index.ts`, `open-sse/handlers/imageGeneration/providers/geminiWeb.ts`, `open-sse/executors/gemini-web.ts`'s stale image-mode branch: base-drift collisions against already-merged sibling retirements (#11691, #11708) — kept deleted / dropped the dead code, since this PR's own branch forked before those merged. - `src/shared/constants/reservedProviderPrefixes.ts`, `open-sse/executors/index.ts`, `executorProxy.ts`, `virtualFactory.ts`, `autoStrategy.ts`, `src/lib/db/providers.ts`, `src/sse/handlers/chat.ts`: combined the Designer + Runtime (Felo/Qwen) + common-ChatGPT-Web retirement guard calls at each shared chokepoint — compute-once-then-OR pattern, consistent with prior combinations in this batch. - `src/sse/services/model.ts` / `src/sse/handlers/chatHelpers.ts`: adopted this PR's new `getModelInfoOrRetirementResponse()` central wrapper (a real improvement over ad-hoc try/catch), and extended it to also catch the Designer + Runtime retirement errors it didn't originally cover, so the consolidation doesn't regress the other two mechanisms. - `src/app/api/v1/images/edits/route.ts`: this PR moved the retirement check earlier (before `enforceApiKeyPolicy`) but left the old later call+catch block in place from base drift — removed the now-redundant duplicate `resolveImageRouteModel()` call and merged the Designer catch into the earlier one. - `open-sse/config/imageRegistry.ts`, `tests/snapshots/executors/executor-map.json` (`keyCount` recomputed to 133), `tests/snapshots/provider/translate-path.json`: same "both sides inserted a different retired provider at the same slot" pattern — resolved by dropping both. - `tests/unit/chatcore-executor-proxy.test.ts`, `provider-node-reserved-prefix.test.ts`, `combo-auto-candidate-expansion.test.ts`, `messages-count-tokens-route.test.ts`, `virtual-auto-combo.test.ts`: split into independent per-mechanism test blocks (established pattern); `virtual-auto-combo.test.ts`'s old "includes cookie web-session providers" positive-inclusion test (which used chatgpt-web as its example) was retired along with the provider and replaced by this PR's negative-exclusion test for the same slot. - `docs/architecture/ARCHITECTURE.md`, `CODEBASE_DOCUMENTATION.md` (+ 4 i18n mirrors), `README.md`, `FREE-TIERS-GUIDE.md`, `docs/diagrams/free-tier-budget.svg`, `docs/screenshots/free-tier-budget-card.svg`, `docs/reference/PROVIDER_REFERENCE.md`: recomputed every stale count from the real merged state — 104 executors (`countFiles` gate logic), 351 providers (regenerated via `gen:provider-reference`), 152/351 `hasFree` entries, 445/438/7 free-tier catalog rows, 13 ToS-avoid providers, budget-card regenerated via its real generator script. One doc conflict (`oauth/` module list) needed picking HEAD's side specifically — theirs still listed the already-removed `raycast` module instead of the real `openference`. - `config/quality/test-masking-allowlist.json`: additive merge of the PR's 17 `_deletedWithReplacement` entries alongside the batch's existing ones (one real duplicate-key mistake in my first pass, caught and fixed via a `object_pairs_hook` duplicate-key check before finalizing). Also fixed two real, unrelated-to-my-merge issues surfaced by the focused suite: - `tests/unit/resolve-web-provider-host.test.ts`: the PR's own test had a typo — it asserted `perplexity-web`'s resolved host as `"perplexity.ai"`, but the provider's registered `website` is `"https://www.perplexity.ai"` and the resolver returns the URL's `host` verbatim (no www-stripping), so the correct value is `"www.perplexity.ai"` (consistent with the same test's own `url` assertion). - `tests/unit/hard-session-lease-bypass-inventory.test.ts`: this golden call-site inventory was already stale on the pristine post-#11713 tip (confirmed via a throwaway probe worktree) — `src/lib/db/providers.ts`'s 3 connection-fallback sites and a third `src/app/api/providers/route.ts` site were never added to the golden list by the earlier-merged #11698/#11720 PRs. Updated it to the real current inventory (dated inline comments explain each delta and which PR introduced it), plus this PR's own legitimate deltas (image-edits duplicate-call removal, `ChatGptWebExecutor.execute()` site removed). Focused suite green (433/433 across executor-proxy, reserved-prefix, hard-session-lease-bypass-inventory, resolve-web-provider-host, retirement/runtime-block/source-retirement/management-retirement/image-handler-retirement, migration-168, combo-auto-candidate-expansion, virtual-auto-combo, executor-map-golden and siblings), plus `typecheck:core`, `check-file-size`, and `check-changelog-integrity` clean. Thanks for the thorough provenance-hold retirement work — appreciated.
5.4 KiB
title, version, lastUpdated
| title | version | lastUpdated |
|---|---|---|
| Getting Started — Web Cookie Providers | 3.8.40 | 2026-07-20 |
Web Cookie Providers
Web Cookie providers let OmniRoute use an AI service through your existing browser session instead of an API key. They are useful when you already have access to a service through its website and want OmniRoute to use the same authenticated session.
Unlike API-key providers, Web Cookie providers authenticate using the credentials that your browser sends to the website.
Before You Begin
Important: Always copy credentials from a live network request, not from your browser's cookie storage.
Many authentication issues are caused by copying cookies from the wrong place.
Do NOT copy from Cookie Storage
Most browsers expose stored cookies through:
DevTools
→ Application (or Storage)
→ Cookies
Although these cookies look correct, they may be:
- stale
- incomplete
- missing cookies only sent on authenticated requests
Using these values may cause authentication failures even if they appear valid.
Copy from a Live Request
Instead, use the cookies from a successful request:
DevTools
→ Network
→ Refresh the page
→ Open a chat or conversation request
→ Request Headers
→ Cookie
The Cookie request header contains the exact authentication information that your browser successfully used.
For most Web Cookie providers, this is the value that should be pasted into OmniRoute.
General Setup
The setup process is the same for most Web Cookie providers.
- Sign in to the provider's website.
- Open the browser's Developer Tools.
- Open the Network tab.
- Refresh the page.
- Open an authenticated chat or conversation request.
- Copy the required authentication credentials.
- Open OmniRoute.
- Go to Providers → Add Provider.
- Select your Web Cookie provider.
- Paste the credentials.
- Click Test Connection.
- Save the provider.
The exact credentials required depend on the provider.
Provider Credential Formats
Different websites store authentication differently. Some require only cookies, while others may require additional headers or tokens.
| Provider | Credential Format | Provider Guide |
|---|---|---|
| Claude Web | Full Cookie request header | docs/providers/CLAUDE_WEB.md |
| ChatGPT Web (Codex) | Full Cookie header | docs/providers/CHATGPT_WEB.md |
| Gemini Web | (verify) | |
| Copilot Web | (verify) | |
| Grok Web | (verify) | |
| ... | ... | ... |
Update this table as new Web Cookie providers are added or existing providers change their authentication requirements.
What Web Cookie Providers Can and Cannot Do
Web Cookie providers reuse a website's chat interface. They do not provide the same capabilities as official APIs.
Supported
- Authenticate using your existing browser session
- Access models available through your account
- Stream chat responses
- No API key required
Not Supported
- Function calling
- Tool calling
- Automatic file editing
- Agentic IDE workflows
- API-only features
This is expected behaviour and is not a bug.
If you need tool execution, automatic file editing, or other agent workflows, use an API-key provider instead of a Web Cookie provider.
Validation Caveat
A successful Test Connection or cookie validation only verifies that the supplied credentials appear to be in the expected format.
Until Issue #7857 is resolved, a successful validation does not guarantee that the provider will authenticate successfully.
If authentication still fails, verify that you copied the credentials from a live network request rather than browser cookie storage.
Troubleshooting
Authentication Fails
Verify that the credentials were copied from:
Network
→ Request Headers
→ Cookie
and not from:
Application
→ Cookies
Cookie Works in Browser but Not in OmniRoute
Some providers include cookies that are only sent during authenticated requests.
Recopy the credentials from a fresh network request after successfully opening a conversation.
Session Expired
Web Cookie providers use your existing browser session.
If your browser session expires or you sign out, you must copy a new set of credentials.
Test Connection Passes but Requests Fail
Until Issue #7857 is resolved, passing validation does not guarantee that the authentication request will succeed.
Recopy your credentials from a fresh authenticated request before troubleshooting further.
Provider Example
For a complete provider-specific walkthrough, see:
- Claude Web —
docs/providers/CLAUDE_WEB.md
The Claude Web guide demonstrates the complete setup process for a Web Cookie provider and serves as the reference implementation.
Best Practices
- Copy credentials from a fresh authenticated request.
- Avoid reusing old cookies.
- Keep your browser session active while using Web Cookie providers.
- Treat copied cookies as sensitive credentials.
- Use API-key providers when you need function calling or agent workflows.