GPT-6 Astra vs Claude Fable 5.1: Why We Use Both

Everything in this comparison moved inside eight days

Astra shipped on 3 September 2026. Fable 5.1 arrived at roughly the same time. On 10 September OpenAI temporarily paused new sign-ups and upgrades to its $200 Pro tier because demand for Astra outran capacity. A buying decision taken from a three-week-old comparison is already out of date.

Both releases point at the same thing. Not chat. Long-horizon agentic work, meaning tasks that run for hours without a human in the loop.

Three things changed materially, and all three hit the invoice:

• Context windows near 1M tokens on both sides. A whole legacy module plus its docs and tests now fits in one request.
• Reasoning effort is a real cost lever. Astra exposes five levels. Fable runs adaptive thinking at default high effort. The setting changes what you pay per task, not just how smart the answer sounds.
• Agent harnesses run unattended for hours. Which makes a wrong assumption in hour one expensive by hour four.

The capacity signal is worth planning around. As Fortune reported on 11 September 2026, the Pro $200 pause covers upgrades from every lower tier. Existing subscriptions keep renewing. If you were planning a team rollout on that tier this month, check availability before you budget it.

Mid-market B2B companies feel this first. ERP work, integrations and legacy modernization are exactly the long-context, high-blast-radius jobs these models were built for. We are not reviewing a product launch here. We are describing the engineering process we changed because of it.

Models, coding agents and work environments are three different layers

Astra and Fable 5.1 are models. Codex and Claude Code are coding agents, which are harnesses that drive a model plus a set of tools. ChatGPT Work and Claude Cowork are long-task environments, both launched on 9 July 2026. A benchmark score belongs to a model and a harness together, which is why half the comparisons online contradict each other.

The plain-words version: Astra is the brain, Codex is the coding environment it works in, Work is the wider environment for long jobs. Same on the other side with Fable 5.1, Claude Code and Cowork. Above all of it sits the orchestration layer, which means provider APIs, agent tooling, MCP services, CI/CD and whatever internal layer you build yourself.

So "Astra vs Claude Code" is a category error. You are comparing a brain to a workshop.

This matters for evaluation, not just vocabulary. Swap the harness and the number moves. Terminal-Bench v4.0 reads 57.9% in OpenAI's own table and 56% in Artificial Analysis's Codex-harness run. Same benchmark name, different scaffold, different result. When a vendor says "our model scores X", the three follow-up questions are always the same: in which harness, at which reasoning effort, on which date.

Codex delegates, Claude Code talks

Codex is something you hand work to. Give it a repo and a task, it runs in an isolated sandbox and reports back when it is done. Claude Code is something you talk to. It works in your terminal, shows its reasoning and stops at decision points.

For us that difference is not about preference. Picking an agent is a decision about how much supervision a task needs. Well-scoped and mechanical goes to the one you delegate to. Ambiguous and architectural goes to the one you argue with.

Spec sheets that look almost the same

Astra carries a 1,050,000-token context window, 128,000 tokens of max output, an April 2026 knowledge cutoff and five reasoning effort levels. Fable 5.1 carries a 1M context window, 128K max output, a June 2026 cutoff and adaptive thinking that is always on at default high effort. On paper they are close. The differences start at the billing line.

Figures confirmed on OpenAI's API model page and the Claude Platform docs, as of 11 September 2026.

Each vendor is clear about its own target. OpenAI positions Astra for "complex reasoning, coding, computer use, research, and document creation". Anthropic positions Fable 5.1 for "demanding reasoning and long-horizon agentic work".

Two rows in that table matter more than they look. The effort dial on Astra is a genuine cost control: Artificial Analysis measured every level from low at $0.82 per task to max at $3.26 per task sitting on the cost-versus-intelligence frontier. And the retirement commitment on Fable 5.1 is the kind of detail nobody puts in a comparison post. A pinned dateless model ID with a published end date means you can plan a two-year ERP project against it.

Same sticker price, two very different invoices

Both models list $10 per million input tokens and $50 per million output. The invoices are not the same. Astra reprices the entire request at roughly 2x once a prompt crosses 272,000 input tokens. Fable 5.1 bills the full 1M window at standard rates and charges $0.25 per million on cache hits, which is 2.5% of base input.

Take Astra's threshold first, because it lands exactly where large B2B codebases live. Above 272,000 input tokens, input and cache rates double and the output rate goes up. Secondary reporting puts that long-context tier at $20 per million input and $75 per million output, and says the higher rate applies to the whole request rather than only the tokens above the line. Treat the $20 and $75 figures as secondary, the 272K rule and the 2x multiplier are in OpenAI's own docs.

Fable 5.1 has two structural advantages here, both stated in Anthropic's own pricing documentation. Cache hits cost $0.25 per million, a 75% cut versus Fable 5. And there is no long-context surcharge at all: a 900k-token request is billed at the same per-token rate as a 9k-token request.

Here is what that looks like in money. This example is illustrative, not a quote. One request with 500,000 uncached input tokens and 20,000 output tokens. On Astra the request sits above the threshold, so you pay about $10.00 for input and $1.50 for output, roughly $11.50. On Fable 5.1 the same request bills at standard rates, about $5.00 plus $1.00, roughly $6.00.

Now the honest counterweight, because the independent data points the other way on finished work. In Artificial Analysis's standardized runs, Astra spends about 27k output tokens per Index task against Fable's 78k, and lands at $3.26 per task against $7.63. Cheaper per request is not the same as cheaper per result.

One more footnote that breaks naive math. Claude 4.7 and later use a newer tokenizer that produces roughly 30% more tokens for the same text. Comparing dollars per million tokens across two vendors is not comparing the same unit.

So we work to a rule instead of a price list: measure cost per completed task, not price per million tokens. A cheaper token that needs three passes is not cheaper. Where caching actually pays in our setup is narrow and predictable, which is several agents reading the same repository docs, specs and ADRs over and over during one piece of work.

Why two benchmark tables give you two different answers

Independent testing calls this a tie. Artificial Analysis, published 9 September 2026: Intelligence Index v4.3 at 53 for both models, Coding Agent Index at 62 for both. OpenAI's own table shows Astra ahead on most coding benchmarks, and Fable 5.1 clearly ahead on Humanity's Last Exam with tools at 65.0% against 57.2%. Both tables are real. They measure different things.

Independent numbers first

Intelligence Index v4.3 is a composite of 10 evaluations, including AA-Briefcase, GDPval-AA v2, AutomationBench-AA, Terminal-Bench v4.0, SciCode, Humanity's Last Exam, CritPt, AA-Omniscience and AA-LCR v1.1. The headline from Artificial Analysis's benchmark run is that Astra "ties leadership with Claude Fable 5.1 in both of our flagship Indices, at lower cost".

Independent measurement by Artificial Analysis, 9 September 2026, all figures at max reasoning effort.

Two details inside those numbers are worth more than the headline. On AA-Omniscience, Astra's hallucination rate drops from 92% on the previous generation to 51% at max effort, and accuracy goes up 4 points at the same time. And inside the Coding Agent Index the wins split rather than stack: Astra gains on Terminal-Bench v4.0 and SWE-Atlas-QnA, and loses on DeepSWE at 68% against 72%.

OpenAI's own table, and the row that gives the game away

Vendor-reported by OpenAI, September 2026. These are not independent measurements.

The last row is the most useful line in the whole table for our argument. In OpenAI's own numbers, Fable is almost eight points ahead on research and reasoning over unfamiliar domains. Being better at a coding benchmark does not make a model better at challenging an architecture decision, which is a different job entirely.

Three caveats that decide how you read any of this

• Vendor-reported and independent numbers do not merge. You cannot average OpenAI's table with Artificial Analysis's Index and get a ranking. They use different harnesses and different scoring.
• The harness is not neutral. Terminal-Bench v4.0 comes out at 57.9% in one setup and 56% in another. Same benchmark, different scaffold.
• A comparison without a stated reasoning effort is meaningless. Every AA figure quoted here is max effort. Change the effort and both the score and the cost move.

One more thing on sourcing. At least one outlet reports the Coding Agent Index as 67 for Astra and 70 for Fable 5.1. That contradicts Artificial Analysis's own published 62 vs 62. When sources disagree, take the primary one and say which you used. We use AA.

Nobody wins this on points. So stop shopping for a winner.

What Astra does better

Astra wins on economy and execution. Same Index score at roughly 40% of the cost per task, about one third of the output tokens, the largest context window at 1,050,000 tokens, five effort levels for per-task cost control, and a hallucination rate cut nearly in half.

Token efficiency is the headline. 27k output tokens per Index task against 78k, $3.26 against $7.63. In a standardized harness it finishes the same work for less. In vendor-reported coding and automation tests it also leads on Terminal-Bench, DeepSWE, AutomationBench, BenchCAD and OpenAI's internal DB migration benchmark.

The effort dial is not a marketing slider. Every level from low to max sits on the cost frontier, which means you can route cheap mechanical work to low effort and keep max for the parts that need it. That is real budget control per task type.

The hallucination drop deserves more attention than it gets. For an agent that runs unattended for four hours, a lower rate of confident invention is a safety property, not a statistic. Computer use and browser control matter for the same practical reason: admin panels, test environments and legacy software with no API.

• Pros: cost per finished task, token economy, execution stamina, five effort levels, computer use.
• Cons: the 272K repricing cliff lands exactly in the monorepo and legacy-codebase zone, benchmark leadership is not universal since HLE with tools goes the other way, new Pro 20x access is paused as of 11 September 2026, and one long-running agent can carry a convincing wrong hypothesis all the way to the end.

What Fable 5.1 does better

Fable 5.1 matches Astra on measured intelligence and on the Coding Agent Index, then wins on the things that turn up in month three of a project. Cache reads at $0.25 per million, no long-context surcharge, adaptive thinking always on, and a clear lead on research over unfamiliar domains.

Start with the tie, because it reframes everything else as "and also". 53 against 53. 62 against 62. Nothing below is compensation for a lower score.

The cache economics matter most in exactly our workflow. Several agents repeatedly read the same repository, the same specs, the same architecture context. At 0.025x base input, the second, third and tenth read cost almost nothing. Add flat pricing across the full 1M window and long-context work stops being a budget conversation.

Then the Humanity's Last Exam result, 65.0% against 57.2%, in OpenAI's own table. That benchmark measures research and reasoning over domains the model has not seen. Which is a fair description of what ADR critique actually is: reading an unfamiliar system and finding the wrong assumption in it.

Adaptive thinking at default high effort means less tuning and fewer mistakes from picking the wrong effort level. And Claude Code's agent patterns are mature: subagents, parallel research, worktrees, agent teams, independent reviewer agents.

• Pros: cache economics, flat long-context pricing, research over unfamiliar domains, agent patterns, and a published retirement date you can plan a roadmap against.
• Cons: higher measured cost per standardized task at $7.63 against $3.26, roughly 3x the output tokens at max effort, a newer tokenizer that produces about 30% more tokens for the same text, and parallel subagents that multiply usage fast if nobody is watching.

What the plans cost right now, and the 20x trap

As of 11 September 2026: Claude Pro is about $20 a month, Max 5x is $100 and Max 20x is $200. ChatGPT Plus is $20, Pro 5x is $100 and Pro 20x is $200, but new Pro $200 sign-ups and upgrades were temporarily paused on 10 September 2026. The two "20x" labels do not mean the same amount of usage.

Plans for one developer

On the Anthropic side, Pro runs about $20 a month, or around $17 a month equivalent on annual billing. Max 5x is $100 and Max 20x is $200, monthly only on the web. Sessions reset on a five-hour cycle, and Max plans also carry a weekly limit that applies across all models. Both Max tiers include Claude Code and Cowork.

On the OpenAI side, Plus is $20, Pro 5x is $100 and Pro 20x is $200. The 10 September pause blocks new sign-ups and upgrades to Pro $200 from every lower tier. Existing subscriptions are unaffected and keep renewing. Once one ends, it cannot be repurchased until the pause lifts.

The 20x trap. OpenAI's 20x is measured against ChatGPT Plus. Anthropic's 20x is per session, measured against Claude Pro. Two different baselines, and neither one is a token package. Comparing the two plans by their label tells you nothing.

OpenAI also publishes five-hour message estimates for Codex on Astra: 5 to 45 local messages on Plus and Business Standard, 25 to 225 on Pro $100, and 100 to 900 on Pro $200. Read those as ranges, not caps. ChatGPT Work and Codex share the same quota, and actual consumption moves with task size, reasoning effort and context volume.

Team and company plans

Anthropic figures are published. OpenAI Business and Enterprise street prices are reported rather than published, so treat them as an indication for budgeting and confirm them in a quote.

One billing difference catches finance teams out. On Claude Team, usage is bundled into the subscription. On the usage-based Claude Enterprise model, the seat fee covers platform access and usage bills separately at API rates. Those are two different shapes of monthly invoice.

Our advice as a team that buys both: pilot on API billing first, because that is the only way to see your real cost per completed task. Move to seats once you know what your team actually consumes.

Our ten steps: research, ADR, build, cross-review

A human defines the business task. Two agents investigate independently. A human merges the findings. One agent drafts the ADR and the other attacks it. A senior engineer approves the design. One model implements, the other reviews without seeing the implementer's reasoning, tests verify, a human signs off, and only then does CI/CD run. Ten steps, and the humans hold three of the gates.

This is Webdelo's practice as our team describes it. No invented benchmark, no invented percentage. The same ten steps run across client delivery, from ERP modules to web development in the USA.

• Step 1. Business task. A human sets the goal, acceptance criteria, domain limits, affected integrations, data constraints, security requirements, expected tests and the rollback plan. The AI does not define done.
• Step 2. Independent discovery. Both models inspect the module, repo, existing ADRs, DB schema, APIs, tests and dependencies separately. Agent B never just summarizes agent A. We want two hypotheses.
• Step 3. Merge research. Agreements, contradictions, gaps, risks, open questions. Disagreement is signal, not noise, and it usually points at the part nobody understands yet.
• Step 4. ADR plus adversarial critique. One drafts the architecture decision record. The other attacks it on wrong assumptions, backward compatibility, migration risk, concurrency, permissions, data consistency, observability, rollback, performance and integration failure modes.
• Step 5. Human architecture gate. A senior engineer accepts or changes the design. Non-negotiable on ERP and core business systems.
• Step 6. Implementation. One model becomes the primary implementer. The choice depends on the repo, the shape of the task, observed quality, cost, available quota and whether a large cached context is in play. Not on who scored higher last week.
• Step 7. Cross-provider review. The model that wrote the code never reviews it. The reviewer gets requirements, the diff, relevant architecture and tests. It does not get the implementer's reasoning narrative. That is the anti-anchoring step.
• Step 8. Objective verification. Unit and integration tests, static analysis, linters, migration verification, security checks, and browser tests where the change touches a UI.
• Step 9. Human review. AI findings stay suggestions until they are backed by code, a test, a constraint or a reproduced problem.
• Step 10. CI/CD. Only reviewed and verified changes enter normal delivery. The AI pipeline supplements engineering controls, it never replaces them.

The plumbing that keeps it survivable

Two things make this practical instead of exhausting. Worktree isolation, so parallel agents do not fight over the same directory. And an orchestrator that assigns work and synthesizes results, so two engineers are not copy-pasting between two terminals all afternoon.

Here is where we disagree with common practice. Running the whole loop inside one vendor's orchestration is convenient, and it hands that vendor your process. We keep permissions, routing, policy, secrets, audit logs and cost governance in our own layer. The dual-provider strategy is itself the argument: the moment your workflow only exists inside one platform, switching providers stops being a decision and becomes a project.

What this looks like on an ERP module

Picture the mistake this workflow exists to catch. An agent reads an ERP module and decides one field is informational. It is not. That field drives a downstream posting rule that somebody wrote in 2014 and nobody documented.

The agent designs a migration around its assumption. Then it writes code that matches the migration. Then it writes tests that match the code. Then it reviews its own work against its own mental model and finds nothing wrong, because from the inside nothing is wrong. Everything is internally consistent. It is also wrong for the business, and you find out during month-end close.

A second agent from another provider has a real chance of catching that. Different training data, different default assumptions, different harness, and no exposure to the first agent's reasoning. It reads the field, reads the spec, and asks why the migration treats it as cosmetic.

ERP is where this pays because of what ERP carries. Financial data, roles and permissions, audit trails, imports and exports, third-party integrations, business logic older than the current team, legacy dependencies, customer-specific workflows, database migrations and availability requirements. The hard part is rarely writing a function. The hard part is knowing what changing that function will touch.

That is also where parallel agentic discovery earns its keep. Repository exploration, dependency tracing, documentation analysis, test inspection, migration planning and risk discovery can all run at the same time. Senior engineers spend their hours deciding instead of searching. The same parallel discovery pays off on data-heavy client platforms, for example real estate website development, where listings, pricing rules and integrations pile up fast.

Routing in practice is simple. Terminal-heavy, well-scoped, batch-shaped work goes to Astra in Codex. Ambiguous, context-heavy, planning-shaped work goes to Fable in Claude Code. Then we swap them for review.

An honest caveat belongs here. Both models are about ten days old. No published ERP case study exists for either of them, ours included. What we are describing is a process, not a case study.

Our next validation step, and it is a plan not a result

We are setting up an internal comparison on 8 to 12 anonymized real B2B and ERP tasks, run in four modes: Astra only, Fable only, Astra implements and Fable reviews, Fable implements and Astra reviews.

What we will measure: accepted solution rate, tests passing, wall-clock time, usage, human corrections required, valid review findings, false positives, regressions, and iterations to merge-ready. The decisive number is accepted findings found only by the second provider, because that is what actually tests the thesis of this article.

No results exist yet. We are not presenting a plan as evidence.

Why a model is a bad reviewer of its own code

2026 research documents why self-review fails: anchoring bias, self-preference, and hallucinated correctness, where a model reproduces during review the same reasoning error it made while generating. Multi-agent debate does not fix it when every agent runs on the same model.

The failure modes are specific, and each one has research behind it:

• Anchoring bias. The first information disproportionately shapes every later judgment, including the model's judgment of its own work.
• Self-preference. RLHF-trained models tend to agree rather than challenge, and rate their own output higher than comparable text from elsewhere.
• Hallucinated correctness. Models repeat their generation-time reasoning errors during review instead of checking the code against the spec. The paper "Articulate but Wrong: Self-Review Failures in LLM-Based Code Modernization" documents exactly this.
• Debate amplifies bias when agents share a model. Research on bias reinforcement in LLM agent debate finds that strong self-consistency reinforces the same blind spots rather than correcting them.
• LLM-as-judge has blind spots. Production multi-turn agent studies find judges catching only a fraction of real failures.

What the research supports instead is review across different training distributions, and separating the production session from the review session so the reviewer never sees how the implementer got there. That is why step 7 withholds the reasoning narrative. Remove the anchor and the reviewer has to derive its own opinion from the spec and the diff.

Specification is the gate that makes review possible at all. Acceptance criteria written by a human before implementation are what the reviewer checks against. Without them, review has no anchor except the code itself, and code always agrees with itself.

Now the limitation, and we insist on stating it. Consensus is not proof. In roughly a quarter of cases where debating agents diverge, the minority position is the correct one, so majority rule can throw away the right answer. Cross-provider review raises review diversity. It does not mathematically guarantee fewer defects. The human gate stays.

There is a commercial side effect that finance understands immediately. Two providers means a price change, an outage or a policy shift at one vendor does not stop delivery. We apply the same hedging logic to GEO and AI SEO, so one platform's ranking shift never takes a client's whole traffic with it.

What a mid-market team gets, and what it pays

The value comes from workflow design, not from access to a stronger model. We will not tell you that AI makes development 40% cheaper. Nobody can hand you that number honestly for your codebase. What we can name is mechanisms.

• Faster discovery. Parallel inspection of a system by two agents instead of sequential reading by one engineer.
• Shorter architecture cycle. The ADR draft and its critique both arrive before senior review, so the senior engineer starts from a challenged proposal.
• More review coverage. A second independent pass on code that previously got one pass at most.
• Cheaper mechanical analysis. Dependency tracing and documentation reading stop consuming senior hours.
• Faster migrations and refactors, with engineers still owning the architecture.
• Better continuity on long tasks, because a 1M-token context holds the whole module and its history.

The cost side is real and we say so plainly. Two subscriptions. Two token bills. Two sets of tooling. Two data-processing regimes to review. And engineering time to keep the loop running. Dual-agent development is a line item, not a free upgrade.

Where the money comes back is narrow and large. Fewer wrong architectural hypotheses reaching implementation. On an ERP migration, one wrong premise caught in week two is worth more than a year of token savings.

So the budgeting rule is boring on purpose. Pilot on one module. Measure cost per completed task and rework rate. Then decide. Rolling two providers across an entire engineering org on day one is how you get a bill and no data. The same staged logic applies when we scale digital marketing in the USA: prove one channel, then fund the next.

Governance: two vendors means two of everything

Every provider you add is another data processing agreement, another subprocessor entry, another regime to reconcile. Before you compare seat prices, compare what each vendor does with your code. OpenAI does not train on Business or Enterprise content by default, and Anthropic Enterprise adds audit logs, SCIM, custom retention and customer-managed encryption keys.

The questions that decide this are not about price. Ask them in this order:

• Can access be managed centrally, with SSO and provisioning?
• What happens to corporate data, and is it used for training?
• What are the concurrent and weekly limits, and who notices when a team hits them?
• How are API workloads separated from subscription usage?
• Can AI actions be audited after the fact?
• Which of your systems can the agents actually reach?

On controls, both vendors are in a similar place at the top tier. OpenAI Enterprise adds SOC 2, end-to-end encryption, data residency, customer-managed keys, SSO and SAML, SCIM, IP allowlists, workspace policies, audit logs and role-based access control. Anthropic Team and Enterprise add shared workspaces, central billing and SSO, with Enterprise adding audit logs, SCIM, custom retention, Compliance and Analytics APIs, customer-managed keys, US-only inference, connectors and HIPAA-ready configurations for eligible organizations.

The cost of "use both" that nobody mentions is procurement. Doubled vendor due diligence, doubled DPAs, doubled subprocessor review. For a German mid-market company with a real data protection officer, that is weeks of work, not a checkbox. Budget it before you commit.

Our own non-negotiables are short. A named human engineer approves every merge. Agents have no commit rights to main. The reviewing agent gets the spec and the diff, never production credentials. Our security practice is aligned with ISO 27001 and SOC 2 principles, and we are on the path to formal certification.

When one model is enough

One model is plenty for small, well-scoped changes with a small blast radius, no migration and no integration surface. We bring in the second one where the cost of a wrong architectural hypothesis is higher than the cost of another review pass, which in practice means ERP, integrations, migrations and legacy modernization. A landing page tied to a campaign for SEO in the USA does not need that second pass.

One model is enough when the task is well scoped, the blast radius is small, an experienced engineer will read the diff anyway, or the module is simple and the budget is tight.

Astra with Codex on its own handles terminal automation, CI/CD and infrastructure scripting, batch changes across many similar modules, and browser or GUI automation on software with no API.

Fable 5.1 with Claude Code on its own handles ambiguous planning work, multi-file refactoring in context-heavy code, debugging something nobody on the team fully understands, and financial or ERP business logic.

We use both when the system is business-critical, the code touches money or compliance, the codebase is legacy and undocumented, a migration has to be proved equivalent, or a mistake is expensive to undo.

We use neither setup when it is a prototype, a throwaway internal tool, or a two-person team that will not maintain the orchestration. The cost of running two agents is real, and on the wrong project it buys you nothing. A small booking site built around appliance repair SEO is exactly that kind of project.

Talk to us before you pick a provider

Webdelo builds complex B2B software in Germany and the United States. ERP customization, system integrations, platform migration and custom business systems, with the dual-agent process described above already running in production.

Two things we can do for you. Design a safe AI-assisted development workflow inside your own engineering organization, with the governance and human gates that your compliance team will actually sign. Or run an ERP, modernization, migration or custom B2B project with this process in place from day one.

A first conversation is short and concrete. Your blast radius, your governance constraints, and which parts of your work justify two agents and which do not. Get in touch to discuss your project.

Build the engineering system, not the model shortlist

The interesting question was never which model wins. Independent testing says neither does. The question is what engineering system you build around them, and whether a human still owns the architecture.

• The honest headline is a tie. 53 against 53 on the Intelligence Index, 62 against 62 on the Coding Agent Index.
• Identical sticker prices hide two opposite economics. Astra is cheaper per completed task, Fable is cheaper on repeated large-context reads. Measure cost per completed task.
• Strengths genuinely diverge, and coding strength does not transfer to unfamiliar-domain research or architecture critique.
• Cross-provider review is supported by 2026 research, not just by our opinion. It raises review diversity. It does not guarantee fewer defects.
• For ERP, integrations, migrations and modernization, the expensive mistake is a wrong architectural hypothesis, not a slow function.

Every figure in this article is dated 11 September 2026. Both models are roughly ten days old, pricing has already moved once this month, and this comparison deserves a re-test in three months. If you are deciding now, decide on process first and providers second, and come talk to us about the part that will still be true next quarter.