TouchGrass AI: A Local-First Outdoor AI Companion
Explore TouchGrass AI: a local-first outdoor companion that creates practical missions with open-weight AI, a fallback planner, and no cloud dependency.
Can AI Help You Put Your Phone Down? Inside TouchGrass AI
Most apps try to win more of your attention. TouchGrass AI is built for the opposite outcome: you get a solid plan, and then the app gets out of the way.
The project is a local-first outdoor activity companion. You pick your mood, how much time you have, your energy level, and what kind of activities you'd like. Then it suggests a small "mission" - a mindful walk, birdwatching, tending a garden, or some gentle movement. When an open-weight model is available, it generates the plan locally. If the model isn't installed or isn't running, a built-in planner still produces suggestions.
To me, that design is a useful case study for AI product teams: should a model be part of the core experience, and where should it run? In TouchGrass AI, the model's job is simple - tailor an activity - without trying to keep you stuck staring at a screen. This article walks through how the project works, what local inference changes, and where the trade-offs still show up.
What TouchGrass AI does
TouchGrass AI takes a handful of practical inputs - how you feel, how much time you have, your current energy, and the kinds of activities you prefer - and turns them into a realistic activity suggestion. The goal is for the output to include a duration, an appropriate difficulty level, and step-by-step instructions.
The range is intentionally broad. If you only have a few minutes and you're low on energy, you might get a gentle walk or a prompt to notice a few nearby sounds. If you have more time, you might get a nature exploration idea, a gardening task, or a longer walk. The app isn't trying to prescribe a lifestyle or claim anything about health outcomes. It's meant to reduce the friction of deciding what to do next.
When you're tired, indecision is often enough to keep you indoors. A useful suggestion has to match what's actually available - your time, your energy, and the reality of the moment. TouchGrass AI's inputs help the planner account for those constraints instead of assuming you've got a free afternoon, ideal weather, and plenty of motivation.
From a prompt to a mission
Instead of writing a detailed prompt, the user makes a few selections. Those preferences get turned into a request for the local model. The desired output is more structured than a loose list: it should name the activity, estimate a reasonable duration, set a difficulty level, and include steps to follow.
The app also asks for an alternative when going outside isn't realistic. That matters because your first choice shouldn't become a commitment. Weather, mobility, safety, time, and access to outdoor space can all change the picture. Offering an alternative keeps the experience usable instead of acting like those constraints don't exist.
The interface has a related goal, too: get you the plan and then help you leave the app. That's a different design objective than maximizing time-on-screen. TouchGrass AI isn't trying to turn "go outside" into notifications, badges, and follow-up screens. Its value is making the jump from planning to doing feel painless.
The fallback is part of the product
A local AI model is optional - it isn't the only way the app works. TouchGrass AI includes a built-in fallback planner so you still get suggestions if the model hasn't been downloaded or can't be reached.
This isn't just a demo-friendly trick. If a feature only works when an external dependency is present, it's fragile. The fallback reduces the number of conditions you need for a basic journey. You can try the experience even before setting up local inference.
There's a trade-off, though. A rules-based fallback will generally be less varied and less personalized than a language model. But predictable suggestions are often better than richer ones that fail to load. In this case, the fallback protects the core promise, while the model adds extra flexibility when it's available.
Why local-first AI changes the trade-offs
TouchGrass AI is designed without user accounts, analytics, or dependence on a third-party cloud AI service. It uses Ollama to run the open-weight llama3.2:3b model locally, with the backend talking to Ollama through its local API. In the intended flow, your activity preferences stay on your machine while a model generates the plan.
That architecture changes the privacy and operating-cost picture. A developer doesn't have to send every request to a commercial inference API, and the app doesn't depend on a provider being available or pricing staying stable for its main AI path. Users also have more control over which model runs locally, and developers can inspect and modify the prompts or test alternatives.
Those are real benefits, but they need to be stated clearly. "Local inference" isn't an automatic "no data ever leaves your device" guarantee. The app avoids certain external data flows, but users still need to understand what's installed on their device and how their environment behaves. Local software can still have bugs, and a privacy-minded design doesn't remove the need to review dependencies, permissions, and data handling.
Privacy is an architecture decision, not a label
"Local-first" only matters if it describes what the system actually does. Here, the project's stated design includes no accounts, no analytics, and no third-party cloud AI dependency. That gives users a simpler story about how data moves than apps that forward preferences to a hosted model by default.
For a product team, the practical questions are specific:
- What user inputs are collected, and are they needed for the feature?
- Which parts of the app can access those inputs?
- Does anything leave the device, including telemetry or error reporting?
- Can the core product still work if the AI model isn't available?
- Is the user clearly told where inference happens?
It's more useful to answer those questions than to slap a privacy claim on a landing page. What the app does on the network should match what it tells people. And if a future version adds cloud services, sync, or analytics, those assumptions should be revisited.
Lower API costs do not mean zero cost
Using a local open-weight model avoids per-request charges from a hosted inference API. That can matter for a small open-source project, a prototype, or a product where usage is hard to predict. It also avoids tying the basic experience to a recurring provider bill.
But "no cloud inference bill" isn't the same as "free to operate." Local models use the user's hardware, and setup can take time and technical know-how. Model downloads also cost storage and bandwidth. Developers still have to maintain the application, test model behavior, update dependencies, and support users with different machines and performance levels.
In other words, costs shift rather than disappear. For an occasional tool on a capable computer, that can be a fair trade. For a broadly distributed consumer product, installation friction and uneven hardware performance may matter more than API pricing. The right deployment choice depends on who the product serves and how much convenience you want to promise.
How the application is built
TouchGrass AI uses a straightforward web stack. Node.js and Express handle the backend, and the frontend uses HTML, CSS, and JavaScript. Ollama provides the local inference interface for llama3.2:3b. The setup keeps the UI, request handling, and model interaction separate without turning it into a huge platform dependency.
At a high level, the flow is:
- The user selects mood, available time, energy level, and preferred activity types.
- The frontend sends those preferences to the application backend.
- The backend builds a prompt requesting a realistic outdoor mission.
- The backend calls Ollama through its local API.
- If the model isn't available, the built-in planner provides an alternative suggestion.
- The user gets the plan and can leave the application to do it.
You can run the project locally by installing dependencies with npm install, starting the server with npm start, and visiting http://localhost:3000. The project's source submission on DEV links to the repository and README for setup details.
Keep the model's job narrow
A language model helps here because activity suggestions benefit from variation and context. The model can take a few selected preferences and turn them into a coherent set of steps. But the product doesn't need the model to manage accounts, track behavior, or make high-stakes decisions. Keeping the model's role narrow makes the system easier to reason about.
The prompt asks for concrete fields: duration, difficulty, instructions, and an alternative. That structure helps reduce the chance of getting something too vague to act on (like "spend time in nature"). Still, generated text isn't guaranteed to be accurate or suitable for every user. A model can suggest something impractical, overlook a constraint, or produce instructions that require judgment.
That's manageable as long as the product treats the output as a suggestion, not an authority. The user is still responsible for deciding whether an activity fits their location, physical ability, weather, and safety needs. The app should make that boundary clear - without turning a simple activity tool into something overly warning-heavy.
Reliability comes from the whole path
The useful unit isn't just the model call. It's the full journey - from opening the app to getting a suggestion you can actually use. That includes form design, request construction, model availability, response handling, and what happens when the model fails or returns something unusable.
A model response isn't enough if it's slow, comes back in a weird format, or requires setup the user can't complete. Likewise, a fallback that's coded in but hard to trigger - or that returns irrelevant content - doesn't really save the experience. These are normal product engineering concerns, but they're especially noticeable in AI features because models add another source of variability.
For an early-stage project, the described approach makes sense: keep the interface simple, make local inference possible, and keep a non-model route. The next useful step would be testing the whole experience with people on different devices, and with different levels of comfort installing and configuring local models. That's where you'd see whether the personalization gains outweigh the setup friction.
What product teams can learn from the project
TouchGrass AI is small, but the underlying question applies more broadly: should AI make the user spend more time in the product, or help them get something done and move on? The answer depends on the product - but it should be intentional. Engagement isn't automatically the same thing as value.
In this project, the "win" happens outside the interface. That changes what success metrics should mean. A long session or frequent returns isn't necessarily evidence that the product works. More relevant signals might include whether users can get a useful suggestion quickly, whether the fallback prevents dead ends, and whether people understand how the local inference part works. If the product later adds measurement, it can aim for minimal, privacy-conscious signals rather than building a profile of routines.
Open source makes experimentation more accessible
Because the project is open source, developers can inspect the implementation and adapt it. They can learn from the prompt construction, tweak the activity options, swap in other local models, or build a different interface around the same basic idea. Open-weight models also make experimentation easier without paying for every inference request.
That matters for learning and prototyping. A developer can test the interaction locally, compare model behavior, and decide whether AI adds enough value to justify its added complexity. This doesn't guarantee every deployment will be smooth or cheap - but it lowers barriers and avoids making a proprietary service the only way to get the feature.
There's also a maintenance side to openness. A public codebase doesn't maintain itself. Model changes can affect output quality, dependencies still need updating, and setup docs can drift. If the project gains users, someone has to handle support, compatibility, and safe defaults. Open source changes who can participate - but it doesn't remove operational responsibility.
A practical way to decide where AI belongs
If a team is thinking about a similar feature, a simple decision sequence can help:
- Define the user's job. If a fixed planner solves it well, start there. AI should earn its place by improving personalization, flexibility, or usefulness.
- Identify sensitive inputs. Mood and routine preferences can feel personal even if they're not "health data." Collect less than you think you need, and be clear about how you process it.
- Choose an inference location. Local execution gives users more control and avoids per-request cloud costs, but adds setup and hardware limits. Hosted inference may be easier for users, but brings provider, cost, and data-transfer dependencies.
- Design the failure path. Decide what the product does when the model is missing, slow, or returns unusable output. A fallback isn't an afterthought - it's part of the product.
- Measure the intended outcome. If the goal is to help someone act, session length is probably the wrong metric. Focus on whether users get a useful result with minimal friction.
This framework helps avoid treating "AI" as the requirement. Start with the job to be done, then compare the cost and payoff of using a model against simpler options.
Conclusion
TouchGrass AI makes a clear product choice: use AI to generate a better starting point, not to keep someone trapped inside an app. Local inference supports that direction by reducing reliance on hosted AI services, and the built-in planner ensures the experience doesn't depend entirely on a model being available.
It's not a free ride, though. Local setup, hardware differences, model output quality, and ongoing maintenance all matter. The costs are visible - and that makes them easier to weigh against the product's actual goal. That's a better starting point than adding AI just because it's fashionable.
If you're exploring local AI, start with the smallest useful workflow: define the user's task, keep data collection limited, make failure behavior explicit, and test whether a model actually improves the experience compared to a simpler planner. You can explore the TouchGrass AI project submission and its repository to see how the idea is implemented.