--- title: How tools run description: >- Every tool runs as a tracked compute job, an instant lookup, or code in the chat's workspace, and that decides its latency and cost. tags: - concepts - tools - execution --- *How a tool runs* decides four things: how long you wait, whether you get a job you can track, what it costs, and where the result lives. Predicting a protein structure spins up a GPU, hands you a job to watch, and bills for compute time. Looking up that protein's sequence returns almost at once and costs next to nothing. Tools in the same execution class share a rhythm. The sidebar groups the compute tools by scientific domain, and gives database lookups, the code workspace, the Galaxy bridge, and lab and local tools their own entries. Learn the rhythm of a class once and every tool in it feels familiar. The rest of this page walks the classes, so when a tool answers slowly or shows up in your job list, you already know why. ## GPU jobs — the tracked heavy compute Most scientific compute on the platform runs this way: structure prediction, docking, generative design, property panels, retrosynthesis. You submit the tool, it is dispatched to a Modal compute backend (a GPU when the model needs one, CPU otherwise), and a **job** is created — a tracked unit with its own status that moves through `queued → running → completed` (or `failed`). You do not wait at the prompt; the job runs in the background and you can leave, come back, and find it in your job history. Because these tools stand up real compute, they are the ones with meaningful latency (seconds to many minutes) and the ones that consume credits by compute time. The upside of that cost is durability: every run leaves a job record and downloadable artifacts, so results are reproducible and revisitable rather than one-shot. When you ask for a structure and the platform tells you "your job is running," this is the class you are in. ## Database & lookup tools — the instant answers Lookups run the opposite way. A tool like a compound search, a protein-annotation fetch, or a literature query calls a curated database directly and returns **immediately, inline** — there is no job created, nothing to track, and only a small flat charge per run. You get the answer in the same beat as the request. You reach a lookup by asking Ivy in chat; there is no form, job or CLI command for one. This is why a lookup is almost always the cheapest, fastest first step: before you spend a GPU job on modeling, you check whether the compound, structure, or paper you need already exists. Because nothing is queued, there is no job record for a lookup — the result renders straight into a canvas card and you move on. Reach for this class whenever the question is "does this already exist / what is known about it," and save the GPU jobs for when you actually need to compute something new. ## The code workspace — code Ivy writes and runs for you Every chat has a private Linux workspace, one per conversation and kept warm while you work. When no packaged tool covers a step, Ivy writes Python, R, Julia, Octave or shell code and runs it there: filtering a large result, joining two tools' outputs, a custom statistic or plot, or a notebook you uploaded. You describe the analysis; you never call the workspace directly. The latency here is the workspace itself: the first run waits briefly while it boots, then later runs are fast because the same workspace is reused. Files it writes stay in the workspace until you ask Ivy to save them to your files. > A handful of GPU-job tools describe themselves as running "in a sandboxed library call". That only means the tool isolates a Python or R computation internally; it is still a tracked GPU job. The code workspace is the per-chat environment described above. Same word, different thing. ## Galaxy bridge tools — external analysis, still tracked The Galaxy bridge connects the platform to a Galaxy analysis server. These tools dispatch to that external service and, like GPU jobs, run asynchronously — the platform submits the work, polls for progress, and delivers the result back into your chat when it is ready. So they feel like jobs (you wait, you get tracked progress) but the compute happens on the bridged Galaxy backend rather than the platform's own GPUs. Reach for this class when your workflow needs a bioinformatics analysis that lives in the Galaxy ecosystem. The experience mirrors the GPU-job rhythm — submit, wait, receive — with results routed home for you. ## Lab & data-prep tools — bench and lightweight steps Some tools cover steps that happen outside the GPU backend entirely — lightweight data-preparation or bench-facing operations that support the scientific workflow without standing up heavy compute. They tend to be fast and inexpensive, and like lookups they typically return inline rather than creating a long-running job. Treat this class as the connective tissue of a workflow: the data transformations and lab-oriented steps that sit between the heavier modeling jobs. ## Reusing results you already have Large results are never pasted whole into the conversation. Ivy works from a compact summary, and the full payload is kept for the rest of the session. When a later question needs the detail ("show every pose, not just the top five"), Ivy reads it back from the stored result instead of re-running the job. That read starts no compute and costs nothing, and it is how a long conversation stays grounded in earlier data. You do not need to do anything to enable it. ## Reading the class from what you see You rarely need to name a tool's class up front — you can read it off the experience. If the platform tells you a **job is running** and it shows up in your job history, you are in a GPU-job or Galaxy-bridge tool, and the wait and the credit cost come with tracked, revisitable results. If the answer arrives **inline with no job**, it is a lookup, a local step, or a read-back of an earlier result — fast, cheap, and one-shot. And when Ivy runs code or touches files in your workspace, you are in the code workspace. ## Read next