July 10, 2026

Preset version history in the RouteShift dashboard

Named presets — the saved bundles of model, parameters, system prompt, and provider preferences you attach to routing rules — now expose their full version history in the dashboard. Every time a preset is edited, RouteShift already writes a snapshot to preset_versions; two new authenticated, team-scoped endpoints let the dashboard list those snapshots and open any single one:

• List every past version of a preset (newest first), including the model, params, system prompt, provider preferences, author, and timestamp for each revision.
• Open a specific historical version by number to compare or copy fields back into the current preset.

Access is strictly team-scoped: a preset that belongs to another workspace returns the same preset_not_found response as one that doesn't exist, so version numbers can't be used to probe other teams. Malformed slugs and out-of-range versions are rejected before any database read.

Live web search as a per-request plugin

RouteShift now runs live web search inside the proxy as a per-request plugin, so any model can be given fresh context without your client wiring a separate search API.

Two ways to opt in on any request:

• Add a :online suffix to the model name (gpt-4o:online, claude-3-5-sonnet:online) for zero-config search with defaults.
• Pass a plugins array with {"id": "web", "max_results": …, "search_prompt": "…"} for per-request control over how many results to fetch and the exact query to run.

Results are injected into the system prompt as a clearly-delimited untrusted-context block, and the plugins array is stripped before the request reaches the upstream provider — providers never see RouteShift-specific fields.

Two safety semantics carry through:

• Optional (default) plugin failures return a warnings entry on the response and the underlying model call proceeds normally.
• Required plugin failures ("required": true) fail closed with 502 plugin_required_failed, so a caller that depends on fresh context never silently gets a stale answer.

Plugin-enabled requests are non-cacheable in either direction, so search results always reflect a live call and never resurface on a cache hit. Web-search invocations carry a fixed per-call surcharge that appears on your usage feed; see Savings and pricing.

Versioned request presets with immutable history

Presets — team-scoped bundles of a canonical model, sampling parameters, system prompt, and provider preferences — now expose two new authenticated, team-scoped version-history routes:

• GET /api/presets/{slug}/versions — every snapshot for a slug, newest first.
• GET /api/presets/{slug}/versions/{version} — one immutable snapshot by integer version.

Every accepted POST and PUT on a preset already appended a preset_versions row; those rows are now readable so you can diff a bad change, audit who touched what and when, and roll back by replaying an earlier snapshot as a PUT (there's no POST /rollback — history stays linear and append-only).

Cross-team requests return the same preset_not_found response as a truly missing slug, so a team can't probe another team's namespace. Slugs are validated against ^[a-z0-9][a-z0-9-]{0,63}$ and versions against the PostgreSQL int4 range before any database lookup. Demo mode reads the demo workspace's history transparently; demo writes stay blocked.

Four FOIA-derived datasets now shape Locus cell scores

Four new civic datasets received through the FOIA request program are now live inputs to Locus scoring, covering federal real-estate presence, broker-discipline actions, utility-service complaints, and nuclear-reactor proximity:

• GSA FRPP federal leases (7,212 rows) → economicStrength. Rentable-square-footage of federally-leased space is now summed inside the H3 res-8 query ring around each cell, so scoring reflects the concentration of federal tenants nearby.
• DOS broker discipline (62 rows) → businessVitality. Applied as a state-level penalty (the source carries no address or coordinates), so a cell in a state with an elevated recent-discipline count sees a small vitality drag.
• ICC utility complaints (8,665 rows, mostly Illinois) → safetyEnvironment. Joined at the ZIP-code level via the same nearest-ZIP RPC used by the FEMA flood signal.
• NRC reactor units (116 units — 94 operating, 22 decommissioning) → safetyEnvironment. Distance from each cell to the nearest reactor site is compared against the NRC's 16 km and 80 km Emergency Planning Zone radii. The dataset arrived without geolocation; a plant-name → site-coordinate crosswalk (68 sites) was built to back the signal.

Nothing changes in how you call scoring — the four groups above pick up the new inputs on the next scheduled recompute.

Updates

• Codex: GSA FRPP leases are now projected into codex_entities as entity_type=facility, and DOS broker-discipline actions into codex_events as event_type=broker_disciplinary_action. Both projections run on a continuous drain, so new source rows appear in the entity graph within a minute of landing.
• Locus: The HMDA loader that powers the Highest Mortgage Activity ranking and the multifamily / construction-loan signals in amenityDemand now filters multifamily loans client-side using the CFPB's derived_dwelling_category, instead of relying on a property_types=3 server parameter that silently stopped being honored upstream. hmda_agg.multifamily_loans and hmda_agg.construction_loans will start reflecting real volumes on the next refresh instead of the zeros the legacy path silently produced. A hard per-state ceiling and a derived_dwelling_category-present check now fail the ingest loudly if the upstream shape shifts again.
• Locus: Longer per-run timeouts for the HMDA, Legistar council-minutes, and MAUP tract → H3 areal-weight loaders on the continuous-collection scheduler. All three were routinely exceeding the previous global 3600-second ceiling and being reaped mid-run; runs can now complete cleanly on the observed 3,600–4,240 s durations. Paired with a separate streaming-memory fix, HMDA and Legistar should return to green.

Fixes

• Locus: The qcew_construction loader — construction-sector Quarterly Census of Employment & Wages, an input to the businessVitality and economicStrength groups — now actually loads rows. Three bugs (an incorrect owner-code filter, a renamed source column, and an off-by-one on the release-quarter lag) had combined to keep the table empty since the source was added; all three are corrected and the next scheduled run will backfill from the earliest available quarter.
• Locus: The collector's OpenSanctions ingest (~126K rows per run) no longer trips false "dead upstream" alerts. The scheduler's health check reads a fetched/upserted count out of each loader's completion log line; the OpenSanctions log line had drifted out of the expected shape, so successful runs were being paged as failures. The line is back to the canonical format and health alerts once again reflect reality.

Web search plugin for any chat completion

Any chat completion routed through RouteShift can now be augmented with fresh, cited web results — no client changes, no separate search integration. See Web search.

Two ways to opt in per request:

• Model suffix. Append :online to the model name (for example, gpt-4o:online). The suffix is stripped before dispatch and a default web plugin is attached.
• Explicit plugin entry. Add a web object to the top-level plugins array to tune max_results, pass a custom search_prompt, or mark the plugin as required.

RouteShift runs the search, formats the top results as a clearly labeled context block, appends them to the system prompt, and forwards the request to the upstream provider — the model sees titles, URLs, and snippets, and never sees a raw plugins field. Augmented turns are non-cacheable, so time-sensitive results are never replayed and the per-search surcharge is charged exactly once.

Failure modes are explicit: a missing or transient backend surfaces a warning header (X-RouteShift-Plugin-Warning) alongside a normal completion, unless the caller sets required: true — in which case the request fails cleanly with plugin_required_failed instead of returning a silently un-augmented response.

Preset writes now report proxy-cache invalidation status

Every write against a preset — create, update, disable, delete — invalidates the proxy's in-memory preset cache so the next request sees the new configuration immediately. Previously, if that cache invalidation call failed after the database write had already committed, the API returned a plain success and the caller had no way to know the proxy would keep serving the stale preset until its TTL expired.

Preset write responses now include an explicit outcome for the cache-invalidation step:

• On success: "proxy_cache_invalidated": true.
• On failure: "proxy_cache_invalidated": false, "proxy_cache_error": "proxy_cache_invalidation_failed", and "cache_ttl_seconds" so you know how long the stale entry may linger.

The database write is still committed either way — partial success is reported honestly rather than masked. Dashboards and CI pipelines that update presets can now surface a clear signal when a config change is written but not yet visible on the routing path.