Addy Osmani 谈 Claude Code 的实用循环工程：goal 与 loop 的用法和边界
Addy Osmani 探讨了 Claude Code 中的循环工程实践，详细介绍了 goal 与 loop 原语的定义、用法及各自边界。文章指出，goal 适用于有明确完成标准的有界任务，而 loop 适合定时轮询或监控外部状态，同时强调人类应把控判断力而非盲目委派。
- Explore Skills
View all * Data Engineering * Data Warehouse * SQL * Apache Spark * Microsoft SQL Server * MySQL * Kafka * Data Lake * Streaming & Messaging * NoSQL Databases * Relational Databases
View all * Data Science * Pandas * R * MATLAB * SAS * D3 * Power BI * Tableau * Statistics * Exploratory Data Analysis * Data Visualization
View all * AI & ML * Generative AI * Machine Learning * Artificial Intelligence (AI) * Deep Learning * Reinforcement Learning * Natural Language Processing * TensorFlow * Scikit-Learn * Hyperparameter Tuning * MLOps
View all * Programming Languages * Java * JavaScript * Spring * Python * Go * C# * C++ * C * Swift * Rust * Functional Programming
View all * Software Architecture * Object-Oriented * Distributed Systems * Domain-Driven Design * Architectural Patterns
View all * IT/Ops * Kubernetes * Docker * GitHub * Terraform * Continuous Delivery * Continuous Integration * Database Administration * Computer Networking * Operating Systems * IT Certifications
View all * Security * Network Security * Application Security * Incident Response * Zero Trust Model * Disaster Recovery * Penetration Testing / Ethical Hacking * Governance * Malware * Security Architecture * Security Engineering * Security Certifications
View all * Design * Web Design * Graphic Design * Interaction Design * Film & Video * User Experience (UX) * Design Process * Design Tools
View all * Business * Agile * Project Management * Product Management * Marketing * Human Resources * Finance * Team Management * Business Strategy * Digital Transformation * Organizational Leadership
View all * Soft Skills * Professional Communication * Emotional Intelligence * Presentation Skills * Innovation * Critical Thinking * Public Speaking * Collaboration * Personal Productivity * Confidence / Motivation
Platform
Search for books, courses, events, and more
- Explore Skills
Explore Skills
* Cloud Computing
Cloud Computing
* [Microsoft Azure](https://www.oreilly.com/search/skills/microsoft-azure/)
* [Amazon Web Services (AWS)](https://www.oreilly.com/search/skills/amazon-web-services-aws/)
* [Google Cloud](https://www.oreilly.com/search/skills/google-cloud/)
* [Cloud Migration](https://www.oreilly.com/search/skills/cloud-migration/)
* [Cloud Deployment](https://www.oreilly.com/search/skills/cloud-deployment/)
* [Cloud Platforms](https://www.oreilly.com/search/skills/cloud-platforms/)
Back
* Data Engineering
Data Engineering
* [Data Warehouse](https://www.oreilly.com/search/skills/data-warehouse/)
* [SQL](https://www.oreilly.com/search/skills/sql/)
* [Apache Spark](https://www.oreilly.com/search/skills/apache-spark/)
* [Microsoft SQL Server](https://www.oreilly.com/search/skills/microsoft-sql-server/)
* [MySQL](https://www.oreilly.com/search/skills/mysql/)
* [Kafka](https://www.oreilly.com/search/skills/kafka/)
* [Data Lake](https://www.oreilly.com/search/skills/data-lake/)
* [Streaming & Messaging](https://www.oreilly.com/search/skills/streaming-messaging/)
* [NoSQL Databases](https://www.oreilly.com/search/skills/nosql-databases/)
* [Relational Databases](https://www.oreilly.com/search/skills/relational-databases/)
Back
* Data Science
Data Science
* [Pandas](https://www.oreilly.com/search/topics/pandas/)
* [R](https://www.oreilly.com/search/topics/r/)
* [MATLAB](https://www.oreilly.com/search/topics/matlab/)
* [SAS](https://www.oreilly.com/search/topics/sas/)
* [D3](https://www.oreilly.com/search/topics/d3/)
* [Power BI](https://www.oreilly.com/search/topics/power-bi/)
* [Tableau](https://www.oreilly.com/search/topics/tableau/)
* [Statistics](https://www.oreilly.com/search/topics/statistics/)
* [Exploratory Data Analysis](https://www.oreilly.com/search/topics/exploratory-data-analysis/)
* [Data Visualization](https://www.oreilly.com/search/topics/data-visualization/)
Back
* AI & ML
AI & ML
* [Generative AI](https://www.oreilly.com/search/skills/generative-ai/)
* [Machine Learning](https://www.oreilly.com/search/skills/machine-learning/)
* [Artificial Intelligence (AI)](https://www.oreilly.com/search/skills/artificial-intelligence-ai/)
* [Deep Learning](https://www.oreilly.com/search/skills/deep-learning/)
* [Reinforcement Learning](https://www.oreilly.com/search/skills/reinforcement-learning/)
* [Natural Language Processing](https://www.oreilly.com/search/skills/natural-language-processing/)
* [TensorFlow](https://www.oreilly.com/search/skills/tensorflow/)
* [Scikit-Learn](https://www.oreilly.com/search/skills/scikit-learn/)
* [Hyperparameter Tuning](https://www.oreilly.com/search/skills/hyperparameter-tuning/)
* [MLOps](https://www.oreilly.com/search/skills/mlops/)
Back
* Programming Languages
Programming Languages
* [Java](https://www.oreilly.com/search/skills/java/)
* [JavaScript](https://www.oreilly.com/search/skills/javascript/)
* [Spring](https://www.oreilly.com/search/skills/spring/)
* [Python](https://www.oreilly.com/search/skills/python/)
* [Go](https://www.oreilly.com/search/skills/go/)
* [C#](https://www.oreilly.com/search/skills/c-sharp/)
* [C++](https://www.oreilly.com/search/skills/c-plus-plus/)
* [C](https://www.oreilly.com/search/skills/c/)
* [Swift](https://www.oreilly.com/search/skills/swift/)
* [Rust](https://www.oreilly.com/search/skills/rust/)
* [Functional Programming](https://www.oreilly.com/search/skills/functional-programming/)
Back
* Software Architecture
Software Architecture
* [Object-Oriented](https://www.oreilly.com/search/skills/object-oriented-architecture/)
* [Distributed Systems](https://www.oreilly.com/search/skills/distributed-systems/)
* [Domain-Driven Design](https://www.oreilly.com/search/skills/domain-driven-design/)
* [Architectural Patterns](https://www.oreilly.com/search/skills/architectural-patterns/)
Back
* IT/Ops
IT/Ops
* [Kubernetes](https://www.oreilly.com/search/topics/kubernetes/)
* [Docker](https://www.oreilly.com/search/topics/docker/)
* [GitHub](https://www.oreilly.com/search/topics/github/)
* [Terraform](https://www.oreilly.com/search/topics/terraform/)
* [Continuous Delivery](https://www.oreilly.com/search/topics/continuous-delivery/)
* [Continuous Integration](https://www.oreilly.com/search/topics/continuous-integration/)
* [Database Administration](https://www.oreilly.com/search/topics/database-administration/)
* [Computer Networking](https://www.oreilly.com/search/topics/computer-networking/)
* [Operating Systems](https://www.oreilly.com/search/topics/operating-systems/)
* [IT Certifications](https://www.oreilly.com/search/topics/it-certifications/)
Back
* Security
Security
* [Network Security](https://www.oreilly.com/search/skills/network-security/)
* [Application Security](https://www.oreilly.com/search/skills/application-security/)
* [Incident Response](https://www.oreilly.com/search/skills/incident-response/)
* [Zero Trust Model](https://www.oreilly.com/search/skills/zero-trust-model/)
* [Disaster Recovery](https://www.oreilly.com/search/skills/disaster-recovery/)
* [Penetration Testing / Ethical Hacking](https://www.oreilly.com/search/skills/penetration-testing-ethical-hacking/)
* [Governance](https://www.oreilly.com/search/skills/governance/)
* [Malware](https://www.oreilly.com/search/skills/malware/)
* [Security Architecture](https://www.oreilly.com/search/skills/security-architecture/)
* [Security Engineering](https://www.oreilly.com/search/skills/security-engineering/)
* [Security Certifications](https://www.oreilly.com/search/skills/security-certifications/)
Back
* Design
Design
* [Web Design](https://www.oreilly.com/search/skills/web-design/)
* [Graphic Design](https://www.oreilly.com/search/skills/graphic-design/)
* [Interaction Design](https://www.oreilly.com/search/skills/interaction-design/)
* [Film & Video](https://www.oreilly.com/search/skills/film-video/)
* [User Experience (UX)](https://www.oreilly.com/search/skills/user-experience-ux/)
* [Design Process](https://www.oreilly.com/search/skills/design-process/)
* [Design Tools](https://www.oreilly.com/search/skills/design-tools/)
Back
* Business
Business
* [Agile](https://www.oreilly.com/search/skills/agile/)
* [Project Management](https://www.oreilly.com/search/skills/project-management/)
* [Product Management](https://www.oreilly.com/search/skills/product-management/)
* [Marketing](https://www.oreilly.com/search/skills/marketing/)
* [Human Resources](https://www.oreilly.com/search/skills/human-resources/)
* [Finance](https://www.oreilly.com/search/skills/finance/)
* [Team Management](https://www.oreilly.com/search/skills/team-management/)
* [Business Strategy](https://www.oreilly.com/search/skills/business-strategy/)
* [Digital Transformation](https://www.oreilly.com/search/skills/digital-transformation/)
* [Organizational Leadership](https://www.oreilly.com/search/skills/organizational-leadership/)
Back
* Soft Skills
Soft Skills
* [Professional Communication](https://www.oreilly.com/search/skills/professional-communication/)
* [Emotional Intelligence](https://www.oreilly.com/search/skills/emotional-intelligence/)
* [Presentation Skills](https://www.oreilly.com/search/skills/presentation-skills/)
* [Innovation](https://www.oreilly.com/search/skills/innovation/)
* [Critical Thinking](https://www.oreilly.com/search/skills/critical-thinking/)
* [Public Speaking](https://www.oreilly.com/search/skills/public-speaking/)
* [Collaboration](https://www.oreilly.com/search/skills/collaboration/)
* [Personal Productivity](https://www.oreilly.com/search/skills/personal-productivity/)
* [Confidence / Motivation](https://www.oreilly.com/search/skills/confidence-motivation/)
Back
Back
- Platform
Platform
* [All features](https://www.oreilly.com/online-learning/features.html)
* [Verifiable skills](https://www.oreilly.com/online-learning/verifiable-skills.html)
* [Academies](https://www.oreilly.com/online-learning/academies.html)
* [Courses](https://www.oreilly.com/online-learning/courses.html)
* [Certifications](https://www.oreilly.com/online-learning/feature-certification.html)
* [Interactive learning](https://www.oreilly.com/online-learning/intro-interactive-learning.html)
* [Live events](https://www.oreilly.com/online-learning/live-events.html)
* [Virtual conferences](https://www.oreilly.com/products/superstreams.html)
* [Answers](https://www.oreilly.com/online-learning/feature-answers.html)
* [Insights reporting](https://www.oreilly.com/online-learning/insights-dashboard.html)
Back
Search for books, courses, events, and more
Toggle dark mode
AI & MLBusinessDataInnovationResearchSecurity
Try the O’Reilly learning platform
With the O’Reilly learning platform, you get the resources and guidance to keep your skills sharp and stay ahead. Try it free for up to 14 days.
Try a course for free
Join a live online event on the O’Reilly platform to learn from the experts shaping tech.
Get the Radar Trends newsletter
Your email
Country
Subscribe
Please read our privacy policy.
Thank you for subscribing to the O’Reilly Radar Trends to Watch newsletter.
Practical Loop Engineering
Goals, loops, and the discipline of not delegating your judgment
By Addy OsmaniNovember 2, 2026 • 15 minute read
Share
CloseLinkedInXFacebookThreadsBlueskyReddit
The following article originally appeared onAddy Osmani’s Elevate blogand is being republished here with the author’s permission.
The way that I typically work is I have anywhere between five and ten agents working at the same time in parallel. There are going to be some tasks that I’m very happy to delegate fully to agents, as long as I have a very clear idea of the stopping conditions and the constraints around them. And then there are going to be some tasks where I am going to want to keep a closer eye on and code-review what the agent is doing.
You’ve probably heard about loop engineering. I talked about it a couple of months ago when I wrote a big blog post about it.
A loop is an autonomous, self-correcting feedback cycle where an AI agent repeatedly acts, tests its results, and adjusts its approach until a specific goal is met.
There are now basically two core primitives you can think about. In Claude Code you have a goalprimitive, which can drive a single bounded task forward until you’ve got a particular goal, like a measurable finish line that’s been met. And then loop reruns on a timer or a fixed interval, so you can use it to schedule changes.
Before the primitives were primitives
I remember back before we had primitives baked into Claude Code and Codex: Loop engineering was heavily about setting up your own bash loop, a hand-rolled thing. That’s how I approached it. And you might remember earlier in the year, a number of us were playing around with the Ralph loop by Geoff Huntley. We were experimenting, we were sharing our workflows, we were sharing what worked and what didn’t, but it was largely on some of our personal projects where, if we ran into a wall, it didn’t really have a big cost to us.
And as we’ve tried to see what patterns and what aspects of loop engineering are now a little bit more baked, I think we have a clearer idea of how you babysit it. I can now largely rely on the output of the primitives in Claude Code and Codex. We’ve come a little way. But at the same time we need to be very diligent, because loop engineering, where you kind of leave it sitting alone and haven’t really thought about whether the end goal or the constraints have been well defined, can leave you in a problematic state. This is why there’s nuance when deciding to use it for an evergreen codebase without users or without as much historical complexity as a brownfield bank codebase.
How the Claude Code team frames loops
The Claude Code team published their take on four kinds of loops, and it lines up with how I use the primitives (their write-up). Before we get to it, here’s my quick summary:
On the Claude Code team, we define loops as agents repeating cycles of work until a stop condition is met. We categorize a few different types of loops based on how they are triggered, how they are stopped, what Claude Code primitive is used, what type of task is most appropriate for each. Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.
Every prompt you send starts a manual loop with you directing each turn. Claude gathers context, takes action, checks its work, repeats if needed, and responds. We call this the agentic loop. For example, ask Claude to create a “Like” button. It reads your code, makes the edit, runs the tests, and hands back something it believes works. You then manually check the work, and write the next prompt.
Their write-up walks each rung.
On goal-based loops:
Sometimes, a single turn is not enough, especially for more complex tasks. Agents do better when they can iterate. You can extend how long Claude keeps iterating by defining what done looks like with /goal. When you define the success criteria, Claude doesn’t have to make a determination on what is “good enough” and end the loop early. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or a number of turns you define is reached. This is why deterministic criteria, such as number of tests passed or clearing a certain score threshold, are so effective. For example: /goal Get the homepage Lighthouse score to 90 or above, stop after 5 tries.
On time-based loops:
Some agentic work is recurring: the task stays the same and only the inputs change. For example, summarizing Slack messages every morning. Other work depends on external systems, and a simple way to interface with one is to check it on an interval and react to what changed. For example a PR, which may receive code reviews or fail CI. For these, you can trigger when Claude runs with /loop, which reruns a prompt on an interval. For example: /loop 5m check my PR, address review comments, and fix failing CI. /loop runs on your computer, so if you turn it off, it stops. You can move the loop to the cloud by creating a routine with /schedule.
And on proactive loops, the top rung:
Triggered by an event or schedule, with no human in real time. Stop criteria: each task exits when its goal is met. The routine itself runs until you turn it off. Best used for recurring streams of well-defined work: bug reports, issue triage, migrations, dependency upgrades. Managed usage by routing routines to smaller, faster models and using the most capable model for judgment calls.
Their verification advice is worth lifting whole, because it moves the manual checking into something Claude applies itself:
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input,
toggle): click it, confirm the expected state change, and screenshot
before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit
Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 - do not hand
back partially verified work.
Goal
The way that I use goal is for building any specific piece of work until it’s proveably done. For example, you can use a goal to say: “Make sure that this experience loads in five seconds, keep going until it’s done.” And it will continue to use an independent evaluation check to keep checking if the completion criteria has been met. What’s better is to be even more specific about what tooling is being used.
As for real goals that I’ve run to a number, there’s a few things that I’ve done. I’ve used goals for running through GitHub issues: “Review and close the last 10 issues,” or “Review and move the last 10 issues forward,” something like that. And that’s semi-open-ended, right? Or “Let’s make this page load 50% faster.” Sometimes that works well, sometimes it doesn’t, but it’s really about the experimentation.
Loop
Loop is a little bit more of a scheduler, so it keeps an eye on something or repeatedly executes a pattern on some cadence. Think of it a little bit like a cron. It’s best for doing things like polling logs or monitoring external states. You could use it for potentially checking in. If there are repetitive tasks you find yourself doing on some cadence, loop is pretty good for that.
What I delegate, and what I watch
I use probably between five and ten agents every day. Typically I’ll max out at about five concurrently. And some of those tasks might be ones that are a little bit safer. So maybe it’s: “Hey, I implemented this feature, go write the documentation for it.” Or “Go double check that we have sufficient test coverage.” Or something in that vein. If I’m working on a more complex problem, and I’ve given it a good spec, or what I think is a good spec, and tried to give it some stopping conditions, there’s still a reasonable chance it may not get everything right, so I would try to watch it more closely. If the task involves anything just a little bit sensitive, whether it is “I’ve given this access to a system,” or whether the feature happens to touch authentication, or something related to security or finance, I’ll definitely be watching that closely.
Generally speaking, I do think we’re going to get to a place where folks are increasingly comfortable with delegation, as long as they’re able to have these clear ways of verifying that their goal or their stopping condition has been met. But you do still need to take a look at the code, at the thing that’s being generated, to make sure that it’s meeting your mark.
The other habit that matters is not letting the agent that did the work decide the work is good. One subagent drafts the change; a separate one verifies it.
Sometimes an agent can be confident about something, and a verifying agent can catch things that are unexpected. If an agent thinks that the baseline performance of an experience it has generated is actually fine, but it’s only evaluating performance based on desktop, and you actually care about the experience on mobile, that might mean the agent is being very confident about one dimension of the problem but not the other.
And I learned this one the hard way. I was curious to figure out: Is there something that we’re missing that we haven’t gotten direct feedback on from our users, either in an issue tracker or in a comment somewhere? And so I asked it to go and take a look at some of our competitors and put together a list, and some PRs, not pushed, but some PRs locally, of what solving some of those gaps might look like. And I almost pushed some of those changes. But I didn’t actually look at them closely enough. I read through its research, but I didn’t look at the implementations closely enough. So I delegated the task, but I was close to delegating the judgment as well. When I actually looked through the changes, what I realized is that it would introduce a lot of additional complexity for our users, for, I thought, not all that much gain. And so I feel like you need to sometimes check that you are not delegating the taste and the judgment to your agent. You’re delegating the task, and then you are actually checking back that it’s meeting your bar.
The evaluator sitting behind goal is not that checker, by the way. It doesn’t look at the content to see if it’s good or bad in any way, shape, or form. All it does is examine the conversation transcript to see if the hard rules you specified have been met.
/goal Refactor the data-fetching layer in Dashboard.tsx until
Lighthouse performance score is >= 92 and LCP is under 1.8s as
shown by the Lighthouse CLI output. Do not change the public API
of any hooks. Each turn must improve at least one reported metric;
abort if two consecutive turns show no improvement. Stop after 10 turns.
The workflow I run every day
One of the workflows that I do every day: I have a popular open source repository called Agent Skills. We’ve got over 80,000 stars, and up until recently we were getting anywhere from 80 or 90 pull requests that we had to review a day. And so every day I would go and spend some time checking on this. Now with loop, what you can do is say: “Well, every 24 hours or every 12 hours check the GitHub repository for any new open issues and provide a summary of their urgency,” or “Provide a first pass review,” or anything like that.
/loop every 1h "Check the GitHub repository for any new open issues.
Provide a bulleted summary of their urgency."
Combining loops and goals
Now you can also sort of combine loops and goals. So you use loop to schedule a check, and then goal to solve the problem. So you can say something like: “Loop for every 24 hours, check GitHub for issues labeled bug. If one exists, use goal to implement a fix until all local tests pass and push the branch.”
/loop every 24h "Check GitHub for issues labeled 'bug'. If one exists,
use /goal to implement a fix until all local tests pass and push the branch."
But also keep in mind that goal has got some limitations around just how much you can cram in there.
Claude Code team’s write-up also has a composed example that shows where this is all heading:
The primitives above, along with other Claude Code features like auto mode and dynamic workflows (research preview) can be composed into a loop for long-running work. For example, to handle incoming feedback, you can use: /schedule (research preview) to run a routine that checks for new reports, /goal to define what done looks like, and skills to document how to verify it. Dynamic workflows to orchestrate agents that triage each report, fix it, and review the fix. Auto mode so the routine runs without stopping to ask for permission. Putting it together, a prompt could look like this: /schedule every hour: check the project-feedback channel for bug reports. /goal: don’t stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.
What the triage system actually does
Inside the PR triage, when I have loops and goals working together for me, what I end up having is a system that allows me to continue accepting PRs and issues, being able to stay on top of what is coming on my plate every day, and especially being able to cross-reference. That’s been a really big deal for me. If I want to work on a particular goal of, “Hey, we’re going to be redoing this part of the system,” and I need to make sure that any issues that happen to touch it are closed as a result of this rework, or that we’re not stepping on anyone else’s toes, I can make sure that that’s well defined.
Scheduled tasks are really useful for regularly just reviewing new PRs and closing things that clearly don’t fit. One good stopping condition, for example: We have a set of contribution guidelines, and our contribution guidelines include things like, “Hey, we currently don’t accept translations.”
And it’s not that we don’t care, it’s that they’re difficult for us to maintain because we don’t speak all the languages that often come in. And so if we tell it to close any issues or close any PRs that happen to touch that aspect of our contribution guidelines, that’s something that can do really well when it’s on that schedule. And so it reduces the overall batch of things that we need to review.
What loops don’t buy you
I’m often asked what loop engineering is not a great fit for. Generally speaking, if you don’t have a clear idea of what the end-state/done/good means for your completion, it may not be the right pattern for your work. For example, a vague goal would be “Keep going until this UI design is good.” What does that mean? Good to who? How is it being evaluated? Tasks that require human taste, subjective design, or open-ended creative exploration aren’t a good fit. When you have a pretty clear idea of the goal, I think loops are a good option to consider.
The fine print
One classic sign that you’ve got a loop spinning in place is the same command being tried over and over without any change in the result. Give the same command a third time with no change from the second and it’s probably time to stop.
One bit of fine print worth knowing: Recurring loops expire seven days after creation. I’d been telling people it was three days. It’s seven. And loops are session-scoped, so they stop when you start a new conversation, though resuming that session with –resume or –continue brings back any recurring task still inside its seven-day window. If you need something that outlives your session, /schedule runs it in the cloud.
If there’s a check you already run every morning by hand, that’s your first loop. Mine was the pull request pile.
Post topics: AI & ML
Explore related articles
article AI & ML ## Loop Engineering By Addy Osmani | June 22, 2026
article AI & ML ## Own the Outer Loop By Addy Osmani | September 9, 2026
Follow us
About O'Reilly
- Teach/Write/Train
- Careers
- O'Reilly News
- Media Coverage
- Community Partners
- Affiliate Program
- Diversity
- Content Sponsorship
Support
International
Download the O'Reilly App
Take O'Reilly with you and learn anywhere, anytime on your phone and tablet.
Do not sell or share my personal information.
© 2026, O'Reilly Media, Inc. All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
Close Previous
Next
Privacy Preference Center
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
More information
Enable All
Manage Consent Preferences
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
View Vendor Details
Performance Cookies
Always Active
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
View Vendor Details
Functional Cookies
Always Active
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
View Vendor Details
Targeting Cookies
Always Active
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
View Vendor Details
Vendors List
Clear
- checkbox label label
Apply Cancel
Consent Leg.Interest
checkbox label label
checkbox label label
checkbox label label
Reject All Confirm
来源：O'Reilly Radar · oreilly.com