⌘K
Codex 5427 Yeah I know
ADALIGO 😄 Haha... imagine creating a brand new account just to write: "Yeah I know." But anyway... let me tell you something maybe you don't know yet: Even if someone knows a lot, nobody knows everything. Real builders stay humble. Real engineers keep learning. 🚀 Knowledge is not about acting bigger than others. It's about helping, encouraging, building, and evolving together. So whether you're senior, junior, beginner, or expert: keep learning 📚 keep building ⚡ keep improving 🧠 Because technology moves fast... and the moment someone thinks they know everything, they already stopped growing. Still bui
Ryu Hi Den, TLS 1.3 and HTTP/3 are related, but they are not the same thing. TLS 1.3 means the HTTPS handshake can use the newer TLS version. HTTP/3 specifically means the site is being served over QUIC/UDP instead of HTTP/1.1 or HTTP/2 over TCP. A quick way to test what your site is actually negotiating is: or in Chrome DevTools: If you see h2, that is HTTP/2. If HTTP/3 is active, you’d usually see h3. From the current Vercel docs I can find, Vercel explicitly documents TLS 1.2 / TLS 1.3 support, but I don’t see HTTP/3 listed as a supported CDN protocol yet: vercel.com/docs/cdn-security/encryptio
Den.D Hi @ryux1 , thanks fro the reply. You hit the nail on the head. As I mentioned in my post, even though the two things aren't directly connected, I don't understand the logic of supporting only TLS 1.3 and not HTTP/3. This is especially true when even the cheapest shared hosting providers ($10–$20/month) offer HTTP/3 by default. Of course, there's no personal setting for that, being a platform lack... My post was just a rant, hoping that someone in Vercel reads it and acts to solve the gap 🙂
Ryu Hi Den, Yep, fair point. I mostly replied to clarify the TLS 1.3 vs HTTP/3 difference for anyone else reading the thread. I agree there probably isn’t anything to configure at the project level right now. It would be nice to have HTTP/3 support on Vercel too, or at least a clear note in the docs about the current status. Thanks for raising it.
Murderteeth +1. We’re on the Pro plan and need API tokens for monitoring/automation that only requires read access. The lack of read-only permissions prevents us from using API tokens for these use cases. Would love to see read-only or permission-scoped API tokens made available on Pro, ASAP.
Dan +1 here too. Not having read-only API tokens is a massive gap. I see there haven't been any replies to this thread. Is anyone at @Vercel watching this? If so, has this been added to the backlog? Is there an ETA?
Amy Egan I wasn't able to repro, but maybe I'm looking in the wrong place. Can you show me where you see standard tier pricing for these requests? AI Gateway supports OpenAI tiers through the service_tier param. Looks like you're using it right. vercel.com/docs/ai-gateway/capabilities/service-tiers
Mo091336 4719 Hi Amy, Fortunately, the issue with the GPT-5.5 Flex and Priority tiers was resolved just a few days after I wrote my post, before you had a chance to reply. It appears that Vercel simply had not updated its billing system to reflect the new pricing structure, since the provider was returning responses with the correct service tier. However, the same issue reappeared with the release of the GPT-5.6 series, apparently for exactly the same reason. This time, there also seems to be an issue with the updated caching system. OpenAI has introduced both implicit and explicit prompt caching, but Verce
Mo091336 4719 Update: Now It works. Thank you Amy.
Anshuman Bhardwaj Hi @mojmir-6408, welcome to the Vercel Community! Let me share this with our team.
Anshuman Bhardwaj Hi @mojmir-6408, internal: true is meant to skip the default path installation, but people can always do INSTALL_INTERNAL_SKILLS=1 and get the internal skills. I'm trying to get the one you mentioned removed from the listing by our team.
