Repository navigation
Model Routing Peers AIP - #10
Merged
Merged
Conversation
Adds a routing peer role: discovery via a routing.v1 peer capability (mirroring AIP-3's verifier.* pattern, no new capability enum or metadata codec bump), reserved /_antseed/route and /_antseed/route/digest paths modeled on AIP-3's attestation dispatch/rate-limit rules, wire schemas for the route request/response and daily digest, and five new optional methods on the buyer-side Router interface. No contract or payment-message changes; routing-peer pricing is left to a companion AIP. Co-authored-by: Cursor <cursoragent@cursor.com>
RouteRequestBody: sagePrompt -> inputMessage, contextTokens -> promptTokens (the field names read as an implementation detail of one particular scoring backend, not a protocol-level concept every routing peer needs to share). RouteResponseBody: drop score and predictedQuality from ranked[] -- a routing peer's own internal ranking signal, not something a buyer can recompute or verify, and not needed once the returned order itself is the decision (see Rationale, "Preserving the routing peer's returned order"). Wrap the four predicted* fields into a single estimate object (costUsd/inputTokens/cachedInputTokens/outputTokens), matching the units a buyer already reconciles against observed usage elsewhere in this protocol. Drop baselineSuggestion entirely -- a routing peer's own alternate suggestion duplicates what `ranked`'s own order already expresses, and a buyer's fallback-target logic has its own, better-motivated source for a fallback model (its own already-chosen default), not a third party's opinion of one. Collapse the three-field receipt object into a single router: string -- a plain identifier for logging/diagnostics, not a structured field this AIP has any reason to standardize further. Also flags a real implementation gap found while updating the reference branch: its desktop application hardcodes a single vendor router as the only one its UI can enable, and its persisted preference (autoSubscriptionEnabled: boolean) has no field for which router a multi-router build would select -- noted under Reference Implementation alongside the two gaps already disclosed there.
…c concern for now
Premature for a Draft AIP whose reference implementation is still WIP -- tests belong once the interface stabilizes, not pinned to this revision.
…config A routing peer's own setup belongs to the host's plugin-configuration mechanism, not this type or the wire protocol.
RouteRequestBody, RouteResponseBody, DailyDigestBody, the Router extensions, and RouteCandidate/RoutingDecisionRow/ConversationIdentity/ ModelRoutingPreferences now carry an inline comment on every field, not just the subset already covered by surrounding prose.
- The co-author line was silently reverted by the digest-field-removal commit (1efc29c) -- restored. - Two references to sagePrompt survived the field's rename to inputMessage earlier tonight.
…apes and dispatch pattern
Rationale: 8 points down to 4 -- merged the three points that were all really "modeled on AIP-3" (capability string, announcer fix, overall shape) into one, and folded the payment/digest scope points together. Security Considerations: 6 points down to 4 -- merged "routing peer can steer" with "unfiltered constraints let an untrusted candidate through", since both were the same underlying point (advisory filtering, buyer re-applies policy locally) stated twice across the two sections. Every MUST/SHOULD is preserved; only the surrounding prose is trimmed.
…the seller, not instead of it
…igestBody autoSubscriptionEnabled gates configureDailySigning specifically -- a metered or free router has nothing to check it against, unlike the other ModelRoutingPreferences fields every router can use regardless of its own pricing model. It now lives with the rest of a subscription router's own setup, in its plugin configuration, not in this type. DailyDigestBody and the /_antseed/route/digest reserved path are implementation-specific to a subscription/metered pricing model, not something every routing peer needs -- dropped along with every reference to it (Reserved Request Paths, the rate-limit carve-out, Rationale, Backwards Compatibility, Security Considerations). Left a pointer in Rationale that a companion pricing AIP can define a digest or other periodic-reporting mechanism if a subscription-priced routing peer needs one, same as pricing itself.
…erence to a companion AIP
Both were payment-shaped (daily signing cadence) despite this AIP's own "no payment mechanism" stance -- a companion pricing AIP defines its own Router extension for whatever signing its pricing model needs instead. The host-mediated-closure security rule (a Router never gets direct signer access) stays, generalized to apply to whatever signing mechanism a companion AIP adds, not tied to a method this AIP no longer defines. Router interface goes from five new optional methods to three (selectRoute, getRoutingDecisions, updateRoutingPreferences).
selectRoute already receives fresh routingPreferences on every call, so any router that only reads preferences inside selectRoute never needed a push. The one thing that did need preferences outside of a live request -- triggerDailySigningCheck's background timer -- was pulled in the previous commit. Nothing left in this AIP's two-method Router surface (selectRoute, getRoutingDecisions) has a background/non-request code path that would ever consult it.
Two of the three mentions read as if the host's own dispatch walk was responsible for policy filtering (skipping disallowed entries "during the walk"), contradicting the third (Security Considerations), which already correctly placed this on the Router implementation inside selectRoute. All three now consistently say the plugin drops disallowed candidates itself before ever returning the list, so by the time the host walks it, it's already policy-compliant -- the host's walk is then a pure failover mechanism, not a filtering one.
…g decision Downgrades the host-side MUST/MUST NOT around following the routing peer's ranking to SHOULD/SHOULD NOT: a decentralized buyer retains full discretion to disregard a routing peer's suggestion, consult a different one, or blend rankings, rather than being bound to follow whichever routing peer answered. The routing peer's own obligation to produce a well-ordered response (ranked MUST be ordered...) is unaffected -- this only softens what the CLIENT is compelled to do with that response. Constraint re-application (a Router MUST enforce the buyer's own price/trust/allow-block limits regardless of what a routing peer returns) is untouched -- that protects buyer autonomy, it doesn't constrain it, so it stays a MUST throughout. Also: "contract" -> "smart contract" in both Payments-section mentions, for clarity. NOT PUSHED YET -- holding for review per explicit request.
…lizing
Previous commit over-explained the autonomy point with new sentences
("a buyer retains full discretion...", "the routing peer proposes, the
buyer decides", etc.). Reworked to just weaken MUST/MUST NOT to
SHOULD/SHOULD NOT in place, keeping every sentence's original
structure otherwise -- the Rationale point's title still flips (it
directly restates the reviewer's own wording), but the body is back to
near-original phrasing.
AIP-5: revise the /_antseed/route wire schema
kotevcode
marked this pull request as ready for review
August 29, 2026 18:47
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.
What kind of change is this?
aipnumber unassigned — an editor assigns it)Discussion link
Notes for editors