Laravel Copilot Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app AI features. Still a thin, Laravel-idiomatic adapter over the GitHub Copilot CLI, and the 1.0.22 surface widens the gap against a hand-rolled integration: permission-context prompts, content-exclusion paths, folder trust, model catalog metadata, and OAuth discovery are all things a team would otherwise re-implement (badly) over weeks. The build-vs-buy math now favors buy more strongly than at 1.0.21.
• Provider strategy: Copilot-first vs. multi-provider. Unchanged and still reversible via the Laravel AI SDK driver. Note that 1.0.22 adds experimental LLM inference request handling — interesting directionally, not yet a reason to change the provider bet. Treat multi-provider as a config-level hedge, not a roadmap item.
• Whether long-running agent sessions are a product surface or a demo. History compaction controls and handoff summaries are the single most consequential item in this release for PMs. Compaction plus structured handoff is what makes a multi-turn, context-retaining assistant survivable past the first hour without unbounded cost or context rot. This moves "persistent session assistant" from a research spike into a plannable roadmap item — provided you decide the handoff policy (when to compact, what the summary must contain, what the user sees afterwards) as a product spec, not a default.
• Unit economics before commitment. Model token price unit RPC plus runtime image-model catalog metadata means per-model cost is now readable at runtime. That enables model routing decisions (cheap model for triage, expensive for code review), per-feature budget estimates in the business case, and cost guardrails as an acceptance criterion rather than a post-launch surprise. Build this into the pilot's success metrics.
• Data-boundary, trust, and permissions policy. The permission story matured: session permission location, folder trust RPCs, session content-exclusion path checks, permission prompt context with user-prompt blocking, and host session withdrawal. permission_approve: 'deny-all' remains the default. This is now a genuinely reviewable governance artifact for security — scoped trust (which folders an agent may touch), explicit exclusion paths (never read these), and the ability to block a pending user prompt mid-flight. Still a product decision, but a far better-specified one to bring to review.
• Autonomy ladder and human-in-the-loop design. Exit-plan and auto-mode reverse-RPC handling, plus user-prompt blocking, lets you specify an approval model concretely: propose-a-plan → human approves → execute autonomously within scope. That is the artifact the "agentic" roadmap stage was missing; it can now be scoped with named gates instead of hand-waving.
• Ecosystem and integration strategy: plugins vs. custom tools. Verified Agent Plugin installation RPCs, extension launch providers, and MCP OAuth discovery plus login identity selection change the build question from "which tools do we write?" to "which tools do we write, which do we consume from a marketplace, and how do OAuth-protected internal MCP servers get authorized?" Add an ownership decision for plugin provenance/verification to the roadmap.
• Which use cases to greenlight now. Unchanged best-fit list, now extended with: long-session assistants where compaction is configured, cost-tiered routing, and OAuth-gated internal MCP integrations. Still poor-fit: latency-critical end-user chat, hard uptime guarantees.
• Test-and-ship velocity. Copilot::fake(), sequences, assertPrompt/assertPromptCount, and the added PendingCompletions coverage keep AI features inside normal CI. Note that the release's own test contribution came from a bot — fine for coverage, worth knowing that human review bandwidth on this package is thin.
• Version and upgrade cadence as a planning input. 1.0.22 is a large, mostly additive RPC expansion — including a bot-authored upstream sync from copilot-sdk. Good news: the package tracks vendor protocol changes fast, so you won't be stuck on missing Copilot capabilities. Bad news: expect frequent minor releases; budget pinning and a periodic upgrade slot.

When to Consider This Package

Adopt (pilot or internal-tooling scope) when:

• The organization already holds GitHub Copilot Business/Enterprise seats — marginal cost is integration time, not new model spend.
• The team is Laravel-native and values a facade, helper function, enums, and typed config over hand-rolled clients.
• You need streaming into an existing Laravel surface (Blade SSE, Livewire wire:stream).
• You want long multi-turn sessions and are prepared to own a compaction/handoff policy — 1.0.22 finally gives you the controls.
• You need cost visibility per model tier before committing to a feature (token price unit + model catalog metadata).
• You require OAuth-protected MCP servers, verified plugin installation, or folder-scoped trust — these are now supported rather than custom work.
• The workload is asynchronous or long-running (queues, Artisan, background review jobs) where process lifecycle is manageable.
• AI features are internal or advisory — a human reviews output before irreversible actions, and you want that gate expressed as a permission handler plus user-prompt blocking.

Look elsewhere when:

• You need vendor support, an SLA, or a security questionnaire answered by a company. Still two stars, zero dependents, one maintainer. You are the support tier.
• High-volume, multi-tenant, latency-sensitive workloads. Process-per-client stdio, or an operated shared TCP server, remains an operational shape most product teams underestimate.
• Serverless or ephemeral containers where long-lived child processes are awkward or disallowed.
• No Copilot license in place, or procurement will not approve one. The package is a client with no standalone value.
• You only need straightforward completions. A direct API call or the first-party Laravel AI SDK is less machinery.
• You intend to build on the experimental LLM inference path. It is explicitly experimental in this release; do not put it in a committed roadmap.
• Data residency, audit trail, or regulated-workload constraints require a contracted vendor. Content-exclusion paths help with hygiene, not compliance attestation.
• You need a stable RPC surface. 1.0.21 → 1.0.22 added a large batch of RPCs and event metadata; expect continued additive churn across 1.x. Pin the version.

Mitigation if adopted: wrap the facade behind your own AssistantService interface, pin the version, and treat the package as a replaceable adapter. Additionally: version-pin the RPC-level config separately from the Laravel-level API, and record your compaction/handoff policy in your own code so it survives an upstream default change. That converts maintainer and churn risk into a contained swap rather than a rewrite.

How to Pitch It (Stakeholders)

One line: A small MIT-licensed Laravel package that lets our application drive GitHub Copilot programmatically — sessions, streaming, custom tools, governed permissions — using Copilot seats we already pay for, now with the cost and safety controls a real feature needs.

For executives: This remains an adapter, not a platform, but the 1.0.22 release closes the two gaps that would have blocked productization. First, cost: per-model token pricing and catalog metadata are readable at runtime, so we can forecast spend per feature and route cheap models to cheap work. Second, control: folder-scoped trust, content-exclusion paths, permission prompt context, and the ability to block a pending request give security a concrete policy to approve rather than a promise. Long-running assistants also became viable via history compaction and handoff summaries. Maturity risk is unchanged and should be stated plainly: two GitHub stars, no downstream dependents, one maintainer, and part of this release was authored by automation. Correct posture: a bounded pilot on internal tooling, behind our own interface, version-pinned — not a dependency in a customer-facing critical path. Approve a scoped pilot with a cost ceiling; the decision to productize comes after output quality and unit economics are measured on real tasks.

For engineering: JSON-RPC 2.0 over stdio (default) or TCP to copilot --headless. Core abstraction is unchanged: Copilot::run() for one-shot, Copilot::start() with a CopilotSession for multi-turn, on()/sendAndStream() for event and streaming control, SessionConfig for model, reasoning effort, system message, tool allow/deny, MCP servers, and resume by ID. What's new and worth designing around: history compaction and handoff summaries (own the policy, don't inherit defaults); session permission location, folder trust, and content-exclusion path checks (map these to our own authorization model); permission prompt context with user-prompt blocking (the hook for human-in-the-loop); verified plugin installation, extension launch providers, and MCP OAuth discovery with login identity selection (plan for credential and provenance handling); model token price unit and runtime model catalog (wire into our cost telemetry); exit-plan/auto-mode reverse RPC (the approval-gate primitive for agentic flows). Treat the experimental LLM inference handling as off-limits for anything committed. Testing stays first-class — fakes, sequences, prompt assertions, plus new PendingCompletions coverage — so this lives in normal CI. Two things to design deliberately: the permission handler (default deny-all; gate shell and write behind our own authorization in any web-facing flow) and process lifecycle on the target runtime. Keep it behind a service interface and pin the version.

Pilot success criteria to agree up front: one internal workflow automated end to end, benchmarked against a human baseline for quality and time saved; measured cost per task within an agreed ceiling using the new token pricing data; a documented compaction/handoff policy reviewed by the owning team; no security exceptions required beyond the folder-trust and exclusion-path policy; and a documented swap cost if the package stalls.