Studio previewSelf-host Studio locally.Run it
Kortyx
Open Kortyx on GitHub
Open navigation
ProductExamplesOpen sourceDocs

Anthropic Provider

Updated 22 days ago • September 11, 2026

@kortyx/anthropic is the Anthropic Claude provider package for Kortyx.

It gives you two entry points:

  • anthropic: a batteries-included default provider selector
  • createAnthropic(...): an explicit factory for custom setup

1. Install the package

pnpm add @kortyx/anthropic

2. What the package exports

import { MODELS, PROVIDER_ID, anthropic, createAnthropic, } from "@kortyx/anthropic";

What each export is for:

  • anthropic: default provider selector for the fastest start
  • createAnthropic(...): custom provider instance with explicit settings
  • MODELS: built-in Anthropic model ids exposed by the package
  • PROVIDER_ID: the provider id string, currently "anthropic"

3. Basic usage in the same file

import { anthropic } from "@kortyx/anthropic"; const model = anthropic("claude-sonnet-4-5");

anthropic is a provider selector, which means:

  • it is callable: anthropic("claude-sonnet-4-5")
  • it also exposes provider metadata: anthropic.id, anthropic.models
anthropic.id; // "anthropic" anthropic.models; // readonly list of built-in model ids

Good to know: The built-in model list gives autocomplete, but arbitrary Anthropic model ids are accepted as strings.

4. Shared app bootstrap usage

If you want one shared import path across your app, re-export anthropic from a bootstrap file such as src/lib/providers.ts.

src/lib/providers.ts
export { anthropic } from "@kortyx/anthropic";

Then import it from that file where you actually use it:

src/nodes/chat.node.ts
import { anthropic } from "@/lib/providers";

5. Advanced usage with explicit settings

Use createAnthropic(...) when you want app-owned configuration instead of the default environment-based setup.

import { createAnthropic } from "@kortyx/anthropic"; export const anthropic = createAnthropic({ apiKey: process.env.ANTHROPIC_API_KEY, });

Use the factory when you need to:

  • pass apiKey explicitly
  • pass authToken explicitly
  • use a custom baseUrl
  • provide a custom fetch

Good to know: createAnthropic(...) accepts either apiKey or authToken, not both.

6. Credentials and first-use behavior

The default anthropic export resolves credentials on first use, not at import time.

Supported API key environment variables:

  • ANTHROPIC_API_KEY
  • KORTYX_ANTHROPIC_API_KEY

Supported auth token environment variables:

  • ANTHROPIC_AUTH_TOKEN
  • KORTYX_ANTHROPIC_AUTH_TOKEN

If no supported credential is set and you did not pass credentials to createAnthropic(...), the provider throws a configuration error the first time an Anthropic model is actually used.

7. Create model refs for workflow and node params

params: { model: anthropic("claude-sonnet-4-5"), temperature: 0.3, }

You can also attach default model options to the ref itself:

const model = anthropic("claude-sonnet-4-5", { maxOutputTokens: 800, providerOptions: { anthropic: { topP: 0.9, }, }, });

Those become default options for later useReason(...) calls unless you override them at call time.

8. Use the model with useReason(...)

import { useReason } from "kortyx"; import { anthropic } from "@/lib/providers"; const result = await useReason({ model: anthropic("claude-sonnet-4-5"), input: "Write a concise project update for our beta users.", maxOutputTokens: 800, emit: true, stream: true, }); result.text; result.usage; result.finishReason; result.providerMetadata; result.warnings;

Good to know: Provider setup is not done on createAgent(...). Model selection happens where you call useReason(...) by passing a model ref.

9. Supported normalized call options

Anthropic currently maps these generic Kortyx options:

  • temperature
  • streaming
  • maxOutputTokens
  • stopSequences
  • abortSignal
  • reasoning.effort
  • reasoning.maxTokens
  • reasoning.includeThoughts
  • responseFormat.type

Current Anthropic provider options:

  • providerOptions.anthropic.thinking
  • providerOptions.anthropic.topK
  • providerOptions.anthropic.top_k
  • providerOptions.anthropic.topP
  • providerOptions.anthropic.top_p

Current mapping details:

  • system messages map to Anthropic system
  • adjacent user or assistant messages are merged for the Messages API
  • responseFormat.type: "json" maps through system instructions
  • reasoning.* maps to Anthropic thinking configuration

Current warning-backed gaps:

  • temperature is omitted when Anthropic thinking is enabled
  • schema-bearing JSON requests use native schema output on compatible Anthropic models; plain JSON mode uses instructions
  • generic reasoning.effort uses adaptive effort controls on current models and documented budget presets on manual-thinking models
  • unknown providerOptions keys are ignored and reported in result.warnings

10. Normalized metadata you get back

Anthropic returns the normalized Kortyx result fields when the API provides them:

  • usage
  • finishReason
  • providerMetadata
  • warnings
  • raw

Anthropic-specific metadata currently includes fields such as:

  • providerId
  • modelId
  • responseId
  • responseModel
  • stopSequence
  • usage
  • cacheReadTokens
  • cacheWriteTokens
  • serverToolUse

Use providerMetadata when you need debugging or observability details without coupling your app code to the raw provider payload shape.

Supported scope

@kortyx/anthropic currently supports text generation through the Anthropic Messages API via useReason(...), including streaming and non-streaming invocation.

It does not currently expose provider-native file APIs, skills, tool execution, or multimodal output APIs. Check result.warnings when you rely on advanced generic options and want to verify how Anthropic handled them.

Available built-in Anthropic model ids

  • claude-sonnet-4-5
  • claude-sonnet-4-5-20250929
  • claude-haiku-4-5
  • claude-haiku-4-5-20251001
  • claude-opus-4-5
  • claude-opus-4-5-20251101
  • claude-sonnet-4-0
  • claude-sonnet-4-20250514
  • claude-opus-4-1
  • claude-opus-4-1-20250805
  • claude-3-haiku-20240307

Next steps

  • See Hooks for useReason(...) behavior and structured output
  • See Provider API for the shared normalized provider contract

Reasoning, tools, and structured output

useReason preserves signed thinking and redacted-thinking blocks privately across tool rounds and approval resumes. Current adaptive models use thinking: { type: "adaptive" } and native effort controls. Older manual-thinking models map minimal/low/medium/high to 1,024/2,048/8,192/16,384 tokens; use reasoning.maxTokens for a specific manual budget. effort: "none" disables thinking. Models that require adaptive thinking reject manual budgets explicitly.

For native overrides, use providerOptions.anthropic.thinking and providerOptions.anthropic.effort. Compatible outputSchema calls use native output_config.format; JSON mode or older models retain explicit compatibility warnings and local output validation. Empty reasoning: {} leaves model behavior unchanged. Older models retain the existing 1,024-token manual thinking budget for generic effort settings, with a compatibility warning; set reasoning.maxTokens to explicitly increase it. Existing maxOutputTokens behavior is retained: manual thinking budget is added to the requested answer budget. Unsupported native schema constraints are moved into descriptions with a compatibility warning, while useReason validates the original outputSchema locally. Direct provider callers must perform that local validation themselves. For adaptive thinking with tools, useReason keeps the native output schema off tool-selection turns. It reuses a locally valid final answer when only outputSchema was requested; otherwise it makes a schema-only final call within the existing limits. Explicit responseFormat.schema always requires that final provider-enforced call. This avoids live API failures observed with adaptive thinking, tools and native schemas in the same streaming request.

See Anthropic thinking and structured output.