What Claude receives in each interface and how to ask for reliable JSON

A prototype works perfectly in claude.ai: it formats nicely and knows what day it is. The team moves it to the API with the same text, and it answers in plain paragraphs with the wrong date. The model didn’t change: what the model receives changed. Designing a Claude application starts with knowing what context each interface adds and what you have to add yourself.

Each interface builds a different context

Interface	What it adds on its own	What you have to do
claude.ai and the desktop apps	Its own system prompt: date, formatting habits, tools	Nothing; but don’t expect the same elsewhere
API and SDKs	Nothing: the model sees only what you send	Pass the date, describe the format, the role and the rules in your system prompt
Claude Code	CLAUDE.md, rules, skills and project configuration as context	Block what is forbidden with permissions or hooks, not with text

The case that comes up most in Claude Code: CLAUDE.md says “never run migrations on staging” and Claude runs one anyway. CLAUDE.md is context, not a mandatory rule. For an action to never happen, you need a deny rule in the permissions or a PreToolUse hook in the shared .claude/settings.json.

Content boundaries: what is an instruction and what is data

Content boundaries separate what your application commands from what arrives from outside:

• stable instructions go in the system prompt; the request’s data goes in the user message;
• each document goes inside its own tags, with its source;
• external content (a web page, an email, a file) arrives as a tool result and is treated as data, never as an order.

Schemas: the API guarantees the format, not a request in prose

If your code is going to parse the response, “answer in JSON” is not enough:

1. Define the object as a JSON schema with structured outputs, with the mandatory fields marked as required.
2. Before parsing, check stop_reason. With max_tokens the response was cut off; with refusal the model declined. Neither is treated as valid JSON.
3. After parsing, validate the business rules: the schema guarantees the shape, not that the numbers add up.

Session hygiene and plugins

Session hygiene keeps old context from contaminating new work. In Claude Code, an all-day session that mixes unrelated tasks drags along reverted code and old decisions. Start each task with /clear and keep in CLAUDE.md only what always applies.

Plugins are similar: if everyone installs them by hand from a wiki, they end up with different versions. The internal marketplace is declared in extraKnownMarketplaces and the plugins in enabledPlugins, in the versioned .claude/settings.json.

The usual traps

• Blaming the model for a difference that comes from claude.ai’s own system prompt.
• Writing the prohibition in CLAUDE.md with more emphasis, instead of a deny rule or a hook.
• Asking for JSON in prose, adding examples or lowering the temperature instead of using a schema.
• Parsing without checking stop_reason, or removing validation because “there’s a schema now”.
• Staying in the same endless session and compensating with more instructions.

On the exam

If the scenario compares two interfaces, ask what context each one adds: the answer is usually to make explicit in the API what the app gave for free. If something “isn’t respected” in Claude Code, look for permissions or hooks. If the JSON fails now and then, look for structured outputs plus the stop_reason check.