feat: add Infron as an open_code gateway provider

[meridah7]

Summary

• What changed: Adds Infron as an open_code gateway provider. Infron is an OpenAI-compatible inference gateway serving the standard <provider>/<model> ids, so wiring it in is a base-URL change rather than a model-mapping exercise: infron/moonshotai/kimi-k2.6 routes the same model the bare id names, and nothing else in a deployment moves.
• Why it changed: It gives deployers a second open-model gateway behind the exact same resolution rules, so switching (or A/B-ing) is an env-var change instead of a fork.

Disclosure: I work on Infron. Everything below is checkable from the diff and the commands under Validation.

File	Change
docker/opencode.json	New. The OpenCode provider block moves out of the two Dockerfiles into one shared file both images COPY, so they cannot drift apart. Declares infron (@ai-sdk/openai-compatible) next to the existing provider.
Dockerfile, go/Dockerfile	Replace the inlined echo '{...}' config with COPY docker/opencode.json.
swe_af/execution/schemas.py	_infron_only_env() + _INFRON_AUTO_DEFAULT_MODEL, following the existing gateway path through _default_runtime, _default_planning_model, and resolve_runtime_models.
go/internal/config/resolve.go	Same, for the Go port (infronOnlyEnv, infronAutoDefaultModel).
agentfield-package.yaml, go/agentfield-package.yaml	INFRON_API_KEY offered as a third llm_provider option.
.env.example, README.md	Document the prefix swap and the auto-select rule.
tests/test_model_config.py, tests/test_dockerfile.py, go/internal/config/config_test.go	Coverage for the new path and for the shared-config invariant.

Behavior

With only an INFRON_API_KEY set (no ANTHROPIC_API_KEY, no other gateway key, no SWE_DEFAULT_RUNTIME), SWE-AF auto-selects the open_code runtime and defaults to infron/deepseek/deepseek-v4-flash — the same rule the existing gateway path already follows, with the prefix swapped.

A gateway key that was already honored before Infron existed keeps precedence. Adding an Infron key never silently reroutes an existing deployment; moving traffic across is an explicit act (drop the other key, or set SWE_DEFAULT_MODEL=infron/...). A provider with no key set is never selected, so shipping both in the image costs nothing at runtime.

Validation

Rebased on main at 7a8dba0 and re-run today.

• make check — python -m pytest tests/ -q: 1154 passed, 1 skipped, 0 failed, plus python -m compileall -q swe_af/ clean
  (note for anyone reproducing: tests/conftest.py requires AGENTFIELD_SERVER to be set to a local address, e.g. AGENTFIELD_SERVER=http://localhost:9999, or every test errors at fixture setup)
• cd go && go test ./... — 27 packages ok, 0 failures (Go 1.23.4)
• cd go && go build ./... clean; gofmt -l internal/config/ clean
• The 81 tests covering this change specifically (tests/test_model_config.py, tests/test_dockerfile.py) pass, including test_both_dockerfiles_share_one_opencode_config, which pins the new shared-config invariant.
• Live smoke test against the gateway: moonshotai/kimi-k2.6, minimax/minimax-m2.5 and z-ai/glm-5.2 over https://llm.onerouter.pro/v1 return well-formed completions with usage accounting, on both the sync and the streaming path, under the same ids already used in the image.

Behavior Impact

• No behavior change — every new path is gated on INFRON_API_KEY being the only gateway key present, and an existing key wins ties.

Notes

• The docker/opencode.json extraction is the one structural change. It was the cleanest way to avoid a ~900-character echo line and to stop the Python and Go images from drifting; test_both_dockerfiles_share_one_opencode_config now pins that. Happy to inline it back into both Dockerfiles if you would rather keep the diff to a single mechanism.
• @ai-sdk/openai-compatible providers are not in models.dev, so the model list has to be explicit. I listed the eight open-weight models SWE-AF realistically uses (Kimi K2.6 / K2.7-Code / K3, DeepSeek V4 Flash/Pro, MiniMax M2.5/M3, GLM-5.2). Easy to extend.
• Companion PR on the SDK side, which is what makes infron/... work for AgentField apps generally: feat(sdk/go/ai): support the Infron gateway agentfield#874. The two are independent; either can land alone.
• Happy to follow up with a joint benchmark on SWE-AF's own workload (same model, both gateways, cost + cache + latency side by side) if that is useful for the docs.

[CLAassistant]

All committers have signed the CLA.

[AbirAbbas]

Thanks for the disclosed, well-tested integration. The precedence logic is correct and symmetric in both swe_af/execution/schemas.py and go/internal/config/resolve.go (verified: an existing gateway key always wins, the two *_only_env() predicates are mutually exclusive by construction), and the shared docker/opencode.json extraction is a genuine improvement over the duplicated inline JSON. But the branch is three commits behind main and the staleness is now load-bearing. Requesting changes:

1. Rebase onto current main (ef508a8). Four files conflict (schemas.py, resolve.go, both agentfield-package.yamls) — all mechanical.
2. Stale model constants: #132 renamed the shared open_code default to deepseek-v4-flash-0731. _INFRON_AUTO_DEFAULT_MODEL / infronAutoDefaultModel still say infron/deepseek/deepseek-v4-flash, and two tests copied from the pre-#132 tree (test_explicit_open_code_keeps_minimax, test_model_ids_unchanged_after_prefix_swap) auto-merge cleanly and then fail. Bump both constants to -0731, add that model id to docker/opencode.json's infron.models list (OpenCode can't resolve it otherwise — your own test_infron_declares_models explains why), and update tests/test_dockerfile.py to match.
3. The headline claim breaks inside the project's own images: both Dockerfiles bake ENV HARNESS_MODEL=openrouter/moonshotai/kimi-k2.6, which sits above the auto-gateway default in the resolution cascade. An INFRON_API_KEY-only container deployment therefore resolves every model to an OpenRouter id with no OpenRouter key and dies on auth. Document the required SWE_DEFAULT_MODEL override for Infron the same way the README already does for Codex, or make the baked default gateway-aware.
4. INFRON_API_KEY never reaches the container: all five compose service env blocks (docker-compose.yml ×2, docker-compose.go.yml ×2, docker-compose.local.yml) enumerate provider vars explicitly and none pass it through, so the documented .env path is broken end-to-end.
5. Re-validate after the rebase: the PR's current make check / go test numbers were measured against the old base.

Separate from the code review: adding INFRON_API_KEY to require_one_of.llm_provider promotes Infron into the af install wizard on equal footing with Anthropic/OpenRouter for every installer. That's a maintainer policy decision rather than a review item and is still being weighed — if it ends up moved to optional, everything else above still stands.

[AbirAbbas]

I pushed the rebase-equivalent onto your branch as a merge from main plus two commits, so it's current and CI is green again.

On the review items: main's #97 turned out to have done the same config extraction you did, into a repo-root opencode.json that both Dockerfiles already COPY, so I dropped docker/opencode.json and moved the infron provider block into that file instead — the MiniMax entries main added are untouched and both images still share one config. The auto default is now infron/deepseek/deepseek-v4-flash-0731 on both nodes, that id is declared in infron.models, and the two tests written against the pre-#132 default are fixed. On the baked HARNESS_MODEL: #142 scoped it to open_code, which doesn't help here because an Infron-only container auto-selects open_code — so the image's openrouter/... value still wins over the Infron default. Rather than change the baked value I documented the required HARNESS_MODEL=infron/... override in the README and .env.example and pinned both directions in a test. INFRON_API_KEY now passes through all five compose service blocks.

Local runs on the merged head: make check 1229 passed / 1 skipped, and go test -race ./... green across all packages.

One thing I deliberately left alone: INFRON_API_KEY still sits in require_one_of.llm_provider, which puts Infron in the af install wizard alongside Anthropic and OpenRouter. That's a maintainer call, not a review item, so it's unchanged and still open.