* fix(routing): auto-migrate v0.3.0 inline routing_preferences to v0.4.0 top-level
Lift inline routing_preferences under each model_provider into the
top-level routing_preferences list with merged models[] and bump
version to v0.4.0, with a deprecation warning. Existing v0.3.0
demo configs (Claude Code, Codex, preference_based_routing, etc.)
keep working unchanged. Schema flags the inline shape as deprecated
but still accepts it. Docs and skills updated to canonical top-level
multi-model form.
* test(common): bump reference config assertion to v0.4.0
The rendered reference config was bumped to v0.4.0 when its inline
routing_preferences were lifted to the top level; align the
configuration deserialization test with that change.
* fix(config_generator): bump version to v0.4.0 up front in migration
Move the v0.3.0 -> v0.4.0 version bump to the top of
migrate_inline_routing_preferences so it runs unconditionally,
including for configs that already declare top-level
routing_preferences at v0.3.0. Previously the bump only fired
when inline migration produced entries, leaving top-level v0.3.0
configs rejected by brightstaff's v0.4.0 gate. Tests updated to
cover the new behavior and to confirm we never downgrade newer
versions.
* fix(config_generator): gate routing_preferences migration on version < v0.4.0
Short-circuit the migration when the config already declares v0.4.0
or newer. Anything at v0.4.0+ is assumed to be on the canonical
top-level shape and is passed through untouched, including stray
inline preferences (which are the author's bug to fix). Only v0.3.0
and older configs are rewritten and bumped.
* support configurable orchestrator model via orchestration config section
* add self-hosting docs and demo for Plano-Orchestrator
* list all Plano-Orchestrator model variants in docs
* use overrides for custom routing and orchestration model
* update docs
* update orchestrator model name
* rename arch provider to plano, use llm_routing_model and agent_orchestration_model
* regenerate rendered config reference
* Add Codex CLI support; xAI response improvements
* Add native Plano running check and update CLI agent error handling
* adding PR suggestions for transformations and code quality
* message extraction logic in ResponsesAPIRequest
* xAI support for Responses API by routing to native endpoint + refactor code
* Add OpenClaw + Plano intelligent routing demo
Demonstrates preference-based routing for personal AI assistants:
Kimi K2.5 handles conversation and agentic tasks, Claude handles
code generation, testing, and complex reasoning — with zero
application code changes and ~48% cost savings.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Remove redundant provider_interface from Kimi K2.5 config
The openai/ prefix in the model name already sets the provider
interface. Setting provider_interface explicitly conflicts with it
and fails config validation.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Simplify config to v0.3.0 format, remove explicit Arch-Router entry
Arch-Router is implicit when routing_preferences are defined.
Aligns with the preference_based_routing demo pattern.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Clean up Ollama/Arch-Router references, make Jaeger optional
Router is handled internally by Plano — no need for Ollama or
explicit Arch-Router setup. Jaeger is kept as an optional step
in the README for developers who want tracing visibility.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Remove run_demo.sh, use planoai CLI directly
The planoai CLI already handles startup. README now uses
planoai up/down directly instead of a wrapper script.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Remove docker-compose.yaml, use inline docker run for Jaeger
No need for a compose file when Jaeger is the only optional
service. A single docker run command in the README is simpler.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Clarify testing: OpenClaw channels vs direct Plano requests
Primary testing is through messaging channels (Telegram, Slack,
etc.) with log monitoring. The test_routing.sh script is now
documented as an optional direct verification tool.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add OpenClaw onboarding instructions to README
Includes install, onboarding wizard, channel setup, doctor
check, and how to point the gateway at Plano.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Use OpenClaw onboarding wizard for Plano provider setup
Replace manual JSON config with instructions to use the
openclaw onboard wizard to set up a custom OpenAI-compatible
provider pointing at Plano.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fixed readme and removed unnecessary testing.sh file
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Salman Paracha <salmanparacha@MacBook-Pro-342.local>
Demonstrates preference-based routing for personal AI assistants:
Kimi K2.5 handles conversation and agentic tasks, Claude handles
code generation, testing, and complex reasoning — with zero
application code changes and ~48% cost savings.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix llm_routing provider element
We replaced provider with provider_interface to make it more clear to developers about provider api/backend being used. During that upgrade we removed support for mistral in provider to encourage developers to start using provider_interface. But this demo was not updated to use provider_interface as it was using mistral. This code change fixes it by replacing provider with provider_interface.
Signed-off-by: Adil Hafeez <adil.hafeez@gmail.com>
* fix the path
* move
* add more details
* fix
* Apply suggestions from code review
* fix
* fix
---------
Signed-off-by: Adil Hafeez <adil.hafeez@gmail.com>
