First-class inter-compatibility

The harnesses you already use and the models you actually want to run — both sides keep their full capabilities, and nothing in the middle is degraded.

Syntax sits between two ecosystems: the coding harnesses you already use and the wider catalog of models you might run behind them. Both sides keep their full capabilities. Harnesses stay unmodified. Every OSS model in the catalog keeps every feature its authors shipped it with. Nothing in the middle is degraded.

The harness you already use, unmodified

Every supported coding assistant — the Syntax CLI, Codex, Claude Code, OpenCode, and Pi — works with Syntax without modification. None of them are forked. None of them have a Syntax plugin. The integration is as simple as it gets:

The harness's existing configuration points it at an LLM endpoint.
syntax connect <agent> edits that configuration to point at localhost:<port> (the Bridge) instead.
The harness sends OpenAI- or Anthropic-compatible requests to the Bridge.
The Bridge resolves the model, applies your policy, picks a backend, and streams the response back in the wire format the harness asked for.

The harness has no idea Syntax is in the middle.

Reasoning, tool use, and modalities — on by default

For every OSS model in the catalog that supports reasoning, tool use, or additional modalities, Syntax deploys those capabilities enabled by default. You don't toggle on tool use; you don't enable the reasoning channel separately; you don't wire up a different endpoint for vision or audio. The deployment exposes the model's full declared feature surface from the first request.

This support is not narrow. It spans the catalog: across LLMs, MoE models, vision-language models, audio models, embedding and reranking models, and multimodal generation models, Syntax includes the engine-specific work that makes each model's official tool-call parser, reasoning channel, and modality inputs flow correctly through the OpenAI- and Anthropic-compatible surfaces on the Bridge.

The practical consequence: an OSS model dropped into a deployment behaves like a frontier hosted model from the harness's perspective. Tool calls round-trip with full fidelity. Reasoning content arrives in the channel the harness expects. Image, audio, and other modalities work without a separate code path. Consuming an OSS deployment is not a downgraded version of consuming a hosted-provider deployment.

Why it matters

Zero learning curve. You keep the keyboard shortcuts, the configuration files, the workflow you're used to.
No harness lock-in. If you switch from Codex to Claude Code tomorrow, your Syntax config doesn't change at all.
No model-feature lock-in. Reasoning, tool use, and modalities on OSS models aren't gated behind hosted-provider APIs — what the model's authors shipped is what you get through Syntax.
Multiple harnesses simultaneously. Connect all of them at once. They share the same Bridge, the same active model policy, the same budgets.
Reversible. syntax disconnect <agent> puts the harness's config back exactly the way it was. The change is recorded so it can always be undone.

What this isn't

This isn't a "compatibility shim". The Bridge is a real implementation of the OpenAI- and Anthropic-compatible APIs, with full streaming, tool-call, and reasoning support. Anything you can do with those APIs, you can do through Syntax — just with the option to redirect the request anywhere.

Compared to alternatives

Approach	Harness lock-in	OSS model-feature parity	Setup
Proprietary IDE hard-coded to one model	High	N/A — vendor's model only	Trivial
Manually wire each tool's config per provider	Medium	Provider-dependent	Per-tool
Custom proxy you wrote yourself	Low	You build it	High
Syntax	None	First-class across the catalog	One install + `syntax connect`