--- title: Troubleshooting description: The refusals and failures you are most likely to meet, and what each one means. --- Redline tries to fail at the earliest honest moment and to say what would fix it. This is what the common messages mean. The launch was refused before it spent anything. Open **Agents**, connect that agent with your own key or subscription, and make sure its switch is on — only enabled agents are offered to the builder, and the absence of a connection is read as off rather than as "probably fine". One of your own agents can only run while its worker is connected, because nothing else can execute it. Start it again in that repository: ```bash cd ~/code/my-agent && npx redline dev ``` The Agents page shows that exact line, with the directory it last ran in already filled in, and a *Copy start command* button beside it. If a **schedule** hit this, it recorded the reason on its row and waited for its next slot rather than retrying. The run finished but could not be judged. The evaluator thinks with OpenRouter: either your Redline was started with a key, or you connect one in the project — on **Agents**, connect **OpenCode** with its *OpenRouter key* method. An experiment with no rubric needs no evaluator at all. A clone is a required step: a run whose repository never arrived cannot mean anything, so it stops rather than continuing without it. Almost always one of two things — the URL is wrong, or the repository is private. Redline holds no git credentials, so private repositories cannot be cloned. Attach the code as an upload instead. Check three things, in order: 1. Was the file actually ticked? On the builder it belongs to the **Files** row in the Configuration rail; on a task it is the file picker in the task dialog. The run's Instructions panel lists what the task carried. 2. Did the task refer to it by the name it lands under? An upload keeps its own name in the working directory; a repository becomes a directory named after it. The Files table spells out both. 3. Is this one of your own agents? Then the file is on the run's machine, not on your computer — read it with `machine_run`. The ceiling is about memory rather than disk — every byte is read, encoded and pushed into the container in one go, so the machine's tens of gigabytes are not the constraint. Split the file, or ask whoever runs your Redline to raise the limit. The file in `redline/` does not export a `defineAgent` object (or, in Python, `agents.py` has no `@agent`-decorated function). Every file in that directory is imported by the CLI, so it must export agent definitions and must not start a server on import. If registration is rejected instead, the `id` collides with a catalog agent's — pick another slug. Run `npx redline doctor`. It reports whether the tools are reaching the framework you use without spending a run. The SDK injects attached tools into `generateText`, `streamText` and `Agent` (Vercel AI SDK), `createReactAgent` and `createToolCallingAgent` (LangChain / LangGraph), and `Agent(...)` in Pydantic AI. If your agent builds its own loop, ask for them explicitly: ```ts const attached = await redlineTools(task); // spread attached.tools into your agent, then await attached.close() ``` Skills are not affected — they arrive as text in `task.prompt`. That is deliberate. Installing a CLI on a catalog run happens inside a disposable container; doing it for your agent would install software on *your* computer, so Redline never does. The run has a machine of its own — reach it with `machine_run`, where the CLI is installed. If you really do want it locally, call `installClis(task)` yourself. That is the per-attempt time limit; the machine is killed when it is reached. Either the task is too large for one attempt, or the agent is stuck in a loop — the transcript's last few entries usually say which. Split the task, or ask whoever runs your Redline to raise the limit. No rubric was chosen for that experiment, so there is nothing to score. The verdict is whether the agent's own process succeeded. Pick a rubric in the builder to get criteria, notes and a percentage. Two usual causes. Either the criterion is not the kind of thing that can be established by looking — "the code is clean" — in which case rewrite it as a fact, and remember that a borderline criterion is failed on purpose. Or the run was executed by one of your own agents with nothing attached, so no machine was built and there was no box to open. The evaluator judged the record and the final answer instead. Attaching a repository or an upload gives that run a machine. Deleting the task would orphan runs that were produced from it. Delete the experiment — which takes its runs with it — or leave the task in place. Tasks with no runs delete cleanly. Machines have the same rule: one that experiments have run on cannot be deleted, and the default one cannot be deleted until another is made the default. Three possibilities, cheapest first: 1. The experiment's **At once** setting is 1 and one run is already going. Raise it on the experiment page. 2. The server is at its own capacity because other experiments are running. Runs are claimed oldest-first, and an experiment at its limit is skipped rather than allowed to block the queue. 3. The run belongs to one of your own agents and its worker is not connected. Start `redline dev`. Missed firings are not made up. A schedule that was due while nothing was running comes back to *one* launch at its next slot, not to every slot it missed — six stale copies of last night's answer would cost real money and tell you nothing. If it is failing rather than skipping, the row carries the reason as a warning. ## Still stuck? Ask the project agent. [Ask Redline](/automation/ask) can read your experiments, open a failing run, read the evaluator's notes against each criterion, and tell you what it found — which is usually faster than reading the transcript yourself.