Lesson 18 — Probe a real provider safely

Outcome

Detect whether the first real coding-agent strategy is available without accidentally opening a real session or running provider hooks.

Why this comes now

Provider setup can have side effects: starting MCP servers, hooks, login flows, or mutable sessions. Settings health checks must be cheaper and safer.

Understand

Separate Probe from Start. Probe should answer: binary found? version readable? supported protocol likely available? basic configuration/auth status if provider exposes a side-effect-minimal check? It should not be treated as absolute proof that a future Run will start successfully.

Build the real project

1. Close OD-002 and document the first provider/strategy.
2. Implement a side-effect-minimal probe behind the adapter strategy.
3. Parse and store/report provider version diagnostics.
4. Add capability availability output.
5. Surface unavailable/unsupported state in Settings or a small provider diagnostic page.
6. Add fixtures/tests for missing binary, unsupported version, and healthy probe.

Completion gate

Opening/reloading the Settings diagnostic repeatedly does not create provider sessions, start task work, or mutate repository/user config. Missing/unsupported provider produces an actionable explanation.

Pitfalls to avoid

Do not implement health check by launching a full chat session. Do not assume a cached model list proves current authentication. Do not silently select another strategy when probe fails.

References

T3 provider guidance: https://github.com/pingdotgg/t3code/blob/main/docs/internals/providers.md

Checkpoint

Record the exact live provider version/protocol surface used for development in a provider-specific README/fixture metadata.