The callback already verifies state — reusing it for Google login…
- Editapp/models/user.rb2.1sWire the provider column into the auth flow
Any model — even a cheap one. Queue a task in the morning and review a finished pull request, a proposed code change ready to merge, in the afternoon.
Nothing merges without your approval · the repository stays on your machine · 30 days free, no card required
The callback already verifies state — reusing it for Google login…
An AI coding agent orchestrator decides which coding agent works on what, runs it, and checks the result before anything is merged. mcptask.online keeps one task queue with priorities and blocker links, a triage step picks the model for each task, and the mcptask runner drives Claude Code, Codex CLI or OpenCode on your own machine, opens a pull request and runs your local CI. In auto-squash modes it merges only after the checks are green, and a daily quota caps how much the runner works each day.
Read more – what an orchestrator has to do and how to start →Plenty of tools hand a task to AI. Far fewer answer the question your client will ask when the invoice arrives.
The AI fixed a bug — but the invoice shows nothing. Your client asks what they are paying for, your reports have no line item, and you have no proof the AI tool paid off.
AI helped you with five tasks today. Your task system shows zero. At the end of the day you reconstruct what it did and type it into the timesheet by hand.
Every time you launch your AI assistant you paste the description, criteria, and context. The AI only gets what you hand it — and often less than it needs.
One runner, one queue. The task does not stop at the merged pull request — the time worked on it flows into your timesheet and your invoice.
One task — the full lifecycle on a single screen
The runner pulls the next well-specified task from your queue and matches it with the right model.
The agent writes the code, runs tests and the runner opens a pull request on GitHub, GitLab or Bitbucket. A human merges it — or the runner does, if you chose auto-squash mode at install, and only after your project's own test suite passes.
The agent logs time worked as it goes, or it is attached to the task from commits that link the task (GitHub and GitLab; Bitbucket has no timesheet link). The merged pull request sets the task's progress to 100 %.
From the timesheet, one click turns the work into a Fakturoid or iDoklad invoice.
The manager asks: “What exactly did the AI help with this sprint?” — and the next question: “Can we justify the AI tool cost?” In mcptask.online every entry of time worked carries the name of whoever did the work. You stop guessing and start reporting.
Every work entry says who did it, when, and how long it took. No scattered chat logs. No fuzzy memories.
When leadership asks whether the AI subscription pays off, you have a number. Time worked by the AI is logged the same way as people's — comparable, reportable, billable.
The runner opens a pull request and a human reviews and merges it — unless you chose at install that the runner merges on its own after green tests. A boss or tester then approves the finished task, as their project role allows. Where a project has flagged its AI membership, the dashboard breaks the work down by who actually did it.
When the AI reports progress on a task, the time worked is taken from the task's estimate by how many percent the task moved. The “AI efficiency” coefficient on the project membership then scales it — at 75 % the entry counts as 1.33× the estimate; with no coefficient the estimate stands as it is.
How it becomes an invoiceFive things we do differently from generic AI agents.
Our runner works with any model, including cheap and local ones. Copilot, Codex and Claude Code on their own tie you to their vendor's model; mcptask_runner drives Claude Code, Codex CLI or OpenCode and lets you route each task to any model.
The agent works against your real database, system tests and screenshots, not a generic cloud sandbox.
An unrelated bug the agent runs into is filed as a new task and fixed. The step-by-step walk-through is below.
When the model runs out of context or a service drops out for a moment, the runner picks up and carries on with the task in progress.
The runner logs time worked against the task as it goes. Same mcptask.online that hosts the queue exports it as a timesheet for your invoice — no copy-paste. The client sees hours worked the same as from any other team member.
And the basics you would expect, listed once instead of as ten headline cards:
When the agent hits an unrelated bug mid-task, it does not stop and wait for you. Here is what actually happens:
Task #47 in progress
Agent-1 is working on the OAuth login refactor.
Hits an unrelated bug
Agent-1 spots a flaky test that has nothing to do with OAuth.
Files task #53 as urgent
Agent-1 files a tracked urgent task. The pin lifts it past triage so it runs on the strongest model — but only after the working copy is clean. If there are uncommitted changes, the run stops and waits for a person to sort it out.
Fixes #53
Agent-1 writes the fix for the flaky test and opens a PR for it.
Merges #53
In auto-squash mode the runner merges the PR itself. In manual mode the run stops at the PR and a person merges it after review.
Returns to #47
Agent-1 picks #47 back up from where it left off and finishes the original work.
All six steps happen without you. The runner picks up #47 again on its next loop if the agent crashes mid-task.
Three situations where the agent makes noise instead of going silent.
When something the work cannot do without is missing, the runner says so out loud. It does not guess a replacement and does not carry on where the work cannot succeed.
When the work crashes, the runner files its own bug report with the run log attached. It does not wait for you to notice on your own.
The one case we admit is blind: when reaching mcptask.online itself fails, the runner cannot report it through mcptask.online — the reporter authenticates with the same access as everything else. In that case it reports through the exit code and the log instead. That is why the runner refuses to start at all rather than try and hope.
Five rules that did not fit on the homepage and that you want to know before you point the runner at your repository.
Every user, human or AI, has working hours for each day set in the app. Once they end, the runner takes no new task. The daily hour limit stops the loop as well.
You choose the default mode at install. In manual mode the runner opens a PR and a person merges it after reviewing it. In auto-squash mode the runner merges the PR itself as soon as CI passes. Nothing merges without green CI.
You choose the model and pay its provider directly, a different one per runner if you like — a local model for routine work, a strong model for hard tasks. Your repository and database stay on your machine. What reaches us is the task text, the time log and the run's progress for the live card.
The runner opens PRs on GitHub, GitLab (where they are called merge requests) and Bitbucket. Commits and PRs are matched to tasks in mcptask.online through webhooks, which only GitHub and GitLab support so far.
The runner works under the account and with the access you set up for it — just like a new team member. mcptask.online stores none of your passwords or keys.
Three scenarios where the runner helps most. The technical implementation is under every card.
Names and numbers in the cards are illustrative. We publish the real numbers from our own operation as they come in. See the live numbers
Spin up five machines, one agent on each — five users, five seats. A week's worth of scope lands in a day and the deadline you could not have hit holds.
Technical implementation
Parallel agent fleet
An agent is a user in mcptask.online like any other — same seat, same price. A cheap model and our runner keep the cost per task low.
Technical implementation
Feature implementation team
Set the priority in the morning; after lunch you review the PR and the dashboard hands you the day's numbers to forward to your boss. No night shifts, no overtime.
Technical implementation
Conservative autonomous mode
Three honest panels. The same interface for everyone — no hidden controls.
excl. VAT · 2 users included
excl. VAT · min. 5 users billed
Price on quote · over 50 users
An AI developer is a user like any other: same permissions, same price.
The runner starts the AI you choose on your own machine. Every hour worked is logged against its task and carries through to the invoice.
Every user — human or AI — is one seat. Audit trail. 30-day trial, no credit card.
An agent is a user in mcptask.online like any other — same seat, same price, same dashboard. Add as many users as you have seats for.
One runner per checkout, enforced. A second runner in the same checkout refuses to start.
Task is automatically unlocked after timeout. Another agent (or the same one after restart) can pick it up.
Yes, with project roles. An agent is a user like any other — it sees only the projects you add it to and may do there only what its role allows. There are no read-only roles and no label filters.
Activity log captures everything. The dashboard summarises each run as it lands.
Revoke the token and the runner will not start again. The task it is working on right now is stopped after about 18 minutes of failed checks. There is no stop button on the web.
Yes. mcptask.online holds the task queue and triages each task to pick the model, and its runner drives Claude Code, Codex CLI or OpenCode on your own machine through to a pull request and your local CI. In auto-squash modes it merges only after the checks are green; in manual modes the pull request waits for your review.