#ai

Zhengqikk 3732 Update — NoPager’s incident authority UX is now live I’ve just shipped a major OSS UI update based on early security feedback. The incident flow now makes the execution boundary explicit before anything happens: Trigger → Evidence → AI assessment → Policy → Exact action → Exact target → Attempt budget → Approval → Verification → Outcome The worker still has no Docker socket, Docker group, Docker CLI, or arbitrary shell access. Safe Mode remains the default. The first real operations path is intentionally narrow: 3 failed HTTPS checks → incident → AI triage → one bounded restart_container proposal → human approval → restart exactly one enrolled container → external HTTPS + container-state verification I’m now specifically looking for people willing to actually run it on a disposable/non-critical Linux Docker service. I’m much more interested in: “setup failed here” “I don’t trust this permission” “the incident didn’t recover” “this approval UI is missing something” than general product opinions. OSS: https://github.com/nopager/nopager If you’re willing to test the full loop, I’m happy to help personally with setup.

system While a member of our team prepares to jump in, you might find your answer even faster in our community resources. - Official Documentation: https://v0.app/docs - The v0 expert walkthrough: https://community.vercel.com/t/become-a-v0-expert/5981 - Watch v0 in Action: https://community.vercel.com/live#v0

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Justin Harr Ah, turns our it IS outputting an vector image, the `mediaType` (image/png) on the returned image result is just incorrect. I'll leave this up in case it's an unknown defect but easy enough for me to work around.

Ryu Hi octoo, Those generation IDs and the exact UTC window are the right kind of evidence for this. Since all 31 requests completed and the main difference is latency while the resolved provider was `baseten`, I’d treat this as a provider/routing/capacity question first, not a prompt or request-shape issue. For the next probe run, I’d capture the Gateway metadata alongside your latency numbers: ``` console.log(JSON.stringify(await result.providerMetadata, null, 2)) ``` The useful fields to compare are the resolved/final provider, generation ID, whether any fallback happened, TTFT, total latency, input/output tokens, and timestamp. If this route has more than one usable provider, you could also do a short A/B probe with provider ordering pinned, using the provider slugs from the model page: ``` providerOptions: { gateway: { order: ["<preferred-provider>", "baseten"], }, } ``` If the same prompts stay fast when routed elsewhere but slow only on `baseten`, that makes the report much easier to distinguish from prompt size or structured-output parsing overhead. If every provider is slow during the same window, then it points more toward Gateway-level routing/queueing or the model route overall. For escalation, I’d include a compact table with generation ID, provider, UTC time, TTFT, total latency, token counts, and whether it was from the affected or baseline run.

Frdwings Successful control: gen_01M2CQE67VEZVYMBTG88XF787H GPT-5.4-mini → OpenAI → HTTP 200 → inference completed Failed current control: gen_01M2EE8Y8GE0B21BARH3R3XW7T GPT-5.4-mini → Azure → HTTP 403 → pre-inference Gateway API Key ID: 2anmn74Bq2bVwWbkAWWEP09dres3z3ha85VOzqvUT9jJM2M0

Amy Egan Great blog post, as always! Looking forward to learning how it goes with your internal apps

Jonoroboto Don't worry Amy, it's guaranteed we'll break at least a core part of it, trying to fix security exploits 😂

Belty6979 5979 That’s a really interesting use case for Deepsec. Finding issues on a few hundred pages is already impressive, so I’d be curious to see what it uncovers when you run it against your internal apps.

Jonoroboto Sick thumbnail - love it. Can't wait to build a full blown accounting tool with Jev

tope love to see this, welldone

Abhivarde cool concept!

8008makoto 9443 I am seeing the same error on my Ortus Lab Hobby team as of 4 October 2026. A single connection-only request to POST /v1/evaluate, using typesafe-ai/jev with providerOptions.gateway.only = ["typesafe-ai"], returned HTTP 403 / no_providers_available. No retries were made. Gateway generation: gen_01M42Z5VSGVE2NZHP2PFH7B9JS Request ID: kix1::cle1::xxhnt-1791101169365-b47ac4afa936 Timestamp: 2026-10-04 08:06:09.456 UTC The authenticated dashboard shows provider allowlist, model allowlist and ZDR disabled. The request log shows TypeSafe AI / Jev and no reported usage. Provider reachability and the root cause are still unknown. Could Vercel confirm whether this team is currently eligible to access Jev and identify why this generation had no available provider? No API keys or Authorization headers are included.

Amy Egan To make sure the team has all the info they need, please fill out this MCP client request form Let me know if you have any other questions!

Tadeu Tupinambá OBSERVATIONS 1. The largest inline payload ever returned to us is 16,123 KB. Re-running the dropped prompts dropped them again, and the delivered ones came through again, which points to a fixed size threshold rather than a transient fault. 2. On dropped jobs `expired` is already true at completion time, while `expiredAt` is completion + 24 h, the same window a hosted result gets. The result appears to be discarded rather than stored. 3. The status is "completed" with empty `warnings`. There is no error, no 413, and the webhook payload carries no bytes and sends the receiver back to the same status call. 4. The documentation mentions only the 300 KiB cap on the persisted start request and the `expiresAt` / `expiredAt` / `partial` / `unretained` keys. Neither `inlineTooLarge` nor a result-size limit is documented. 5. Providers that hand back a hosted URL are unaffected: 18 of 18 Seedance jobs in the same period delivered with result: { expiresAt }. EXPECTED Either the result is hosted with an `expiresAt`, as URL providers' results are, or the job ends in an explicit error so a client can retry at a smaller size. A "completed" job with no output and no warning is indistinguishable from success. REQUESTS a) Host inline results above the cap, or raise the cap for the async job store. b) Until then, return an error status, or at least a warning, when a result is dropped. c) Document the limit and the `inlineTooLarge` key. d) Credit for the seven generations billed without an output. RAW STATUS RESPONSE for job_68M78EC73RVNDWQBD5XKBJ37WA (queried again at 2026-09-03 00:53 UTC) { "status": "completed", "videos": [], "warnings": [], "providerMetadata": { "gateway": { "asyncJob": { "jobId": "job_68M78EC73RVNDWQBD5XKBJ37WA", "status": "completed", "completedAt": 1788396479596, "result": { "expired": true, "expiredAt": 1788482879550, "inlineTooLarge": true } }, "generationId": "gen_01M1JBDZ9FB4MC8X02M709VGZW" } }, "response": { "modelId": "google/veo-3.1-generate-001", "headers": { "x-matched-path": "/v4/ai/video-model/status", "x-vercel-id": "iad1::iad1::cznpt-1788396828104-fe62f2166fbb" } } } Happy to share more job ids or re-run a controlled case if it helps. Thanks, Tadeu Tupinambá