Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office search. Vibefilter adds relevance ("vibe") filtering to Filament tables without standing up a vector database or an embedding pipeline. The decision it unblocks is: do we build semantic filtering ourselves, or adopt a plugin that precomputes scores against our own models and caches them?
• Relevance tuning as a product-owner activity, not an engineering ticket. The new ->thresholdTuner() panel shows how many rows survive at 0.6 / 0.7 / 0.8 / 0.9 using already-cached scores, so changing a threshold costs zero model calls. That turns "how strict should the filter be?" into a side-by-side comparison a PM can run in the UI during a demo, instead of a benchmark request to the team.
• Cost model decisions. Because scoring happens ahead of query time and is cached, unit economics are per-statement and per-model-run rather than per-keystroke. This lets you commit to a spend envelope for an internal tool and reason about it — something per-query LLM filtering makes very hard to forecast.
• Data retention and lifecycle policy. vibefilter:prune --days=90 (with --dry-run) makes cache retention an explicit, schedulable policy rather than an unbounded table. It's the difference between "we'll clean it up later" and a defensible answer to "how long do we keep derived data about our records?"
• Vendor and procurement posture. The OpenRouter attribution headers (HTTP-Referer, X-OpenRouter-Title) are now configurable — point them at your own app, suppress them, or turn them off. That's a real decision input for teams whose vendor agreements or security review require identifiable traffic from their own tenant, and a blocker removed for teams that assumed they were stuck with package branding.
• Roadmap sequencing. The threshold tuner (default off) signals that relevance quality is expected to be iterated on in-place. If the pilot shows thresholds need frequent adjustment, that's a product signal to invest in per-table defaults or learned thresholds — not in replacing the package.

When to Consider This Package

Adopt when:

• The surface is a Filament admin or internal tool with text-heavy tables (notes, descriptions, tickets, transcripts) where keyword search is too literal.
• Query volume is human-scale and bursty — a handful of operators, not public traffic. Precomputed scores fit this profile well; per-request inference does not.
• Staleness is tolerable. Scores reflect the statement when it was run; if a record's text changes materially, the cached score is stale until the statement re-runs. Confirm your data changes slowly enough for that, or plan a re-score path.
• Your team is already on OpenRouter or a comparable provider and has settled the egress question for the relevant data classes.
• You want no new infrastructure — no embeddings store, no vector index, no second database.

Look elsewhere when:

• You need public-facing, high-QPS, low-latency search. The cache pattern helps, but this is an admin-panel tool, not a search service; evaluate a dedicated retrieval stack.
• Results must be fresh per query (per-query freshness is exactly the cost the cache is designed to avoid).
• Data residency or third-party egress rules prohibit sending record text to a model provider at all — including at score time.
• Your UI is not Filament; the value here is concentrated in the table component and you'd be paying for an integration you can't use.
• You have low risk tolerance for pre-1.0 APIs. v0.3.0 still ships breaking-adjacent surface area (config blocks, migrations, artisan signatures). Pin the version and budget for upgrade work.

Upgrade notes for the current release: the new last_used_at column requires publishing and running the migration. Filtering continues to work without it — only vibefilter:prune depends on it — so the migration is safely additive and can ship behind your normal deploy cadence. Copy the new attribution config block only if you published config previously.

How to Pitch It (Stakeholders)

For executives: this gives operators semantic filtering inside the admin tools they already use, at a predictable cost, because relevance scores are computed once and cached rather than regenerated on every search. The v0.3.0 release removes three practical objections to adoption: you can now tune filter strictness in the UI without spending anything, you can cap storage growth with a scheduled cleanup command, and you can control how traffic is attributed to your own OpenRouter app. It's an internal-tooling investment with no new infrastructure and no per-query inference bill.

For engineering: adopt as a Filament plugin. Scores are precomputed and cached; the threshold tuner reads cached scores only, so it makes no model calls. v0.3.0 adds a last_used_at column via a publishable migration, an idempotent vibefilter:prune --days=N [--dry-run] command suitable for a daily schedule, and configurable OpenRouter attribution headers. The migration is backwards compatible — existing filtering is unaffected until you run it. Pin the version; this is pre-1.0.

Risks to state plainly: pre-1.0 API churn, cached-score staleness on edited records, and model-provider data egress at score time. All three are manageable, but each should be an explicit acceptance rather than a surprise during rollout.