I gave Modal a real shot over the past 3 months. Some things worked, some did not. Here is the breakdown.
For AI infrastructure, Modal's approach is surprisingly well-considered. It picks up on naming conventions, project structure, and the patterns I actually use. No boilerplate that does not fit.
Refactoring across multiple functions works better than I expected. I was bracing for the "change one endpoint, break three others" experience. Modal holds context across a small refactor.
The main thing Modal could improve is pricing. For a tool at this price point, I expected better enterprise features.
Also, support for less common frameworks is noticeably weaker than for mainstream ones. If you work in niche stacks, expect to do more hand-holding.
The documentation has gaps on advanced configuration. Some settings I only discovered by reading the source.
Who should use Modal: DevOps engineers who are past the experimentation phase and want a tool that works. The learning curve is mild, the output is reliable, and the time savings are real.
Who should skip: hobbyists on a tight budget (use the free tier of a competitor), enterprises with strict compliance needs (look at the enterprise tier or a different tool), and anyone who needs features this tool does not have.
For most people reading this: try the free tier. If it sticks, upgrade. If not, you have lost nothing.
Final verdict on Modal: it is a solid infrastructure tool in 2026. Not the best at any one thing but good enough at most things. I will keep using it.
Rating: 4.6/5. The score reflects my assessment after 3 months of real use, not just a quick test.
The bottom line: Modal is a safe bet. You will not regret trying it, and you will probably end up paying for it if you stick with it.
What changed after 3 months
My first impression was more enthusiastic than my current view, but only because I had not yet found the limitations. After 90 days, I know exactly when to use Modal and when to switch to alternatives. That specificity is more valuable than initial excitement. Tools that look magical in week 1 often disappoint in month 3. Modal did the opposite for me: it got more useful the longer I used it, because I learned its patterns.
The dealbreakers I wish I knew earlier
Three things would have saved me time if I knew upfront: (1) the learning curve is steeper than the marketing suggests, so budget a week to find your workflow, (2) the mobile experience is functional but not great, and (3) customer support is slow on weekends. None of these are fatal, but they are the kind of details that only show up after daily use.
Who should skip Modal
The honest take on Modal after daily use: it is good at the things it was designed for, mediocre at everything else. The marketing copy oversells. I keep it open for the 2 to 3 specific tasks where it shines and switch to other tools for the rest. That setup is where Modal pays for itself.
Real Workflow: Running a Nightly Fine-Tune Job Without Managing Servers
Two months ago I needed to run a nightly fine-tuning job on a small domain-specific dataset. The job needed a GPU, had to run on a schedule, and I did not want to manage a persistent server for something that runs for 40 minutes each night.
Step one: I wrote the training script in Python as I normally would. Then I added a single Modal decorator to the function: @app.function(gpu="A100", schedule=modal.Period(hours=24)). That was the entire infrastructure change. No Dockerfile, no Kubernetes config, no server to provision.
Step two: I ran modal deploy from my terminal. Deployment took 90 seconds. Modal built the container, registered the schedule, and confirmed the first run time. I did not touch a cloud console.
Step three: the job ran the following night. I checked the logs through the Modal dashboard the next morning. The fine-tune completed in 38 minutes. The output model was saved to an attached Modal volume. I pulled it down and tested it locally.
Step four: the job has run every night since without intervention. Two nights it failed due to dataset issues on my end. Modal sent me an email within two minutes of each failure. Both were easy to diagnose from the logs.
The concrete result: a scheduled GPU job with monitoring, logging, and automatic retries, set up in about 45 minutes. My previous approach involved a persistent EC2 instance running idle for 23 hours a night. Modal eliminated that waste entirely. The cost dropped from roughly $180 per month to under $30.
Pricing Reality
Modal charges for compute time, not a flat subscription. That distinction matters when you are estimating costs for workloads that are not running 24/7.
The free tier gives you $30 in credits per month with no credit card required. That is enough for meaningful experimentation. A40 GPU time costs roughly $0.90 per hour on Modal. Your $30 free credit covers about 33 hours of A40 time per month. For scheduled batch jobs or intermittent inference tasks, that goes a long way.
Paid access removes credit limits. Current GPU pricing as of mid-2026: T4 at around $0.59 per hour, A10G at roughly $1.10 per hour, A100 at approximately $3.70 per hour, H100 at around $4.00 per hour. CPU compute is billed separately at a much lower rate. Storage is $0.10 per GB per month for Modal volumes.
There is no minimum monthly spend. You pay for what you use. That model works well for variable workloads but requires active monitoring. A job with a bug that loops indefinitely will run up a bill before you notice. Set spend alerts in the dashboard before you deploy anything to production.
The hidden cost most people miss: container build time. Modal builds a fresh container image when you change your dependencies. That build time is billed at CPU rates and is usually small, but it adds up if you are iterating rapidly on your environment. Cache your dependency layers carefully to avoid rebuilding from scratch on every deploy.
For teams, Modal does not currently offer a seat-based enterprise plan with centralized billing and access controls in the standard tier. Enterprise arrangements are available through direct contact. If you are deploying Modal for a team of more than a few developers, ask about organizational account options before assuming the standard setup covers your needs.
The One Thing Nobody Tells You
Modal's cold start behavior is much better than most serverless platforms, but it is not zero. And that gap matters more than it sounds.
Most Modal functions cold-start in two to five seconds for simple Python environments. Functions with large dependencies (PyTorch, transformers, large models) can take 30 to 90 seconds on a fresh container. Modal caches container images aggressively, so repeat invocations after the first one are fast. But the first call after a deployment or a long idle period will be slow.
This matters for user-facing applications. If you are building an API endpoint on Modal that users hit directly, that first cold start is a user-visible delay. I learned this in my second month when I moved a synchronous inference endpoint to Modal and started getting support tickets about "slow first responses." The subsequent requests were fine. The first one was not.
The fix: use Modal's keep_warm parameter to keep one container instance running at all times. That eliminates cold starts but costs money for the idle time. For a low-traffic endpoint, the cost is roughly the price of one GPU-hour per day. Whether that trade-off is worth it depends entirely on how user-visible the latency is in your application.
Asynchronous batch jobs and scheduled workloads are not affected by this at all. Cold start only matters when a user is waiting for the response. Know which category your use case falls into before you deploy.
Three Honest FAQs
Q: How does Modal compare to AWS Lambda or Google Cloud Run for deploying Python functions?
Modal's main advantage over Lambda and Cloud Run is GPU support and Python-native configuration. Lambda does not support GPUs. Cloud Run supports GPUs but requires more infrastructure setup. If your workload is CPU-only and you are already in AWS or GCP, the managed options are probably simpler. If you need GPU access or want to avoid cloud-provider-specific configuration files, Modal is meaningfully easier to work with. The trade-off is less vendor ecosystem integration compared to native AWS or GCP services.
Q: Is Modal suitable for production workloads, or is it better for experimentation?
It handles production workloads, but with caveats. The platform is reliable in my experience: I have not had an unexpected outage in three months of daily use. The caveats are around the enterprise features that heavier production deployments expect: audit logs, role-based access control, and SLA guarantees are not available on the standard tier. For production workloads with strict uptime or compliance requirements, evaluate the enterprise tier or a more established cloud provider. For production batch jobs and internal tooling, the standard tier is solid.
Q: Can I run large language model inference on Modal cost-effectively?
Yes, for the right workload shape. Modal is cost-effective for inference that is bursty or scheduled: high volume for short periods, then idle. You pay only for active compute. For sustained high-throughput inference where a GPU needs to be running constantly, a reserved instance on a major cloud provider will usually be cheaper. The break-even point depends on your utilization rate. If your GPU utilization is above 60% of the time, reserved instances are likely cheaper. Below that, Modal's pay-per-use model wins on cost.
