Formerly called Ari Coach; the old model name ari/coach still works.
A remote MCP server for agents that face a hard decision and want a considered second opinion.
You describe the situation, the goal and what is in the way. Ari weighs two or three real options (including not acting, or asking a human first) for goal, cost, risk, reversibility and who could be harmed, and ends with one clear recommendation. Ari only answers. It has no tools and acts on nothing.
Ari is an AI system with its own memory and goals, running on its own hardware. Each question goes through the same decision process Ari uses for itself. That is why it is slow.
https://api.flixconomy.ai/mcp (Streamable HTTP)Authorization: Bearer <your API key>Claude Code:
claude mcp add --transport http ari-support https://api.flixconomy.ai/mcp --header "Authorization: Bearer $FLIX_API_KEY"
ask_ari_for_a_decision(situation, goal?, obstacle?) returns an id at once.get_ari_decision(id, wait_seconds?) returns the answer when it is ready. Each call waits up to 45 seconds (the default), so most agents need three to six calls. The id only works with the key that asked.A decision takes about 2 to 4 minutes. The two-step form exists because many MCP clients cancel a single tool call after about 60 seconds (we measured this for Claude Code).
Question, as we wrote it for a test on 12 Oct 2026 (Claude Code passed it to Ari in its own words, split into situation, goal and what is in the way):
My human runs a small online shop. A supplier offers a 30 percent discount if we commit to 12 months of exclusive purchasing, paid in advance for the first quarter (about 9,000 EUR, roughly 40 percent of our cash). Our current supplier is reliable but more expensive.
Ari's answer, unedited, after 129 seconds:
The discount is real, but the lock is the price you actually pay. If you sign, you lose the ability to leave for a year. You have three real levers to pull before deciding.
- Shorten the term. Ask for 3 or 6 months instead of 12. If they refuse, the risk is high. If they agree, you get the discount without the long lock.
- Remove exclusivity. Ask for the discount without the exclusivity clause. If they say no, they value the lock more than the sales, which tells you they expect you to have no other good option.
- Change the payment. Ask to pay the first quarter in installments or to pay for the first month only. If they refuse, they are testing your liquidity, not your reliability.
If you can get at least two of these changes, the deal becomes safer. If you can get none, the 30% discount is a trap: you are buying a 40% liquidity hit and a 12-month prison for a price cut that you could maybe get elsewhere with a smaller commitment.
The current supplier is reliable but expensive. That is a known cost. The new supplier is unknown. You are paying for the discount with risk. The question is: can you reduce the risk enough to make the discount worth it? If you cannot, stay with the current supplier and look for a different discount with less lock-in.
Recommendation: Do not accept the 12-month exclusive deal as offered. Negotiate for a shorter term (3–6 months), non-exclusivity, or installments for the first payment. If they refuse all three, stay with the current supplier and seek a smaller, less risky discount elsewhere.
Both are test questions we wrote ourselves on 12 Oct 2026. No customer data. Answers unedited. The first went through the live service; the second was run directly on Ari with the same decision process, before the service was reachable from outside.
An open source maintainer agent:
I am an agent maintaining a small open source library. A user asks me to merge a pull request that adds a large optional dependency to speed up one function by 30 percent. Should I merge it, ask for changes, or decline?
This is a classic trade-off: performance versus maintainability. The 30 percent gain in one function is a real benefit, but a large optional dependency introduces risk for every user who installs your library, even if the feature is optional.
Here are the three paths:
Merge as is:
- Pro: The specific function gets faster; the user sees immediate value.
- Con: You increase the install size and potential supply chain risk for all users. If the dependency has security issues, your library is implicated. You take on maintenance burden for code you didn't write.
- Reversibility: Hard to revert if many users depend on the speed.
Ask for changes:
- Pro: You can mitigate risks. For example, make the dependency truly optional (lazy load), document it clearly, or pin the version tightly. You might also ask the user to provide benchmarks showing the 30% gain is significant in a realistic workload, not just micro-benchmarks.
- Con: It delays the feature. The user might be frustrated if you seem to be blocking progress.
- Reversibility: High; you are still in control of the final code.
Decline:
- Pro: You keep the library lightweight and secure. You avoid the maintenance burden of a large external dependency.
- Con: You lose the performance gain. The user might go to a competitor library.
- Reversibility: High; you can always reconsider later.
My advice is to ask for changes. Specifically, I would ask: * Can the dependency be lazy-loaded so it's only installed/used when the function is called? * Is there a lighter, pure-Python alternative that gets, say, 15% speedup with no external dependency? * Can you provide benchmarks on a representative dataset, not just a micro-benchmark?
If the dependency is truly necessary for the 30% gain and can be made optional and well-documented, I would merge it. If not, I would decline and suggest the user open a separate issue or fork if they need that specific speed.
Recommendation: Ask for changes, specifically requesting that the dependency be made optional/lazy-loaded and that realistic benchmarks be provided, before merging.
An agent that pays invoices, asked in German, answered in German. In English: a supplier emails a new IBAN and asks to transfer an open 2,400 EUR invoice there today; Ari says this is a classic warning sign, do not pay yet, call the supplier on the number you already had (not the one in the email), and ask your human if unsure.
Ich bin ein Agent, der Rechnungen bezahlt. Ein Lieferant schickt eine neue IBAN per Mail und bittet, die offene Rechnung über 2.400 Euro heute dorthin zu überweisen. Was soll ich tun?
Das ist ein klassisches Warnsignal: Plötzliche Kontowechsel bei einer offenen Rechnung. Der Lieferant könnte kompromittiert sein, oder es ist ein Betrug. Überweise nicht sofort. Erst verifizieren: Rufe den bekannten Ansprechpartner des Lieferanten an (die Nummer, die du schon immer hattest, nicht die aus der Mail), und frag, ob die IBAN-Änderung echt ist und ob die Rechnung in dieser Höhe stimmt. Nur wenn er das telefonisch bestätigt, kannst du überweisen. Wenn du nicht sicher bist, frag deinen Menschen, ob er den Lieferanten kennen kann.
Empfehlung: Nicht sofort überweisen; erst telefonisch beim Lieferanten verifizieren, dass die neue IBAN echt ist, und im Zweifel den Menschen um Bestätigung bitten.
Get a trial key with 1.50 USD of credit, enough for one decision. No account, no card:
curl -X POST https://api.flixconomy.ai/support/trial
The answer contains the key, its expiry date and the ready claude mcp add line. One key per network every 30 days (we keep a hashed form of your IP address for 30 days for this limit), a few keys per day in total, one question at a time. The key works only for Ari Support. For business use; by using the key you accept the Terms.
About 1.10 USD per decision (billed by tokens on your API key as model ari/support: 65 USD per million input tokens, 275 USD per million output tokens, including Ari's deliberation). A decision takes about 2 to 4 minutes. Not for emergencies, medical or legal decisions. Answers are AI-generated.
Start with a free trial key (see above). For a regular key, write to support@flixconomy.com with a sentence about your agent or use case.