Skip to main content

Claude Opus 5.5 on the Felo API: 1M Context, Cached Input, and the Real Cost of Agent Loops

· 7 min read
Felo Search Tips Buddy
Felo Search Tips Buddy
Committed to answers at your fingertips

Claude Opus 5.5 is now on the Felo API with a 1M-token context window, cached input rates, and an Anthropic-compatible Messages endpoint. Here is what caching actually does to the cost of a long-running agent.

Abstract illustration of a translucent glass cube holding thousands of stacked luminous planes with a warm coral core

A 1M-token context window means the agent stops summarizing and starts reading.

Anyone who has shipped a long-running agent knows the shape of the bill. The first request is cheap. The fiftieth request of the day costs three times as much, because by then the model is reading a system prompt, a tool schema, a working file, and everything the agent has done so far, and it reads all of it again on every single step.

Claude Opus 5.5 is now available on the Felo API. It is Anthropic's flagship route, built for multi-step changes in large codebases and long-horizon agent work. It pairs a 1M-token context window with cached input and cache-write rates, which is another way of saying: it was designed for the exact loop that makes agent bills interesting.

What Opus 5.5 is​

Model IDclaude-opus-5-5
Input$4.00 per million tokens
Output$20.00 per million tokens
Context window1M tokens
Max output128K tokens
LatencyDeep
ProtocolMessages (Anthropic-compatible)
CapabilitiesReasoning, tool calling, structured output (JSON), streaming, vision
Best forLong-horizon agents, complex coding, deep reasoning, large codebases

The specs describe a workhorse for hard problems rather than a cheap default. The pricing says the same thing: input costs four dollars per million, output twenty. What makes those numbers workable in production is everything around them: a context window large enough to stop summarizing, and cache rates that reward you for sending the same big prompt fifty times.

The Anthropic-compatible surface​

Felo's platform exposes three compatible surfaces: Chat Completions, Responses, and Messages. Opus 5.5 speaks the Messages protocol, so Claude-style clients and the official Anthropic SDK work by changing the base URL and the key. Nothing else moves.

import os
from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["FELO_API_KEY"],
    base_url="https://openapi.felo.ai/api",
)

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=8192,
    messages=[
        {
            "role": "user",
            "content": "Review this module for race conditions. Cite line numbers.",
        },
    ],
)

text = "".join(block.text for block in message.content if block.type == "text")

The same shape holds for tool use: pass tools with JSON schemas, read back tool_use blocks, return results as tool_result blocks. If you already have an agent written against the Messages API, migrating it is a base-URL change, not a rewrite.

What a 1M context actually holds​

Context windows get discussed in tokens, which is a unit nobody has intuition for. In practice, 1M tokens is somewhere around 750,000 words of English, and for engineering work the meaningful comparisons are:

  • A mid-sized service codebase, in full, with room left for the conversation
  • A quarter of incident history, or a year of design documents
  • An entire contract set, plus the correspondence around it

The practical effect is that the agent stops summarizing. Summarization is where long-horizon agents quietly fail: the model compresses 80,000 tokens of prior work into a 400-token recap, loses the detail that mattered, and confidently rebuilds the wrong thing. When the context holds the whole file instead of a description of the file, that failure mode disappears.

The 128K output ceiling matters for the same reason from the other direction. A multi-file change with tests and a summary fits in one response, so the agent does not have to leave work half-applied while it asks for a continuation.

Why caching is the difference between a demo and a production loop​

Here is the economics of a typical agent step on a large codebase. Each turn sends roughly the same 60,000-token preamble: system prompt, tool definitions, the target file, and accumulated history. The model reads all of it before generating maybe 2,000 tokens of actual work.

Without caching, you pay full input price on 60,000 tokens every turn. Over a 40-turn task, that is 2.4 million input tokens, about $9.60 at this route's rates, spent re-reading the same text.

With prompt caching, the stable prefix of that prompt is written to cache once and read back on later turns at a reduced rate. Felo lists cached input and cache-write rates for this route on the model page. The mechanic is standard: you pay a modest premium the first time a prefix is cached, then a discount on every subsequent read of it. For loops that re-send the same big context dozens of times, that flips the dominant cost term.

Two practical notes from the Felo quick start. First, the route is reasoning-capable, and the docs recommend preserving the returned reasoning metadata when continuing a conversation, so multi-turn loops do not re-derive decisions. Second, if you use a compatible SDK, set the base URL rather than hand-rolling HTTP, so streaming and tool-call parsing stay on the well-tested path.

Stacked bar chart comparing the cost of a 40-turn agent task with uncached input at $9.60 versus cached input at $2.40

The same 40-turn task, with and without prompt caching. Illustrative rates.

A worked example​

Say your agent does a dependency upgrade across a service. The task takes 30 turns. Each turn sends a 50K-token preamble and produces 1,500 output tokens.

  • Input, uncached: 30 × 50,000 = 1.5M tokens, about $6.00
  • Output: 30 × 1,500 = 45,000 tokens, about $0.90
  • With the stable prefix cached, the input side drops to a fraction of that, depending on how much of the preamble is cacheable and what the cache rates work out to on your plan

The output side, $0.90 for the whole task, is the part people usually worry about and shouldn't. Input volume is what scales with loop length, and caching is what keeps it from scaling in dollars. That is why the pairing of a 1M window with cache rates is the actual headline here, more than either number alone.

On Felo's credit system (1,000 credits = $1), Standard accounts get 200 free credits per day, and paid plans include 15,000 credits per month. That is enough free budget to run a real multi-turn task before deciding anything.

Where Opus 5.5 fits, and where it doesn't​

This is a route for the steps that are hard, not the steps that are frequent. Multi-file refactors, architecture-level reasoning over a whole repository, long-horizon agents that must remember why they made a decision forty turns ago. If a task needs deep reasoning and a big working set, the premium is the point.

For the frequent, easy steps in the same pipeline, classification, extraction, routing, short chat turns, the platform carries cheaper routes. The same API key and the same base URL reach all of them, so a sensible agent uses Opus 5.5 for the hard 10% of the work and something fast for the rest. Routing is a config change, not an integration project.

Get started​

Claude Opus 5.5 is live on the Felo API Platform. The model page carries current rates, the full parameter reference, cached input and cache-write pricing, and drop-in code for the Messages protocol:

Claude Opus 5.5 on the Felo API Platform

If you run agents that re-send the same large context, that is the workload this route was built for. Point the base URL at Felo, keep your loop, and watch what happens to the input line of the bill.