Anthropic Php Laravel Package

Product Decisions This Supports

• Build vs. buy for Claude integration. This is a thin, MIT-licensed PHP SDK over the Anthropic HTTP API: messages, streaming, tool use, extended thinking, web search/code execution (server tools), citations, token counting, models, batches, files, and completions. Unless you have a hard requirement for an official vendor-supported SDK, buying here (free) is cheaper than an internal client — you'd be reimplementing SSE parsing, DTOs, retries, and error mapping.
• Roadmap sequencing for AI features. The feature surface maps cleanly to shippable increments, so you can sequence: (1) single-turn messages + streaming for a chat/copilot surface, (2) tool use for internal actions (lookups, ticket updates), (3) citations for document Q&A where trust matters, (4) extended thinking for high-stakes reasoning, (5) batches for offline/backfill work. Each is a small step from the previous one, not a re-platform.
• Unit economics and pricing decisions. Typed usage objects expose input/output tokens, cache creation vs. cache read tokens (5m/1h ephemeral breakdown), serviceTier (standard/priority/batch), and server-tool usage counts. That's enough to model per-request cost, evaluate prompt-caching ROI, and decide which workloads belong on the batch tier vs. interactive. Token counting before send enables pre-flight budget checks and quota enforcement in-product.
• Capacity planning and rate-limit UX. Every response — including streams and batch results — carries meta information with request/token limits and reset times, plus a dedicated RateLimitException for 429s. That directly supports tier-upgrade decisions, backpressure design ("try again in N seconds"), and graceful degradation instead of generic 500s.
• Async vs. sync product scope. The 1.3.0 batches work (create/retrieve/list/cancel/delete/stream results, per-status counts) unlocks "run this overnight" features — bulk summarization, classification backfills, enrichment jobs — without building a queue-based orchestration layer yourself.
• Test-and-ship velocity as a product lever. The built-in ClientFake (queue fake responses, assert the exact request sent, fake() on batch results) means AI features can be covered in the normal CI suite with no HTTP mocking or test server. That lowers the cost of iterating on prompts and tool schemas, which is where most of the real product work happens.
• Framework integration decision. The package is framework-agnostic (PSR-18, any HTTP client); the maintainer ships a separate anthropic-laravel wrapper with container binding, config-based setup, and a facade. For a Laravel shop this is a two-line decision: adopt the wrapper for ergonomics, keep the underlying SDK for portability.
• Model/vendor hedging. Because parameters pass through to the API as-is, new Anthropic capabilities (new tool types, thinking modes, parameters) are usable the same day without waiting for an SDK release. That removes "SDK hasn't shipped it yet" from the critical path — but it also means your service layer, not the SDK, is where you should enforce schema and guardrails.
• Concrete use cases this unblocks cheaply: support triage and drafting with tool calls into your own systems; document Q&A with citations over uploaded files (Files API); streamed long-form generation in an admin console; batch re-scoring of content; agentic internal workflows using server-side web search and code execution instead of building sandboxes.

When to Consider This Package

Adopt when most of these hold:

• Your stack is PHP 8.2+ / Laravel (or any PHP service) and you've chosen Claude as a primary model — you want the full API surface, not just chat completions.
• You need streaming in PHP (SSE over a PSR-18 client) and don't want to hand-roll the event parser.
• You value typed, immutable response objects with IDE autocompletion and a first-class test double — i.e., you plan to write real tests around AI features.
• You want low lock-in: MIT license, no vendor SDK mandate, swap HTTP clients, wrap it behind your own interface.
• You're comfortable with a community-maintained dependency for a non-critical-path integration layer, and your team can absorb a small amount of upgrade work (changelog is detailed, 1.2.0 was explicitly backwards compatible).
• You want batch and token-counting primitives for cost control without building them.

Look elsewhere or proceed with explicit mitigation when:

• Procurement requires an official vendor SDK or a commercial support contract/SLA. This is community-maintained; there is no support agreement to sign.
• You need multi-provider abstraction (OpenAI + Anthropic + local models behind one interface). A provider-neutral layer is a better fit than a single-vendor client — though this package works well underneath such a layer.
• Bus-factor risk is unacceptable. Public signals are thin: ~47 stars, zero known dependents, effectively a single maintainer. That is the main diligence flag, not code quality. Mitigations: wrap it behind an internal LlmClient interface, pin versions, vendor the dependency, and be prepared to fork (MIT permits it).
• Your runtime is not PHP for the heavy paths, or your streaming endpoints sit behind web-server/proxy timeouts you can't raise. PHP-FPM streaming long generations is an infrastructure decision to validate before committing to the roadmap.
• You need guaranteed forward compatibility with breaking API changes handled for you. Pass-through parameters are a feature and a risk: unknown fields reach the API unchecked, and behavior changes may surface at runtime rather than at upgrade time.
• The feature you actually need is a single narrow call (e.g., one classification endpoint). A raw PSR-18 request may be less dependency surface than any SDK.
• Due diligence to run before sign-off: confirm the anthropic-laravel wrapper's release cadence and Laravel-version support; verify PHP/PSR-18 client versions against your platform; check open issues for streaming/proxy edge cases; confirm the latest release (dated 2026-08-01) actually corresponds to the features you're planning on.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can ship Claude-powered features — streaming chat, tool-using assistants, document Q&A with citations, and overnight batch jobs — on top of a free, MIT-licensed PHP library instead of building and maintaining an API client ourselves. It gives us the cost-control levers we need on day one: per-request token and cache accounting, batch-tier execution for non-urgent work, pre-send token counting for quota enforcement, and rate-limit metadata so we degrade gracefully rather than fail. Because it's framework-agnostic and passes new API parameters straight through, we are not locked into a vendor SDK cycle or blocked waiting for library releases when Anthropic ships something new. The main risk is maintenance: it's a community project with a small user base and one primary maintainer. We mitigate that by keeping it behind a thin internal interface, pinning versions, and treating it as replaceable — the MIT license means we can fork if we ever need to. Net: fast time-to-market, low license cost, contained dependency risk.

To engineering (the short version): PSR-18, so it drops into whatever HTTP client you already run. Typed readonly response DTOs — $response->usage->inputTokens, not array spelunking. Full surface: messages, streaming, tool use, thinking, server tools, citations, token counting, models, batches, files. ClientFake replaces the client in tests, so you assert on the outgoing request payload — no HTTP mocking, no test server. Dedicated RateLimitException (extends the base error type, non-breaking) plus PSR-7 response access on exceptions for debugging. Parameters pass through unmodified, so forward compatibility is free — but that also means we own request validation, retries, timeouts, and prompt/tool-schema versioning in our own service layer, not in the SDK. For Laravel, use the anthropic-laravel wrapper for the facade and container binding, and keep our code depending on an internal interface so the SDK stays swappable.