Add Wayfinder Provider (Local vs Hosted Router)#1966
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 7, 2026, 2:43 PM ET / 18:43 UTC. Summary Reproducibility: yes. for the review finding: source inspection shows configured Wayfinder fetches use the projected Gateway URL while the dashboard action still falls through to the descriptor's default URL. The provider itself is feature work, so general bug reproduction is otherwise not applicable. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Derive the Wayfinder dashboard URL from the same validated configured gateway base URL used for polling, add redacted macOS app proof, and then have a maintainer decide whether to accept Wayfinder as a built-in provider. Do we have a high-confidence way to reproduce the issue? Yes for the review finding: source inspection shows configured Wayfinder fetches use the projected Gateway URL while the dashboard action still falls through to the descriptor's default URL. The provider itself is feature work, so general bug reproduction is otherwise not applicable. Is this the best way to solve the issue? No, not yet. The provider architecture follows local patterns, but the dashboard action should use the same configured gateway base URL as polling before this is maintainable. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against aa401f1d8b74. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (3 earlier review cycles)
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4fdb0a84d1
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| toggleTitle: "Show Wayfinder usage", | ||
| cliName: "wayfinder", | ||
| defaultEnabled: false, | ||
| dashboardURL: "http://127.0.0.1:8088/router", |
There was a problem hiding this comment.
When a user overrides the Wayfinder Gateway URL (for example to http://localhost:9099), fetches use that override via the projected environment, but the menu's Usage Dashboard action falls through StatusItemController+Actions.dashboardURL to this hard-coded metadata URL for Wayfinder. In that configuration the dashboard button opens the default 127.0.0.1:8088 instance, which is wrong or unreachable even though polling succeeds against the configured gateway.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Pushed a fix for the route-summary assumption (commit 4cbf4ab). Root cause: Fix: removed the local/cloud guess entirely. Tests added ( Still open (unchanged by this push, already noted in the PR body): no macOS screenshot, This push should trigger CI on macos-15-intel, which will give a real answer on both. |
The gateway's /router/models has no field asserting which configured route is "local" - route names are whatever the user named their own endpoints. Render the real per-route breakdown by name (matching the existing ClawRouter pattern) instead of guessing from array position.
clawsweeper
Bot
added
the
merge-risk: 🚨 compatibility
|
@clawsweeper re-review please |
|
🦞🧹 I asked ClawSweeper to review this item again. |
1 participant
Summary
Adds Wayfinder as a CodexBar provider.
Wayfinder is a self-hosted, deterministic local/cloud LLM router — its gateway runs on the user's machine and scores each prompt offline (no model call) to route it to a cheap/local or dearer/cloud tier. This provider polls the gateway's read-only JSON API and surfaces gateway health, the local/cloud routing split, savings versus always-cloud, and average routing decision latency.
Why
Users running Wayfinder currently have no way to see its routing activity from the menu bar alongside their other AI tool usage — they'd have to open Wayfinder's own dashboard separately. CodexBar already aggregates 50+ providers into one place; Wayfinder fits the same pattern as the existing ClawRouter integration (a router with a budget/usage split), so adding it here means one less place users have to check.
What Changed
Sources/CodexBarCore/Providers/Wayfinder/, followingdocs/provider.md./healthz,/router/models,/v1/savings?period=30d,/metrics— never the chat endpoints, and never reads or transmits prompt text.http://127.0.0.1:8088), validated with the same loopback-HTTP policy already used by the CrossModel provider.Sources/CodexBar/Providers/Wayfinder/,Sources/CodexBar/Resources/ProviderIcon-wayfinder.svg).UsageProvider/IconStyleenum cases, both provider registries, a newUsageSnapshot.wayfinderUsagefield, andProviderConfigEnvironmentbase-URL projection. All existing exhaustive switches overUsageProvider(widget colors/names, debug-log messages, cost validation) were extended for the new case — the compiler enforces this, so nothing else can silently break.docs/wayfinder.mdand a README/docs/providers.mdentry.TestsLinux/WayfinderProviderLinuxTests.swift(16 tests) and a registry resolution test inTests/CodexBarTests/WayfinderProviderTests.swift.defaultEnabled: false) — zero effect on existing behavior unless a user explicitly enables it.Proof
Ran the actual
wayfinder-routergateway locally (two stand-in OpenAI-compatible upstreams for a local and cloud tier, priced config) and sent it real prompts — easy ones stayed on the local tier, hard reasoning/math/constraint-heavy prompts escalated to cloud under Wayfinder's lexical routing. 14 requests total: 10 local / 4 cloud, 61.5% saved. Fetched through the real provider code via the CLI:Before: no Wayfinder provider exists in CodexBar; a user running the gateway has to check its own dashboard separately.
After:
Failure path (gateway not running), showing the error is actionable:
Menu card screenshot: to be added — see Risk section.
Validation
Automated tests:
swift test --parallel— full suite green: 107 tests across 18 suites, including 16 new Wayfinder tests plus a registry-resolution test. The Wayfinder tests use the live gateway responses above as fixtures (not hand-written JSON): full/empty/degraded/unpriced response variants,UsageSnapshotmapping, Prometheus metrics parsing (missing/garbage/labeled lines), URL normalization, loopback-HTTP endpoint policy (accepts127.0.0.1/localhost, rejects other plain-HTTP hosts, accepts any HTTPS), config→environment projection, Codable round-trip, an endpoint-set pinning test (proves the fetcher only ever calls the 4 documented paths), HTTP error mapping, same-origin/redirect rejection, and CLI text rendering.swiftformat Sources Tests --lint(0.61.1, matching this repo's pinned CI version) — clean, 0 files need formatting.swift build -c release --product CodexBarCLI— clean.Scripts/lint.sh(generated-hash check, package/product paths, repository size, documentation links) — all pass.Manual testing: exercised the provider end-to-end against a real, locally running Wayfinder gateway (not mocked) via the CLI, on Linux, including both the healthy path and the gateway-unreachable failure path shown above.
Not yet verified:
swiftlint --strict— could not be run as CI would in the environment this was developed in (no outbound access to fetch the pinned release binary, and a from-source build of the same version crashed on any input there — confirmed unrelated to this diff since it crashed identically on pre-existing files too). The diff was reviewed by hand against every rule in.swiftlint.ymlwith no findings, but this repo's CI run will be the first real confirmation.CodexBar) itself — only the cross-platformCodexBarCoreandCodexBarCLItargets were built and tested, on Linux. Every macOS-only exhaustive switch was extended for the new case, but hasn't been compiled/run on macOS yet.Risk
/v1/chat/completionsor anything that could route a prompt.UsageSnapshot(wayfinderUsage), additive andCodable-compatible; no schema migration needed..wayfinderprovider (Gateway URL); no existing provider's settings are touched.snapshot.wayfinderUsage != nil. Every existing exhaustive switch was extended (compiler-enforced), so no other provider's behavior changes. The provider defaults to disabled.swiftlint --stricthasn't had a real run (see Validation). Opening as a draft for that reason — will flip to ready once verified on macOS.Notes for Review
The three files worth actually reading:
Sources/CodexBarCore/Providers/Wayfinder/WayfinderUsageFetcher.swift— the core fetch/parse logic and theUsageSnapshotmapping.Sources/CodexBarCore/Providers/Wayfinder/WayfinderSettingsReader.swift— the loopback-HTTP validation policy (mirrors CrossModel's).TestsLinux/WayfinderProviderLinuxTests.swift— the live-gateway-fixture tests.Everything else in the diff is mechanical wiring into existing registration points (enum cases, registries, exhaustive switches) — shouldn't need line-by-line attention.