- How do I install and set up halilcosdu/laravel-chatbot in a Laravel app?
- Install it with Composer, then publish the package config and migrations and run php artisan migrate. Add OPENAI_API_KEY to your environment, and on v2.1.0 or later also set OPENAI_PROJECT to scope requests to the correct project. After that you create or update conversations through the package's thread methods, such as createThreadStreamed() and updateThreadStreamed().
- Which Laravel and PHP versions does laravel-chatbot support?
- CI covers PHP 8.2 through 8.5 and Laravel 11 through 13. For production you should target Laravel 12 or 13 on PHP 8.4 or 8.5, because Laravel 11 security support has ended and that framework upgrade is owned by your application team rather than the package. The package will still run on Laravel 11, but treating it as a production target carries avoidable risk.
- How does the package store chat conversations and messages?
- It is a database-backed wrapper around OpenAI's Responses API, so conversations and messages are persisted in your own database using the models and migrations the package ships. That means retention, PII handling, and compliance posture are your responsibility, not the package's. You should also verify existing rows against the ownership scoping fix in v2.1.0, since that change affects how records with an owner ID of 0 are resolved.
- Does laravel-chatbot support streaming responses over SSE?
- Yes. The primary API is streaming-first: createThreadStreamed() and updateThreadStreamed() push responses incrementally, and you consume them from a Blade or Inertia frontend with EventSource or fetch streaming. Make sure your proxy, load balancer, or CDN has idle and read timeouts configured above the package's request timeout, otherwise long generations will be cut off at the edge. Test long-form prompts explicitly, because it is not clearly documented whether the timeout bounds connection setup or total stream duration.
- How does per-user or multi-tenant conversation ownership work?
- The package owns thread persistence and applies ownership scoping so users only reach their own conversations. Version 2.1.0 fixed an issue where an owner ID of 0 could be mishandled, which implies a prior tenant-isolation defect, so audit existing data before relying on the new behavior. Multi-tenancy beyond owner scoping is not documented, so if you need team-level or organization-level isolation you should verify it or build a layer on top.
- How do I configure the OpenAI API key, project, and request timeout?
- All of it lives in the published config file, which reads from environment variables, so keep your API key and project ID out of version control. In v2.1.0 the config adds project, a cast request_timeout, and response_options; the effective default timeout is around 30 seconds, which is sensible for cost and worker occupancy. Because the published config is a merge target on minor upgrades, diff it each time or you may silently run without project scoping or with an un-cast timeout.
- Can I customize the chatbot UI and the model or tool options per request?
- The package ships a customizable UI that works in server-rendered Blade and Inertia apps, so you can adapt the presentation to your design. Per-request response_options let you override things like model and tool settings, but v2.1.0 added protection so caller-supplied options cannot corrupt package-managed input, conversation, and stream state. Define an internal policy for what application code is allowed to override so nobody defeats that managed state.
- Does the package include token usage tracking, cost accounting, or rate limiting?
- No. Token and cost accounting, rate limiting, and quota enforcement are not part of the documented surface, so plan to build them yourself if you need them. The roughly 30-second default request timeout helps contain both spend and worker occupancy, but it is not a substitute for per-user quotas. For anything beyond a small internal feature, add your own logging of usage and spend around the thread calls.
- How do I upgrade to v2.1.0 and does it require a new migration?
- Version 2.1.0 adds no new migration, which is the biggest de-risker for existing installs. The real cost is a manual merge of the published config: add project, cast request_timeout, and add response_options, then set OPENAI_PROJECT in every environment and confirm scoping behavior where it is absent. Re-run your existing non-streaming flows in staging as a parity baseline, and exercise the migration rollback path in CI before you depend on it.
- Is laravel-chatbot production-ready, and what are the alternatives?
- It fits a Laravel monolith or Inertia/Blade app where chat is a feature rather than a platform capability, and v2.1.0's package-isolated client makes it safe enough for several teams to share. The caveats are real: it is a single-maintainer dependency, test coverage is thin for a path that persists user content and spends money per request, and there is no provider abstraction, so you are explicitly coupled to OpenAI. Octane and queue compatibility and observability hooks are not documented, so verify them yourself, and if you need model-agnostic orchestration put your own facade in front of it or evaluate a multi-provider alternative.