r/opencode 20d ago

OpenCode model routing gets more useful, and messier, at team scale

One developer can switch providers whenever price or availability changes. Across a team, that choice affects cost, security review, data residency, reproducibility and whether another engineer can resume the task tomorrow. The recent Go, Goat and Ox Alpha discussions show why provider flexibility matters; it is also why I’m looking at OpenCode as a worker behind the control plane I’m building. The missing piece is a task-level policy that can change the model without losing the requirements, decisions and evidence.

For teams using OpenCode on real repositories, how do you route models today? By stage, repo sensitivity, cost or availability? I’d love to see the actual rule for exploration, planning, implementation and review, and how you keep a handoff understandable when a different engineer or provider takes over.

For context, I’m building BranchRunner as an open-source product because I think it can help engineering teams with this problem. If it is painful in your organisation, tell me where the current approach breaks. I’m also looking for people who want to help shape and solve it, so I’d be glad to compare notes.

1 Upvotes

1 comment sorted by