Repository navigation
docs(rfc): RFC-0036 positioning and layered architecture - #198
Merged
Merged
Conversation
Positions aimux as a provider access and governance runtime and re-orders the 0.6 -> 1.0 plan around it: - six principles: perf/size as the first baseline, multi-stack behavior unification, provider testing/governance, private APIs reachable day one, harness decoupling, AI SDK data shape kept but not frozen - L0-L3 layering: truth moves down to transport/protocol; L2 (AI SDK shape) becomes a versioned projection; L0 native passthrough - ops protocol: #166 track C lifted into a transport-agnostic protocol (FFI / stdio / UDS / HTTP over one dispatch), binary frames, version negotiation - aimux-proxy as an extension package (same-protocol passthrough, cross-protocol via L2; no gateway business features) - governance line (evidence-backed capability matrix, drift detection, probe/replay/diff CLI) - #166 code reduction and S1-S3 size work kept and re-classified, not dropped Co-Authored-By: Claude <noreply@anthropic.com>
No binding tiers: all 8 bindings follow #166 track D as thin FFI wrappers over the ops protocol. The stdio CLI is the only other entry into the same dispatch. UDS/HTTP transports and aimux-proxy stay as direction without scheduling. Co-Authored-By: Claude <noreply@anthropic.com>
eric8810
marked this pull request as ready for review
September 29, 2026 14:00
This was referenced Oct 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Draft RFC that sets aimux's direction before the 0.5.0 → 1.0 roadmap (#197) is finalized. #197 derives versions from the ideal code shape (#166); this RFC answers who aimux is for and which layer the long-term abstraction bets on, then re-orders the plan.
Positioning: aimux is a provider access and governance runtime — performance and size are hard constraints; it unifies behavior across a multi-language stack, follows each vendor's evolving and private protocols, ships provider testing/governance, and runs embedded (FFI bindings) or as a stdio CLI subprocess decoupled from harnesses. No agent loop, no multi-tenant gateway business.
What the RFC establishes
model_new+call(op, json)+stream(op, json)) lifted into a transport-agnostic protocol with two entries into onedispatch: FFI (all 8 bindings, one shape, no tiers) and a stdio CLI; adds binary frames (realtime audio, uploads) and version negotiation. UDS/HTTP transports deferred until needed.aimux-proxyextension package (direction only, unscheduled) — foreign protocol facades; same-protocol via L0 passthrough, cross-protocol via L2 with explicit lossy-field reporting; outside default builds.aimux probe / replay / diff.Open questions (§10)
Generator vs hand-written bindings; binary frame format; L2 model choice.
Follow-up
Once this settles, #197 is rewritten against it (including detail fixes found in its review).
🤖 Generated with Claude Code