Frequently asked questions
Short answers. Each one links to the page that explains it properly.
Using it
- Do I need a GitHub token?
- Not for public repositories. Private ones need a token configured on the server, and without one you are also subject to GitHub's unauthenticated rate limit, which a single investigation can exhaust.
- Can I investigate a specific run rather than the latest failure?
- Yes — paste the run URL into the repository field. It pins the investigation to that run.
- How long does one take?
- Usually 15 to 45 seconds. The first ten to fifteen are spent downloading and unzipping the log archive and resolving the baseline commit, before any model runs.
- What does it cost?
- Whatever three model calls cost on the provider you chose. On a free Groq key, nothing. TraceCI itself takes no payment and has no accounts.
- Can I run it without an API key?
- You can replay a recorded investigation, which is a captured live run played through the same interface. A live run needs a key.
Safety and data
- Can it change my repository?
- No. There is no code path that commits, comments, opens a pull request or re-runs a job. Every GitHub call it makes is a read.
- Where does my API key go?
- To the TraceCI API with one request, then to the model provider. It is never written to graph state, checkpoint metadata or a shared record — see models and keys.
- What is sent to the model provider?
- The failure context — log window, diff summary, and any source the agent chooses to read. If your CI logs contain secrets, those secrets are in the request.
- Who can see an investigation I ran?
- Anyone with the thread id can read that record from the server. Ids are random and not listed anywhere, but they are not access-controlled — treat one like a share link.
Results
- Why did it use zero tool calls?
- Because the log already contained the answer. On a dependency conflict or a lint error that is the correct behaviour, not a shortcut.
- Why is the confidence low?
- Confidence measures how much of the root cause is quotation rather than inference. A low score usually means a thin log window, a non-deterministic failure, or an exhausted tool budget.
- It blamed the wrong file. What now?
- Open the full record and check the log window and the baseline. Most wrong diagnoses are input problems rather than reasoning problems — the procedure is in troubleshooting.
- Can I trust the suggested patch?
- Read it after the evidence, and treat it as the minimal change that addresses the stated cause rather than the change you should ship. It is most reliable on lint and type errors, least reliable on dependency conflicts.
- Does it get better if I re-run it?
- Not meaningfully. If the first result was thin, the input was thin. A narrower branch, a more precise run, or a stronger model will change the outcome; repetition will not.
Scope
- Does it work with GitLab, CircleCI or Jenkins?
- No. GitHub Actions only.
- Can it diagnose two failures in one run?
- It diagnoses the first failing step. Investigate the second separately once the first is fixed.
- Does it track flaky tests over time?
- No. Each investigation is independent; there is no aggregation or trend analysis. See limitations.
- Are my past investigations stored anywhere I can search?
- The list is kept in your browser, not on the server — there are no accounts, and a shared index would expose everyone's repositories to everyone else. Diagnosed runs remain reachable on the server by id.