Skip to content

Remove inference_geo from the Agent model contract - #182

Merged
yanpgwang merged 2 commits into
mainfrom
codex/remove-inference-geo
Aug 27, 2026
Merged

Remove inference_geo from the Agent model contract#182
yanpgwang merged 2 commits into
mainfrom
codex/remove-inference-geo

Conversation

@yanpgwang

Copy link
Copy Markdown
Owner

Problem

Mango exposed model.inference_geo because it appeared in a Claude Managed Agents SDK contract delta, not because Mango had selected a portable user or operator workflow for per-Agent provider placement.

That field crosses the wrong boundary for Mango:

  • it is a hosted-provider routing policy rather than durable Agent behavior;
  • model platforms express geography through different request fields, endpoints, inference profiles, or deployment resources;
  • Mango cannot enforce one portable meaning across replaceable model adapters;
  • it introduced Agent/Session API surface, multi-agent roster constraints, Temporal payloads, request fingerprinting, persistence, and pricing coupling for a vendor-specific option.

Operators already select and govern Mango's configured model endpoint outside the Agent contract.

Solution

  • Remove inference_geo from Mango's /v1 Agent and Session model configuration, resolved snapshots, OpenAPI schema, and documentation.
  • Reject it as an unknown model field instead of silently retaining or forwarding it.
  • Remove the copied multi-agent same-geography invariant and all Temporal/runtime request propagation.
  • Stop sending inference_geo from the Messages adapter and remove the dedicated request-usage database column.
  • Continue reading the provider-reported response region as an internal per-request pricing fact so US data-residency surcharges remain exact without making geography user-configurable in Mango.
  • Record the CMA influence and Mango's rejection decision in docs/provenance.md.

Acceptance criteria

  • Agent and Session responses contain model ID, effort, and speed only.
  • Agent creation with model.inference_geo returns the normal 400 unknown-field error.
  • Working, Advisor, and outcome-grader requests never receive or forward an Agent geography setting.
  • Multi-agent rosters have no geography coupling.
  • Per-request list-cost accounting still applies provider-reported regional pricing where applicable.
  • OpenAPI, API docs, capability claims, migrations, generated database models, and tests agree with the new /v1 contract.

Non-goals

  • Add a generic model-placement or data-residency policy.
  • Configure provider workspaces, endpoints, inference profiles, or deployments through Mango.
  • Change Mango's model-adapter interface beyond removing this request option.
  • Preserve compatibility with the earlier pre-release /v1 field.

API and migration impact

This is an intentional breaking development-API change: model.inference_geo is removed in place from /v1 and now returns 400 as an unknown field.

The unused inference_geo column is removed from the pre-release 00031_model_request_usage baseline migration and regenerated database model. Development databases may be rebuilt under the repository policy. An already-applied development schema may retain the unused defaulted column without affecting new inserts.

Durability and security

No Session lifecycle, retry, or recovery semantics change. Older serialized payloads may contain an ignored JSON field, while new Workflows and model requests no longer carry it. Provider credentials and sandbox boundaries are unchanged. Routing and residency enforcement remain the responsibility of the operator-selected model endpoint rather than an unenforceable Agent declaration.

Validation

  • make verify
  • make docs-check
  • make test-service

@yanpgwang
yanpgwang merged commit be29120 into main Aug 27, 2026
7 checks passed
@yanpgwang
yanpgwang deleted the codex/remove-inference-geo branch August 27, 2026 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant