Skip to content

Instantly share code, notes, and snippets.

View nerdalert's full-sized avatar
🐈
🦀 🐿

Brent Salisbury nerdalert

🐈
🦀 🐿
View GitHub Profile

AI Grid Progress Summary — July 14

Summary

AI Grid has moved from architecture sketch to repeatable Kind validation for the core routing story.

  • The routing foundation is now real enough to review: multi-cluster routing, API fallback, full-grid mixed backend routing, metrics-driven routing, GridSite discovery, and lost-peer route-away all have repeatable validation commands.
  • The next work is not adding more demo surfaces. The highest-value work is hardening the implementation behind the demos.
  • The main architecture boundary is now clear: Praxis core should stay generic, while AI/Grid routing semantics move to the AI repo.
  • The remaining design decisions are around production credential lifecycle, stale-state policy, GridSite lifecycle automation, metrics normalization, and deferred product surfaces like KV cache affinity, MCP federation, and budgets.

Praxis Grid Demo Status

Demo Current status Size to unblock Deferred? Notes
Demo 1: Basic Multi-Cluster Model Routing Enabled / Kind-proven Done No Exact two-provider llm-d-style path is proven. Consumer routes model-east and model-west through provider gateways, ext_proc, mock EPP, endpoint_selector, and inference-sim.
Demo 2: API Provider Fallback Enabled / Kind-proven, with caveat Done for demo; S for production hardening No Mock API fallback and gateway credential injection are proven. Packet 1 now validates Secret-backed CRD → Kubernetes Secret → Praxis config projection in xtask. Production controller-owned credential lifecycle remains future work.
Demo 3: Full Grid — Clusters + Cloud + APIs Enabled / Kind-proven Done No One consumer gateway routes across local, remote, cloud-managed mock, and API-provider mock. Selected-backend evidence is proven by matching response model fields. Real cloud/API protocols are not claimed.

MCP Profile Support Discussion

Summary

Praxis should keep three MCP operating modes available for now:

  • Pass-through / classifier mode for backend-owned MCP behavior.
  • protocol_profile: current for the existing session-based broker behavior.
  • protocol_profile: stateless for the MCP 2026-07-28 release-candidate broker behavior.

If the maas-api log shows a TLS handshake error like remote error: tls: bad certificate, this usually means the client side (Authorino) rejected the certificate rather than the other way around.

This looks like the Authorino-to-maas-api TLS path. maas-api serves HTTPS with an OpenShift service-serving cert, so Authorino needs the OpenShift service CA bundle when it calls the tier lookup endpoint. The Authorino CR does not expose generic env vars, so the current workaround is to mount the CA via the Authorino CR and set SSL_CERT_FILE / REQUESTS_CA_BUNDLE on the generated deployment.

There are two separate TLS connections in the MaaS auth flow:

  1. Gateway -> Authorino (listener TLS) -- requires spec.listener.tls.enabled: true on the Authorino CR and the security.opendatahub.io/authorino-tls-bootstrap: "true" annotation on the gateway. On RHOAI/ODH this is usually already configured as a platform prerequisite.

  2. Authorino -> maas-api (outbound TLS) -- Authorino makes HTTPS calls to maas-ap

```diff
diff --git a/filter/src/builtins/http/ai/openai/responses/rehydrate/mod.rs b/filter/src/builtins/http/ai/openai/responses/rehydrate/mod.rs
index 5e60a3f..8dc4ced 100644
--- a/filter/src/builtins/http/ai/openai/responses/rehydrate/mod.rs
+++ b/filter/src/builtins/http/ai/openai/responses/rehydrate/mod.rs
@@ -27,6 +27,7 @@ use crate::{
filter::{HttpFilter, HttpFilterContext},
};
+// -----------------------------------------------------------------------------

Responses Passthrough Live Demo Capabilities

Codex and Upstream Providers

Praxis can sit between Codex and an upstream provider that supports the native OpenAI Responses API. Codex sends Responses requests to Praxis; Praxis rewrites the configured model name, adds effective-model routing metadata, and forwards the request to the selected backend.

The passthrough path preserves request fields such as input, instructions, tools, streaming flags, and function_call_output. Praxis does not run Codex tools or own the tool loop.

Epic 354 Complete E2E Demo Transcript

Generated: 2026-05-20T17:42:22Z

This transcript was generated by:

bash ~/praxxis/epic-354/e2e/run-complete-e2e-demo.sh \
  ~/praxxis/epic-354/e2e/complete-e2e-demo-output.md

PR Output: add --dump / -T CLI flag for effective config output

# dump a real config with conditions
  cargo run --quiet --bin praxis -- -T -c examples/configs/pipeline/conditional-filters.yaml 2>/dev/null

# Output

config_source: examples/configs/pipeline/conditional-filters.yaml

PR Validation Output: Add --validate / -t CLI flag for config checking

  • Add --validate / -t flag that loads and fully validates configuration then exits without starting the proxy
  • Validation runs the same pipeline resolution as server startup (filter instantiation, chain expansion, ordering checks, body limits)
  • Normal server startup unchanged when flag is absent
# Validate the built-in default config (should exit 0, no output)
cargo run -p praxis -- -t

Validation of experimental e2e of agentic Praxis support

Full code for the demo here

./target/debug/praxis --config /tmp/mcp-gateway-two-backends.yaml &
cd <directory with the script at the bottom>
source .venv/bin/activate
MCP_SERVER_NAME=weather uvicorn dev_mcp:app --host 127.0.0.1 --port 8001 &
MCP_SERVER_NAME=calendar uvicorn dev_mcp:app --host 127.0.0.1 --port 8002 &