gantt-toThe Gantt chart your agent keeps current.
Nobody builds a Gantt chart for their own benefit. It is owed to someone else, and it is stale the day after you make it. Your agent already knows the state of the work — one HTTP call writes the whole plan, and the same call next week rewrites it. Same chart, same link, no cleanup.
The docs are public — no key, no signup, nothing to install. The example chart opens without an account too. Sign-in to the app itself is invite-only while it is in early access.
Twelve tasks, nested three deep, with dependencies and a milestone. One request, no SDK, no second call to resolve ids. Open the live chart.
The problem
The plan is a chore, and it is somebody else's requirement.
Every planning tool ever built assumes you enjoy this. They compete on how pleasant the dragging is. The dragging is not the problem.
You did not want a chart
Somebody asked you for a timeline. It is a report, not a tool, and the people it is for are not the people doing the work.
It is wrong by Tuesday
Scope moves, a date slips, one task splits into three. The chart you spent an afternoon on now quietly misinforms everyone reading it.
Updating it is unpaid
Nobody was hired to keep a Gantt chart current. It is the work you do instead of the work, and it is the first thing to rot.
How it works
Hand the chore to the thing that already knows.
Your agent has read the repository, the tickets and the thread. It is better placed to write the timeline than you are — it just needed somewhere to write it.
Connect it, or point it at the contract
There is an MCP server at /mcp,
so a client that speaks it needs no instructions at all. Everything
else reads one plain-markdown file at /llms.txt, with
an OpenAPI document beside it. No SDK to install.
It writes the plan by name
Give each task a ref you chose. Nesting and
dependencies join by those names, so the agent never has to see a
UUID or make a second call.
Send the link once
A read-only URL anyone can open, no account required. When the plan changes, the agent sends the whole thing again and it lands on the same chart. Nobody gets a second link, and nothing has to be reconciled.
curl -X PUT $API/v1/projects/$PROJECT/gantt \
-H "Authorization: Bearer $GT" -H 'Content-Type: application/json' \
-d '{
"tasks": [
{"ref":"design","name":"Design","start_date":"2026-09-01","end_date":"2026-09-07"},
{"ref":"build","name":"Build","start_date":"2026-09-08","end_date":"2026-09-25"},
{"ref":"launch","name":"Launch","start_date":"2026-09-30","is_milestone":true}
],
"dependencies": [
{"predecessor_ref":"design","successor_ref":"build"},
{"predecessor_ref":"build","successor_ref":"launch","lag_days":2}
]
}'That is the entire integration. One call replaces the whole chart inside a single transaction — either all of it lands or none of it does.
Through MCP it is the same call, named write_chart. Every tool
there dispatches the REST route it stands for, so the two cannot answer
differently.
Run it again next month and it lands on the same chart. That is the whole difference between a plan and a picture of one. Generating a chart is easy — the hard part is the fiftieth revision still being at the address you sent in week one, with the tasks that survived keeping their identity and the ones you dropped actually gone.
Built for agents
It fails loudly, not quietly.
An agent cannot notice that a field went missing. So nothing is ever silently ignored, and nothing is ever half-written.
Typos are errors
An unknown or misspelled field is rejected outright, never a silently dropped value. A wrong key in a generated payload surfaces immediately instead of becoming a missing date nobody notices.
Replace or add, never both
PUT /gantt replaces the chart. tasks:batch
only applies what you send and deletes nothing. The docs lead with
the distinction, because getting it wrong is what costs real data.
Cycles rejected in the database
A dependency loop is refused inside the same transaction as the insert, so a concurrent write cannot slip one past the check.
Nothing half-written
Bulk writes are all or nothing. A rejected task means the chart is exactly as it was, so a failed call needs no cleanup and no guessing about what got through.
Critical path, as a read
Ask which tasks have no slack and how many days each of the others can lose. It measures the dates already on the chart and never moves a bar, so time you left on purpose is reported rather than quietly scheduled away.
Keys that cannot escalate
An API key cannot mint more keys and cannot start a subscription. Both need a signed-in human, so a leaked key cannot compound into anything worse.
Private stays unprovable
A private project you have no role in reports "not found" rather than "forbidden", so the existence of a plan never leaks to someone guessing at URLs.
Who it is for
People who owe someone a timeline.
Consultants and agencies
The plan is the deliverable, and rebuilding it after every scope change is unbillable. Regenerate the whole chart in one call and hand the client a link that needs no account and no licence.
Tech leads and engineering managers
You were asked for a timeline again. Your agent already knows what shipped and what slipped, so let it keep the chart honest instead of spending your Friday on it.
People building agent products
You need somewhere for a planning agent to keep state. A documented contract, machine-readable docs and keys that cannot escalate, so it is not a detour from your actual product.
Not for you if the dragging is the point, or if you need resource levelling, auto-scheduling that moves your dates for you, or SSO. None of those are built, and saying so now is cheaper than you finding out later. Critical path is a read here: it tells you where the slack is, and leaves the chart alone.
Plans
You pay for how many plans you keep.
Never for what you can do with them. The full contract, real keys, the
MCP server, llms.txt and OpenAPI are on the free plan with
no card — and so is the whole 5,000-task ceiling, because a chart is the
same size on every plan. What paid plans raise is how many plans you own
and how many people can write to them.
$0 forever, no card
One real plan, start to finish.
- 2 editors, unlimited viewers
- 3 projects, 5,000 tasks each
- 2 API keys, full API
- Public read-only sharing
$9 / month
You, your agents, and the timeline you owe somebody.
- 3 editors, unlimited viewers
- 2 organizations, 25 projects each
- 5,000 tasks per project
- 10 API keys
$49 / month
A practice running plans for clients.
- 25 editors, unlimited viewers
- Unlimited organizations and projects
- 5,000 tasks per project
- 25 API keys
Viewers are free, on every plan, forever. You are never charged for the people you have to show the plan to — only for the people who change it.
What each plan allows, exactly
Every limit is readable at runtime from GET /v1/plans, so a
client never hard-codes them. Going over a limit refuses the new thing
with a 402 — it never deletes what you already have.
| Capability | Free | Pro | Studio |
|---|---|---|---|
| Price per month | $0 | $9 | $49 |
| Editors per organization | 2 | 3 | 25 |
| Viewers | Unlimited | Unlimited | Unlimited |
| Organizations owned | 1 | 2 | Unlimited |
| Projects per organization | 3 | 25 | Unlimited |
| Tasks per project | 5,000 | 5,000 | 5,000 |
| API keys | 2 | 10 | 25 |
Full REST API, llms.txt, OpenAPI |
Yes | Yes | Yes |
Bulk chart writes with ref |
Yes | Yes | Yes |
| Public read-only sharing | Yes | Yes | Yes |
Scroll the table sideways to see every plan.
Prices are in US dollars. gantt-to is free to use right now — paid plans open later, and no card is asked for in the meantime.
Questions
The things people actually ask.
Why not just use a spreadsheet?
Because you are not the one editing it. A spreadsheet will not refuse a dependency cycle or reject a misspelled field, and an agent rewriting one twice a week corrupts it quietly. You find out when somebody acts on a wrong date.
My project tool already has an API.
It does, and it was built for syncing between systems rather than for authoring. Ask it to accept a whole plan — tasks, nesting and dependencies wired by names you chose — in one call, and see what happens.
Is there AI in the product?
No, and that is deliberate. There is no model inside gantt-to. It is a plain, boring, well-specified place for your agent to put a plan, which is why it behaves the same way every time.
What happens when the agent gets it wrong?
The write is refused and the chart is unchanged. That is the design, not a fallback: bad input fails at the boundary with a status code, so a failed call needs no cleanup and never leaves half a plan behind.
Is my plan public?
Only if you make it so. Private is the default, and someone with no role in a private project cannot even confirm it exists. Public sharing is one setting, free on every plan.
Will this still be here in a year?
A fair question, and no answer to it is worth much. What we can say is checkable: the contract is versioned and machine-readable, the docs are served as plain text, and your data comes back out through the same documented API it went in through.
Stop maintaining the chart.
One URL for your agent, one call to write the plan, one link for the person who asked. Nothing to install and no card to enter.
Sign-in is limited to invited testers while the app is in early access.