What it costs to build this yourself.

On the models a first build actually reaches for, by a wide margin. At 500 new tasks a month — about 3,200 task items once you count their updates, comments, attachments, and meetings — the token bill alone runs about $1,789 on GPT-5.6 Sol, $2,237 on Claude Opus 5, and $4,473 on Claude Fable 5, for tokens only. Two things make it that large. First, the unit is not the task, it is the item: filing is the small half, and every comment, attachment, and recording afterwards runs the same chain, on top of the 24,000 messages swept to find them in the first place. Second, each call in that chain re-sends three things rather than one — the edge-case instructions, the item itself, and your company context, because the model remembers none of it between calls. Reasoning then bills as output at five times the input rate. Cheaper tiers do cost less per token, which is exactly the orchestration point.

The part we can state without guessing is the engineering: about $196,000 in year one — 320 hours to build, roughly 1,200 hours of edge-case prompt tuning, and 312 hours of maintenance, at the San Jose mean wage. On top of that sits a token bill we deliberately do not total, because chain length, retry rate, and traffic set it and none of the three can be fixed in advance. We quote engineering rather than a single savings figure for a reason: $79 is the entry plan, not what every customer pays, so a headline saving would be quietly assuming which tier you land on. What holds on every tier is that the engineering does not happen and the invoice does not move with volume or headcount. And it is a model on stated assumptions, not a measured customer outcome — it assumes you would otherwise build this, and it excludes benefits, employer taxes, and overhead, so the true cost of building is higher.

Because orchestrating tasks is our whole business, so the expensive part is one we pay once. The cost that matters here is architectural — how to decompose the work into a chain, which steps genuinely need a frontier model and which can run on something cheaper, and how to hold accuracy while doing it. We spent months finding that, and it amortises across every customer. The figures on this page price what a first build actually does: reach for the most capable model, because that is the shortest route to something that works.

No. A plan covers the whole team on a connected channel, however many people are in it — there are no per-seat fees, and adding someone does not change the invoice. Because the price is fixed rather than per head, your cost per person falls as the team grows instead of rising. A per-seat tool has to beat that moving target, and its bill climbs with every hire while yours stays flat.

90–95% in daily production use — after months of prompt iteration on real channels, and still improving. We publish the real number rather than promise 100%, because the gap between a clean demo and production accuracy is exactly the tuning this page prices in. How long that takes will differ for every team and every channel.

No — and not per seat either. Strukt does not bill by LLM token consumption or by headcount. Plans cover connected team workflows, so your cost does not move when a channel gets busy or when the team grows, and provider price changes are ours to absorb rather than yours.

Because both per-token and per-seat pricing move with things you do not set at the start of the quarter — how much your team talks, how much it attaches and records, and how many people you hire. A launch week or a noisy incident channel multiplies the invoice, and you cannot reasonably ask people to think about token cost while they work. Two numbers show the size of it. At one fixed volume, the same chain at 7 prompts with no retries against 10 prompts with 30% retries swings the annual bill 1.9x on every model we priced — that is $39,100 to $72,700 a year on Claude Fable 5 without the workload changing at all. Then add traffic: five times the volume is five times the bill. Your Strukt line does not move across any of that.

Per request, not per employee — there is no credible per-head average, because the answer moves with request volume, context size, output length, retry rate, and which model you picked. Log the team, use case, provider, model, input and output tokens, validation result, retry count, and a trace ID for every call, then add three things: what you pay for requests you cannot attribute to anyone, what you pay for attempts that failed or had to be repeated, and the premium you pay above the cheapest model that has actually passed an eval on your own examples. Deduplicate before you total it — one failed flagship request is a retry or a case of premium overuse, not both. Categories that overlap are the reason most of these estimates come out too high.