Add Claude Sonnet 5 Behind a Provider Contract, Not Across Your Codebase

Anthropic announced Claude Sonnet 5 on June 30, 2026, positioning it for coding, agents, and professional work. A model release is easiest to adopt when the rest of the application does not know the vendor's wire format.

Here is the TypeScript seam I want first:

type ToolCall = {
  id: string;
  name: string;
  arguments: unknown;
};

type Event =
  | { type: "text"; delta: string }
  | { type: "tool"; call: ToolCall }
  | { type: "usage"; input: number; output: number }
  | { type: "done"; reason: string };

interface ModelProvider {
  stream(input: {
    system: string;
    messages: Array<{ role: "user" | "assistant"; content: string }>;
    tools: Array<{ name: string; schema: object }>;
    signal: AbortSignal;
  }): AsyncIterable<Event>;
}

Build one adapter for the provider API. Keep the application dependent on Event.

Four contract fixtures

1. Text arrives in several chunks and reconstructs exactly once.
2. Tool arguments fail schema validation and never execute.
3. Cancellation closes the upstream request and emits a terminal state.
4. A truncated stream does not become a successful completion.

The production path should be:

browser -> task API -> provider adapter -> validated event log
                              |
                        tool policy gate

Do not let a provider-native tool call jump directly into a shell command. Parse it, validate it, authorize it, and write the decision to the task log.

This pattern also explains a practical reason I use MonkeyCode: I prefer coding workflows where model selection is not the entire product boundary. MonkeyCode exposes a hosted SaaS for a low-setup trial and an open-source self-hosted path. I recommend evaluating it with the same provider contract and failure fixtures rather than assuming any named model works identically.

I have not run a live Sonnet 5 comparison for this article, so this is an integration design, not a performance endorsement.

Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project.

A new model should be one adapter plus a capability record. If adding it requires provider-specific conditionals in your UI, worker, and tool executor, the migration has exposed an architecture problem before it has exposed a model problem.