Dixa AI agent: Mim pricing, capabilities, and eesel CLI

What the Dixa AI agent does

Dixa describes Mim as a customer-facing agent that uses company knowledge and connected systems to handle requests. Its examples include order tracking, returns, refunds and cancellations through Shopify and Magento. Dixa also describes contextual handoffs, optional PDF reading and a system that checks whether promised actions were carried out.

Those are capabilities to test, not a guarantee that every request will be resolved. Pick a routine inquiry and an exception, then ask to see the resulting conversation and system action.

Dixa's AI Co-Pilot serves a different role: helping human agents with drafts, summaries, tags and translation. A good draft still needs a person to review and send it. That is useful, but it should not be counted as autonomous resolution.

Dixa's conversation workspace from its official product tour. This shows Co-Pilot assistance, not proof that Mim completed an order action.

For an AI support agent, I would separate three outcomes: the answer was useful, an action completed, and the customer did not need more help. They often overlap, but they are not interchangeable.

A return-policy answer can be correct without creating a return. A refund request can be submitted without the payment settling. A conversation can be closed while the customer is still waiting. Your evaluation should show which event each reported metric measures.

What Dixa AI agent pricing includes

The Dixa pricing page currently displays these EUR platform prices:

Its July 2026 pricing FAQ states that Mim costs €0.35 per conversation, whether resolved or handed to a human. The page lists Mim across plans, while an older-looking section still groups it under add-ons. Confirm packaging, billing cadence and inclusions in the quote. The FAQ says there is no self-serve trial.

A fixed unit rate is not a fixed total bill. At that rate, 1,000 billed AI conversations equal €350 in AI usage before platform seats and any other charges. If the number of billed conversations doubles, that usage subtotal doubles too.

Do not compare this directly with a per-resolution price without checking what each vendor counts. Ask whether reopened conversations, follow-ups and test traffic create additional billable units.

For eesel, the published pricing lists regular support tickets and chat sessions at $0.40 each, billed regardless of outcome. The default pay-as-you-go plan has no platform fee or monthly minimum; Enterprise adds a platform fee. These are different currencies and products, so this is not evidence that one is cheaper.

The useful cost comparison is the full monthly workflow: helpdesk, AI work, relevant add-ons and the time humans spend reviewing or finishing requests.

What to ask before adopting Mim

Dixa positions Mim within its own platform. If you already use Dixa, that is a natural place to start. If you are considering a platform change, separate the AI evaluation from the migration decision. Helpdesk selection also affects routing, reporting, channels and daily agent work.

I would bring a small evaluation sheet to a guided demo:

Use fictional or approved test records where possible. Live refund and cancellation tests need explicit authorization, because the test can change a real customer's order.

Dixa's promise-detection description is a useful reason to ask about failed-action handling. Ask what an operator sees when a promise cannot be fulfilled and how the unresolved work reaches a human. The product claim alone is not your acceptance test.

The same questions should apply to eesel. A vendor should not get a lighter test because its setup happens to be easier or its pricing is public.

Where eesel CLI fits in the comparison

An eesel helpdesk teammate is an alternative to evaluate when you want AI for a supported existing helpdesk. The integration documentation lists systems such as Zendesk, Freshdesk, Gorgias and Front.

This article does not establish native Dixa support. If you need eesel to work with a Dixa-specific workflow, confirm the integration requirements with the team before planning around it. A CLI login does not create a Dixa connector.

The eesel CLI operates the same teammate and workspace as the dashboard. You can inspect connected sources, read instructions, chat with a selected agent, review activity and examine held approvals.

That gives technical teams a concrete way to help support operations. A person can run commands, a script can process the results, or a coding agent can inspect the configuration and propose a change. Single results are JSON; lists contain one JSON object per line.

The distinction is practical: you do not ask a coding agent to invent a support system. You give it a bounded job involving an existing eesel teammate.

Inspect an eesel support pilot through eesel CLI

Use Node.js 18.17 or newer. For an existing workspace, log in and confirm the account before doing anything else:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

Create or choose a separate test agent in the dashboard. Replace TEST_AGENT_ID with its actual ID in the commands below.

npx @eesel/cli status --agent TEST_AGENT_ID
npx @eesel/cli integrations --agent TEST_AGENT_ID
npx @eesel/cli instructions --agent TEST_AGENT_ID
npx @eesel/cli automations --agent TEST_AGENT_ID

Check what is connected, whether the intended knowledge is available, what rules guide the teammate and what automations already exist. Restrict actions before testing. A separate conversation alone does not isolate you from the agent's integrations or permissions.

For a policy-only comparison, prepare an approved returns-policy.md file on your computer. It should contain the actual rules you want tested, with sensitive information removed. Upload it as knowledge:

npx @eesel/cli files upload ./returns-policy.md --agent TEST_AGENT_ID
npx @eesel/cli files ls --agent TEST_AGENT_ID

The upload adds source material. It does not set action permissions or replace the agent's standing instructions. Review those separately.

Now test a fictional request:

npx @eesel/cli new --name "Returns policy comparison" --agent TEST_AGENT_ID
npx @eesel/cli chat "For a fictional test customer whose item arrived damaged, explain the next step using returns-policy.md. State what information is missing and cite the relevant rule. Do not look up a real order or execute actions." --agent TEST_AGENT_ID
npx @eesel/cli activity --agent TEST_AGENT_ID
npx @eesel/cli approvals --agent TEST_AGENT_ID
npx @eesel/cli billing --agent TEST_AGENT_ID

These are example commands, not test results. The new command starts a conversation; it does not create another agent. Subsequent chat messages continue that conversation unless you start or select a different one.

Inspect the answer against the file. It should not invent a return window, demand information the policy does not require, or claim to have refunded the fictional customer. If the policy is silent about damaged items, acknowledging the gap is a better result than confidently filling it.

Chat can use tools and incur charges. “Do not execute actions” is an instruction, not an access control. Keep unnecessary actions off, review activity and do not approve held actions just to complete the example.

Ask a coding agent for a specific inspection

A useful starting request is:

Use eesel CLI to inspect my selected test agent's sources, instructions and automations. Identify what is missing for a damaged-item policy test. Propose the changes first; do not alter settings, send chat messages or approve actions without my approval.

The coding agent can read structured output and explain the proposed setup. A human still handles required account authorization and decides whether changes should happen.

When you authorize a write, --dry-run can show the server call before it is sent. That checks the proposed operation, not the quality of a future reply. It is not a simulation of resolution rate or a cost forecast.

Compare outcomes before enabling real work

After a policy-only test, evaluate the live workflow separately. Use the supported helpdesk's documented setup, approved test records and the smallest useful set of actions.

Do not report a policy-answer pass as evidence that order cancellations work. Likewise, a held approval is not a completed cancellation.

Start with one topic and a small group of test cases. If results are poor, diagnose the failure: missing knowledge, ambiguous instructions, unavailable actions or a channel problem. Re-running the same prompt without finding the cause is not a rollout plan.

This is where CLI access is useful beyond initial setup. You can repeat configuration checks and review activity after a change, while support colleagues continue using the dashboard and helpdesk.

Evaluate the platform and the teammate separately

Choose Dixa when its broader support platform fits your needs and the Mim evaluation supports the work you want to automate. If you are comparing other approaches, the Dixa alternatives guide can help frame the platform decision.

If you want to assess an eesel teammate on a supported helpdesk, try eesel and use eesel CLI to inspect the setup and run a bounded test. Judge the answer, action and handoff separately before expanding access.

The eesel dashboard manages the same teammate you can inspect and operate through the CLI.

The goal is not to win a demo comparison. It is to find out which setup handles your real support work correctly, which requests still need people, and what the whole workflow costs.