/ docsWhat NthCase isllms.txt
On this page
The loopThe surfaces

What NthCase is

End-to-end testing for iOS, Android and web. You can afford to test every release. Write the test yourself, or ask your AI tool to. You choose the AI model for each compile, run and discovery, from seventeen Claude and OpenAI models. You see the estimated cost in credits before you run or schedule a test.

NthCase: everything of yours on one side, the system on the otherA map of NthCase as two territories side by side, with one gap between them. On the left, inside one border, everything of yours. Along its top stand the four that ask for a test, each with its own line straight across the gap to its own door: you, a person at a screen, to the Dashboard; your AI agent, a small robot, to the MCP server and its 46 tools; your CI, a pipeline, which runs the nth command line, to the CLI; and your own code, to the REST API. Below a dashed line marked on your premises: your machine, with the NthCase agent standing on it, the bridge between your devices and the system, and your own phones and tablets cabled to the machine. From the agent one green line goes out across the gap, through the system's wall and into the farm, and under it is written: connects outward — nothing reaches in to you. Beside your premises, in a dotted corner that belongs to neither territory: devices on an outside platform you already use, a building of phones under a cloud — your account, your credentials — they never enter the system. One line reaches it, from the agent, and nothing from the system. On the right, the system: a green territory named NthCase. Its wall has four doors — Dashboard, MCP server, CLI and REST API — and behind the wall they merge into one line that arrives at the engine. Beside the doors: one workspace key opens all four. The engine prepares a test, runs it, records what happened. Below it, the farm finds a free device and gives the run to it, and our devices hang off the farm: physical devices, real phones and a tablet on a rack, and emulators, a dashed phone inside a screen — a phone that is software on a machine of ours. Every line between the two territories crosses in one direction, from your side into the system.youyour AI agentyour CIyour own codeDashboardMCP serverCLIREST APIon your premisesNthCase agentthe bridge between yourdevices and the systemyour own phonesand tabletsconnects outward —nothing reachesin to youdevices on anoutside platformyou already useyour account,your credentials —they never enterthe systemone workspace key opens all fourNthCasethe engineprepares a test, runs it,records what happenedthe farmfinds a free device andgives the run to itphysical devicesemulators

The loop

Describe a test as ordered natural-language steps. Compile it into a deterministic plan: with a map from Discovery, the compile takes your app's real selectors from it; without one, it works from the steps alone. Runs replay the plan, so a green run is reproducible, not a lucky improvisation. Run it on a real device from the farm. Read the evidence: a screenshot per step, the duration, the model used, the redacted logs, the network capture when the run recorded one, and an honest pass / fail / error verdict — an error is an infrastructure answer, never a fake test verdict.

Around that loop: Discovery crawls an app screen by screen and proposes scenarios (quoted before it starts), schedules run scenarios unattended on a cron cadence, and everything the app can do is also reachable by your agent and your CI — the same workspace API key drives the CLI, the MCP server and the REST surface.

The surfaces

Scenarios, runs, discovery, schedules and devices are also documented in the app — each screen explains its own contracts. What is on these pages is the part you need before you are signed in, plus the machine surfaces (nth, MCP, REST) an app screen cannot show you.