Launch HN: AgentMail (YC S25) – An API that gives agents their own email inboxes
137 points by Haakam21 14 hours ago
137 points by Haakam21 14 hours ago
Hey HN, we're Haakam, Michael, and Adi. We're building AgentMail (https://agentmail.to), the email inbox API for agents. We’re not talking about AI for your email, this is email for your AI.
Email is an optimal interface for long-running agents. It’s multithreaded and asynchronous with full support for rich text and files. It’s a universal protocol with identity and authentication built in. Moreover, a lot of workflow critical context already lives in email.
We wanted to build email agents that you can forward your work to and get back a completed task. The agents could act entirely autonomously as you wouldn't need to delegate your identity. If they did get stuck they could just send you, or anyone else, an email.
Using Gmail, we kept getting stuck on the limitations of their API. No way to create inboxes programmatically. Rate and sending limits. OAuth for every single inbox. Keyword search that doesn't understand context. Per-seat pricing that doesn't work for agents.
So we built what we wished existed: an email provider for developers. APIs for creating inboxes and configuring domains. Email parsing and threading. Text extraction from attachments. Realtime webhooks and websockets. Semantic search across inboxes. Usage-based pricing that works for agents.
Developers, startups, and enterprises are already deploying email agents with AgentMail. Agents that convert conversations and documents into structured data. Agents that source quotes, negotiate prices, and get the best deals. Agents that emulate internet users for training models on end-to-end tasks.
Here's demo of Clawdbots communicating using AgentMail: https://youtu.be/Y0MfUWS3LKQ
You can get started with AgentMail for free at https://agentmail.to
Looking forward to hearing your thoughts and feedback.
I'm 100% for this, but I think you can go even more granular than "gives agents their own inboxes". Thanks to Action Mailbox in Rails[1], I give all my records email addresses. Eg let ecommerce "order" records accept forwarded emails that are pinned as comments. It opens you up for doing things like forwarding a purchase order and having the PO number pulled out and attached to an order, or forwarding tracking information from a supplier and having it attached to a "supplier order" etc. In my personal life I have individual email addresses for all my utilities and emails automatically get filed away. If this idea tickles your fancy, I opensourced Emitt[2], an inbound email processing server with LLM-powered automation. 1. https://guides.rubyonrails.org/action_mailbox_basics.html The only problem I have experienced few times with those unique email addresses is, sometimes they/utilities ask me to email from my official email address, and my setup is a catch-all, so I have to log in my pc at home, set up that address, send email. The transition timing here is key - while native agent protocols will eventually emerge, email provides the interoperability bridge we need today. Building on established infrastructure makes sense when you're solving the coordination problem of getting all agents to adopt the same communication standard. Rather than waiting for consensus on new protocols, using email lets agents participate in workflows immediately. I've used email as MQ since forever also, and can highly recommend this pattern. I'm concerned that this fits in "using today's innovation to solve outdated paradigms". Google has A2A: An Agent-to-Agent Protocol. SaaS is plumetting in value. Arbitrary semantics made sense when communications were human-dominated. If agents dominate these fields, why wouldn't they simply set their own protocols and methods to communicate both text, binary, and agreed data structures? There's an assumption that email is somehow the best channel, when you've found yourself that the most popular, functional interfaces don't align with your expectations. Then, ultimately I have a single agent that can sit in numerous communication platforms, such as email Fair concern, and I agree on the end state. Agents will eventually use native agent-to-agent protocols. The question is the transition, because email is undoubtedly the most ubiquitous channel of communication in today. I would only give my agent an A2A integration if your agent has an A2A integration, but because you don't we are at a stalemate. I'd rather just give my agent an inbox where I know it can communicate with the other billions of people that already have an email address. Email isn’t the final protocol for agents. It’s the bridge that lets them participate in today’s internet while native agent protocols/networks emerge. Interesting take, but this feels like one of those tarpit ideas that YC discourages their portco to start attacking. Guaranteed this is going to attract a ton of abusers who are looking to use this for signing up to services, spamming or other nefarious purposes, which then blacklists the doman. This is an infinite whack-a-mole. do you guys have some ways of handling it? We do have robust checks in place to catch spam and bad actors(reputation, SPF DKIM DMARC, etc.) but as with all tools there will be bad actors who come up with creative ways to scheme for nefarious purposes. We expect our infra and policies to evolve with usage, and one of our goals is to make agent driven email safer than the status quo, not just more scalable But as of now you're just wide open for abuse? Okay Resend uses SES since it's almost impossible to get private IP mail to hit the inbox through ProofPoint filters. Looks like you have no idea about any of this. You don't even have knowledge of email reputation, much less a plan. Have you heard of Senderscore? You will have all zeros. Saying "SPF DKIM DMARC" is wild - that's a checklist from 15 years ago. I think we’re aligned on the hard parts here, so let me be precise. We’re not wide open for abuse nor are we bypassing the hard parts of email reputation. Quite the opposite. We also utilize SES's infrastructure and monitor reputation continuously, but we don’t assume SPF/DKIM/DMARC are sufficient on their own. They’re basics we have implemented, not the entire strategy. You are correct private IPs per customer make sense once you’re sending meaningful volume (on the order of ~10k+/day per IP). But its inaccurate to say we are sending from a single private IP. IP pools are typically segmented by reputation and traffic profile for customers. Reputation here is earned at multiple layers: per-IP, per-domain, per-inbox, and over time. We rate-limit, isolate, or revoke bad actors without poisoning unrelated senders. Hopefully this makes sense. I don't think they use the agentmail domain for sending emails. Users connect their own domain and manage reputation (similar to all the other email marketing tools) Cool launch. Assuming you guys view email (and therefore SMTP) as becoming the de facto agent communication protocol in the long run. My question — why not something bespoke, similar to OpenAI’s Agentic Commerce Protocol or x402 from Coinbase? Network effects - agents need to meet humans where they already work. Would rather use something standard than bespoke. And how long will humans and agents be communicating over email? We have strict rules for our customer service people not to respond to what seems to be a bot, since all the "agent" based communication we get is for conducting scams. It is never worthwhile to engage with or pursue. If we lose a sale or two, that's okay. I think there will be bad actors in any field, and right now, a lot of agent-based outreach might fall into that bucket, so its rational to be initially skeptical. The more interesting shift isnt whether humans will keep using email with agents, but whether agents can become distinguishable from noise. Historically, we ignored anonymous calls but we engaged with known vendors that had reputation, contracts, and consequences. Once an agent has a persistent identity/a domain, trust becomes something that can be accumulated over time instead of being assumed per message. > Application error: a client-side exception has occurred while loading www.agentmail.to (see the browser console for more information). I would advise to have the landing page static, or at the very least as something that can't crash entirely. This is super interesting. Interesting to see how I'll be able to use this to help my customers with handling email responses. Gmail sucks for this. Super excited to see what you guys develop this into. Will this be able to eventually expand to other forms of agent communication (i.e. payment or phone numbers)? A pricing thought: if you keep the volume limits but do 10x the amount of inboxes per plan, I think that could be more attractive. For If I have 100s of agents that send limited email each. > Agents that source quotes, negotiate prices, and get the best deals. Didn't Alexa fail miserably with the "have AI buy something for me" theory? There is a significant mental in allowing someone else make purchase decisions on my behalf: - With a human, there is accountability. - With deterministic software, there is reproducibility. With an agent, you get neither. FWIW - I am not anti-LLM. I work with them and build them full time. We are using AgentMail for sourcing quotes here at scale with various top shippers. It’s not about letting the agent act in fully deterministic ways, it’s about setting up the right guardrails. The agents can now do most of the job, but when there’s low confidence on their output, we have human in the loop systems to act fast. At least in competitive industries like logistics, if you don’t leverage these types of workflows, you’re getting very behind, which ultimately costs you more money than being off by some dollars or cents when giving a quote back. Okay that makes sense. Do you see more pushback in specific industries? I did some quote/purchasing automation work in food mfg a decade ago, and those guys were super difficult to work with. Very opaque, guarded, old-school industry. I've seen different industries. CPG, mfg, and others are very old school still. Logistics moves so fast. I think it's due to how frequent feedback loops are that puts pressure on players to adopt to new tools. This refers to B2B use cases that are live in production. Finding, contacting, and negotiating with vendors is a tedious process in many industries. In the time a human reaches out to 10 vendors, an agent reaches out to 100 or 1000. So it finds deals that a human would not have. Once vendors are getting AI spam sent to 1,000 of them and their competitors, they will stop responding and find other sales channels. This won't be sustainable. Unless they have agents reading those emails and responding ... Oh I feel like this is already in the making. Let me create another (Y-combinator backed) startup which will intend on solving this issue haha (/s just kidding) wait till you find about B2B procurement marketplaces... ya'll this stuff exists But if you hire ten or 100 real humans you have accountability and the same number of contacts per day? Are logistics companies really that poor so they cannot afford to pay workers wages? By that logic why send email newsletters when I could hire 10 or 100 people email them manually instead? Obviously there's a cost tradeoff here where it's worth it to have email negotiation in an automated way, but not in a human call center way. The tradeoff isnt agents vs humans its where humans sit in the loop. Sure hiring 10–100 humans gives accountability, but reality is it doesn't scale in any comparable way compared to agents in speed, coverage, or responsiveness. The sheer volume agents can pump out(more vendors, more quotes, faster cycles) is the benefit, while humans retain accountability at the decision boundary. In practice the agent does the gruntwork, and the human gets looped in when confidence is low. Accountability doesnt dissapear, it gets concentrated where it matters most The moat for SaaS is gone. I am 99% certain I could build to parity in a weekend using Cloudflare without the the pricing limitations. I am thinking it would be within the free tier of CF usage. I am not certain I have the bandwidth to communicate over delivery and plain text inspection concerns. The moat around TV shows feels gone with TikTok/YT. I am 99% certain I could reach parity in a weekend by publishing content on public networks, without the old distribution or pricing constraints. I think it would all run on infrastructure that is effectively free to use. I am not certain I have the bandwidth to handle distribution, sustained attention, and moderation once the content starts flowing. We're going to collapse society with this style of thinking, particularly since it can now escape out into the realm of non-technical folks. Death of true understanding because everyone feels entitled to paying the lowest perceived monetary cost possible for everything in their lives. This depends on what kind of SaaS I guarantee you that the "moat" is very much intact for the SaaS we are building (more developer / gaming tool but then again so is this) because it requires specialized skills, synthesis and most importantly AI would have no idea how to build it without very specific prompting from our architect CRUD wrappers never had a moat. Even the most basic viable SaaS that wasnt a micro SaaS had some secret sauce or differentiation. And AI doesnt help you get that unless you already know what it is. Not to mention network effects. Users are a moat and if you can sell and grow fast enough and create a community, no amount of "there's a clone" can beat it. Never underestimate the power of brand recognition. the moat is always going to exist between the haves and have nots. AI just raises the bar for the standard of quality. you are not going to vibe code a new OS in a weekend - or else everyone else and their mamas could, too, in which case, you wouldn't be special This is not true. And it's easy to disprove. Most SaaS pre-AI had an open source alternative. Most people didn't use them not because the open source alternative lack some features, it was because mainteinance was hard. It's way easier to pay a small monthly fee and forget about it. Isn’t your comment just the “modern” take on the famous HN comment deriding Dropbox? For every dropbox that managed to build a business out of a feature, there are probably >1000 that didn't. But I guess this meme is a good way to kill off bad businesspeople. Perhaps you could, but you probably always could've built a clone of any SaaS app you wanted, it's just become faster. I'm reminded of the infamous Dropbox Hacker News comment[1]. If you're looking at stuff like this thinking "what's the point? I could just make that myself" then you're not the target audience in the same sort of way Ikea isn't trying to sell stuff to carpenters. This is true even when the barrier to entry in making these sorts of systems has gotten way lower. But in this case it’s become so much faster and cheaper as to represent a serious disruption Exactly this ... tools like Claude Code have flattened the complexity curve of building/maintaining things like this to practically zero. I thought cloudflares email product is only for receiving, not outbound ? I was writing this comment and then asked AI model to find me a blog post and it looks like Cloudflare does support outbound now (I am seeing a send mail option)
https://blog.cloudflare.com/email-service/ So yes it supports both and this feature was recently added (september 2025) & its still in private beta or something similar but yes now its possible. But I have still written parts of the comments where I had assumed that you were right and I am still gonna let it be to show what my thinking process was I guess. Not that it matters now but I am frugal in finding alternatives sooo yeah :> lol (currently the cf private beta option's the best imo) Yea I am a little bit confused as well being honest. That being said, I feel as if even if Cloudflare might not be the best approach, one can try out purelymail (https://purelymail.com/) as well. I feel as if Amazon SES might be the best option for it (or any EU alternative, I remember seeing an UK service with the same competitive pricing of Amazon SES) But that being said, I am unable to understand the exact use of E-mail & what's the real idea to suggest the best infrastructure to use. I mean technically, can something like cloudflare workers for inbox and amazon ses for outbound work if cloudflare email product is only for receving That being said all of this is basing on the fact that what you thought is right Cloudflare/SES works if you want raw email sending and receiving. If you want threading, parsing, storage, retrieval, logic, filtering, labeling, search -- you'll need to build it out yourself. We're devs ourselves so ik the first thought is usually "how hard can it be?" in our validation, we thought it was hard enough to build a startup around :) these things are easier said than done, and no one in 2026 should be stitching together email workflows. especially not agents > The moat for SaaS is gone. What does this even mean? I could spend $1,000s on tokens asking an agent to build (some semblance of) Sentry, or New Relic, but why would I bother? I have real work to do in the near-term, and I'm happy to pay for services that help me do it. All the hard work is always chasing down edge cases, scaling, operational issues and other things that don't show up the user-exposed features. And talking about features, the innovation in coming up with them, or iterating on making them work with real customer experience is a ton of value, even if copying the ideas that work later is much easier - which is why I generally prefer betting on an innovator with just of enough traction to show they can stick with it. The best category leaders both innovate and steal/copy/buy all the innovation they aren't producing in house to maintain their lead. and a lot of those features only really matter if you are serving a lot of customers. PHP is just fine if your serving 10-20 internal customers. You don't tell agents to build this stuff from the ground up. Someone builds an open source tool, and you get your agents to deploy and customize it. The plumbing and groundwork is already laid, you're just detailing. It's a bit vague, but the idea is right. If your SaaS is built with AI, then any customer you have can also build it with AI, and whatever they build is going to be better suited to their needs and will run cheaper because they aren't paying your margin. AI skews the build vs buy curve massively, because it makes building so much easier This completely ignores that a lot of products distill expertise into something manageable for the end user. And that the actual act of these 3rd parties offering said products maintains not only the software, but the knowledge required to build it. honestly, I have been thinking about it. But I feel like it would be a fun little side project if people actually try it out. (maybe you mention that you can build it) So let's see how many people actually build it. Let's make it the new browser test instead and launch many open source solutions instead and see what's the best perhaps. It would be a really great experiment imo. How does this differentiate from a solution like AWS SES? (Which I assume AI Agents would be quite adept at using to send email) I understand the differentiator vs GMail, but API-based scripted email access isn’t new. Because we built the same inbox infrastructure as Gmail. Inboxes have threads, threads have messages, messages have attachments. You can search, label, filter, reply, forward. None of this comes out of the box with SES. Couldn't someone just ask Claude Code to make an email system with threads/messages and handle attachments? Doesn't seem like a particularly difficult problem to solve. Harder than you would expect! Since we tried this ourselves before switching to Agentmail. Threads, attachments, ccing, DNS management, sending to gmail vs outlook vs yahoo, etc. It add up to be a major pain. This is a pretty clear emergent pattern. An OSS alternative is https://github.com/Dicklesworthstone/mcp_agent_mail. We know the founder of this pretty well actually. It's not really an alternative. They are an MCP that is building an email-like layer for coding agents to talk to each other. We are an actual email inbox provisioned via API for agents to email agents or humans. excellent idea, this will eventually be the SendGrid for email agents. Just automating 2FA alone is worth the gold. And there's tons of use cases. I have no doubt this will be huge. If the agent is sending emails to people you don’t know (“sourcing quotes”) wouldn’t this be a violation of Amazon SES (and all other email providers) terms? Dont they expect permission from the people you are contacting? How’d you get around that? Seems like you're using email as a long lived task queue/journal system. Definitely optimizing for customer recognition/novelty over technical merits. Best of luck! > Here's demo of Clawdbots communicating using AgentMail: https://youtu.be/Y0MfUWS3LKQ Did you record yourself reading out the output of an LLM prompt in this video? If you know agents email address, it can still be Prompt Injected.. what prevention exists there ? we have a few things in place, allowlists and permissions act as a layer. also beginning some work on prompt isolation within api soon. but having an isolated identity + data within a separate agentic inbox also puts less risk of your personal email data being injected - which is most people's main concern Looked into this for my clawdbot, but ended up just using himalaya CLI connected to a new Gmail. Been working great so far - curious about what agentmail is better for We have had some users get banned from Gmail for using it Clawdbot. Regardless our API is way more agent friendly and I think your Clawdbot would agree. I’ve been looking at getting this going but stalwart mail, I have it setup but haven’t done much. I actually for now was thinking vpn only between me any my agents > Email is an optimal interface for long-running agents. Long-running agents are themselves not optimal though. There are a ton of these coordination layers for long running agents now but they don't make any sense under other paradigms We build "long running" email agents. But it's not really long running in the sense of an agent taking 1000's of actions in a giant loop. It's more "long running" because the agent takes 4 steps, then waits a week for the user to email it back. We might have a successful client exchange that takes a month, but for the Agent it's 99% just waiting for the next user reply. So AgentMail uses Mail Agent Nope AgentMail is its own infra. Not a single line of Gmail/Outlook code in the codebase The 2FA via email case is great. I recently had to build a browser automation workflow that required 2FA. I ended up using Zapier to monitor email inbox and then extract the code and send back to our API. It was a bit slow. Why didn't you just use something like Mailinator? They specialize in this exact thing. Gives you an API to grab links and everything. That's what I use. Yup plus webhooks are overkill for this. Need to set up a public HTTP server and pass messages to your agents. With websockets you can open connection right from your agent and close it in seconds once the 2FA code is delivered. ... you had to use Zapier to extract an email from an inbox? Google API scopes for email are pretty restrictive, which is generally a good thing from a security perspective. Retrieving e-mail using the Google API is just about trivial. You can generate a code snippet in Grok or what have you in about 30 seconds to do it. Alternatively you can set up IMAP access. Obviously you have to be able to configure proper OAuth2 keys to do this, but again, that's another 30 seconds spent in Grok/GPT/Claude/whatever. It’s a really nice idea actually. There will be some concerns, maybe some mistakes, but it really works as a mean to communicate much easier with an agent This is fascinating - giving agents dedicated email addresses solves a real coordination problem in multi-agent workflows. I can see this being especially valuable for customer service automation where different agents need to maintain conversation continuity. Curious about how you handle email threading and context preservation across agent handoffs? hah this is a great idea! sending email is such a common way to communicate and having agents with an inbox makes so much obvious sense. heh just don't let their addresses get out who knows how they'll respond to spam and phishing attempts. This is a good point. We have anti-spam measures in place and allow users to configure allow/blocklists to mitigate attacks. What about a concerted attack? Spam doesn't matter for an agent mailbox, but sophisticated fraud does. Can't wait for agents to change the code they are building to buy Amazon Point cards at Target and send the codes back. Looks like SES + api access, isn’t Amazon offering that already? > Because we built the same inbox infrastructure as Gmail. Inboxes have threads, threads have messages, messages have attachments. You can search, label, filter, reply, forward. None of this comes out of the box with SES. aws just gives you a low-level smtp + api service. we are the application layer they do not offer but your agents need to actually use email as first-class users. No offence, but this reads to me like the classic dropbox HN comment The idea is pretty solid, automation platforms often provision a mailbox per flow for this reason, so it makes sense to make a generic service that can be used through MCP for agents Cool website. I built Croft a few weeks ago — very similar. how's traction going? Do you worry about some open-source project replacing it? How do you think this will help with identity verification in the future? Email is already the internet’s identity layer. By giving agents their own inbox they don't need to borrow human identity rather act as first class actors on their own. It lets agents plug into the same trust systems the web already uses! And this opens the door to new ways agents can do work and build credibility on the internet. The nice thing about email is that identity verification is already built in. In fact online identity is based on email. Very interesting. I have a lot of enterprise AI use cases that would really benefit from being email native. We’re an O365 GCC shop. Appreciate that your enterprise options include Bring Your Own Cloud, that makes things much easier for us. It would be nice to have integrations with n8n and Glean. Thats why we built it :)
We have an integration with n8n, will build one for Glean and a request for gumloop. (a YC alum)
https://docs.gumloop.com/ i'd love to know more about how you use gumloop and how agentmail can fit in. mind shooting me an email? adi@agentmail.cc i'd love to know more about these use cases. open to chatting sometime? adi@agentmail.cc is my email I guess not to be confused with https://github.com/Dicklesworthstone/mcp_agent_mail? yup, hard to do that too. AgentMail actually gives agents email addresses and treats them as first class inbox owners with the capability of sending and receiving emails with any other email address. the mcp agent mail project is agents getting their own identity in an internal messaging layer. I have written in one of my comments here about how slow teh website is in one interacton Then I scrolled even more in the website and the amount of lag, my my, I don't even know what to say but the amount of lag is something I have genuinely never witnessed in any website. This is like a new low. I really just want to archive this website to preserve how abysmally slow the website is and its aniations and everything. image literally loading 10% and everyhting. Ship fast and break things is shying from what I am witnessing in here. Sfabt (ship fast and break things) is gonna use your service to talk to the agent which created this project to ask it personally to slow down I can't view your website in 16 gigs of a computer... Weird where the world's progressing in this sense and how it got (YC funded?) Quite frankly I am out of words for how slow the website is. Its really just that bad to be in its own league. Sorry to say. amazing now do the same for voice and sms! Done. Texts can be sent to email addresses and texts can be sent via email, and you can dictate texts and have them read back to you with text-to-voice. We have gotten a lot of requests for SMS. Seems like a natural next step. i think when someone makes the cli like this they're going to win $ phone call bill ok call_id=3f2a $ phone status 3f2a dialing $ phone status 3f2a answered bill: hello $ phone say 3f2a "hey, quick question" ok congrats, I have been following you guys along for a while on LinkedIn. Good Luck Hey I’m also working on this what a coincidence: https://ai-chat.email Second time at least HN is launching YC on one of my products: BrowserBox - hyperbeam Mailpilot/AI-chat.email - agentnail Nice seems like we are building towards a similar vision. Would love to collaborate! Sure, bud. Cut me in on your 500K! My Show from 14 days ago: https://news.ycombinator.com/item?id=46629191 - hmm, why didn't it get into YC? Just trying to provide you some helpful feedback. This reply comes off pretty rude, bitter, and immature. Probably not the look you want if you're trying to get funding. Thanks for sharing how you took it. I'm not sure how helpful that it for me here, as my goal is simply to express exactly how I feel, but it does tell me where you're at. Here's where I'm at: I applied to YC 15 times, never once got a call back. I saw products I applied with later on become the pivot-intos for other teams. I don't think you captured the emotions that are there for me with the words you chose. I'd pick: angry, disappointed, unhappy with this kind of shady behavior. The words you pick are more negative, and frame me as an angry, immature loser. If you're trying to be helpful, don't try to humilitate the person you're trying to help. I'm not immature and bitter, I'm facing that situation I described and having normal emotions about it, and expressing how I feel. If you have a problem with that, where you feel you need to humiliate the person who expresses that, maybe that's something you need to examine in yourself. Also - probably not the "look I want"? "The look" to get funding? It's an attitude/or appropach that sounds so fake, like bullshist. I'm much more into something that's real. But anyway all of this, the experience, the emotions, even this interaction here, is singal and information to me, about what YC is and about what people think about it. "The Look" to get funding? Okay. Or we could just accept reality that there is no moat around this kind of stuff. This seems like an afternoon or weekend project to build, particularly with the promises made about how much more efficient coding is with AI tools now. Yeah, I largely agree. This might seem offensive, but I think this is kind of an obvious product, at least in retrospect. It's easy to implement, and provides no moat. "Application error: a client-side exception has occurred while loading www.agentmail.to (see the browser console for more information)." > Looks at developer console... - "Failed to create WebGL context: WebGL is currently disabled."
Dafuq does an email website need WebGL for? - "Cookie “dmn_chk_xxxxxxxx-yyyy-dead-beef-123456789ABC” has been rejected for invalid domain." Let me guess...vibe-coded? Love getting downvoted for mentioning that the website doesn't properly load and reeks of vibe coding :D If that's the quality y'all can live with and accept, no wonder the web turned to shit. Taking a look will make a fix asap This is just a graphic design gripe, but on: https://www.agentmail.to/enterprise the cutesy ASCII art is rendered in a proportional, not monospace, font, so it looks terrible. The website is really bad. If one moves from Python to curl in the website, one really sees how much noticable lag there is. Like holy Cow, I am not sure what to say seeing such noticable lag The time to go from python to curl. I have seen websites load faster, heck I feel like even 2-3 whole websites can actually be loaded in the noticable lag time we observe. Absolutely crazy to witness.
schappim - 9 hours ago
davchana - 6 hours ago
asyncadventure - 5 hours ago
flemhans - an hour ago
MattDaEskimo - 12 hours ago
mhykim - 12 hours ago
suriya-ganesh - 10 hours ago
mhykim - 9 hours ago
bofadeez - 9 hours ago
mhykim - 8 hours ago
themanmaran - 9 hours ago
smpandya - 13 hours ago
Haakam21 - 13 hours ago
trollbridge - 11 hours ago
mhykim - 11 hours ago
charles_f - 3 hours ago
jessechoe10 - 11 hours ago
petervandijck - 10 hours ago
biddit - 13 hours ago
gustrigos - 12 hours ago
biddit - 12 hours ago
gustrigos - 5 hours ago
Haakam21 - 12 hours ago
trollbridge - 11 hours ago
jacobr1 - 10 hours ago
Imustaskforhelp - 9 hours ago
calvinmorrison - 6 hours ago
fmbb - 12 hours ago
themanmaran - 11 hours ago
mhykim - 11 hours ago
pizzafeelsright - 10 hours ago
baxtr - 10 hours ago
awillowingmind - 9 hours ago
rulelet - 8 hours ago
javaskrrt - 10 hours ago
101008 - 6 hours ago
TheTaytay - 7 hours ago
CuriouslyC - 7 hours ago
christiangenco - 10 hours ago
petesergeant - 9 hours ago
ray_v - 10 hours ago
eagleinparadise - 10 hours ago
Imustaskforhelp - 9 hours ago
adisingh13 - 8 hours ago
VWWHFSfQ - 10 hours ago
jacobr1 - 10 hours ago
calvinmorrison - 6 hours ago
CuriouslyC - 7 hours ago
vimda - 10 hours ago
awillowingmind - 9 hours ago
Imustaskforhelp - 9 hours ago
nerdsniper - 13 hours ago
Haakam21 - 12 hours ago
trollbridge - 11 hours ago
themanmaran - 11 hours ago
smoyer - 4 hours ago
adisingh13 - 4 hours ago
pirsquare - 10 hours ago
thetwopct - 5 hours ago
CuriouslyC - 7 hours ago
nubg - 8 hours ago
Jayakumark - 10 hours ago
adisingh13 - 8 hours ago
swaraj - 8 hours ago
Haakam21 - 7 hours ago
ncrmro - 9 hours ago
wild_egg - 12 hours ago
themanmaran - 11 hours ago
umrashrf - 12 hours ago
mhykim - 11 hours ago
throw03172019 - 13 hours ago
ckenst - 12 hours ago
Haakam21 - 13 hours ago
trollbridge - 11 hours ago
iamacyborg - 10 hours ago
trollbridge - 3 hours ago
lucasayb97 - 11 hours ago
asyncadventure - 8 hours ago
chasd00 - 13 hours ago
Haakam21 - 13 hours ago
trollbridge - 11 hours ago
rootnod3 - 13 hours ago
mrklol - 12 hours ago
ktanishqk - 11 hours ago
mpeg - 11 hours ago
adammiribyan - 10 hours ago
rnc000 - 9 hours ago
ritomsen09 - 13 hours ago
mhykim - 12 hours ago
Haakam21 - 12 hours ago
pbronez - 13 hours ago
Haakam21 - 13 hours ago
thedrake - 12 hours ago
adisingh13 - 8 hours ago
adisingh13 - 6 hours ago
wild_egg - 13 hours ago
ktanishqk - 12 hours ago
Imustaskforhelp - 9 hours ago
waynenilsen - 13 hours ago
stronglikedan - 13 hours ago
Haakam21 - 13 hours ago
waynenilsen - 13 hours ago
calvinmorrison - 5 hours ago
keepamovin - 13 hours ago
Haakam21 - 13 hours ago
keepamovin - 12 hours ago
freedomben - 12 hours ago
keepamovin - 3 hours ago
trollbridge - 11 hours ago
freedomben - 7 hours ago
rootnod3 - 13 hours ago
rootnod3 - 13 hours ago
Haakam21 - 13 hours ago
trollbridge - 11 hours ago
Imustaskforhelp - 9 hours ago