#ai

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

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 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.

Ryu Hi Vadym, This looks like a mobile viewport/keyboard layout issue rather than something specific to your prompt. The useful details to add for whoever triages it would be: ``` Device: iOS version: Browser: Browser version: Does it happen in Safari, Chrome, or both: Does it happen only after the keyboard opens: Does rotating to landscape change anything: ``` From the repro steps, it sounds like the Ask AI panel/input is not recalculating correctly when the iOS keyboard appears, so the input area gets pushed or clipped in the visual viewport. A temporary workaround would be to use the docs Ask AI flow from desktop/tablet, or try Safari vs Chrome on the same iPhone to see whether it is WebKit/iOS-wide or browser-specific. If you can, I’d also add whether the screenshot was taken after typing starts or immediately after focusing the input. That distinction helps narrow down whether the bug is in the initial mobile layout or only after the keyboard resize event.

Vadym Kotai iPhone 16 Pro Max iOS 26.5 Browser Safari - version that is bundled with iOS 26.5 Doesn’t happen all the time - only sometimes when I try to focus the text area, it jumps randomly up. Sometimes to the middle of the screen, sometimes stays the bottom, sometimes jumps up, and only half of it is visible. When I rotate the screen - the ai chat is displayed on the right side and there is no jump Regarding Chrome - this never happens. The behavior in chrome is stable - it always jumps to to the same place like on the screenshot attached and the full area is always visible

Ryu Hi Vadym, Thanks, that detail helps. Since it is intermittent on iPhone Safari and only happens while focusing the textarea, this sounds even more like a visual viewport / keyboard resize race rather than a static CSS breakpoint issue. The landscape behavior is useful too: if the panel moves to the right side in landscape and no longer jumps, then the bug is probably specific to the bottom-sheet/mobile layout. I’d add this as the clearest repro summary: ``` Device: iPhone 16 Pro Max iOS: 26.5 Browser: Safari Path: eve.dev → Read docs → Ask AI → focus textarea Issue: textarea sometimes jumps upward randomly when focused Observed positions: bottom / middle of screen / partially clipped Landscape: no jump, Ask AI opens on right side Frequency: intermittent, not every focus ``` If you can reproduce it again, a short screen recording would probably be more useful than another screenshot because the bug is about the textarea jumping during focus/keyboard open. For whoever debugs it, I’d specifically check the mobile bottom-sheet positioning when `window.visualViewport` changes after the keyboard opens. The layout may be calculating the input position before Safari finishes applying the keyboard viewport change, then not correcting it after the final resize/scroll event.

Abhivarde cool concept!

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!

Amy Egan I opened an internal ticket to update the allowlist!

joshsoup Just added you to the list! Let us know if you run into any problems.

joshsoup Thanks for the details! Axyen has been approved. You can use Dynamic Client Registration (DCR) to connect to Vercel MCP. No additional form or documentation is needed at this point. Let us know if you run into any problems going forward.

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á