Framer AI AgentsDesign and publish professional sites with AI
TryCase
Disposable test environments for AI coding agents
292 followers
Disposable test environments for AI coding agents
292 followers
TryCase gives AI coding agents disposable Linux environments to run apps, test changes end to end, capture screenshots and recordings, and return verified code instead of asking you to test manually.
Free Options
Launch Team
'Return verified code instead of asking you to test manually' is the exact gap. My coding agent writes the fix, then I'm the one clicking through the app like it's 2015. The agent proving its own work with screenshots and recordings flips the trust equation completely. How isolated are the environments - can it safely test against a copy of production data? Congrats on the launch.
@david_marko Thanks David. Each run gets its own Firecracker microVM with a separate filesystem and network boundary. It can only reach production services if you explicitly give it the credentials.
I would not use raw production data by default. A sanitized copy or staging database with short-lived, limited credentials is much safer.
Would you want TryCase to create a masked database copy automatically, or connect to staging infrastructure you already have?
How do you handle state between runs if the agent needs to verify something like a running database or queued background jobs from a previous step?
@as_hulya85969 Within the same environment, the state sticks around. A database can keep running, queued jobs can continue, and filesystem changes persist while the agent works through multiple steps.
A new environment starts clean, and TryCase does not currently carry runtime state between separate environments. When you say “between runs,” do you mean steps within one PR QA session, or a later run after another commit?
I’m curious about the differences between GPT-5.5 browsing and testing and TryCase. What makes TryCase unique, apart from just screenshots and videos? Thank you
@otman_alami Good question. GPT-5.5 can already browse and test when it is paired with the right tools. In Codex it can use a shell, control a browser, and inspect the DOM, console, and network traffic. So screenshots and recordings alone are not the difference.
Today TryCase is a model-agnostic runtime layer. Any coding agent can spin up an isolated Linux environment, upload a repo, run apps and tests, use a browser or desktop, collect artifacts, and destroy the environment afterward. It does not yet have its own built-in agent or automatic PR QA.
The direction I’m exploring is more opinionated: connect GitHub, automatically QA each PR, generate temporary scenarios and E2E tests, then have a separate agent review the results and return issues with evidence. That part is not built yet.
Congrats on the launch, this is a real problem. My question is more about the iteration loop than the verification side - if an agent fails, tweaks the code, and needs to test again, does it get a brand new disposable box each time, or does it reuse the same one until the task is done? Fully fresh every retry sounds cleanest for isolation but on a repo with a slow install/build step that could add up fast if the agent is iterating 10+ times on one bug.
@galdayan Thanks Gal. In the current version, the agent reuses the same environment until the task is done, so dependencies, build caches, files, and running services stay available across retries.
I’m currently working on the next version, which will automatically QA GitHub PRs. The plan is to reuse an environment while the generated tests iterate, then run the final verification in a fresh environment. I’m still deciding whether every individual test scenario should also start clean. What would you prefer?
@ben_chomsang i'd want per-scenario cleanliness only when the scenarios could interfere with each other (shared db state, leftover queue items). if they're independent, forcing a fresh boot per scenario just to be safe seems like paying the install/build cost again for no real isolation benefit. maybe make it configurable per test suite rather than a global default either way.
how does it handle cleanup of those disposable environments when an agent spins up a bunch in parallel, anything to worry about resource-wise?
@uurk6oe Good question. Today each environment is its own Firecracker microVM. The agent is expected to destroy it when the task finishes, and TryCase also has idle and maximum runtime limits to catch forgotten environments.
Workspaces have concurrency and credit limits, and the scheduler will not overcommit a host. During teardown, TryCase stops the VM and removes its writable disk and network resources. It also reconciles orphaned resources after crashes.
I’m working on PR-based QA now, where this lifecycle should happen automatically for each PR. Is your main concern runaway billing, cleanup reliability, or handling lots of PRs at once?
As a solo dev shipping an iOS app, the final manual-verify step is exactly where my releases stall — I'm the QA team of one, and "done" from an agent usually just means "it compiled." The disposable box per agent is a smart way to move that check off my laptop. Does it handle mobile/app flows (simulator or a device) yet, or is it web + CLI apps only for now?
@lennoxbeflying Thanks Ziang. TryCase does not support iOS simulators or real devices yet. It currently runs Linux environments, so the main use cases are web, CLI, and backend apps.
The blocker is mostly cost. iOS testing requires macOS hardware, which is much more expensive to run on demand. Would simulator-only testing cover most of your workflow, or would you need real-device testing too? Would you be comfortable with macOS runs being priced separately per PR?
The "come back with proof instead of just code" framing matches exactly where my agent workflow breaks. I ship an iOS app and the agent can pass tsc and lint all day, then I'm still the one clicking through the simulator to see if the thing actually renders. Since the environments are Linux, is mobile out of scope for the foreseeable, or do you have thoughts on a macOS/simulator story? Even screenshot-level proof for a web preview would change my loop.
@narek_keshishyan You’re right, Linux is the current constraint. Native iOS testing is not supported yet because running macOS simulator workers is much more expensive than Linux environments.
I’m looking at whether a separately priced macOS runner could make sense, but it is not built yet. Is your app React Native or Expo with a web target, or fully native SwiftUI? A web preview might cover part of the QA loop much more cheaply.