chore: prepare v1.13.0 release

CHANGELOG.md

@@ -1,5 +1,21 @@
 # fusionAIze Gate Changelog
 
+## v1.13.0 - 2026-03-30
+
+### Added
+
+- Added an optional Anthropic-compatible bridge inside Gate with `POST /v1/messages` and `POST /v1/messages/count_tokens`, so Claude-native clients can enter through a dedicated surface without splitting routing, policy, health, or fallback behavior into a second gateway
+- Added an internal canonical request and response layer for bridge traffic, which keeps Anthropic-shaped ingress mapping separate from the existing routing and completion core instead of adding one-off protocol logic directly in the router
+- Added a community `claude-code-router` hook that can prefer coding-strong, tool-capable, and larger-context routes for Claude Code traffic without making the bridge itself depend on any one routing policy
+- Added bridge-specific validation and release-readiness helpers, including a client-near validation script and an explicit bridge release checklist for opt-in production rollouts
+
+### Changed
+
+- Hardened Anthropic bridge compatibility for real operator workflows: basic `tool_use` / `tool_result` flows now stay on the same execution path, Anthropic version and beta headers survive the bridge, and bridge responses expose the key route-resolution headers needed for debugging
+- Improved quota-aware fallback behavior for Anthropic-shaped traffic by introducing shared quota metadata on routes, which lets Gate avoid blindly retrying another path that is still backed by the same exhausted Anthropic or BYOK quota domain
+- Clarified the Bridge release position across docs: `v1.13.0` ships the Anthropic surface as opt-in and production-usable for early adopters, but does not claim full Anthropic, Claude Code, or Claude Desktop parity yet
+- Aligned the doctor and bridge validation tooling with non-default live configs so release validation runs against the same configured DB, env file, and runtime instance instead of silently falling back to repo-local defaults
+
 ## v1.12.0 - 2026-03-29
 
 ### Added

RELEASES.md

@@ -18,7 +18,7 @@ This repo does not require a heavy release process. Use lightweight tags plus Gi
 10. For hardening-heavy releases, keep the API functional tests green alongside unit and config coverage.
 11. Publish the GitHub Release so [`notify-tap`](./.github/workflows/notify-tap.yml) can dispatch the Homebrew tap update automatically.
 12. If the tap dispatch fails or the formula needs manual follow-up, bump `Formula/faigate.rb` in the separate [`fusionAIze/homebrew-tap`](https://github.com/fusionAIze/homebrew-tap) repo to the new release tag and update its `sha256`.
-13. For Anthropic bridge releases, also run the client-near validation flow in [docs/anthropic-bridge-release-readiness.md](./docs/anthropic-bridge-release-readiness.md) before tagging.
+13. For Anthropic bridge releases, run the client-near validation flow in [docs/anthropic-bridge-release-readiness.md](./docs/anthropic-bridge-release-readiness.md) before tagging, and keep the feature positioned as opt-in unless a later release closes the documented parity gaps.
 
 ## Example
 
@@ -99,6 +99,8 @@ The repo also includes [publish-dry-run](./.github/workflows/publish-dry-run.yml
 - `v1.10.1` is the first `v1.10` follow-up: the Grok adapter path and virtual-provider registration line are stable enough to ship as a public release.
 - `v1.11.0` establishes the modern model-registry baseline: Gemini 3 / 3.1 lanes, dynamic model labels, and the first release-helper automation now move together instead of being hardcoded across the router, wizard, and catalog.
 - `v1.11.2` is the release-reliability follow-up: Python 3.10 compatibility for the update helpers is restored and version surfaces are realigned so package metadata, CLI version output, and API version reporting stay in sync.
+- `v1.12.0` establishes the operator-catalog baseline: provider-source drift is surfaced earlier, Kilo and BLACKBOX semantics are clearer, and release automation is boring and repeatable again.
+- `v1.13.0` establishes the optional Anthropic bridge baseline: Claude-native clients can use an internal Anthropic-compatible surface, bridge traffic stays on the normal Gate routing core, and production rollout is supported as an explicitly opt-in feature line.
 
 ## Planned Publishing Path
 

docs/FAIGATE-ROADMAP.md

@@ -37,29 +37,44 @@ The detailed design lives in [Adaptive model orchestration](./ADAPTIVE-ORCHESTRA
 
 The next block should stay disciplined: build on the workstation baseline, keep packaging practical, and avoid turning fusionAIze Gate into a sprawling platform.
 
-## Current release target: `v1.12.0`
+## Current release target: `v1.13.0`
 
-The next release should land as a clean operational release, not as another loose pile of runtime slices.
+The next release should land as a clean bridge release, not as a grab bag of protocol experiments.
 
-`v1.12.0` should close around three themes that now fit together:
+`v1.13.0` should close around one coherent theme:
 
-- provider source cataloging and alerting as a first-class operator surface
-- clearer aggregator behavior for Kilo and BLACKBOX, especially where "free", "budget", "wallet", and explicit paid lanes are easy to conflate
-- hardened release automation after the `v1.11.x` release failures
+- an optional Anthropic-compatible bridge that stays inside the existing Gate core instead of spawning a second gateway or a protocol-specific routing stack
 
-The release should feel coherent from an operator point of view:
+That release should feel disciplined from an operator point of view:
 
-- Quick Setup, Doctor, Provider Probe, Dashboard, and route preview all explain drift or route pressure using the same language
-- Kilo explicit Sonnet/Opus lanes are visible as deliberate routing choices instead of hidden aggregator magic
-- release prep, tag validation, and publish dry-runs are boring and repeatable again
+- Claude-native clients can enter through `/v1/messages` while Gate still owns routing, policy, fallback, and health decisions
+- basic `tool_use` / `tool_result`, Anthropic header tolerance, and bridge-shaped error mapping are stable enough for everyday opt-in usage
+- quota-group-aware fallback behavior avoids the most obvious "same exhausted Anthropic account via another path" mistakes
+- doctor, provider probe, README, API docs, and release-readiness docs all describe the same v1 bridge limits
 
-What is intentionally not in scope for `v1.12.0`:
+What is intentionally not in scope for `v1.13.0`:
 
-- the virtual key layer
-- gateway-level response caching
-- fully automated external provider-source crawling on a long-running schedule
+- full Anthropic parity
+- full Claude Code parity
+- full Claude Desktop parity
+- SSE streaming parity
+- exact provider-side token counting
 
-Those stay as follow-on tracks once the operator surfaces, release path, and aggregator semantics are stable enough to trust.
+Those remain follow-on work once the opt-in bridge line has shipped and seen real operator usage.
+
+## Next target after `v1.13.0`: make the provider catalog truly live
+
+Once the bridge line is out, the next meaningful track should return to provider intelligence:
+
+- move the provider-source catalog from "visible" to "continuously trustworthy"
+- mirror local model visibility per key and per route more directly against the global catalog
+- escalate drift, quota coupling, and stale assumptions earlier in the operator surfaces
+
+That next line should stay operational:
+
+- no second platform
+- no sprawling memory layer
+- no heavy UI dependency just to understand route health
 
 ## Shipped: `v1.8.0` – `v1.9.1`
 

faigate/__init__.py

@@ -1,3 +1,3 @@
 """fusionAIze Gate package."""
 
-__version__ = "1.12.0"
+__version__ = "1.13.0"

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "faigate"
-version = "1.12.0"
+version = "1.13.0"
 description = "Local OpenAI-compatible routing gateway for OpenClaw and other AI-native clients."
 readme = "README.md"
 license = "Apache-2.0"